[要約] RFC 8393は、Next Protocol "None"を使用してネットワークサービスヘッダ（NSH）を操作するためのガイドラインです。このRFCの目的は、NSHを使用してネットワークサービスを提供するための手順と要件を定義することです。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8393 J. Drake
Category: Standards Track Juniper Networks
ISSN: 2070-1721 May 2018
Operating the Network Service Header (NSH) with Next Protocol "None"
次のプロトコル「なし」でのネットワークサービスヘッダー（NSH）の操作
Abstract
概要
This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".
このドキュメントでは、ペイロードデータなしでメタデータのみを伝送するネットワークサービスヘッダー（NSH）を使用してサービス機能チェーン（SFC）をサポートするネットワークについて説明します。これは、「None」という新しいNSHの「Next Protocol」タイプの値を定義することによって実現されます。
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.
このドキュメントでは、このメカニズムによって実現または強化される可能性のあるいくつかの機能について説明しますが、ユースケースの完全なリストを提供するものではなく、説明する機能について決定的なものでもありません。他のドキュメントで特定のユースケースをより詳細に説明し、各ユースケースのプロトコルメカニズムを定義することが期待されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8393.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8393で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. The Network Service Header . . . . . . . . . . . . . . . . . 4
3.1. Next Protocol "None" . . . . . . . . . . . . . . . . . . 4
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
6. Overview of Use Cases . . . . . . . . . . . . . . . . . . . . 6
6.1. Per-SFP Metadata . . . . . . . . . . . . . . . . . . . . 6
6.2. Per-Flow Metadata . . . . . . . . . . . . . . . . . . . . 7
6.3. Coordination between SFC-Aware SFIs . . . . . . . . . . . 7
6.4. Operations, Administration, and Maintenance (OAM) . . . . 8
6.5. Control-Plane and Management-Plane Uses . . . . . . . . . 8
6.6. Non-applicable Use Cases . . . . . . . . . . . . . . . . 9
7. Management and Congestion Control Considerations . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
An architecture for Service Function Chaining (SFC) is presented in [RFC7665]. That architecture enables packets to be forwarded along Service Function Paths (SFPs) to pass through various Service Functions (SFs) that act on the packets. Each packet is encapsulated with a Network Service Header (NSH) [RFC8300] that identifies the SFP that the packet travels along (by means of a Service Path Identifier -- SPI) and the hop (i.e., the next SF to be executed) along the SFP that the packet has reached (by means of a Service Index -- SI). The SPI and SI are fields encoded in the NSH.
Service Function Chaining（SFC）のアーキテクチャは[RFC7665]に示されています。このアーキテクチャにより、パケットはService Function Path（SFP）に沿って転送され、パケットに作用するさまざまなService Function（SF）を通過できます。各パケットは、パケットが通過する（サービスパス識別子-SPIによって）SFPとホップ（つまり、次に実行されるSF）を識別するネットワークサービスヘッダー（NSH）[RFC8300]でカプセル化されます。パケットが到達したSFP（サービスインデックス-SIによる）。 SPIとSIは、NSHでエンコードされたフィールドです。
Packets are classified at the SFC network ingress boundaries by classifiers (Section 4.4 of [RFC7665]) and have an NSH applied to them. Such packets are forwarded between Service Function Forwarders (SFFs) using tunnels across the underlay network, and each SFF may hand the packet off to one or more Service Function Instances (SFIs) according to the definition of the SFP.
パケットは、分類子（[RFC7665]のセクション4.4）によってSFCネットワークの入力境界で分類され、NSHが適用されます。このようなパケットは、アンダーレイネットワークを介してトンネルを使用してサービス機能フォワーダー（SFF）間で転送され、各SFFは、SFPの定義に従って1つ以上のサービス機能インスタンス（SFI）にパケットを渡すことができます。
The SFC classifier or any SFC-aware SFI may wish to share information (possibly state information) about the SFP, the traffic flow, or a specific packet, and they may do this by adding metadata to packets as part of the NSH. Metadata may be used to enhance or enable the function performed by SFC-aware SFs, may enable coordination and data exchange between SFIs, or may be used to assist a network operator in the diagnosis and monitoring of an SFP. The nature of metadata to be supplied and consumed is implementation- and deployment-specific.
SFC分類子またはSFC対応のSFIは、SFP、トラフィックフロー、または特定のパケットに関する情報（状態情報の可能性があります）を共有したい場合があり、NSHの一部としてメタデータをパケットに追加することでこれを行うことができます。メタデータは、SFC対応のSFによって実行される機能を強化または有効化するために使用されたり、SFI間の調整およびデータ交換を可能にしたり、SFPの診断および監視においてネットワークオペレーターを支援したりするために使用されます。提供および消費されるメタデータの性質は、実装固有およびデプロイメント固有です。
This document defines a mechanism for metadata to be carried on an SFP without the need for payload data. This mechanism enables diagnosis and monitoring of SFPs, and coordination between SFC-aware SFIs. The mechanism can be applied without the need for traffic to be flowing; if traffic is flowing, it can be applied without the need to insert what might be substantial amounts of metadata into data packets (an operation that may be costly in some hardware).
このドキュメントでは、ペイロードデータを必要とせずに、SFPでメタデータを伝送するメカニズムを定義しています。このメカニズムにより、SFPの診断と監視、およびSFC対応のSFI間の調整が可能になります。このメカニズムは、トラフィックを流す必要なく適用できます。トラフィックが流れている場合は、相当量のメタデータをデータパケットに挿入することなく適用できます（一部のハードウェアではコストがかかる操作）。
This document describes how this function is achieved through the use of a new value for the NSH "Next Protocol" field to indicate "None". Like any NSH packets, such packets are contained within the SFC-enabled domain.
このドキュメントでは、NSHの「次のプロトコル」フィールドに「なし」を示す新しい値を使用してこの機能を実現する方法について説明します。他のNSHパケットと同様に、そのようなパケットはSFC対応ドメイン内に含まれています。
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes (see Section 6).
このドキュメントは、このメカニズムによって実現または強化される可能性のある機能の一部を示していますが、ユースケースの完全なリストを提供するものではなく、それが説明する機能についての決定的なものでもありません（セクション6を参照）。
This document uses the terms defined in [RFC7665] and [RFC8300].
このドキュメントでは、[RFC7665]と[RFC8300]で定義されている用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The NSH includes a field called "Next Protocol" that is used to indicate the nature of the payload data that follows the NSH. The field can be used by any component that processes the NSH (for example, to understand how to interpret and parse the payload) and by nodes at the end of the SFP that remove the NSH and forward the payload data.
NSHには、NSHに続くペイロードデータの性質を示すために使用される「次のプロトコル」と呼ばれるフィールドが含まれています。このフィールドは、NSHを処理するコンポーネント（たとえば、ペイロードを解釈および解析する方法を理解するため）と、NSHを削除してペイロードデータを転送するSFPの最後のノードで使用できます。
This document defines a new value (0x00) for the "Next Protocol" field to indicate that the next protocol is "None", which means that there is no user/payload data following the NSH.
このドキュメントでは、「次のプロトコル」フィールドに新しい値（0x00）を定義して、次のプロトコルが「なし」であることを示します。これは、NSHの後にユーザー/ペイロードデータがないことを意味します。
When the next protocol is "None", the rest of the NSH still has meaning; in particular, the metadata carried in the NSH may still be present. It is not intended that a packet with next protocol set to "None" be sent with no metadata (see Section 4). Thus, an SFC-aware node SHOULD NOT create a packet with "Next Protocol" set to "None", Metadata Type set to 0x2, and with an NSH Length of 0x2.
次のプロトコルが「なし」の場合でも、NSHの残りの部分には意味があります。特に、NSHで伝送されるメタデータがまだ存在する場合があります。次のプロトコルが「なし」に設定されたパケットがメタデータなしで送信されることは意図されていません（セクション4を参照）。したがって、SFC対応ノードは、「次のプロトコル」が「なし」に設定され、メタデータタイプが0x2に設定され、NSHの長さが0x2のパケットを作成するべきではありません（SHOULD NOT）。
A packet with no payload data may be inserted at the head end of an SFP (such as at a classifier) and may be easily forwarded by an SFF or SFI on the SFP using the processing rules defined in [RFC8300].
ペイロードデータのないパケットは、SFPのヘッドエンド（分類子など）に挿入でき、[RFC8300]で定義された処理ルールを使用して、SFPのSFFまたはSFIによって簡単に転送できます。
A packet with no payload may also be generated by an SFC-aware SFI as a result of processing an incoming packet (i.e., triggered by a condition arising from processing a normal NSH packet with a payload). In such cases, the SPI/SI can be inherited from the original packet or can be set according to information supplied in one of three ways:
ペイロードのないパケットは、着信パケットの処理の結果としてSFC対応のSFIによって生成される場合もあります（つまり、ペイロードのある通常のNSHパケットの処理から生じる条件によってトリガーされます）。このような場合、SPI / SIは元のパケットから継承するか、次の3つの方法のいずれかで提供される情報に従って設定できます。
o through the control plane,
o コントロールプレーンを介して
o through the management plane, or
o 管理プレーンを介して、または
o through information carried in the metadata of the data packet.
o データパケットのメタデータで運ばれる情報を通して。
This document does not further specify the triggers to generate an NSH packet with a "Next Protocol" set to "None".
このドキュメントでは、「次のプロトコル」が「なし」に設定されたNSHパケットを生成するトリガーをさらに指定していません。
An SFC-aware node wishing to send metadata without a data packet (i.e., a node that conforms to this specification):
データパケットなしでメタデータを送信したいSFC対応ノード（つまり、この仕様に準拠するノード）：
o MUST create a packet carrying an NSH and the desired metadata.
o NSHと必要なメタデータを含むパケットを作成する必要があります。
o MUST set the "Next Protocol" field to 0x00.
o 「Next Protocol」フィールドを0x00に設定する必要があります。
o SHOULD ensure that there are no bytes following the end of the NSH (i.e., that there is no payload data).
o NSHの終わりの後にバイトがないこと（つまり、ペイロードデータがないこと）を確認する必要があります。
o MUST encapsulate and send the packet as normal for tunneling to the next hop on the SFP as would be done for any NSH packet (i.e., for a data packet following the SFP).
o 通常のようにパケットをカプセル化して送信し、NSHパケット（つまり、SFPに続くデータパケット）の場合と同様に、SFPのネクストホップにトンネリングする必要があります。
A transit node (SFF, SFI, or classifier) that conforms to this specification and that receives a packet with "Next Protocol" indicating "None" MUST NOT attempt to parse or process beyond the end of the NSH, but it SHOULD process the NSH and the metadata as normal. Processing for nodes that do not support "Next Protocol" set to "None" is described in Section 5. Note, however, that an intermediate node that is instructed to strip all metadata from packets will create a packet with an NSH but no metadata and no payload. Such packets SHOULD NOT continue to be forwarded along the SFP.
この仕様に準拠し、「なし」を示す「次のプロトコル」のパケットを受信する中継ノード（SFF、SFI、または分類子）は、NSHの終わりを超えて解析または処理を試みてはならないが、NSHを処理する必要がある（SHOULD）メタデータは通常どおりです。 「Next Protocol」が「None」に設定されていないノードの処理については、セクション5で説明します。ただし、パケットからすべてのメタデータを削除するように指示された中間ノードは、NSHを含むパケットを作成しますが、メタデータはありません。ペイロードはありません。そのようなパケットは、SFPに沿って転送され続けるべきではありません。
A node that is the egress of an SFP would normally strip the NSH and forward the payload according to the setting of the "Next Protocol" field. Such nodes MUST NOT forward packets with "Next Protocol" indicating "None" even if there are some bytes after the NSH.
SFPの出口であるノードは通常、NSHを取り除き、「次のプロトコル」フィールドの設定に従ってペイロードを転送します。そのようなノードは、NSHの後にいくつかのバイトがある場合でも、「次のプロトコル」が「なし」を示すパケットを転送してはなりません（MUST NOT）。
In deployments where use of next protocol "None" is not desired, administrators SHOULD instruct SFC-aware nodes to not create such packets and to discard packets with next protocol "None".
次のプロトコル「なし」の使用が望ましくない展開では、管理者はSFC対応ノードにそのようなパケットを作成せず、次のプロトコル「なし」のパケットを破棄するように指示する必要があります。
SFC-aware nodes that do not understand the meaning of a value contained in the "Next Protocol" field of the NSH are unable to parse the payload. Such nodes silently drop packets with unknown "Next Protocol" values unless explicitly configured to forward them (Section 2.2 of [RFC8300]).
NSHの「次のプロトコル」フィールドに含まれる値の意味を理解していないSFC対応ノードは、ペイロードを解析できません。そのようなノードは、明示的にそれらを転送するように構成されていない限り（[RFC8300]のセクション2.2）、不明な「次のプロトコル」値を持つパケットを静かにドロップします
This means that legacy SFC-aware nodes that are unaware of the meaning of the "Next Protocol" value "None" will act as follows:
これは、「次のプロトコル」の値「なし」の意味を認識しないレガシーSFC対応ノードが次のように機能することを意味します。
o SFFs can be configured to forward the packets.
o パケットを転送するようにSFFを構成できます。
o SFC proxies will drop the packets.
o SFCプロキシはパケットをドロップします。
o SFIs will most likely drop the packets.
o SFIはおそらくパケットをドロップします。
o Classifiers (i.e., nodes performing reclassification) will most likely drop the packets.
o 分類子（つまり、再分類を実行するノード）は、パケットをドロップする可能性が最も高くなります。
SFC-aware nodes at the end of an SFP possibly forward packets with no knowledge of the payload in a "pop and forward" form of processing where the NSH is removed, the packet is simply put on an interface, and the payload protocol is known a priori (or assumed). It is a general processing rule for all packet forwarding engines that they should not attempt to send packets with zero length. Packets with the NSH "Next Protocol" field set to "None" are expected to have zero payload length and so should not be forwarded once the NSH has been stripped. In any case, as noted in Section 4, SFC-aware nodes at the end of an SFP do not forward packets with "Next Protocol" set to "None".
SFPの最後にあるSFC対応ノードは、NSHが削除され、パケットがインターフェイスに置かれ、ペイロードプロトコルが既知である「ポップアンドフォワード」形式の処理で、ペイロードを認識せずにパケットを転送する可能性があります。アプリオリ（または仮定）。長さがゼロのパケットを送信しようとしないのは、すべてのパケット転送エンジンの一般的な処理規則です。 NSHの「次のプロトコル」フィールドが「なし」に設定されているパケットは、ペイロード長がゼロであることが想定されているため、NSHが削除された後は転送しないでください。いずれの場合も、セクション4で説明したように、SFPの最後のSFC対応ノードは、「次のプロトコル」が「なし」に設定されているパケットを転送しません。
Per-SFP metadata is metadata that applies to an SFP and any data packets on that SFP. It does not need to be transmitted with every packet, but it can be installed at the points of consumption (such as at SFIs) and applied to all packets on the SFP as they pass through this point. It could be installed by inclusion in the NSH of a data packet sent on the SFP by out-of-band control- or management-plane mechanisms, or by separate metadata-only packets using "Next Protocol" set to "None" as described in this document.
SFPごとのメタデータは、SFPおよびそのSFP上のすべてのデータパケットに適用されるメタデータです。すべてのパケットで送信する必要はありませんが、消費ポイント（SFIなど）にインストールして、SFP上のすべてのパケットがこのポイントを通過するときに適用できます。帯域外のコントロールプレーンまたは管理プレーンメカニズムによって、SFPで送信されたデータパケットをNSHに含めることによって、または「次のプロトコル」を「なし」に設定して説明されているように個別のメタデータのみのパケットを使用してインストールできます。このドキュメントで。
Per-SFP metadata-only packets may be sent along the path of an SFP simply by setting the correct SPI in the NSH, and setting the SI to the correct value for the hop of the SFP at which the metadata is to be introduced. SFC-aware nodes (e.g., classifiers) will know the correct SI values to be used from information supplied by the control or management plane as is the case for NSH packets with payload data.
SSHごとのメタデータのみのパケットは、NSHで正しいSPIを設定し、SIを、メタデータが導入されるSFPのホップの正しい値に設定するだけで、SFPのパスに沿って送信できます。 SFC対応ノード（分類子など）は、ペイロードデータを含むNSHパケットの場合と同様に、コントロールプレーンまたは管理プレーンによって提供される情報から使用される正しいSI値を認識します。
Per-flow metadata is metadata that applies to a subset of the packets on an SFP, such as packets matching a particular 5-tuple of source address, destination address, source port, destination port, and payload protocol. Also, this metadata does not need to be transmitted with every packet, but it can be installed at the SFIs on the SFP and applied to the packets that match the flow description.
フローごとのメタデータは、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、ペイロードプロトコルの特定の5タプルに一致するパケットなど、SFP上のパケットのサブセットに適用されるメタデータです。また、このメタデータをすべてのパケットで送信する必要はありませんが、SFPのSFIにインストールして、フローの説明と一致するパケットに適用できます。
If there is just one flow on an SFP, then there is no difference between per-flow metadata and per-SFP metadata as described in Section 6.1.
セクション6.1で説明されているように、SFPにフローが1つしかない場合、フローごとのメタデータとSFPごとのメタデータの間に違いはありません。
In normal processing, the flow to which per-flow metadata applies can be deduced by looking at the payload data in the context of the value of the "Next Protocol" field. However, when "Next Protocol" indicates "None", this cannot be done. In this case, the identity of the flow is carried in the metadata itself.
通常の処理では、フローごとのメタデータが適用されるフローは、「Next Protocol」フィールドの値のコンテキストでペイロードデータを確認することで推定できます。ただし、「次のプロトコル」が「なし」の場合はできません。この場合、フローのIDはメタデータ自体に含まれます。
A pair of SFC-aware SFIs (adjacent or not) on an SFP may desire to coordinate state and may do this by sending information encoded in metadata.
SFP上の1組のSFC対応SFI（隣接するかどうかにかかわらず）は状態を調整したい場合があり、メタデータにエンコードされた情報を送信することでこれを行うことができます。
To do this using the mechanisms defined in this document:
このドキュメントで定義されているメカニズムを使用してこれを行うには：
o There must be an SFP that passes through the two SFIs in the direction of sender to receiver.
o 送信側から受信側の方向に2つのSFIを通過するSFPが必要です。
o The sender must know the correct SPI to use.
o 送信者は、使用する正しいSPIを知っている必要があります。
o The sender must know the correct SI to use for the point at which it resides on the SFP.
o 送信側は、SFPに存在するポイントに使用する正しいSIを知っている必要があります。
o Ideally, the receiver will know to remove the packet from the SFP and not forward it further as this might share metadata wider than desirable and would cause unnecessary packets in the network. Note, however, that continued forwarding of such packets would not be substantially harmful in its own right.
o 理想的には、レシーバーはSFPからパケットを削除し、それを転送しないことを知っています。これにより、メタデータが望ましい範囲よりも広く共有され、ネットワークで不要なパケットが発生する可能性があるためです。ただし、そのようなパケットの継続的な転送は、それ自体では実質的に有害ではないことに注意してください。
Note that technically (according to the SFC architecture) the process of inserting a packet into an SFP is performed by a classifier. However, a classifier may be co-resident with an SFI so that an implementation of an SF may also be able to generate NSH packets as described in this document.
技術的には（SFCアーキテクチャーに従って）、パケットをSFPに挿入するプロセスは分類子によって実行されることに注意してください。ただし、分類子はSFIと共存できるため、SFの実装は、このドキュメントで説明されているようにNSHパケットを生成することもできます。
Note also that a system with SFIs that need to coordinate between each other may be configured so that there is a specific, dedicated SFP between those service functions that is used solely for this purpose. Thus, such an SFI does not need to insert NSH packets onto SFPs used to carry payload data, but it can use (and know the SPI of) this special, dedicated SFP.
また、相互に調整する必要があるSFIを備えたシステムは、この目的のためにのみ使用されるサービス機能間に特定の専用SFPが存在するように構成されている場合があることに注意してください。したがって、このようなSFIは、ペイロードデータの伝送に使用されるSFPにNSHパケットを挿入する必要はありませんが、この特別な専用SFPを使用できます（SPIを知っています）。
Requirements for Operations, Administration, and Maintenance (OAM) in SFC networks are discussed in [SFC-OAM-FRAME]. The NSH definition in [RFC8300] includes an O bit that indicates that the packet contains OAM information.
SFCネットワークの運用、管理、保守（OAM）の要件については、[SFC-OAM-FRAME]で説明されています。 [RFC8300]のNSH定義には、パケットにOAM情報が含まれていることを示すOビットが含まれています。
If OAM information is carried in packets that also include payload data, that information might be carried between the NSH and the payload. Therefore, the mechanism defined in this document can also be used to carry OAM information independent of payload data.
OAM情報がペイロードデータも含むパケットで運ばれる場合、その情報はNSHとペイロードの間で運ばれる可能性があります。したがって、このドキュメントで定義されているメカニズムは、ペイロードデータとは関係なくOAM情報を伝送するためにも使用できます。
Sending OAM separate from (but interleaved with) packets that carry payload data may have several advantages including:
ペイロードデータを運ぶパケットとは別に（ただしインターリーブされた）OAMを送信すると、次のようないくつかの利点があります。
o Sending OAM when there is no other traffic flowing.
o 他のトラフィックフローがないときにOAMを送信します。
o Sending OAM at predictable intervals.
o 予測可能な間隔でOAMを送信する。
o Measuring path qualities distinct from behavior of SFIs.
o SFIの動作とは異なるパス品質の測定。
o Sending OAM without needing to rewrite payload data buffers.
o ペイロードデータバッファを書き換えることなくOAMを送信する。
o Keeping OAM processing components separate from other processing components.
o OAM処理コンポーネントを他の処理コンポーネントから分離する。
Mechanisms for providing active OAM [RFC7799] in an SFC network have been proposed [OAM-SFC]. This use case is not intended to define another mechanism for active OAM, but it does illustrate a further option for discussion by the working group.
SFCネットワークでアクティブOAM [RFC7799]を提供するメカニズムが提案されています[OAM-SFC]。この使用例は、アクティブなOAMの別のメカニズムを定義することを意図したものではありませんが、ワーキンググループによる議論のためのさらなるオプションを示しています。
As described in Section 6.3, SFPs can be established specifically to carry metadata-only packets. And as described in Section 6.1, metadata-only packets can be sent down existing SFPs. This means that metadata-only packets can be used to carry control-plane and management-plane messages used to control and manage the SFC network.
セクション6.3で説明したように、SFPはメタデータのみのパケットを伝送するために特別に確立できます。セクション6.1で説明したように、メタデータのみのパケットは既存のSFPに送信できます。これは、メタデータのみのパケットを使用して、SFCネットワークの制御と管理に使用されるコントロールプレーンと管理プレーンのメッセージを伝送できることを意味します。
In effect, SFPs can be established to serve as a Data Control Network (DCN) or a Management Control Network (MCN). Further details of this process are out of scope for this document, but it should be understood that, just as for OAM, an essential feature of using a control channel is that the various speakers are assigned identifiers (i.e., addresses). In this case, those identifiers could be SPI/SI pairs or could be IP addresses as used in the normal control and management plane of the SFC network.
実際、SFPはデータ制御ネットワーク（DCN）または管理制御ネットワーク（MCN）として機能するように確立できます。このプロセスの詳細はこのドキュメントの範囲外ですが、OAMの場合と同様に、制御チャネルを使用するための重要な機能は、さまざまなスピーカーに識別子（アドレスなど）が割り当てられることです。この場合、これらの識別子はSPI / SIペアであるか、SFCネットワークの通常の制御および管理プレーンで使用されるIPアドレスである可能性があります。
Per-packet metadata is metadata that applies specifically to a single payload packet. It informs an SFI how to handle the payload packet and does not apply to any other packet.
パケットごとのメタデータは、単一のペイロードパケットに特に適用されるメタデータです。ペイロードパケットの処理方法をSFIに通知し、他のパケットには適用されません。
The mechanisms described in this document are not applicable to per-packet metadata because, by definition, if the "Next Protocol" indicates "None", then there is no packet following the NSH for the metadata to be associated with.
定義により、「次のプロトコル」が「なし」を示す場合、メタデータが関連付けられるNSHに続くパケットはないため、このドキュメントで説明されているメカニズムはパケットごとのメタデータには適用できません。
The mechanisms described in this document allow SFC-aware nodes in an SFC network to generate additional packets. These are not intended to be sent frequently for any flow, but there is still a risk that they might flood the network. For example, if an attempt is made to use this mechanism for "per-packet metadata" (see Section 6.6) then this might double the number of packets in the network. Similarly, if this mechanism is used for a form of aliveness detection OAM that requires very frequent test messages, then the number of additional messages may be very high. Such additional messages risk causing congestion in the network.
このドキュメントで説明するメカニズムにより、SFCネットワークのSFC対応ノードが追加のパケットを生成できます。これらは任意のフローで頻繁に送信されることを意図していませんが、ネットワークをフラッディングする可能性があるというリスクがまだあります。たとえば、このメカニズムを「パケットごとのメタデータ」（セクション6.6を参照）に使用しようとすると、ネットワーク内のパケット数が2倍になる可能性があります。同様に、このメカニズムが、非常に頻繁なテストメッセージを必要とする活性検出OAMの形式に使用される場合、追加のメッセージの数が非常に多くなる可能性があります。このような追加のメッセージは、ネットワークで輻輳を引き起こすリスクがあります。
The underlay network (that is, the tunnels across the underlay between SFC nodes) will not distinguish between data-carrying packets and those packets with "Next Protocol" set to "None". All packets will be treated the same and will need to fall within the capabilities of the underlay network to process and forward packets.
アンダーレイネットワーク（つまり、SFCノード間のアンダーレイを横切るトンネル）は、データを運ぶパケットと、「次のプロトコル」が「なし」に設定されているパケットを区別しません。すべてのパケットは同じように扱われ、パケットを処理して転送するために、アンダーレイネットワークの機能内に収まる必要があります。
Nodes in the SFC overlay network will need to perform special processing on the additional packets according to their roles and according to the application for the metadata. For example, an SFF will likely only have to forward per-SFP metadata, while an SF will need to extract it and process it as it would if the metadata was carried in a packet with user data. On the other hand, metadata might also be used to cause actions at all nodes (see Sections 6.3, 6.4, and 6.5) and could increase the processing load.
SFCオーバーレイネットワークのノードは、役割とメタデータのアプリケーションに応じて、追加のパケットに対して特別な処理を実行する必要があります。たとえば、SFFはSFPごとのメタデータのみを転送する必要がある可能性がありますが、SFはメタデータがユーザーデータと一緒にパケットで運ばれた場合と同様に、抽出して処理する必要があります。一方、メタデータはすべてのノードでアクションを引き起こすためにも使用される場合があり（セクション6.3、6.4、および6.5を参照）、処理の負荷が増加する可能性があります。
In view of these potential issues, all implementations SHOULD implement rate limits on the generation of per-SFP packets with "Next Protocol" set to "None". Furthermore, these rate limits SHOULD be configurable and applied per SFP and per application so that one application on one SFP does not encumber a different application on this or a different SFP. When an implementation finds that it is unable to generate or send a packet, it SHOULD increment a counter that is accessible by the operator and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
これらの潜在的な問題を考慮して、すべての実装は、「次のプロトコル」が「なし」に設定されたSFPごとのパケットの生成にレート制限を実装する必要があります。さらに、これらのレート制限は構成可能であり、SFPごとおよびアプリケーションごとに適用される必要があります。これにより、1つのSFP上の1つのアプリケーションが、このアプリケーションまたは別のSFP上の別のアプリケーションを妨げることはありません。実装がパケットを生成または送信できないことがわかった場合、オペレーターがアクセスできるカウンターをインクリメントする必要があり（SHOULD）、アラートを発生させることができます（ただし、そのようなアラート自体はレート制限する必要があります（SHOULD））。
Additionally, an SFC node needs to protect itself against another node in the network not applying suitable rate limits. Therefore, implementations SHOULD apply incoming rate limits for SFC packets with "Next Protocol" set to "None". Such rate limits MAY be application aware, per SFC or interface, and SHOULD be configurable, but implementations MAY be more subtle if they are aware of internal processing loads and have access to queues/buffers. In any case, when an implementation drops a received packet because of these rate limits, it SHOULD increment a counter that is accessible by the operator and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
さらに、SFCノードは、適切なレート制限を適用しないネットワーク内の別のノードから自分自身を保護する必要があります。したがって、実装では、「次のプロトコル」が「なし」に設定されたSFCパケットに着信レート制限を適用する必要があります。そのようなレート制限は、SFCまたはインターフェースごとにアプリケーション対応であり、構成可能である必要があります（SHOULD）が、実装が内部処理負荷を認識し、キュー/バッファにアクセスできる場合、実装はより微妙な場合があります。いずれの場合でも、これらのレート制限のために実装が受信パケットをドロップすると、オペレーターがアクセスできるカウンターをインクリメントする必要があり（SHOULD）、アラートを発生させることができます（ただし、そのようなアラート自体はレート制限する必要があります（SHOULD））。
Suitable default rate limits will restrict an SFC node to not send more than one packet with "Next Protocol" set to "None" per ten data packets on any flow in a unit of time equal to the end-to-end delivery time on the flow.
適切なデフォルトのレート制限により、SFCノードは、次のプロトコルのエンドツーエンドの配信時間に等しい時間単位で、フローのデータパケットごとに「次のプロトコル」が「なし」に設定された複数のパケットを送信しないように制限されます。フロー。
Metadata-only packets as enabled by this document provide a covert channel. However, this is only different from the metadata feature in the normal NSH in that it can be sent without the presence of a data flow.
このドキュメントで有効になっているメタデータのみのパケットは、隠れチャネルを提供します。ただし、これは、データフローがなくても送信できるという点で、通常のNSHのメタデータ機能とは異なります。
Metadata may, of course, contain sensitive data and may also contain information used to control the behavior of SFIs in the network. As such, this data needs to be protected according to its value and according to the perceived vulnerabilities of the network. Protection of metadata may be achieved by using encrypted transport between SFC entities or by encrypting the metadata in its own right, and by authenticating the sender of the metadata. The need to protect the metadata is not modified by this document and forms part of the NSH definition found in [RFC8300].
もちろん、メタデータには機密データが含まれる場合があり、ネットワーク内のSFIの動作を制御するために使用される情報が含まれる場合もあります。そのため、このデータは、その価値と、ネットワークの認識された脆弱性に従って保護する必要があります。メタデータの保護は、SFCエンティティ間で暗号化されたトランスポートを使用するか、メタデータ自体を暗号化し、メタデータの送信者を認証することで実現できます。メタデータを保護する必要性はこのドキュメントによって変更されず、[RFC8300]にあるNSH定義の一部を形成します。
The mechanism described in this document might be used to introduce packets into the SFC overlay network and might be used to illegitimately introduce false metadata to the nodes on an SFC.
このドキュメントで説明されているメカニズムは、SFCオーバーレイネットワークにパケットを導入するために使用される可能性があり、SFC上のノードに不正なメタデータを不正に導入するために使用される可能性があります。
Therefore, measures SHOULD be taken to ensure authorization of sources of such packets, and tunneling of such packets into the network SHOULD be prevented.
したがって、そのようなパケットの送信元の承認を確実にするための対策を講じるべきであり、そのようなパケットのネットワークへのトンネリングは防止されるべきです（SHOULD）。
The amount of packets with "Next Protocol" set to "None" on an SFP SHOULD be rate limited at each point on the SFP to provide additional network security.
SFPで「次のプロトコル」が「なし」に設定されているパケットの量は、追加のネットワークセキュリティを提供するために、SFPの各ポイントでレート制限する必要があります（SHOULD）。
Further discussion of NSH security is presented in [RFC8300].
NSHセキュリティの詳細については、[RFC8300]で説明されています。
IANA maintains a registry called "Network Service Header (NSH) Parameters" with a sub-registry called "NSH Next Protocol". IANA has allocated a new value to the sub-registry as follows:
IANAは、「ネットワークサービスヘッダー（NSH）パラメータ」と呼ばれるレジストリを「NSH次のプロトコル」と呼ばれるサブレジストリで管理しています。 IANAは、次のように新しい値をサブレジストリに割り当てました。
Next Protocol | Description | Reference
---------------+---------------+-------------
0x00 | None | RFC 8393
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、and C. Pignataro、Ed。、 "Network Service Header（NSH）"、RFC 8300、DOI 10.17487 / RFC8300、January 2018、<https： //www.rfc-editor.org/info/rfc8300>。
[OAM-SFC] Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-Layer Active OAM for Service Function Chains in Networks", Work in Progress, draft-wang-sfc-multi-layer-oam-10, September 2017.
[OAM-SFC] Mirsky、G.、Meng、W.、Khasnabish、B。、およびC. Wang、「ネットワークのサービス機能チェーン用の多層アクティブOAM」、作業中、draft-wang-sfc-multi -layer-oam-10、2017年9月。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「アクティブおよびパッシブメトリックおよびメソッド（中間のハイブリッドタイプを使用）」、RFC 7799、DOI 10.17487 / RFC7799、2016年5月、<https://www.rfc-editor.org/info / rfc7799>。
[SFC-OAM-FRAME] Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, R., and A. Ghanwani, "Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework", Work in Progress, draft-ietf-sfc-oam-framework-04, March 2018.
[SFC-OAM-FRAME] Aldrin、S.、Pignataro、C.、Kumar、N.、Akiya、N.、Krishnan、R。、およびA. Ghanwani、「Service Function Chaining（SFC）Operation、Administration and Maintenance（ OAM）Framework」、Work in Progress、draft-ietf-sfc-oam-framework-04、2018年3月。
Acknowledgements
謝辞
Thanks to the attendees at the SFC interim meeting in Westford, Massachusetts in January 2017 for discussions that suggested the value of this document.
2017年1月にマサチューセッツ州ウェストフォードで開催されたSFC中間会議の参加者に、この文書の価値を示唆する議論をありがとうございました。
Thanks to Eric Rosen, Med Boucadair, Greg Mirsky, Dave Dolson, Tal Mizrahi, and Mirja Kuehlewind for valuable review comments.
貴重なレビューコメントを提供してくれたEric Rosen、Med Boucadair、Greg Mirsky、Dave Dolson、Tal Mizrahi、Mirja Kuehlewindに感謝します。
Contributors
貢献者
Lucy Yong Retired
引退したルーシー・ヨン
Authors' Addresses
著者のアドレス
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
Email: afarrel@juniper.net
John Drake Juniper Networks
ジョンドレイクジュニパーネットワークス
Email: jdrake@juniper.net