[要約] RFC 8595は、サービス機能チェイニングのためのMPLSベースの転送プレーンに関する仕様です。このRFCの目的は、MPLSを使用して効率的かつ柔軟なサービスチェイニングを実現することです。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8595 Old Dog Consulting
Category: Standards Track S. Bryant
ISSN: 2070-1721 Futurewei
J. Drake
Juniper Networks
June 2019
An MPLS-Based Forwarding Plane for Service Function Chaining
サービス機能チェーン用のMPLSベースの転送プレーン
Abstract
概要
This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.
このドキュメントでは、MPLSラベルスタックのネットワークサービスヘッダー（NSH）の論理表現により、MPLSネットワークでサービス機能チェーン（SFC）を実現する方法について説明します。つまり、NSHは使用されませんが、NSHのフィールドはMPLSラベルスタックのフィールドにマップされます。このアプローチはNSHを非推奨にしたり置き換えたりするものではありませんが、ブラウンフィールドネットワークでのSFC機能の暫定的な展開が必要になる可能性があることを認めています。
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/rfc8595.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8595で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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. Choice of Data-Plane SPI/SI Representation ......................4
4. Use Case Scenarios ..............................................5
4.1. Label Swapping for Logical NSH .............................5
4.2. Hierarchical Encapsulation .................................5
4.3. Fine Control of Service Function Instances .................6
4.4. Micro Chains and Label Stacking ............................6
4.5. SFC and Segment Routing ....................................6
5. Basic Unit of Representation ....................................6
6. MPLS Label Swapping .............................................7
7. MPLS Label Stacking ............................................10
8. Mixed-Mode Forwarding ..........................................12
9. A Note on Service Function Capabilities and SFC Proxies ........13
10. Control-Plane Considerations ..................................14
11. Use of the Entropy Label ......................................14
12. Metadata ......................................................15
12.1. Indicating Metadata in User Data Packets .................16
12.2. In-Band Programming of Metadata ..........................18
12.2.1. Loss of In-Band Metadata ..........................21
13. Worked Examples ...............................................22
14. Implementation Notes ..........................................26
15. Security Considerations .......................................26
16. IANA Considerations ...........................................28
17. References ....................................................29
17.1. Normative References .....................................29
17.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract Service Functions (SFs) before being delivered to the intended destination. An architecture for SFC is defined in [RFC7665].
Service Function Chaining（SFC）は、ネットワークを介してパケットを転送するプロセスであり、目的の宛先に配信される前に、順序付けされた一連の抽象サービス機能（SF）によってパケットを処理できます。 SFCのアーキテクチャは[RFC7665]で定義されています。
When applying a particular service function chain to the traffic selected by a service classifier, the traffic needs to be steered through an ordered set of SFs in the network. This ordered set of SFs is termed a Service Function Path (SFP), and the traffic is passed between Service Function Forwarders (SFFs) that are responsible for delivering the packets to the SFs and for forwarding them onward to the next SFF.
特定のサービス機能チェーンをサービス分類子によって選択されたトラフィックに適用する場合、トラフィックはネットワーク内の順序付けられたSFのセットを介して誘導される必要があります。この順序付けられたSFのセットはサービス機能パス（SFP）と呼ばれ、トラフィックは、SFにパケットを配信し、次のSFFに転送するサービス機能フォワーダー（SFF）間で渡されます。
In order to steer the selected traffic between SFFs and to the correct SFs, the service classifier needs to attach information to each packet. This information indicates the SFP on which the packet is being forwarded and hence the SFs to which it must be delivered. The information also indicates the progress the packet has already made along the SFP.
選択したSFF間のトラフィックを正しいSFに導くために、サービス分類子は各パケットに情報を添付する必要があります。この情報は、パケットが転送されているSFPを示しているため、パケットの配信先のSFを示しています。この情報は、パケットがSFPに沿ってすでに行った進行状況も示しています。
The Network Service Header (NSH) [RFC8300] has been defined to carry the necessary information for SFC in packets. The NSH can be inserted into packets and contains various information, including a Service Path Identifier (SPI), a Service Index (SI), and a Time To Live (TTL) counter.
ネットワークサービスヘッダー（NSH）[RFC8300]は、SFCに必要な情報をパケットで運ぶように定義されています。 NSHはパケットに挿入でき、Service Path Identifier（SPI）、Service Index（SI）、Time To Live（TTL）カウンターなどのさまざまな情報を含みます。
Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed forwarding technology that uses labels placed in a packet in a label stack to identify the forwarding actions to be taken at each hop through a network. Actions may include swapping or popping the labels as well as using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. In many cases, MPLS will be used as a tunneling technology to carry packets through networks between SFFs.
マルチプロトコルラベルスイッチング（MPLS）[RFC3031]は、ラベルスタックのパケットに配置されたラベルを使用して、ネットワークの各ホップで実行される転送アクションを識別する、広く展開されている転送テクノロジーです。アクションには、ラベルのスワッピングまたはポップ、およびラベルを使用してパケットを転送する次のホップを決定することが含まれます。ラベルは、パケットが転送されるコンテキストを確立するためにも使用できます。多くの場合、MPLSは、SFF間のネットワークを介してパケットを伝送するトンネリングテクノロジーとして使用されます。
This document describes how SFC can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. This approach is applicable to all forms of MPLS forwarding (where labels are looked up at each hop and are swapped or popped [RFC3031]). It does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The mechanisms described in this document are a compromise between the full function that can be achieved using the NSH and the benefits of reusing the existing MPLS forwarding paradigms (the approach defined here does not include the O bit defined in [RFC8300] and has some limitations to the use of metadata as described in Section 12).
このドキュメントでは、MPLSラベルスタックのNSHの論理表現を使用して、MPLSネットワークでSFCを実現する方法について説明します。このアプローチは、MPLSフォワーディングのすべての形式に適用できます（ラベルは各ホップで検索され、スワップまたはポップされます[RFC3031]）。 NSHの廃止や置き換えは行いませんが、ブラウンフィールドネットワークでのSFC機能の暫定的な展開が必要になる可能性があることを認めています。このドキュメントで説明されているメカニズムは、NSHを使用して実現できるすべての機能と、既存のMPLS転送パラダイムを再利用することの利点との間の妥協です（ここで定義されているアプローチには、[RFC8300]で定義されているOビットが含まれておらず、いくつかの制限がありますセクション12）で説明されているメタデータの使用。
Section 4 provides a short overview of several use case scenarios that help to explain the relationship between the MPLS label operations (swapping, popping, stacking) and the MPLS encoding of the logical NSH described in this document.
セクション4では、MPLSラベル操作（スワッピング、ポップ、スタック）と、このドキュメントで説明する論理NSHのMPLSエンコーディングとの関係を説明するのに役立ついくつかのユースケースシナリオの概要を説明します。
It is assumed that the reader is fully familiar with the terms and concepts introduced in [RFC7665] and [RFC8300].
[RFC7665]と[RFC8300]で導入された用語と概念を読者が完全に理解していることを前提としています。
Note that one of the features of the SFC architecture described in [RFC7665] is the "SFC proxy", which exists to include legacy SFs that are not able to process NSH-encapsulated packets. This issue is equally applicable to the use of MPLS-encapsulated packets that encode a logical representation of an NSH. It is discussed further in Section 9.
[RFC7665]で説明されているSFCアーキテクチャの機能の1つは「SFCプロキシ」であり、NSHカプセル化パケットを処理できないレガシーSFを含めるために存在することに注意してください。この問題は、NSHの論理表現をエンコードするMPLSカプセル化パケットの使用にも同様に当てはまります。これについては、セクション9でさらに説明します。
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]で説明されているように解釈されます。
While [RFC8300] defines the NSH that can be used in a number of environments, this document provides a mechanism to handle situations in which the NSH is not ubiquitously deployed. In this case, it is possible to use an alternative data-plane representation of the SPI/SI by carrying the identical semantics in MPLS labels.
[RFC8300]は多くの環境で使用できるNSHを定義していますが、このドキュメントは、NSHがユビキタスに展開されていない状況を処理するメカニズムを提供します。この場合、MPLSラベルで同一のセマンティクスを伝達することにより、SPI / SIの代替データプレーン表現を使用することが可能です。
In order to correctly select the mechanism by which SFC information is encoded and carried between SFFs, it may be necessary to configure the capabilities and choices either within the whole Service Function Overlay Network or on a hop-by-hop basis. It is a requirement that both ends of a tunnel over the underlay network (i.e., a pair of SFFs adjacent in the SFP) know that the tunnel is used for SFC and know what form of NSH representation is used. A control-plane signaling approach to achieve these objectives is provided using BGP in [BGP-NSH-SFC].
SFC情報がエンコードされてSFF間で伝送されるメカニズムを正しく選択するために、サービス機能オーバーレイネットワーク全体またはホップバイホップベースで機能と選択を構成する必要がある場合があります。アンダーレイネットワーク上のトンネルの両端（つまり、SFPで隣接するSFFのペア）は、トンネルがSFCに使用されていること、およびどの形式のNSH表現が使用されているかを知っている必要があります。これらの目的を達成するためのコントロールプレーンシグナリングアプローチは、[BGP-NSH-SFC]のBGPを使用して提供されます。
Note that the encoding of the SFC information is independent of the choice of tunneling technology used between SFFs. Thus, an MPLS representation of the logical NSH (as defined in this document) may be used even if the tunnel between a pair of SFFs is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself).
SFC情報のエンコーディングは、SFF間で使用されるトンネリングテクノロジーの選択とは無関係であることに注意してください。したがって、SFFのペア間のトンネルがMPLSトンネルでない場合でも、（このドキュメントで定義されている）論理NSHのMPLS表現を使用できます。逆に、MPLSトンネルは、論理NSH（具体的には、NSH自体）の他のエンコーディングを伝送するために使用できます。
There are five scenarios that can be considered for the use of an MPLS encoding in support of SFC. These are set out in the following subsections.
SFCをサポートするMPLSエンコーディングの使用を検討できるシナリオは5つあります。これらについては、次のサブセクションで説明します。
The primary use case for SFC is described in [RFC7665] and delivered using the NSH, which, as described in [RFC8300], uses an encapsulation with a position indicator that is modified at each SFC hop along the chain to indicate the next hop.
SFCの主な使用例は[RFC7665]で説明されており、NSHを使用して配信されます。NSHは、[RFC8300]で説明されているように、チェーンに沿った各SFCホップで変更される位置インジケーター付きのカプセル化を使用して、次のホップを示します。
The label-swapping use case scenario effectively replaces the NSH with an MPLS encapsulation as described in Section 6. The MPLS labels encode the same information as the NSH to form a logical NSH. The labels are modified (swapped per [RFC3031]) at each SFC hop along the chain to indicate the next hop. The processing and the forwarding state for a chain (i.e., the actions to take on a received label) are programmed into the network using a control plane or management plane.
ラベルスワッピングのユースケースシナリオでは、セクション6で説明するように、NSHをMPLSカプセル化で効果的に置き換えます。MPLSラベルは、NSHと同じ情報をエンコードして論理NSHを形成します。ラベルは、次のホップを示すために、チェーンに沿った各SFCホップで変更されます（[RFC3031]に従ってスワップされます）。チェーンの処理と転送状態（つまり、受信したラベルに対して実行するアクション）は、コントロールプレーンまたは管理プレーンを使用してネットワークにプログラムされます。
[RFC8459] describes an architecture for hierarchical encapsulation using the NSH. It facilitates partitioning of SFC domains for administrative reasons and allows concatenation of service function chains under the control of a service classifier.
[RFC8459]は、NSHを使用した階層的なカプセル化のアーキテクチャについて説明しています。管理上の理由からSFCドメインの分割を容易にし、サービス分類子の制御下でサービス機能チェーンを連結できるようにします。
The same function can be achieved in an MPLS network using an MPLS encoding of the logical NSH, and label stacking as defined in [RFC3031] and described in Section 7. In this model, swapping is used per Section 4.1 to navigate one chain, and when the end of the chain is reached, the final label is popped, revealing the label for another chain. Thus, the primary mode is swapping, but stacking is used to enable the ingress classifier to control concatenation of service function chains.
[RFC3031]で定義され、セクション7で説明されているように、論理NSHのMPLSエンコーディングとラベルスタッキングを使用して、MPLSネットワークで同じ機能を実現できます。このモデルでは、セクション4.1に従ってスワッピングを使用して1つのチェーンをナビゲートします。チェーンの最後に到達すると、最後のラベルがポップされ、別のチェーンのラベルが表示されます。したがって、プライマリモードはスワッピングですが、スタッキングを使用して、入力分類子がサービス機能チェーンの連結を制御できるようにします。
It may be that a service function chain (as described in Section 4.1) allows some leeway in the choice of service function instances along the chain. However, it may be that a service classifier wishes to constrain the choice and this can be achieved using chain concatenation so that the first chain ends at the point of choice, the next label in the stack indicates the specific service function instance to be executed, and the next label in the stack starts a new chain. Thus, a mixture of label swapping and stacking is used.
（セクション4.1で説明されているように）サービス関数チェーンにより、チェーンに沿ったサービス関数インスタンスの選択にある程度の余裕ができる場合があります。ただし、サービス分類子が選択を制約したいと考えている可能性があり、これは最初のチェーンが選択したポイントで終了するようにチェーン連結を使用して達成でき、スタック内の次のラベルは実行される特定のサービス関数インスタンスを示します。スタックの次のラベルが新しいチェーンを開始します。したがって、ラベルの交換とスタッキングの混合が使用されます。
The scenario in Section 4.2 may be extended to its logical extreme by making each concatenated chain as short as it can be: one SF. Each label in the stack indicates the next SF to be executed, and the network is programmed through the control plane or management plane to know how to route to the next (i.e., first) hop in each chain just as it would be to support the scenarios in Sections 4.1 and 4.2.
セクション4.2のシナリオは、連結された各チェーンを可能な限り短くすることにより、論理的に極端に拡張できます。1つのSF。スタック内の各ラベルは、実行される次のSFを示し、ネットワークは、コントロールプレーンまたは管理プレーンを介してプログラムされ、各チェーンの次の（つまり、最初の）ホップにルーティングする方法を知っています。セクション4.1および4.2のシナリオ。
This scenario is functionally identical to the use of Segment Routing (SR) in an MPLS network (known as SR-MPLS) for SFC, as described in Section 4.5, and the discussion in that section applies to this section as well.
このシナリオは、SFCのMPLSネットワーク（SR-MPLSとして知られている）でのセグメントルーティング（SR）の使用と機能的に同じであり、4.5節で説明されており、そのセクションの説明はこのセクションにも適用されます。
SR-MPLS uses a stack of MPLS labels to encode information about the path and network functions that a packet should traverse. SR-MPLS is achieved by applying control-plane and management-plane techniques to program the MPLS forwarding plane and by imposing labels on packets at the entrance to the SR-MPLS network. An implementation proposal for achieving SFC using SR-MPLS can be found in [SR-Srv-Prog] and is not discussed further in this document.
SR-MPLSは、MPLSラベルのスタックを使用して、パケットが通過するパスおよびネットワーク機能に関する情報をエンコードします。 SR-MPLSは、コントロールプレーンおよび管理プレーンの技術を適用してMPLSフォワーディングプレーンをプログラムし、SR-MPLSネットワークの入口でパケットにラベルを付けることによって実現されます。 SR-MPLSを使用してSFCを実現するための実装提案は[SR-Srv-Prog]にあり、このドキュメントではこれ以上説明しません。
When an MPLS label stack is used to carry a logical NSH, a basic unit of representation is used. This unit comprises two MPLS labels, as shown below. The unit may be present one or more times in the label stack as explained in subsequent sections.
MPLSラベルスタックを使用して論理NSHを伝送する場合、基本的な表現単位が使用されます。このユニットは、次に示すように2つのMPLSラベルで構成されています。ユニットは、以降のセクションで説明するように、ラベルスタックに1回以上存在する可能性があります。
In order to convey the same information as is present in the NSH, two MPLS label stack entries are used. One carries a label to provide context within the SFC scope (the SFC Context Label), and the other carries a label to show which SF is to be actioned (the SF Label). This two-label unit is shown in Figure 1.
NSHに存在するのと同じ情報を伝達するために、2つのMPLSラベルスタックエントリが使用されます。 1つはSFCスコープ内でコンテキストを提供するためのラベル（SFCコンテキストラベル）を持ち、もう1つはアクションが実行されるSFを示すラベル（SFラベル）を持ちます。この2ラベルのユニットを図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFC
図1：SFCのMPLSラベルスタックの基本単位
The fields of these two label stack entries are encoded as follows:
これら2つのラベルスタックエントリのフィールドは、次のようにエンコードされます。
Label: The Label fields contain the values of the SFC Context Label and the SF Label encoded as 20-bit integers. The precise semantics of these Label fields are dependent on whether the label stack entries are used for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7).
ラベル：ラベルフィールドには、20ビット整数としてエンコードされたSFCコンテキストラベルとSFラベルの値が含まれます。これらのラベルフィールドの正確なセマンティクスは、MPLSラベルスワッピング（セクション6を参照）またはMPLSラベルスタッキング（セクション7を参照）にラベルスタックエントリを使用するかどうかによって異なります。
TC: The TC bits have no meaning in this case. They SHOULD be set to zero in both label stack entries when a packet is sent and MUST be ignored on receipt.
TC：この場合、TCビットは意味を持ちません。パケットが送信されるとき、それらは両方のラベルスタックエントリでゼロに設定する必要があり（SHOULD）、受信時に無視する必要があります。
S: The "Bottom of Stack" bit has its usual meaning in MPLS. It MUST be clear in the SFC Context Label stack entry. In the SF Label stack entry, it MUST be clear in all cases except when the label is the bottom of the stack, when it MUST be set.
S：「スタックの最下位」ビットは、MPLSでは通常の意味を持っています。 SFCコンテキストラベルスタックエントリで明確にする必要があります。 SFラベルスタックエントリでは、ラベルがスタックの最下部である場合と、設定する必要がある場合を除いて、すべてのケースで明確でなければなりません。
TTL: The TTL field in the SFC Context Label stack entry SHOULD be set to 1. The TTL in the SF Label stack entry (called the SF TTL) is set according to its use for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7) and is used to mitigate packet loops.
TTL：SFCコンテキストラベルスタックエントリのTTLフィールドは1に設定する必要があります（SF TTLと呼ばれる）SFラベルスタックエントリのTTLは、MPLSラベルスワップ（セクション6を参照）またはMPLSラベルの使用に従って設定されますスタッキング（セクション7を参照）。パケットループを軽減するために使用されます。
The sections that follow show how this basic unit of MPLS label stack may be used for SFC in the MPLS label-swapping case and in the MPLS label-stacking case. For simplicity, these sections do not describe the use of metadata; that topic is covered separately in Section 12.
次のセクションでは、MPLSラベルスタックのこの基本ユニットを、MPLSラベルスワップの場合とMPLSラベルスタックの場合にSFCに使用する方法を示します。簡単にするために、これらのセクションではメタデータの使用については説明していません。このトピックについては、セクション12で個別に説明します。
This section describes how the basic unit of MPLS label stack for SFC (introduced in Section 5) is used when MPLS label swapping is in use. The use case scenario for this approach is introduced in Section 4.1.
このセクションでは、MPLSラベルスワッピングが使用されている場合に、SFCのMPLSラベルスタックの基本ユニット（セクション5で紹介）がどのように使用されるかについて説明します。このアプローチのユースケースシナリオは、セクション4.1で紹介されています。
As can be seen in Figure 2, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS in UDP, MPLS in GRE, and MPLS in Virtual Extensible Local Area Networks (VXLANs) or the Generic Protocol Extension for VXLAN (GPE)); thus, the tunnel technology does not need to be MPLS, but MPLS is shown here for simplicity.
図2からわかるように、ラベルスタックの最上部には、SFF間のMPLSトンネルを介してパケットを配信するために必要なラベルが含まれています。任意のMPLSカプセル化を使用できます（つまり、MPLS、UDPのMPLS、GREのMPLS、仮想拡張ローカルエリアネットワーク（VXLAN）のMPLS、またはVXLAN（GPE）のGeneric Protocol Extension）。したがって、トンネルテクノロジーはMPLSである必要はありませんが、ここではMPLSを簡略化のために示しています。
An entropy label [RFC6790] may also be present, as described in Section 11.
セクション11で説明されているように、エントロピーラベル[RFC6790]が存在する場合もあります。
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+ - - -
| SPI Label |
+---------------+ Basic unit of MPLS label stack for SFC
| SI Label |
+---------------+ - - -
| |
~ Payload ~
| |
---------------
Figure 2: The MPLS SFC Label Stack
図2：MPLS SFCラベルスタック
Under these labels (or other encapsulation) comes a single instance of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries (provided in Section 5), the following meanings are applied:
これらのラベル（または他のカプセル化）の下には、SFCのMPLSラベルスタックの基本ユニットの単一インスタンスが付属しています。これらのラベルスタックエントリのフィールドの解釈（セクション5で提供）に加えて、次の意味が適用されます。
SPI Label: The Label field of the SFC Context Label stack entry contains the value of the SPI encoded as a 20-bit integer. The semantics of the SPI are exactly as defined in [RFC8300]. Note that an SPI as defined by [RFC8300] can be encoded in 3 octets (i.e., 24 bits), but that the Label field allows for only 20 bits and reserves the values 0 through 15 as "special-purpose labels" [RFC7274]. Thus, a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16.
SPIラベル：SFCコンテキストラベルスタックエントリのラベルフィールドには、20ビット整数としてエンコードされたSPIの値が含まれます。 SPIのセマンティクスは、[RFC8300]で定義されているとおりです。 [RFC8300]で定義されているSPIは3オクテット（つまり、24ビット）でエンコードできますが、Labelフィールドは20ビットしか許可せず、0〜15の値を「専用ラベル」として予約していることに注意してください[RFC7274] 。したがって、論理NSHのMPLS表現を使用するシステムは、2 ^ 20-1より大きいか16より小さいSPI値を割り当ててはなりません（MUST NOT）。
SI Label: The Label field of the SF Label stack entry contains the value of the SI exactly as defined in [RFC8300]. Since the SI requires only 8 bits, and to avoid overlap with the special-purpose label range of 0 through 15 [RFC7274], the SI is carried in the top (most significant) 8 bits of the Label field with the low-order 12 bits set to zero.
SIラベル：SFラベルスタックエントリのラベルフィールドには、[RFC8300]で定義されているとおりのSIの値が含まれています。 SIは8ビットのみを必要とし、0〜15 [RFC7274]の特殊目的のラベル範囲との重複を避けるため、SIは下位12のラベルフィールドの最上位（最上位）8ビットで実行されます。ビットはゼロに設定されます。
TC: The TC fields are as described in Section 5.
TC：TCフィールドはセクション5で説明したとおりです。
S: The S bits are as described in Section 5.
S：Sビットはセクション5で説明したとおりです。
TTL: The TTL field in the SPI Label stack entry SHOULD be set to 1 as stated in Section 5. The TTL in the SF Label stack entry is decremented once for each forwarding hop in the SFP, i.e., for each SFF transited, and so mirrors the TTL field in the NSH.
TTL：セクション5で説明されているように、SPIラベルスタックエントリのTTLフィールドは1に設定する必要があります（SHOULD）。SFラベルスタックエントリのTTLは、SFP内の転送ホップごと、つまり転送されるSFFごとに1つずつ減分されます。 NSHのTTLフィールドをミラーリングします。
The following processing rules apply to the Label fields:
次の処理規則がラベルフィールドに適用されます。
o When a classifier inserts a packet onto an SFP, it sets the SPI Label to indicate the identity of the SFP and sets the SI Label to indicate the first SF in the path.
o 分類子は、SFPにパケットを挿入するときに、SPIラベルを設定してSFPのIDを示し、SIラベルを設定してパスの最初のSFを示します。
o When a component of the SFC system processes a packet, it uses the SPI Label to identify the SFP and the SI Label to determine which SFF or instance of an SF (an SFI) to deliver the packet to. Under normal circumstances (with the exception of branching and reclassification -- see [BGP-NSH-SFC]), the SPI Label value is preserved on all packets. The SI Label value is modified by SFFs and through reclassification to indicate the next hop along the SFP.
o SFCシステムのコンポーネントがパケットを処理するとき、SPIラベルを使用してSFPとSIラベルを識別し、パケットを配信するSFFまたはSF（SFI）のインスタンスを決定します。通常の状況（分岐と再分類を除く-[BGP-NSH-SFC]を参照）では、SPIラベル値はすべてのパケットで保持されます。 SIラベル値は、SFFによって、および再分類を通じて変更され、SFPに沿った次のホップを示します。
The following processing rules apply to the TTL field of the SF Label stack entry and are derived from Section 2.2 of [RFC8300]:
次の処理ルールは、SFラベルスタックエントリのTTLフィールドに適用され、[RFC8300]のセクション2.2から派生しています。
o When a classifier places a packet onto an SFP, it MUST set the TTL to a value between 1 and 255. It SHOULD set this according to the expected length of the SFP (i.e., the number of SFs on the SFP), but it MAY set it to a larger value according to local configuration. The maximum TTL value supported in an NSH is 63, and so the practical limit here may also be 63.
o 分類子がパケットをSFPに配置する場合、TTLを1〜255の値に設定する必要があります。SFPの予想される長さ（つまり、SFPのSFの数）に従ってこれを設定する必要があります（ただし、SFPのSFの数）。ローカル構成に応じて、より大きな値に設定してください。 NSHでサポートされる最大TTL値は63であるため、ここでの実際的な制限も63になる場合があります。
o When an SFF receives a packet from any component of the SFC system (classifier, SFI, or another SFF), it MUST discard any packets with TTL set to zero. It SHOULD log such occurrences but MUST apply rate limiting to any such logs.
o SFFがSFCシステムのコンポーネント（分類子、SFI、または別のSFF）からパケットを受信すると、TTLがゼロに設定されているパケットを破棄する必要があります。そのような発生をログに記録する必要がありますが、そのようなログにはレート制限を適用する必要があります。
o An SFF MUST decrement the TTL by one each time it performs a lookup to forward a packet to the next SFF.
o SFFは、ルックアップを実行してパケットを次のSFFに転送するたびに、TTLを1ずつ減らす必要があります。
o If an SFF decrements the TTL to zero, it MUST NOT send the packet and MUST discard the packet. It SHOULD log such occurrences but MUST apply rate limiting to any such logs.
o SFFがTTLを0にデクリメントする場合、パケットを送信してはならず（MUST）、パケットを廃棄しなければなりません（MUST）。そのような発生をログに記録する必要がありますが、そのようなログにはレート制限を適用する必要があります。
o SFIs MUST ignore the TTL but MUST mirror it back to the SFF unmodified along with the SI (which may have been changed by local reclassification).
o SFIはTTLを無視する必要がありますが、SIとともに変更されずにSFFにミラーリングする必要があります（ローカルの再分類によって変更された可能性があります）。
o If a classifier along the SFP makes any change to the intended path of the packet, including for looping, jumping, or branching (see [BGP-NSH-SFC]), it MUST NOT change the SI TTL of the packet. In particular, each component of the SFC system MUST NOT increase the SI TTL value; otherwise, loops may go undetected.
o SFPに沿った分類子が、ループ、ジャンプ、または分岐（[BGP-NSH-SFC]を参照）を含め、パケットの目的のパスに変更を加える場合、パケットのSI TTLを変更してはなりません（MUST NOT）。特に、SFCシステムの各コンポーネントは、SI TTL値を増加してはなりません。そうしないと、ループが検出されない場合があります。
This section describes how the basic unit of MPLS label stack for SFC (introduced in Section 5) is used when MPLS label stacking is used to carry information about the SFP and SFs to be executed. The use case scenarios for this approach are introduced in Section 4.
このセクションでは、SFPのMPLSラベルスタックの基本ユニット（セクション5で紹介）を使用して、実行するSFPとSFに関する情報をMPLSラベルスタックで伝送する方法について説明します。このアプローチのユースケースシナリオは、セクション4で紹介されています。
As can be seen in Figure 3, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used.
図3に示すように、ラベルスタックの最上部には、SFF間のMPLSトンネルを介してパケットを配信するために必要なラベルが含まれています。任意のMPLSカプセル化を使用できます。
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
~ ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| |
~ Payload ~
| |
-------------------
Figure 3: The MPLS SFC Label Stack for Label Stacking
図3：ラベルスタッキング用のMPLS SFCラベルスタック
An entropy label [RFC6790] may also be present, as described in Section 11.
セクション11で説明されているように、エントロピーラベル[RFC6790]が存在する場合もあります。
Under these labels comes one or more instances of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries (provided in Section 5), the following meanings are applied:
これらのラベルの下には、SFCのMPLSラベルスタックの基本ユニットの1つ以上のインスタンスがあります。これらのラベルスタックエントリのフィールドの解釈（セクション5で提供）に加えて、次の意味が適用されます。
SFC Context Label: The Label field of the SFC Context Label stack entry contains a label that delivers SFC context. This label contains the SPI, encoded as a 20-bit integer using the semantics exactly as defined in [RFC8300]. Note that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC context-specific semantics, such as indicating how to interpret the SF Label or how to forward the packet to the node that offers the SF if so configured and coordinated with the controller that programs the labels for the SFP.
SFCコンテキストラベル：SFCコンテキストラベルスタックエントリのラベルフィールドには、SFCコンテキストを配信するラベルが含まれています。このラベルには、[RFC8300]で定義されているとおりのセマンティクスを使用して20ビット整数としてエンコードされたSPIが含まれています。この場合、論理NSHのMPLS表現を使用するシステムは、2 ^ 20-1または16未満のSPI値を割り当ててはならないことに注意してください。このラベルは、方法を示すなど、他のSFCコンテキスト固有のセマンティクスを伝えるためにも使用できます。 SFラベルを解釈するため、またはSFを提供するノードにパケットを転送する方法。このように構成され、SFPのラベルをプログラムするコントローラーと調整されている場合。
SF Label: The Label field of the SF Label stack entry contains a value that identifies the next SFI to be actioned for the packet. This label may be scoped globally or within the context of the preceding SFC Context Label and comes from the range 16 ... 2^20 - 1.
SFラベル：SFラベルスタックエントリのラベルフィールドには、パケットに対してアクションを実行する次のSFIを識別する値が含まれています。このラベルは、グローバルに、または前述のSFCコンテキストラベルのコンテキスト内でスコープを設定でき、範囲は16 ... 2 ^ 20-1です。
TC: The TC fields are as described in Section 5.
TC：TCフィールドはセクション5で説明したとおりです。
S: The S bits are as described in Section 5.
S：Sビットはセクション5で説明したとおりです。
TTL: The TTL fields in the SFC Context Label stack entry and in the SF Label stack entry SHOULD be set to 1 as stated in Section 5 but MAY be set to larger values if the label indicated a forwarding operation towards the node that hosts the SF.
TTL：SFCコンテキストラベルスタックエントリとSFラベルスタックエントリのTTLフィールドは、セクション5で述べたように1に設定する必要がありますが、ラベルがSFをホストするノードへの転送操作を示している場合は、より大きな値に設定できます（MAY）。 。
The following processing rules apply to the Label fields:
次の処理規則がラベルフィールドに適用されます。
o When a classifier inserts a packet onto an SFP, it adds a stack comprising one or more instances of the basic unit of MPLS label stack for SFC. Taken together, this stack defines the SFs to be actioned and so defines the SFP that the packet will traverse.
o 分類子がパケットをSFPに挿入すると、SFCのMPLSラベルスタックの基本ユニットの1つ以上のインスタンスで構成されるスタックが追加されます。まとめると、このスタックはアクションが実行されるSFを定義し、パケットが通過するSFPを定義します。
o When a component of the SFC system processes a packet, it uses the top basic unit of label stack for SFC to determine to which SFI to next deliver the packet. When an SFF receives a packet, it examines the top basic unit of MPLS label stack for SFC to determine where to send the packet next. If the next recipient is a local SFI, the SFF strips the basic unit of MPLS label stack for SFC before forwarding the packet.
o SFCシステムのコンポーネントがパケットを処理するとき、SFCのラベルスタックの一番上の基本ユニットを使用して、次にパケットを配信するSFIを決定します。 SFFはパケットを受信すると、SFCのMPLSラベルスタックの上位の基本ユニットを調べて、次にパケットを送信する場所を決定します。次の受信者がローカルSFIである場合、SFFはパケットを転送する前にSFCのMPLSラベルスタックの基本単位を取り除きます。
The previous sections describe homogeneous networks where SFC forwarding is either all label swapping or all label popping (stacking). This simplification helps to clarify the explanation of the mechanisms.
前のセクションでは、SFC転送がすべてラベルスワップまたはすべてラベルポップ（スタッキング）である同種ネットワークについて説明しました。この単純化は、メカニズムの説明を明確にするのに役立ちます。
However, as described in Section 4.2, some use cases may use label swapping and stacking at the same time. Furthermore, it is also possible that different parts of the network utilize swapping or popping such that an end-to-end service chain has to utilize a combination of both techniques. It is also worth noting that a classifier may be content to use an SFP as installed in the network by a control plane or management plane and so would use label swapping, but that there may be a point in the SFP where a choice of SFIs can be made (perhaps for load balancing) and where, in this instance, the classifier wishes to exert control over that choice by use of a specific entry on the label stack as described in Section 4.3.
ただし、セクション4.2で説明されているように、一部のユースケースでは、ラベルのスワッピングとスタックを同時に使用する場合があります。さらに、エンドツーエンドのサービスチェーンが両方の手法の組み合わせを利用する必要があるように、ネットワークの異なる部分がスワッピングまたはポップを利用することも可能です。また、分類子は、コントロールプレーンまたは管理プレーンによってネットワークにインストールされた状態でSFPを使用するのに満足できるため、ラベルスワッピングを使用することもありますが、SFPには、SFIの選択が可能なポイントがある場合があることに注意してください。 （おそらくロードバランシングのために）作成され、この場合、セクション4.3で説明されているように、分類子はラベルスタックの特定のエントリを使用して、その選択を制御したいと考えます。
When an SFF receives a packet containing an MPLS label stack, it checks from the context of the incoming interface, and from the SFP indicated by the top label, whether it is processing an {SPI, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider.
SFFは、MPLSラベルスタックを含むパケットを受信すると、着信インターフェイスのコンテキストから、およびトップラベルで示されるSFPから、ラベルスワッピング用の{SPI、SI}ラベルペアを処理しているか、または{コンテキストラベル、SFIインデックス}ラベルスタックのラベルペア。次に、パケットの送信先となる適切なSFIを選択します。 SFIからパケットを受信した場合、4つのケースを検討する必要があります。
o If the current hop requires an {SPI, SI} and the next hop requires an {SPI, SI}, it sets the SPI Label according to the SFP to be traversed, selects an instance of the SF to be executed at the next hop, sets the SI Label to the SI value of the next hop, and tunnels the packet to the SFF for that SFI.
o 現在のホップが{SPI、SI}を必要とし、次のホップが{SPI、SI}を必要とする場合、SFPラベルをトラバースするように設定し、次のホップで実行されるSFのインスタンスを選択します。 SIラベルをネクストホップのSI値に設定し、そのSFIのSFFにパケットをトンネルします。
o If the current hop requires an {SPI, SI} and the next hop requires a {context label, SFI Label}, it pops the {SPI, SI} from the top of the MPLS label stack and tunnels the packet to the SFF indicated by the context label.
o 現在のホップが{SPI、SI}を必要とし、次のホップが{コンテキストラベル、SFIラベル}を必要とする場合、MPLSラベルスタックの最上部から{SPI、SI}をポップし、パケットを次のようにSFFにトンネリングします。コンテキストラベル。
o If the current hop requires a {context label, SFI Label}, it pops the {context label, SFI Label} from the top of the MPLS label stack.
o 現在のホップで{コンテキストラベル、SFIラベル}が必要な場合は、MPLSラベルスタックの一番上から{コンテキストラベル、SFIラベル}をポップします。
* If the new top of the MPLS label stack contains an {SPI, SI} label pair, it selects an SFI to use at the next hop and tunnels the packet to the SFF for that SFI.
* MPLSラベルスタックの新しいトップに{SPI、SI}ラベルペアが含まれている場合、ネクストホップで使用するSFIを選択し、そのSFIのSFFにパケットをトンネリングします。
* If the new top of the MPLS label stack contains a {context label, SFI Label}, it tunnels the packet to the SFF indicated by the context label.
* MPLSラベルスタックの新しいトップに{コンテキストラベル、SFIラベル}が含まれている場合、コンテキストラベルで示されるSFFにパケットをトンネルします。
The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC proxy is logically located between an SFF and an SFI that is not "SFC aware". Such SFIs are not capable of handling the SFC encapsulation (whether that be NSH or MPLS) and need the encapsulation stripped from the packets they are to process. In many cases, legacy SFIs that were once deployed as "bumps in the wire" fit into this category until they have been upgraded to be SFC aware.
「SFCプロキシ」の概念は[RFC7665]で紹介されています。 SFCプロキシは、SFFと「SFC対応」ではないSFIの間に論理的に配置されます。このようなSFIは、SFCカプセル化（NSHまたはMPLSのいずれであっても）を処理することができず、処理するパケットからカプセル化を取り除く必要があります。多くの場合、「バンプインザワイヤー」として展開されたレガシーSFIは、SFC対応にアップグレードされるまで、このカテゴリに該当します。
The job of an SFC proxy is to remove and then reimpose SFC encapsulation so that the SFF is able to process as though it was communication with an SFC-aware SFI, and so that the SFI is unaware of the SFC encapsulation. In this regard, the job of an SFC proxy is no different when NSH encapsulation is used and when MPLS encapsulation is used as described in this document, although (of course) it is different encapsulation bytes that must be removed and reimposed.
SFCプロキシの役割は、SFFがSFC認識SFIと通信しているかのように処理でき、SFIがSFCカプセル化を認識しないように、SFCカプセル化を削除して再度インポーズすることです。この点で、SFCプロキシの役割は、NSHカプセル化が使用されている場合と、このドキュメントで説明されているようにMPLSカプセル化が使用されている場合と変わりませんが、（もちろん）削除して再挿入する必要がある異なるカプセル化バイトです。
It should be noted that the SFC proxy is a logical function. It could be implemented as a separate physical component on the path from the SFF to the SFI, but it could be co-resident with the SFF or it could be a component of the SFI. This is purely an implementation choice.
SFCプロキシは論理機能であることに注意してください。これは、SFFからSFIへのパス上の個別の物理コンポーネントとして実装できますが、SFFと共存することも、SFIのコンポーネントにすることもできます。これは純粋に実装の選択です。
Note also that the delivery of metadata (see Section 12) requires specific processing if an SFC proxy is in use. This is also no different when NSH functionality or the MPLS encoding defined in this document is in use, and how it is handled will depend on how (or if) each non-SFC-aware SFI can receive metadata.
SFCプロキシが使用されている場合、メタデータの配信（セクション12を参照）には特定の処理が必要になることにも注意してください。これは、このドキュメントで定義されているNSH機能またはMPLSエンコーディングが使用されている場合も同様であり、その処理方法は、SFC非対応の各SFIがメタデータを受信する方法（または場合）によって異なります。
In order that a packet may be forwarded along an SFP, several functional elements must be executed.
パケットがSFPに沿って転送されるようにするには、いくつかの機能要素を実行する必要があります。
o Discovery/advertisement of SFIs.
o SFIの検出/アドバタイズ。
o Computation of the SFP.
o SFPの計算。
o Programming of classifiers.
o 分類器のプログラミング。
o Advertisement of forwarding instructions.
o 転送指示のアドバタイズ。
Various approaches may be taken. These include a fully centralized model where SFFs report to a central controller the SFIs that they support, the central controller computes the SFP and programs the classifiers, and (if the label-swapping approach is taken) the central controller installs forwarding state in the SFFs that lie on the SFP.
さまざまなアプローチを取ることができます。これらには、SFFがサポートするSFIを中央コントローラーに報告する完全集中型モデルが含まれます。中央コントローラーはSFPを計算して分類子をプログラムし、中央コントローラーはSFFに転送状態をインストールします。それはSFPにあります。
Alternatively, a dynamic control plane may be used, such as that described in [BGP-NSH-SFC]. In this case, the SFFs use the control plane to advertise the SFIs that they support, a central controller computes the SFP and programs the classifiers, and (if the label-swapping approach is taken) the central controller uses the control plane to advertise the SFPs so that SFFs that lie on the SFP can install the necessary forwarding state.
あるいは、[BGP-NSH-SFC]で説明されているような動的制御プレーンを使用することもできます。この場合、SFFはコントロールプレーンを使用して、サポートするSFIをアドバタイズします。中央コントローラーは、SFPを計算して分類子をプログラムし、（ラベルスワップアプローチが採用されている場合）中央コントローラーはコントロールプレーンを使用して、 SFP上にあるSFFが必要な転送状態をインストールできるようにするためのSFP。
Entropy is used in ECMP situations to ensure that packets from the same flow travel down the same path, thus avoiding jitter or reordering issues within a flow.
エントロピーはECMPの状況で使用され、同じフローからのパケットが確実に同じパスを移動するようにします。これにより、フロー内のジッターや並べ替えの問題を回避できます。
Entropy is often determined by hashing on specific fields in a packet header, such as the "five-tuple" in the IP and transport headers. However, when an MPLS label stack is present, the depth of the stack could be too large for some processors to correctly determine the entropy hash. This problem is addressed by the inclusion of an entropy label as described in [RFC6790].
エントロピーは、多くの場合、IPヘッダーとトランスポートヘッダーの「5タプル」など、パケットヘッダーの特定のフィールドのハッシュによって決定されます。ただし、MPLSラベルスタックが存在する場合、スタックの深さが大きすぎて、一部のプロセッサがエントロピーハッシュを正しく決定できない場合があります。この問題は、[RFC6790]で説明されているように、エントロピーラベルを含めることで解決されます。
When entropy is desired for packets as they are carried in MPLS tunnels over the underlay network, it is RECOMMENDED that an entropy label be included in the label stack immediately after the tunnel labels and before the SFC Labels, as shown in Figures 2 and 3.
パケットがアンダーレイネットワーク上のMPLSトンネルで伝送されるときにエントロピーが必要な場合は、図2および3に示すように、エントロピーラベルをトンネルラベルの直後かつSFCラベルの前にラベルスタックに含めることをお勧めします。
If an entropy label is present in an MPLS payload, it is RECOMMENDED that the initial classifier use that value in an entropy label inserted in the label stack when the packet is forwarded (on the first tunnel) to the first SFF. In this case, it is not necessary to remove the entropy label from the payload.
MPLSペイロードにエントロピーラベルが存在する場合、パケットが（最初のトンネルで）最初のSFFに転送されるときに、初期分類子がラベルスタックに挿入されたエントロピーラベルの値を使用することをお勧めします。この場合、ペイロードからエントロピーラベルを削除する必要はありません。
Metadata is defined in [RFC7665] as providing "the ability to exchange context information between classifiers and SFs, and among SFs." [RFC8300] defines how this context information can be directly encoded in fields that form part of the NSH encapsulation.
メタデータは、[RFC7665]で「分類子とSF間、およびSF間でコンテキスト情報を交換する機能」を提供するものとして定義されています。 [RFC8300]は、このコンテキスト情報をNSHカプセル化の一部を形成するフィールドに直接エンコードする方法を定義しています。
Sections 12.1 and 12.2 describe how metadata is associated with user data packets, and how metadata may be exchanged between SFC nodes in the network, when using an MPLS encoding of the logical representation of the NSH.
セクション12.1および12.2では、NSHの論理表現のMPLSエンコーディングを使用する場合に、メタデータがユーザーデータパケットに関連付けられる方法、およびネットワーク内のSFCノード間でメタデータが交換される方法について説明します。
It should be noted that the MPLS encoding is less functional than the direct use of the NSH. Both methods support metadata that is "per-SFP" or "per-flow" (see [RFC8393] for definitions of these terms), but "per-packet" metadata (where the metadata must be carried on each packet because it differs from one packet to the next even on the same flow or SFP) is only supported using the NSH and not using the mechanisms defined in this document.
MPLSエンコーディングは、NSHを直接使用する場合よりも機能的ではないことに注意してください。どちらの方法も「SFPごと」または「フローごと」（これらの用語の定義については[RFC8393]を参照）のメタデータをサポートしますが、「パケットごと」のメタデータ（メタデータは、同じフローまたはSFPであっても、1つのパケットから次のパケットへ）は、NSHを使用してのみサポートされ、このドキュメントで定義されたメカニズムを使用しません。
Metadata is achieved in the MPLS realization of the logical NSH by the use of an SFC Metadata Label, which uses the extended special-purpose label construct [RFC7274]. Thus, three label stack entries are present, as shown in Figure 4:
メタデータは、拡張特殊用途ラベル構成体[RFC7274]を使用するSFCメタデータラベルを使用して、論理NSHのMPLS実現で実現されます。したがって、図4に示すように、3つのラベルスタックエントリが存在します。
o The Extension Label (value 15).
o 拡張ラベル（値15）。
o An extended special-purpose label called the Metadata Label Indicator (MLI) (value 16).
o メタデータラベルインジケーター（MLI）と呼ばれる拡張特殊目的ラベル（値16）。
o The Metadata Label (ML).
o メタデータラベル（ML）。
----------------
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
----------------
Figure 4: The MPLS SFC Metadata Label
図4：MPLS SFCメタデータラベル
The Metadata Label value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. Out-of-band mechanisms potentially include management-plane and control-plane solutions (such as [BGP-NSH-SFC]) but are out of scope for this document. The in-band mechanism is described in Section 12.2.
Metadata Label値は、インバンドまたはアウトオブバンドメカニズムを使用してネットワークにプログラムされるメタデータのテーブルへのインデックスです。帯域外メカニズムには、管理プレーンソリューションとコントロールプレーンソリューション（[BGP-NSH-SFC]など）が含まれる可能性がありますが、このドキュメントの範囲外です。インバンドメカニズムについては、セクション12.2で説明します。
The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC, as shown in Figure 5. For MPLS label stacking, the SFC Metadata Labels are placed at the bottom of the label stack, as shown in Figure 6.
SFCメタデータラベル（図4に示すように3つのラベルのセットとして）は、MPLS SFCパケット内に0回、1回、またはそれ以上存在する可能性があります。 MPLSラベルスワッピングの場合、SFCメタデータラベルは、図5に示すように、SFCのMPLSラベルスタックの基本ユニットの直後に配置されます。MPLSラベルスタッキングの場合、SFCメタデータラベルは、ラベルスタックの下部に配置されます。図6
----------------
~ Tunnel Labels ~
+----------------+
~ Optional ~
~ Entropy Label ~
+----------------+
| SPI Label |
+----------------+
| SI Label |
+----------------+
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
+----------------+
~ Other ~
| Metadata |
~ Label Triples ~
+----------------+
| |
~ Payload ~
| |
----------------
Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata Label
図5：メタデータラベルを使用したラベルスワッピング用のMPLS SFCラベルスタック
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MLI |
+-------------------+
| Metadata Label |
+-------------------+
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
-------------------
Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata Label
図6：メタデータラベルを使用したラベルスタック用のMPLS SFCラベルスタック
A mechanism for sending metadata associated with an SFP without a payload packet is described in [RFC8393]. The same approach can be used in an MPLS network where the NSH is logically represented by an MPLS label stack.
ペイロードパケットなしでSFPに関連付けられたメタデータを送信するメカニズムは、[RFC8393]で説明されています。 NSHがMPLSラベルスタックによって論理的に表されるMPLSネットワークでも同じアプローチを使用できます。
The packet header is formed exactly as previously described in this document so that the packet will follow the SFP through the SFC network. However, instead of payload data, metadata is included after the bottom of the MPLS label stack. An extended special-purpose label is used to indicate that the metadata is present. Thus, three label stack entries are present:
パケットヘッダーは、このドキュメントで前述したとおりに形成されるため、パケットはSFCネットワークを介してSFPに従います。ただし、ペイロードデータの代わりに、メタデータはMPLSラベルスタックの下部に含まれています。拡張された専用ラベルは、メタデータが存在することを示すために使用されます。したがって、3つのラベルスタックエントリが存在します。
o The Extension Label (value 15).
o 拡張ラベル（値15）。
o An extended special-purpose label called the Metadata Present Indicator (MPI) (value 17).
o メタデータ存在インジケーター（MPI）（値17）と呼ばれる拡張特殊目的ラベル。
o The Metadata Label (ML) that is associated with this metadata on this SFP and can be used to indicate the use of the metadata as described in Section 12.
o セクション12で説明されているように、このSFPでこのメタデータに関連付けられ、メタデータの使用を示すために使用できるメタデータラベル（ML）。
The MPI, if present, is placed immediately after the last basic unit of MPLS label stack for SFC. The resultant label stacks are shown in Figure 7 for the MPLS label-swapping case and Figure 8 for the MPLS label-stacking case.
MPIが存在する場合、SFCのMPLSラベルスタックの最後の基本ユニットの直後に配置されます。結果のラベルスタックは、MPLSラベルスワッピングの場合については図7に、MPLSラベルスタッキングの場合については図8に示されています。
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| Extension = 15|
+---------------+
| MPI |
+---------------+
| Metadata Label|
+---------------+
| |
~ Metadata ~
| |
---------------
Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying Metadata
図7：メタデータを運ぶラベルスワッピング用のMPLS SFCラベルスタック
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MPI |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
-------------------
Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying Metadata
図8：メタデータを運ぶラベルスタッキング用のMPLS SFCラベルスタック
In both cases, the metadata is formatted as a TLV, as shown in Figure 9.
どちらの場合も、図9に示すように、メタデータはTLVとしてフォーマットされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Metadata TLV
図9：メタデータTLV
The fields of this TLV are interpreted as follows:
このTLVのフィールドは次のように解釈されます。
Length: The length of the metadata carried in the Metadata field in octets, not including any padding.
長さ：メタデータフィールドでオクテット単位で運ばれるメタデータの長さ。パディングは含まれません。
Metadata Type: The type of the metadata present. Values for this field are taken from the "NSH MD Types" registry maintained by IANA and defined in [RFC8300] and encoded with the most significant bit first.
メタデータタイプ：存在するメタデータのタイプ。このフィールドの値は、IANAによって維持され、[RFC8300]で定義されている「NSH MDタイプ」レジストリから取得され、最上位ビットが最初にエンコードされます。
Metadata: The actual metadata formatted as described in whatever document defines the metadata. This field is end-padded with zero to 3 octets of zeroes to take it up to a 4-octet boundary.
メタデータ：メタデータを定義するドキュメントで説明されているようにフォーマットされた実際のメタデータ。このフィールドは、0から3オクテットのゼロでエンドパディングされ、最大4オクテットの境界になります。
Note that in-band exchange of metadata is vulnerable to packet loss. This is both a risk arising from network faults and an attack vulnerability.
メタデータのインバンド交換はパケット損失に対して脆弱であることに注意してください。これは、ネットワーク障害と攻撃の脆弱性から生じるリスクです。
If packets that arrive at an SFF use an MLI that does not have an entry in the metadata table, an alarm can be raised and the packet can be discarded or processed without the metadata according to local configuration. This provides some long-term mitigation but is not an ideal solution.
SFFに到着するパケットが、メタデータテーブルにエントリがないMLIを使用する場合、アラームが発生し、ローカル構成に従ってメタデータなしでパケットを破棄または処理できます。これは、長期的な緩和策を提供しますが、理想的なソリューションではありません。
Further mitigation of loss of metadata packets can be achieved by retransmitting them at a configurable interval. This is a relatively cheap, but only partial, solution because there may still be a window during which the metadata has not been received.
構成可能な間隔で再送信することにより、メタデータパケットの損失をさらに軽減できます。これは比較的安価ですが、メタデータが受信されていないウィンドウがまだ存在する可能性があるため、部分的なソリューションにすぎません。
The concern of lost metadata may be particularly important when the metadata applicable to a specific MPI is being changed. This could result in out-of-date metadata being applied to a packet. If this is a concern, it is RECOMMENDED that a new MPI be used to install a new entry in the metadata table, and the packets in the flow should be marked with the equivalent new MLI.
特定のMPIに適用可能なメタデータが変更されている場合、メタデータが失われるという懸念は特に重要です。これにより、古いメタデータがパケットに適用される可能性があります。これが問題になる場合は、新しいMPIを使用してメタデータテーブルに新しいエントリをインストールし、フロー内のパケットを同等の新しいMLIでマークすることをお勧めします。
Finally, if an application that requires metadata is sensitive to this potential loss or attack, it SHOULD NOT use in-band metadata distribution but SHOULD rely on control-plane or management-plane mechanisms, because these approaches can use a more sophisticated protocol that includes confirmation of delivery and can perform verification or inspection of entries in the metadata table.
最後に、メタデータを必要とするアプリケーションがこの潜在的な損失または攻撃に敏感である場合、インバンドメタデータ配布を使用すべきではありませんが、これらのアプローチは、以下を含むより洗練されたプロトコルを使用できるため、コントロールプレーンまたは管理プレーンメカニズムに依存する必要があります配信の確認。メタデータテーブルのエントリの検証または検査を実行できます。
This section reverts to the simplified descriptions of networks that rely wholly on label swapping or label stacking. As described in Section 4, actual deployment scenarios may depend on the use of both mechanisms and utilize a mixed mode as described in Section 8.
このセクションでは、ラベルスワッピングまたはラベルスタッキングに完全に依存するネットワークの簡単な説明に戻ります。セクション4で説明されているように、実際の展開シナリオは両方のメカニズムの使用に依存し、セクション8で説明されている混合モードを利用します。
Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two SFs (SFa and SFb) that are accessed through two SFFs (SFFa and SFFb, respectively). The packet is ultimately delivered to the destination, D.
図10に示す単純なMPLS SFCオーバーレイネットワークについて考えてみます。パケットは、2つのSFF（それぞれSFFaとSFFb）を介してアクセスされる2つのSF（SFaとSFb）を通過することを確認するSFPに分類されます。パケットは最終的に宛先Dに配信されます。
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFa | | SFb | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFa +-------+ SFFb +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 10: Service Function Chaining in an MPLS Network
図10：MPLSネットワークでのサービス機能の連鎖
Let us assume that the SFP is computed and assigned an SPI value of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [BGP-NSH-SFC]) so that the SFFs are programmed with the necessary forwarding instructions.
SFPが計算され、239のSPI値が割り当てられていると仮定します。SFFが必要な転送命令でプログラムされるように、SFPの転送の詳細が（おそらく[BGP-NSH-SFC]のメカニズムを使用して）配布されます。
The packet progresses as follows:
パケットは次のように進行します。
1. The classifier assigns the packet to the SFP and imposes two label stack entries comprising a single basic unit of MPLS SFC representation:
1. 分類子はパケットをSFPに割り当て、MPLS SFC表現の単一の基本ユニットを構成する2つのラベルスタックエントリを課します。
* The higher label stack entry contains a label carrying the SPI value of 239.
* 上位のラベルスタックエントリには、239のSPI値を持つラベルが含まれています。
* The lower label stack entry contains a label carrying the SI value of 255.
* 下のラベルスタックエントリには、255のSI値を示すラベルが含まれています。
Further labels may be imposed to tunnel the packet from the classifier to SFFa.
分類子からSFFaにパケットをトンネリングするために、さらにラベルを課すことができます。
2. When the packet arrives at SFFa, SFFa strips any labels associated with the tunnel that runs from the classifier to SFFa. SFFa examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFa. The packet is forwarded to SFa unmodified.
2. パケットがSFFaに到着すると、SFFaは、分類子からSFFaまでのトンネルに関連付けられているすべてのラベルを取り除きます。 SFFaはトップラベルを調べ、SPI / SIを照合して、パケットをSFaに転送する必要があることを識別します。パケットは変更されずにSFaに転送されます。
3. SFa performs its designated function and returns the packet to SFFa.
3. SFaは指定された機能を実行し、パケットをSFFaに返します。
4. SFFa modifies the SI in the lower label stack entry (to 254) and uses the SPI/SI to look up the forwarding instructions. It sends the packet with two label stack entries:
4. SFFaは、下位ラベルスタックエントリのSIを変更して（254に）、SPI / SIを使用して転送命令を検索します。 2つのラベルスタックエントリを含むパケットを送信します。
* The higher label stack entry contains a label carrying the SPI value of 239.
* 上位のラベルスタックエントリには、239のSPI値を持つラベルが含まれています。
* The lower label stack entry contains a label carrying the SI value of 254.
* 下位のラベルスタックエントリには、SI値が254のラベルが含まれています。
Further labels may be imposed to tunnel the packet from SFFa to SFFb.
パケットをSFFaからSFFbにトンネリングするために、さらにラベルを付けることができます。
5. When the packet arrives at SFFb, SFFb strips any labels associated with the tunnel from SFFa. SFFb examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFb. The packet is forwarded to SFb unmodified.
5. パケットがSFFbに到着すると、SFFbはトンネルに関連するすべてのラベルをSFFaから取り除きます。 SFFbはトップラベルを調べ、SPI / SIを照合して、パケットをSFbに転送する必要があることを識別します。パケットは変更されずにSFbに転送されます。
6. SFb performs its designated function and returns the packet to SFFb.
6. SFbは指定された機能を実行し、パケットをSFFbに返します。
7. SFFb modifies the SI in the lower label stack entry (to 253) and uses the SPI/SI to look up the forwarding instructions. It determines that it is the last SFF in the SFP, so it strips the two SFC Label stack entries and forwards the payload toward D using the payload protocol.
7. SFFbは、下位ラベルスタックエントリのSIを（253に）変更し、SPI / SIを使用して転送命令を検索します。これは、SFPの最後のSFFであると判断し、2つのSFCラベルスタックエントリを取り除き、ペイロードプロトコルを使用してペイロードをDに転送します。
Alternatively, consider the MPLS SFC overlay network shown in Figure 11. A packet is classified for an SFP that will see it pass through two SFs (SFx and SFy) that are accessed through two SFFs (SFFx and SFFy, respectively). The packet is ultimately delivered to the destination, D.
あるいは、図11に示すMPLS SFCオーバーレイネットワークについて考えてみます。パケットは、2つのSFF（それぞれSFFxとSFFy）を介してアクセスされる2つのSF（SFxとSFy）を通過することを確認するSFPに分類されます。パケットは最終的に宛先Dに配信されます。
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFx | | SFy | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 11: Service Function Chaining Using MPLS Label Stacking
図11：MPLSラベルスタッキングを使用したサービス機能の連鎖
Let us assume that the SFP is computed and assigned an SPI value of 239. However, the forwarding state for the SFP is not distributed and installed in the network. Instead, it will be attached to the individual packets using the MPLS label stack.
SFPが計算され、239のSPI値が割り当てられていると仮定します。ただし、SFPの転送状態は分散されず、ネットワークにインストールされません。代わりに、MPLSラベルスタックを使用して個々のパケットに添付されます。
The packet progresses as follows:
パケットは次のように進行します。
1. The classifier assigns the packet to the SFP and imposes two basic units of MPLS SFC representation to describe the full SFP:
1. 分類子はパケットをSFPに割り当て、完全なSFPを記述するためにMPLS SFC表現の2つの基本単位を課します。
* The top basic unit comprises two label stack entries as follows:
* 上部の基本ユニットは、次の2つのラベルスタックエントリで構成されています。
+ The higher label stack entry contains a label carrying the SFC context.
+ 上位のラベルスタックエントリには、SFCコンテキストを運ぶラベルが含まれています。
+ The lower label stack entry contains a label carrying the SF indicator for SFx.
+ 下部のラベルスタックエントリには、SFxのSFインジケータを示すラベルが含まれています。
* The lower basic unit comprises two label stack entries as follows:
* 下の基本ユニットは、次の2つのラベルスタックエントリで構成されています。
+ The higher label stack entry contains a label carrying the SFC context.
+ 上位のラベルスタックエントリには、SFCコンテキストを運ぶラベルが含まれています。
+ The lower label stack entry contains a label carrying the SF indicator for SFy.
+ 下部のラベルスタックエントリには、SFyのSFインジケーターを示すラベルが含まれています。
Further labels may be imposed to tunnel the packet from the classifier to SFFx.
分類子からSFFxにパケットをトンネリングするために、さらにラベルを課すことができます。
2. When the packet arrives at SFFx, SFFx strips any labels associated with the tunnel from the classifier. SFFx examines the top labels and matches the context/SF values to identify that the packet should be forwarded to SFx. The packet is forwarded to SFx unmodified.
2. パケットがSFFxに到着すると、SFFxはトンネルに関連付けられたすべてのラベルを分類子から取り除きます。 SFFxはトップラベルを調べ、コンテキスト/ SF値を照合して、パケットをSFxに転送する必要があることを識別します。パケットは変更されずにSFxに転送されます。
3. SFx performs its designated function and returns the packet to SFFx.
3. SFxは指定された機能を実行し、パケットをSFFxに返します。
4. SFFx strips the top basic unit of MPLS SFC representation, revealing the next basic unit. It then uses the revealed context/SF values to determine how to route the packet to the next SFF, SFFy. It sends the packet with just one basic unit of MPLS SFC representation comprising two label stack entries:
4. SFFxは、MPLS SFC表現の一番上の基本単位を取り除き、次の基本単位を明らかにします。次に、明らかにされたコンテキスト/ SF値を使用して、パケットを次のSFF、SFFyにルーティングする方法を決定します。 2つのラベルスタックエントリで構成されるMPLS SFC表現の1つの基本単位のみでパケットを送信します。
* The higher label stack entry contains a label carrying the SFC context.
* 上位のラベルスタックエントリには、SFCコンテキストを運ぶラベルが含まれています。
* The lower label stack entry contains a label carrying the SF indicator for SFy.
* 下部のラベルスタックエントリには、SFyのSFインジケーターを示すラベルが含まれています。
Further labels may be imposed to tunnel the packet from SFFx to SFFy.
パケットをSFFxからSFFyにトンネリングするために、さらにラベルを付けることができます。
5. When the packet arrives at SFFy, SFFy strips any labels associated with the tunnel from SFFx. SFFy examines the top labels and matches the context/SF values to identify that the packet should be forwarded to SFy. The packet is forwarded to SFy unmodified.
5. パケットがSFFyに到着すると、SFFyはトンネルに関連付けられているすべてのラベルをSFFxから取り除きます。 SFFyはトップラベルを調べ、コンテキスト/ SF値を照合して、パケットをSFyに転送する必要があることを識別します。パケットは変更されずにSFyに転送されます。
6. SFy performs its designated function and returns the packet to SFFy.
6. SFyは指定された機能を実行し、パケットをSFFyに返します。
7. SFFy strips the top basic unit of MPLS SFC representation, revealing the payload packet. It forwards the payload toward D using the payload protocol.
7. SFFyは、MPLS SFC表現の上部の基本単位を取り除き、ペイロードパケットを明らかにします。ペイロードプロトコルを使用して、ペイロードをDに転送します。
It is not the job of an IETF specification to describe the internals of an implementation, except where that directly impacts upon the bits on the wire that change the likelihood of interoperability or where the availability of configuration or security options directly affects the utility of an implementation.
相互運用性の可能性を変えるワイヤ上のビットに直接影響する場合、または構成またはセキュリティオプションの可用性が実装のユーティリティに直接影響する場合を除き、実装の内部を記述するのはIETF仕様の仕事ではありません。 。
However, in view of the objective of this document to acknowledge that there may be a need for an interim deployment of SFC functionality in brownfield MPLS networks, this section provides some observations about how an SFF might utilize MPLS features that are available in existing routers. This section is not intended to be definitive or technically complete; rather, it is indicative.
ただし、ブラウンフィールドMPLSネットワークでSFC機能の暫定的な展開が必要になる可能性があることを認めるこのドキュメントの目的に照らして、このセクションでは、SFFが既存のルーターで利用可能なMPLS機能をどのように利用するかについていくつかの観察を提供します。このセクションは、決定的または技術的に完全なものではありません。むしろ、それは指標です。
Consider the mechanism used to indicate to which Virtual Routing and Forwarding (VRF) system an incoming MPLS packet should be routed in a Layer 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top MPLS label is an indicator of the VRF system that is to be used to route the payload.
着信MPLSパケットをレイヤー3バーチャルプライベートネットワーク（L3VPN）[RFC4364]でルーティングする必要がある仮想ルーティングおよび転送（VRF）システムを示すために使用されるメカニズムを検討してください。この場合、上部のMPLSラベルは、ペイロードのルーティングに使用されるVRFシステムのインジケーターです。
A similar approach can be taken with the label-swapping SFC technique described in Section 6 such that the SFC Context Label identifies a routing table specific to the SFP. The SF Label can be looked up in the context of this routing table to determine to which SF to direct the packet and how to forward it to the next SFF.
SFCコンテキストラベルがSFPに固有のルーティングテーブルを識別するように、セクション6で説明されているラベルスワッピングSFCテクニックでも同様のアプローチをとることができます。このルーティングテーブルのコンテキストでSFラベルを検索して、パケットをどのSFに転送するか、および次のSFFに転送する方法を決定できます。
Advanced features (such as metadata) are not inspected by SFFs. The packets are passed to SFIs that are MPLS-SFC aware or to SFC proxies, and those components are responsible for handling all metadata issues.
高度な機能（メタデータなど）はSFFによって検査されません。パケットはMPLS-SFC対応のSFIまたはSFCプロキシに渡され、これらのコンポーネントはすべてのメタデータの問題を処理します。
Of course, an actual implementation might make considerable optimizations on this approach, but this section should provide hints about how MPLS-based SFC might be achieved with relatively small modifications to deployed MPLS devices.
もちろん、実際の実装ではこのアプローチをかなり最適化する可能性がありますが、このセクションでは、展開されたMPLSデバイスに比較的小さな変更を加えてMPLSベースのSFCを実現する方法についてのヒントを提供します。
Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is provided in [RFC8300]. Those documents provide analysis and present a set of requirements and recommendations for security, and the normative security requirements from those documents apply to this specification. However, it should be noted that those documents do not describe any mechanisms for securing NSH systems.
SFCネットワークのセキュリティ特性の議論は[RFC7665]で見つけることができます。 NSHとその使用に関するセキュリティの詳細については、[RFC8300]で説明されています。これらのドキュメントは分析を提供し、セキュリティに関する一連の要件と推奨事項を提示します。これらのドキュメントの標準的なセキュリティ要件がこの仕様に適用されます。ただし、これらのドキュメントには、NSHシステムを保護するためのメカニズムは記載されていないことに注意してください。
It is fundamental to the SFC design that the classifier is a fully trusted element. That is, the classification decision process is not visible to the other elements, and its output is treated as accurate. As such, the classifier has responsibility for determining the processing that the packet will be subject to, including, for example, firewall functions. It is also fundamental to the MPLS design that packets are routed through the network using the path specified by the node imposing the labels and that the labels are swapped or popped correctly. Where an SF is not encapsulation aware, the encapsulation may be stripped by an SFC proxy such that a packet may exist as a native packet (perhaps IP) on the path between the SFC proxy and the SF; however, this is an intrinsic part of the SFC design, which needs to define how a packet is protected in that environment.
分類子が完全に信頼できる要素であることは、SFC設計の基本です。つまり、分類決定プロセスは他の要素からは見えず、その出力は正確なものとして扱われます。そのため、分類子は、パケットが受ける処理（ファイアウォール機能など）を決定する責任があります。また、MPLS設計の基本は、ラベルを適用するノードによって指定されたパスを使用してパケットがネットワークを介してルーティングされること、およびラベルが正しく交換またはポップされることです。 SFがカプセル化に対応していない場合、SFCプロキシとSFの間のパスにネイティブパケット（おそらくIP）としてパケットが存在するように、SFCプロキシによってカプセル化が取り除かれます。ただし、これはSFC設計の本質的な部分であり、その環境でパケットを保護する方法を定義する必要があります。
SFC components are configured and enabled through a management system or a control plane. This document does not make any assumptions about what mechanisms are used. Deployments should, however, be aware that vulnerabilities in the management plane or control plane of an SFC system imply vulnerabilities in the whole SFC system. Thus, control-plane solutions (such as [BGP-NSH-SFC]) and management-plane mechanisms must include security measures that can be enabled by operators to protect their SFC systems.
SFCコンポーネントは、管理システムまたはコントロールプレーンを介して構成および有効化されます。このドキュメントでは、どのメカニズムが使用されているかについては想定していません。ただし、展開では、SFCシステムの管理プレーンまたはコントロールプレーンの脆弱性はSFCシステム全体の脆弱性を意味することに注意してください。したがって、コントロールプレーンソリューション（[BGP-NSH-SFC]など）および管理プレーンメカニズムには、オペレーターがSFCシステムを保護できるようにするセキュリティ対策を含める必要があります。
An analysis of the security of MPLS systems is provided in [RFC5920], which also notes that the MPLS forwarding plane has no built-in security mechanisms. Some proposals to add encryption to the MPLS forwarding plane have been suggested [MPLS-Opp-Sec], but no mechanisms have been agreed upon at the time of publication of this document. Additionally, MPLS does not provide any cryptographic integrity protection on the MPLS headers. That means that procedures described in this document rely on three basic principles:
MPLSシステムのセキュリティの分析は[RFC5920]で提供されており、MPLSフォワーディングプレーンにはセキュリティメカニズムが組み込まれていないことにも言及しています。 MPLSフォワーディングプレーンに暗号化を追加するいくつかの提案が提案されていますが[MPLS-Opp-Sec]、このドキュメントの公開時点でメカニズムは合意されていません。さらに、MPLSはMPLSヘッダーに暗号化整合性保護を提供しません。つまり、このドキュメントで説明する手順は、次の3つの基本原則に依存しています。
o The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible. MPLS networks are operated with closed boundaries so that MPLS-encapsulated packets are not admitted to the network, and MPLS headers are stripped before packets are forwarded from the network. This is particularly pertinent in the SFC context because [RFC7665] notes that "The architecture described herein is assumed to be applicable to a single network administrative domain." Furthermore, [RFC8300] states that packets originating outside the SFC-enabled domain MUST be dropped if they contain an NSH and packets exiting the SFC-enabled domain MUST be dropped if they contain an NSH. These constraints apply equally to the use of MPLS to encode a logical representation of the NSH.
o MPLSネットワークは、外部の当事者によるパケットの挿入、変更、または検査ができないような閉じたネットワークと見なされることがよくあります。 MPLSネットワークは閉じた境界で動作するため、MPLSカプセル化パケットはネットワークに許可されず、パケットがネットワークから転送される前にMPLSヘッダーが削除されます。 [RFC7665]が「ここで説明されているアーキテクチャは単一のネットワーク管理ドメインに適用できると想定されている」と述べているため、これはSFCコンテキストで特に適切です。さらに、[RFC8300]は、NFCが含まれている場合はSFC対応ドメイン外から発信されたパケットをドロップする必要があり、NSHが含まれている場合はSFC対応ドメインから出るパケットをドロップする必要があると述べています。これらの制約は、MPLSを使用してNSHの論理表現をエンコードする場合にも同様に適用されます。
o The underlying transport mechanisms (such as Ethernet) between adjacent MPLS nodes may offer security mechanisms that can be used to defend packets "on the wire".
o 隣接するMPLSノード間の基盤となるトランスポートメカニズム（イーサネットなど）は、パケットを「ネットワーク上」で防御するために使用できるセキュリティメカニズムを提供します。
o The SFC-capable devices participating in an SFC system are responsible for verifying and protecting payload packets and their contents as well as providing other security capabilities that might be required in the particular system.
o SFCシステムに参加しているSFC対応デバイスは、ペイロードパケットとその内容を検証および保護するだけでなく、特定のシステムで必要になる可能性のあるその他のセキュリティ機能も提供します。
Additionally, where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how the tunnel is secured.
さらに、トンネルを使用して2つの非MPLSドメインをリンクする場合、トンネルの設計では、トンネルの保護方法を指定する必要があります。
Thus, this design relies on the component underlying technologies to address the potential security vulnerabilities, and it documents the necessary protections (or risk of their absence) above. It does not include any native security mechanisms in-band with the MPLS encoding of the NSH functionality.
したがって、この設計は潜在的なセキュリティの脆弱性に対処するためにコンポーネントの基盤となるテクノロジーに依存し、上記の必要な保護（またはそれらが存在しないリスク）を文書化します。 NSH機能のMPLSエンコードを使用したインバンドのネイティブセキュリティメカニズムは含まれていません。
Note that configuration elements of this system (such as the programming of the table of metadata; see Section 12) must also be adequately secured, although such mechanisms are not in scope for this protocol specification.
このようなメカニズムはこのプロトコル仕様の範囲外ですが、このシステムの構成要素（メタデータのテーブルのプログラミングなど、セクション12を参照）も適切に保護する必要があります。
No known new security vulnerabilities over the SFC architecture [RFC7665] and the NSH specification [RFC8300] are introduced by this design, but if issues are discovered in the future, it is expected that they will be addressed through modifications to control/ management components of any solution or through changes to the underlying technology.
SFCアーキテクチャ[RFC7665]およびNSH仕様[RFC8300]を介した既知の新しいセキュリティの脆弱性はこの設計によって導入されていませんが、将来問題が発見された場合、それらの制御/管理コンポーネントの変更を通じて対処されることが期待されますソリューション、または基盤となるテクノロジーの変更を通じて。
IANA has made allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows:
IANAは、「特殊用途マルチプロトコルラベルスイッチング（MPLS）ラベル値」レジストリの「拡張特殊用途MPLSラベル値」サブレジストリから次のように割り当てを行いました。
Value | Description | Reference
-------+-----------------------------------+--------------
16 | Metadata Label Indicator (MLI) | RFC 8595
17 | Metadata Present Indicator (MPI) | RFC 8595
[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>。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、and L. Yong、 "The Use of Entropy Labels in MPLS Forwarding"、RFC 6790、DOI 10.17487 / RFC6790、November 2012、 <https://www.rfc-editor.org/info/rfc6790>。
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.
[RFC7274] Kompella、K.、Andersson、L。、およびA. Farrel、「特別な目的のMPLSラベルの割り当てと廃止」、RFC 7274、DOI 10.17487 / RFC7274、2014年6月、<https：//www.rfc-editor .org / info / rfc7274>。
[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>。
[RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, <https://www.rfc-editor.org/info/rfc8393>.
[RFC8393] Farrel、A。およびJ. Drake、「Operating the Network Service Header（NSH）with Next Protocol "None"」、RFC 8393、DOI 10.17487 / RFC8393、2018年5月、<https：//www.rfc-editor .org / info / rfc8393>。
[BGP-NSH-SFC] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-11, May 2019.
[BGP-NSH-SFC] Farrel、A.、Drake、J.、Rosen、E.、Uttaro、J。、およびL. Jalil、「BGP Control Plane for NSH SFC」、Work in Progress、draft-ietf-bess -nsh-bgp-control-plane-11、2019年5月。
[MPLS-Opp-Sec] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-03, March 2017.
[MPLS-Opp-Sec] Farrel、A。およびS. Farrell、「MPLSネットワークにおけるオポチュニスティックセキュリティ」、Work in Progress、draft-ietf-mpls-opportunistic-encrypt-03、2017年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[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>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>.
[RFC8459] Dolson、D.、Honma、S.、Lopez、D。、およびM. Boucadair、「Hierarchical Service Function Chaining（hSFC）」、RFC 8459、DOI 10.17487 / RFC8459、2018年9月、<https：// www .rfc-editor.org / info / rfc8459>。
[SR-Srv-Prog] Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, draft-xuclad-spring-sr-service-programming-02, April 2019.
[SR-Srv-Prog]クラッド、F。、編、Xu、X。、編、Filsfils、C。、ベルニエ、D.、Li、C.、Decraene、B.、Ma、S.、Yadlapalli、 C.、Henderickx、W。、およびS. Salsano、「セグメントルーティングによるサービスプログラミング」、進行中の作業、draft-xuclad-spring-sr-service-programming-02、2019年4月。
Acknowledgements
謝辞
This document derives ideas and text from [BGP-NSH-SFC]. The authors are grateful to all those who contributed to the discussions that led to that work: Loa Andersson, Andrew G. Malis, Alexander (Sasha) Vainshtein, Joel Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments.
このドキュメントは、[BGP-NSH-SFC]からアイデアとテキストを導き出します。著者は、その作業につながった議論に貢献したすべての人に感謝します：ロアアンダーソン、アンドリューG.マリ、アレクサンダー（サーシャ）ヴァインシュタイン、ジョエルハルパーン、トニープルジギンダ、スチュアートマッキー、キールパテル、ジムギチャード。 Loa Anderssonは、役立つレビューコメントを提供しました。
Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text. Thanks to Russ Mundy for his Security Directorate review and to S Moonesamy for useful discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for comprehensive reviews during IESG evaluation.
このテキストのレビューを提供してくれたLoa Andersson、Lizhong Jin、Matthew Bocci、Joel Halpern、およびMach Chenに感謝します。 Russ MundyのSecurity DirectorateのレビューとSムーネサミーの有益な議論に感謝します。 IESG評価中の包括的なレビューを提供してくれたBenjamin Kaduk、Alissa Cooper、Eric Rescorla、Mirja Kuehlewind、Alvaro Retana、Martin Vigoureuxにも感謝します。
The authors would like to be able to thank the authors of [SR-Srv-Prog] and [RFC8402] whose original work on service chaining and the identification of services using Segment Identifiers (SIDs), and conversation with whom, helped clarify the application of SR-MPLS to SFC.
[SR-Srv-Prog]と[RFC8402]の作成者に感謝します。サービスの連鎖とセグメント識別子（SID）を使用したサービスの識別に関する最初の作業、およびアプリケーションの明確化に貢献した対話者に感謝します。 SR-MPLSのSFCへの。
Particular thanks to Loa Andersson for conversations and advice about working group process.
作業グループのプロセスに関する会話とアドバイスを提供してくれたLoa Anderssonに特に感謝します。
Contributors
貢献者
The following individual contributed text to this document:
次の個人がこのドキュメントにテキストを寄稿しました。
Andrew G. Malis Email: agmalis@gmail.com
Andrew G. Malisメール：agmalis@gmail.com
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Email: adrian@olddog.co.uk
Stewart Bryant Futurewei
スチュワートブライアントフューチャーウェイ
Email: stewart.bryant@gmail.com
John Drake Juniper Networks
ジョンドレイクジュニパーネットワークス
Email: jdrake@juniper.net