[要約] RFC 9491は、NSHとSegment Routingを統合し、SFCを効率的にサポートすることを目的としており、サービスとトランスポートプレーンの分離を維持します。NSHとSRの組み合わせにより、ネットワークオペレーターは特定のネットワークインフラ領域で意味のある輸送技術を使用しながら、NSHを使用してエンドツーエンドのサービスプレーンを維持できることを示しています。
Internet Engineering Task Force (IETF) J. Guichard, Ed.
Request for Comments: 9491 Futurewei Technologies
Category: Standards Track J. Tantsura, Ed.
ISSN: 2070-1721 Nvidia
November 2023
This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.
このドキュメントでは、ネットワークサービスヘッダー（NSH）およびセグメントルーティング（SR）の統合、およびカプセル化の詳細について、SFCが元々意図したサービスと輸送機の分離を維持しながら、サービス機能チェーン（SFC）を効率的にサポートすることについて説明します。建築。
Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a given Service Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.
これらのテクノロジーを組み合わせることで、SRは特定のサービス関数パス（SFP）に沿ってサービス関数フォワード（SFF）間のステアリングパケットに使用できますが、NSHはサービスプレーンの整合性、SFCインスタンスコンテキスト、および関連するすべてのものを維持する責任があります。メタデータ。
This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH.
この統合は、NSHとSRが協力して作業し、ネットワークオペレーターにネットワークインフラストラクチャの特定の分野で理にかなっている輸送技術を使用する柔軟性を提供しながら、NSHを使用してエンドツーエンドのサービスプレーンを維持できることを示しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9491.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9491で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. SFC Overview and Rationale
1.2. Requirements Language
2. SFC within Segment Routing Networks
3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel
4. SR-Based SFC with the Integrated NSH Service Plane
5. Packet Processing for SR-Based SFC
5.1. SR-Based SFC (SR-MPLS) Packet Processing
5.2. SR-Based SFC (SRv6) Packet Processing
6. Encapsulation
6.1. NSH Using SR-MPLS Transport
6.2. NSH Using SRv6 Transport
7. Security Considerations
8. Backwards Compatibility
9. Caching Considerations
10. MTU Considerations
11. IANA Considerations
11.1. Protocol Number for the NSH
11.2. SRv6 Endpoint Behavior for the NSH
12. References
12.1. Normative References
12.2. Informative References
Contributors
Authors' Addresses
The dynamic enforcement of a service-derived and adequate forwarding policy for packets entering a network that supports advanced Service Functions (SFs) has become a key challenge for network operators. For instance, cascading SFs at the Third Generation Partnership Project (3GPP) Gi interface (N6 interface in 5G architecture) has shown limitations such as 1) redundant classification features that must be supported by many SFs to execute their function; 2) some SFs that receive traffic that they are not supposed to process (e.g., TCP proxies receiving UDP traffic), which inevitably affects their dimensioning and performance; and 3) an increased design complexity related to the properly ordered invocation of several SFs.
Advanced Service Functions（SFS）をサポートするネットワークを入力するパケットのサービス由来の適切な転送ポリシーの動的施行は、ネットワークオペレーターにとって重要な課題となっています。たとえば、第3世代パートナーシッププロジェクト（3GPP）GIインターフェイス（5GアーキテクチャのN6インターフェイス）でのSFSのカスケードは、1）機能を実行するために多くのSFSによってサポートされなければならない冗長分類機能などの制限を示しています。2）処理することになっていないトラフィックを受け取る一部のSF（たとえば、UDPトラフィックを受信するTCPプロキシ）は、必然的にその寸法とパフォーマンスに影響を与えます。3）いくつかのSFの適切に順序付けられた呼び出しに関連する設計の複雑さの増加。
In order to solve those problems and to decouple the service's topology from the underlying physical network while allowing for simplified service delivery, SFC techniques have been introduced [RFC7665].
これらの問題を解決し、基礎となる物理ネットワークからサービスのトポロジを分離しながら、単純化されたサービス提供を可能にするために、SFC技術が導入されました[RFC7665]。
SFC techniques are meant to rationalize the service delivery logic and reduce the resulting complexity while optimizing service activation time cycles for operators that need more agile service delivery procedures to better accommodate ever-demanding customer requirements. SFC allows network operators to dynamically create service planes that can be used by specific traffic flows. Each service plane is realized by invoking and chaining the relevant service functions in the right sequence. [RFC7498] provides an overview of the overall SFC problem space, and [RFC7665] specifies an SFC data plane architecture. The SFC architecture does not make assumptions on how advanced features (e.g., load balancing, loose or strict service paths) could be enabled within a domain. Various deployment options are made available to operators with the SFC architecture; this approach is fundamental to accommodate various and heterogeneous deployment contexts.
SFCテクニックは、サービス提供のロジックを合理化し、結果として生じる複雑さを軽減することを目的としています。また、これまでにない顧客の要件に対応するために、よりアジャイルなサービス提供手順を必要とするオペレーターのサービスアクティベーション時間サイクルを最適化します。SFCを使用すると、ネットワークオペレーターは、特定のトラフィックフローで使用できるサービスプレーンを動的に作成できます。各サービスプレーンは、関連するサービス機能を右シーケンスで呼び出してチェーンすることで実現されます。[RFC7498]は、SFCの全体的な問題スペースの概要を提供し、[RFC7665]はSFCデータプレーンアーキテクチャを指定します。SFCアーキテクチャは、ドメイン内で高度な機能（ロードバランシング、ルーズ、または厳格なサービスパスなど）をどのように有効にするかについて仮定しません。SFCアーキテクチャを使用して、さまざまな展開オプションがオペレーターが利用できるようにします。このアプローチは、さまざまな不均一な展開コンテキストに対応するための基本です。
Many approaches can be considered for encoding the information required for SFC purposes (e.g., communicate a service chain pointer, encode a list of loose/explicit paths, or disseminate a service chain identifier together with a set of context information). Likewise, many approaches can also be considered for the channel to be used to carry SFC-specific information (e.g., define a new header, reuse existing packet header fields, or define an IPv6 extension header). Among all these approaches, the IETF created a transport-independent SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic, as it does not require replicating the same specification effort as a function of underlying transport encapsulation. Moreover, this design approach encourages consistent SFC-based service delivery in networks enabling distinct transport protocols in various network segments or even between SFFs vs. SF-SFF hops.
SFCの目的に必要な情報をエンコードするために、多くのアプローチを考慮します（たとえば、サービスチェーンポインターを伝えたり、ルーズ/明示的なパスのリストをエンコードしたり、コンテキスト情報のセットと一緒にサービスチェーン識別子を広めたりします）。同様に、チャネルを使用してSFC固有の情報を運ぶために多くのアプローチを考慮することもできます（たとえば、新しいヘッダーを定義したり、既存のパケットヘッダーフィールドを再利用したり、IPv6拡張ヘッダーを定義したりします）。これらすべてのアプローチの中で、IETFはトランスポートに依存しないSFCカプセル化スキームを作成しました：NSH [RFC8300]。基礎となる輸送カプセル化の関数と同じ仕様の取り組みを複製する必要はないため、この設計は実用的です。さらに、この設計アプローチは、ネットワークでの一貫したSFCベースのサービス提供を促進し、さまざまなネットワークセグメントで、またはSFFとSF-SFFホップ間でさえ、異なる輸送プロトコルを可能にします。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC8300] specifies how to encapsulate the NSH directly within a link-layer header. In this document, IANA has assigned IP protocol number 145 for the NSH so that it can also be encapsulated directly within an IP header. The procedures that follow make use of this property.
[RFC8300]は、リンク層ヘッダー内でNSHを直接カプセル化する方法を指定します。このドキュメントでは、IANAがNSHにIPプロトコル番号145を割り当てているため、IPヘッダー内に直接カプセル化できます。このプロパティを使用する手順。
As described in [RFC8402], SR leverages the source-routing technique. Concretely, a node steers a packet through an SR policy instantiated as an ordered list of instructions called segments. While initially designed for policy-based source routing, SR also finds its application in supporting SFC [SERVICE-PROGRAMMING].
[RFC8402]で説明されているように、SRはソースルーティング手法を活用します。具体的には、ノードは、セグメントと呼ばれる命令のリストとしてインスタンス化されたSRポリシーを介してパケットを操縦します。当初、ポリシーベースのソースルーティング用に設計されていますが、SRはSFC [サービスプログラミング]のサポートに適用されます。
The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and Segment Routing over IPv6 (SRv6) [RFC8754], can encode an SF as a segment so that a service function chain can be specified as a segment list. Nevertheless, and as discussed in [RFC7498], traffic steering is only a subset of the issues that motivated the design of the SFC architecture. Further considerations, such as simplifying classification at intermediate SFs and allowing for coordinated behaviors among SFs by means of supplying context information (a.k.a. metadata), should be considered when designing an SFC data plane solution.
2つのSRデータプレーンのカプセル、つまりSR-MPLS [RFC8660]とIPv6（SRV6）[RFC8754]のセグメントルーティングは、SFをセグメントとしてエンコードして、サービス機能チェーンをセグメントリストとして指定できるようにすることができます。それにもかかわらず、[RFC7498]で議論されているように、トラフィックステアリングは、SFCアーキテクチャの設計を動機付けた問題のサブセットにすぎません。中間SFでの分類を簡素化したり、コンテキスト情報を提供したりすることでSFS間の調整された動作を可能にするなどのさらなる考慮事項を、SFCデータプレーンソリューションを設計する際に考慮する必要があります。
While each scheme (i.e., NSH-based SFC and SR-based SFC) can work independently, this document describes how the two can be used together in concert and to complement each other through two representative application scenarios. Both application scenarios may be supported using either SR-MPLS or SRv6:
各スキーム（つまり、NSHベースのSFCおよびSRベースのSFC）は独立して動作することができますが、このドキュメントでは、2つの代表的なアプリケーションシナリオを通じて2つを一緒に使用し、互いに補完する方法について説明します。両方のアプリケーションシナリオは、SR-MPLSまたはSRV6のいずれかを使用してサポートされる場合があります。
NSH-based SFC with the SR-based transport plane:
SRベースの輸送面を備えたNSHベースのSFC：
In this scenario, SR-MPLS or SRv6 provides the transport encapsulation between SFFs, while the NSH is used to convey and trigger SFC policies.
このシナリオでは、SR-MPLSまたはSRV6はSFF間の輸送カプセル化を提供し、NSHはSFCポリシーを伝達およびトリガーするために使用されます。
SR-based SFC with the integrated NSH service plane:
統合されたNSHサービスプレーンを備えたSRベースのSFC：
In this scenario, each service hop of the service function chain is represented as a segment of the SR segment list. SR is thus responsible for steering traffic through the necessary SFFs as part of the segment routing path, while the NSH is responsible for maintaining the service plane and holding the SFC instance context (including associated metadata).
このシナリオでは、サービス関数チェーンの各サービスホップは、SRセグメントリストのセグメントとして表されます。したがって、SRは、セグメントルーティングパスの一部として必要なSFFを介してトラフィックを操縦する責任がありますが、NSHはサービスプレーンを維持し、SFCインスタンスコンテキスト（関連するメタデータを含む）を保持する責任があります。
Of course, it is possible to combine both of these two scenarios to support specific deployment requirements and use cases.
もちろん、これら2つのシナリオの両方を組み合わせて、特定の展開要件とユースケースをサポートすることができます。
A classifier MUST use one NSH Service Path Identifier (SPI) for each SR policy so that different traffic flows can use the same NSH Service Function Path (SFP) and different SR policies can coexist on the same SFP without conflict during SFF processing.
分類器は、各SRポリシーに1つのNSHサービスパス識別子（SPI）を使用して、異なるトラフィックフローが同じNSHサービス関数パス（SFP）を使用できるようにする必要があり、SFF処理中に異なるSRポリシーが同じSFPで共存できます。
Because of the transport-independent nature of NSH-based service function chains, it is expected that the NSH has broad applicability across different network domains (e.g., access, core). By way of illustration, the various SFs involved in a service function chain may be available in a single data center or spread throughout multiple locations (e.g., data centers, different Points of Presence (POPs)), depending upon the network operator preference and/or availability of service resources. Regardless of where the SFs are deployed, it is necessary to provide traffic steering through a set of SFFs, and when NSH and SR are integrated, this is provided by SR-MPLS or SRv6.
NSHベースのサービス関数チェーンの輸送に依存しない性質のため、NSHは異なるネットワークドメイン（アクセス、コアなど）にわたって幅広い適用可能性があると予想されます。図として、サービス機能チェーンに関与するさまざまなSFSは、単一のデータセンターで利用できるか、複数の場所（例：データセンター、異なる存在点（POP））に広がる場合があります。またはサービスリソースの可用性。SFSが展開される場所に関係なく、SFFのセットを介してトラフィックステアリングを提供する必要があります。NSHとSRが統合される場合、これはSR-MPLSまたはSRV6によって提供されます。
The following three figures provide an example of an SFC-established flow F that has SF instances located in different data centers, DC1 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 100 and the initial Service Index (SI) be 255.
次の3つの図は、さまざまなデータセンター、DC1およびDC2にあるSFインスタンスを備えたSFCが確立したフローFの例を示しています。イラストの目的のために、SFCのNSH SPIを100にし、初期サービスインデックス（SI）を255にします。
Referring to Figure 1, packets of flow F in DC1 are classified into an NSH-based service function chain, encapsulated after classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport>, and forwarded to SFF1 (which is the first SFF hop for this service function chain).
図1を参照すると、DC1のフローFのパケットは、<インナーPKT> <NSH：SPI 100、SI 255> <外輸送>、およびSFF1に転送され、分類後にカプセル化されたNSHベースのサービス関数チェーンに分類されます（これは、このサービス機能チェーンの最初のSFFホップです）。
After removing the outer transport encapsulation, SFF1 uses the SPI and SI carried within the NSH encapsulation to determine that it should forward the packet to SF1. SF1 applies its service, decrements the SI by 1, and returns the packet to SFF1. Therefore, SFF1 has <SPI 100, SI 254> when the packet comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254>, which results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.
外側の輸送カプセル化を削除した後、SFF1はNSHカプセル化内で運ばれたSPIとSIを使用して、パケットをSF1に転送する必要があると判断します。SF1はサービスを適用し、SIを1除去し、パケットをSFF1に返します。したがって、SFF1は、パケットがSF1から戻ってきたときに<SPI 100、SI 254>を持っています。SFF1は、<SPI 100、SI 254>を検索し、<next-hop：dc1-gw1>になり、パケットをDC1-GW1に転送します。
+--------------------------- DC1 ----------------------------+
| +-----+ |
| | SF1 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,255) | | | N(100,254) | |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | F:Inner Pkt| |
| +------------+ ^ | | +------------+ |
| (2) | | | (3) |
| | | v |
| (1) | (4) |
|+------------+ ----> +--+---+ ----> +---------+ |
|| | NSH | | NSH | | |
|| Classifier +------------+ SFF1 +--------------+ DC1-GW1 + |
|| | | | | | |
|+------------+ +------+ +---------+ |
| |
| +------------+ +------------+ |
| | N(100,255) | | N(100,254) | |
| +------------+ +------------+ |
| | F:Inner Pkt| | F:Inner Pkt| |
| +------------+ +------------+ |
| |
+------------------------------------------------------------+
Figure 1: SR for Inter-DC SFC - Part 1
図1：DC Inter -DC SFCのSR-パート1
Referring now to Figure 2, DC1-GW1 performs a lookup using the information conveyed in the NSH, which results in <next-hop: DC2-GW1, encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or SRv6, has the SR segment list to forward the packet across the inter-DC network to DC2.
現在、図2を参照して、DC1-GW1はNSHで伝えられた情報を使用してルックアップを実行します。その結果、<next-hop：dc2-gw1、capsulation：sr>になります。SR-MPLSまたはSRV6である可能性のあるSRのカプセル化には、SRセグメントリストがあり、PacketをDC2に転送するパケットをDC2に転送します。
+----------- Inter DC ----------------+
(4) | (5) |
+------+ ----> | +---------+ ----> +---------+ |
| | NSH | | | SR | | |
+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
| | | | | | | |
+------+ | +---------+ +---------+ |
| |
| +------------+ |
| | S(DC2-GW1) | |
| +------------+ |
| | N(100,254) | |
| +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+-------------------------------------+
Figure 2: SR for Inter-DC SFC - Part 2
図2：DC Inter -DC SFCのSR-パート2
When the packet arrives at DC2, as shown in Figure 3, the SR encapsulation is removed, and DC2-GW1 performs a lookup on the NSH, which results in next hop: SFF2. When SFF2 receives the packet, it performs a lookup on <NSH: SPI 100, SI 254> and determines to forward the packet to SF2. SF2 applies its service, decrements the SI by 1, and returns the packet to SFF2. Therefore, SFF2 has <NSH: SPI 100, SI 253> when the packet comes back from SF2. SFF2 does a lookup on <NSH: SPI 100, SI 253>, which results in the end of the service function chain.
図3に示すように、パケットがDC2に到着すると、SRのカプセル化が削除され、DC2-GW1がNSHのルックアップを実行し、次のHOP：SFF2になります。SFF2がパケットを受信すると、<NSH：SPI 100、SI 254>のルックアップを実行し、パケットをSF2に転送することを決定します。SF2はサービスを適用し、SIを1縮小し、パケットをSFF2に返します。したがって、SFF2には<nsh：SPI 100、SI 253>パケットがSF2から戻ってきたとき。SFF2は<NSH：SPI 100、SI 253>を検索します。これにより、サービス機能チェーンが終了します。
+------------------------ DC2 ----------------------+
| +-----+ |
| | SF2 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,254) | | | N(100,253) | |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | F:Inner Pkt| |
| +------------+ ^ | | +------------+ |
| (7) | | | (8) |
| | | v |
(5) | (6) | (9) |
+---------+ ---> | +----------+ ----> +--+---+ ----> |
| | SR | | | NSH | | IP |
+ DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | |
| | | | | | | |
+---------+ | +----------+ +------+ |
| |
| +------------+ +------------+ |
| | N(100,254) | | F:Inner Pkt| |
| +------------+ +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+---------------------------------------------------+
Figure 3: SR for Inter-DC SFC - Part 3
図3：DC Inter -DC SFCのSR-パート3
The benefits of this scheme are listed hereafter:
このスキームの利点は、以下にリストされています。
* The network operator is able to take advantage of the transport-independent nature of the NSH encapsulation while the service is provisioned end-to-end.
* ネットワークオペレーターは、サービスがエンドツーエンドでプロビジョニングされている間、NSHカプセル化の輸送に依存しない性質を活用することができます。
* The network operator is able to take advantage of the traffic-steering (traffic-engineering) capability of SR where appropriate.
* ネットワークオペレーターは、必要に応じてSRのトラフィックステアリング（トラフィックエンジニアリング）機能を活用できます。
* Clear responsibility division and scope between the NSH and SR.
* NSHとSRの間の明確な責任部門と範囲。
Note that this scenario is applicable to any case where multiple segments of a service function chain are distributed across multiple domains or where traffic-engineered paths are necessary between SFFs (strict forwarding paths, for example). Further, note that the above example can also be implemented using end-to-end segment routing between SFF1 and SFF2. (As such, DC-GW1 and DC-GW2 are forwarding the packets based on segment routing instructions and are not looking at the NSH header for forwarding.)
このシナリオは、サービス関数チェーンの複数のセグメントが複数のドメインに分布している場合、またはSFFの間にトラフィックエンジニアリングパスが必要な場合（たとえば、厳格転送パス）に適用できることに注意してください。さらに、上記の例は、SFF1とSFF2の間のエンドツーエンドセグメントルーティングを使用して実装できることに注意してください。（そのため、DC-GW1とDC-GW2は、セグメントルーティング命令に基づいてパケットを転送しており、NSHヘッダーを転送することはありません。）
In this scenario, we assume that the SFs are NSH-aware; therefore, it should not be necessary to implement an SFC proxy to achieve SFC. The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF transport and the NSH to provide the service plane between SFs, thereby maintaining SFC context (e.g., the service plane path referenced by the SPI) and any associated metadata.
このシナリオでは、SFSがNSH-Awareであると想定しています。したがって、SFCを達成するためにSFCプロキシを実装する必要はありません。操作は、SR-MPLSまたはSRV6に依存してSFF-SFFトランスポートとNSHを実行してSFS間のサービスプレーンを提供し、SFCコンテキスト（SPIが参照するサービスプレーンパスなど）および関連するメタデータを維持します。
When a service function chain is established, a packet associated with that chain will first carry an NSH that will be used to maintain the end-to-end service plane through use of the SFC context. The SFC context is used by an SFF to determine the SR segment list for forwarding the packet to the next-hop SFFs. The packet is then encapsulated using the SR header and forwarded in the SR domain following normal SR operations.
サービス機能チェーンが確立されると、そのチェーンに関連付けられたパケットは、最初にSFCコンテキストを使用してエンドツーエンドのサービスプレーンを維持するために使用されるNSHを運びます。SFCコンテキストは、SFFによって使用され、パケットをNext-Hop SFFに転送するためのSRセグメントリストを決定します。その後、パケットはSRヘッダーを使用してカプセル化され、通常のSR操作に続いてSRドメインに転送されます。
When a packet has to be forwarded to an SF attached to an SFF, the SFF performs a lookup on the segment identifier (SID) associated with the SF. In the case of SR-MPLS, this will be a Prefix-SID [RFC8402]. In the case of SRv6, the behavior described within this document is assigned the name END.NSH, and Section 11.2 describes the allocation of the code point by IANA. The result of this lookup allows the SFF to retrieve the next-hop context between the SFF and SF (e.g., the destination Media Access Control (MAC) address in case Ethernet encapsulation is used between the SFF and SF). In addition, the SFF strips the SR information from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to encapsulate and forward the packet(s) coming back from the SF.
パケットをSFFに接続したSFに転送する必要がある場合、SFFはSFに関連付けられたセグメント識別子（SID）のルックアップを実行します。SR-MPLSの場合、これはプレフィックスSID [RFC8402]になります。SRV6の場合、このドキュメント内で説明されている動作には名前end.nshが割り当てられ、セクション11.2にはIANAによるコードポイントの割り当てについて説明します。このルックアップの結果、SFFはSFFとSFの間の次のホップコンテキストを取得できます（たとえば、SFFとSFの間でイーサネットのカプセル化が使用された場合、宛先メディアアクセス制御（MAC）アドレス）。さらに、SFFはパケットからSR情報をストリップし、SR情報を更新し、NSHサービスパス識別子（SPI）によってインデックスを付けたキャッシュに保存し、1により減少したサービスインデックス（SI）が保存します。SFから戻ってくるパケットをカプセル化して転送するために使用されます。
The behavior of remembering the SR segment list occurs at the end of the regularly defined logic. The behavior of reattaching the segment list occurs before the SR process of forwarding the packet to the next entry in the segment list. Both behaviors are further detailed in Section 5.
SRセグメントリストを記憶する動作は、定期的に定義されたロジックの最後に発生します。セグメントリストの再触媒の動作は、SRパケットをセグメントリストの次のエントリに転送するSRプロセスの前に発生します。両方の動作については、セクション5でさらに詳しく説明しています。
When the SF receives the packet, it processes it as usual. When the SF is co-resident with a classifier, the already-processed packet may be reclassified. The SF sends the packet back to the SFF. Once the SFF receives this packet, it extracts the SR information using the NSH SPI and SI as the index into the cache. The SFF then pushes the retrieved SR header on top of the NSH header and forwards the packet to the next segment in the segment list. The lookup in the SFF cache might fail if reclassification at the SF changed the NSH SPI and/or SI to values that do not exist in the SFF cache. In such a case, the SFF must generate an error and drop the packet.
SFがパケットを受信すると、通常どおり処理します。SFが分類器と共同居住者である場合、すでに加工されたパケットが再分類される可能性があります。SFはパケットをSFFに送り返します。SFFがこのパケットを受信すると、NSH SPIとSIを使用してSR情報をキャッシュにインデックスとして抽出します。SFFは、NSHヘッダーの上に検索されたSRヘッダーを押し、パケットをセグメントリストの次のセグメントに転送します。SFでの再分類がNSH SPIおよび/またはSIをSFFキャッシュに存在しない値に変更した場合、SFFキャッシュのルックアップが失敗する可能性があります。そのような場合、SFFはエラーを生成し、パケットをドロップする必要があります。
Figure 4 illustrates an example of this scenario.
図4は、このシナリオの例を示しています。
+-----+ +-----+
| SF1 | | SF2 |
+--+--+ +--+--+
| |
| |
+-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) |
+-----------+ | +-----------+ +-----------+ | +-----------+
|F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt|
+-----------+ | +-----------+ +-----------+ | +-----------+
(2) ^ | (3) | (5) ^ | (6) |
| | | | | |
| | | | | |
(1) | | v (4) | | v (7)
+------------+ ---> +-+----+ ----> +---+--+ -->
| | NSHoverSR | | NSHoverSR | | IP
| Classifier +-----------+ SFF1 +---------------------+ SFF2 |
| | | | | |
+------------+ +------+ +------+
+------------+ +------------+ +------------+
| S(SF1) | | S(SF2) | | F:Inner Pkt|
+------------+ +------------+ +------------+
| S(SFF2) | | N(100,254) |
+------------+ +------------+
| S(SF2) | | F:Inner Pkt|
+------------+ +------------+
| N(100,255) |
+------------+
| F:Inner Pkt|
+------------+
Figure 4: NSH over SR for SFC
図4：SFCのSR上のNSH
The benefits of this scheme include the following:
このスキームの利点には、以下が含まれます。
* It is economically sound for SF vendors to only support one unified SFC solution. The SF is unaware of the SR.
* SFベンダーが1つの統一されたSFCソリューションのみをサポートすることは経済的に健全です。SFはSRを認識していません。
* It simplifies the SFF (i.e., the SR router) by nullifying the needs for reclassification and SR proxy.
* 再分類とSRプロキシのニーズを無効にすることにより、SFF（つまり、SRルーター）を簡素化します。
* SR is also used for forwarding purposes, including between SFFs.
* SRは、SFF間を含む転送目的にも使用されます。
* It takes advantage of SR to eliminate the NSH forwarding state in SFFs. This applies each time strict or loose SFPs are in use.
* SRを利用して、SFFSのNSH転送状態を排除します。これは、厳格または緩いSFPが使用されているたびに適用されます。
* It requires no interworking, as would be the case if SR-MPLS-based SFC and NSH-based SFC were deployed as independent mechanisms in different parts of the network.
* SR-MPLSベースのSFCおよびNSHベースのSFCがネットワークのさまざまな部分で独立したメカニズムとして展開された場合のように、インターワーキングは必要ありません。
This section describes the End.NSH behavior (SRv6), Prefix-SID behavior (SR-MPLS), and NSH processing logic.
このセクションでは、end.NSHの動作（SRV6）、プレフィックスシドの動作（SR-MPLS）、およびNSH処理ロジックについて説明します。
When an SFF receives a packet destined to S and S is a local Prefix-SID associated with an SF, the SFF strips the SR segment list (label stack) from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to re-encapsulate and forward the packet(s) coming back from the SF.
SFFがSとSに運命づけられたパケットを受信した場合、SFに関連付けられたローカルプレフィックスSIDである場合、SFFはパケットからSRセグメントリスト（ラベルスタック）をストリップし、SR情報を更新し、それをインデックス付けされたキャッシュに保存しますNSHサービスパス識別子（SPI）とサービスインデックス（SI）は1で減少しました。この保存されたSR情報は、SFから戻ってくるパケットを再カプセル化して転送するために使用されます。
This section describes the End.NSH behavior and NSH processing logic for SRv6. The pseudocode is shown below.
このセクションでは、srv6のend.nshの動作とNSH処理ロジックについて説明します。擬似コードを以下に示します。
When N receives a packet destined to S and S is a local End.NSH SID, the processing is the same as that specified by [RFC8754], Section 4.3.1.1, up through line S15.
nがsとsに運命づけられたパケットを受信する場合、ローカルend.nsh sidである場合、処理は[RFC8754]、セクション4.3.1.1で指定されたものと同じです。
After S15, if S is a local End.NSH SID, then:
S15の後、SがローカルEnd.nsh Sidの場合、次のとおりです。
S15.1. Remove and store IPv6 and SRH headers in local cache
indexed by <NSH: service-path-id, service-index -1>
S15.2. Submit the packet to the NSH FIB lookup and transmit
to the destination associated with <NSH:
service-path-id, service-index>
Note: The End.NSH behavior interrupts the normal SRH packet processing, as described in [RFC8754], Section 4.3.1.1, which does not continue to S16 at this time.
注：END.NSHの動作は、[RFC8754]、セクション4.3.1.1で説明されているように、通常のSRHパケット処理を中断します。
When a packet is returned to the SFF from the SF, reattach the cached IPv6 and SRH headers based on the <NSH: service-path-id, service-index> from the NSH header. Then, resume processing from [RFC8754], Section 4.3.1.1 with line S16.
パケットがSFからSFFに返されると、NSHヘッダーの<nsh：service-path-id、service-index>に基づいて、キャッシュされたIPv6およびSRHヘッダーを再触手します。次に、[RFC8754]、セクション4.3.1.1から行S16から処理を再開します。
SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels; therefore, the segment routing header is a stack of MPLS labels.
SR-MPLSは、MPLSラベルとしてセグメント識別子（SIDS）をインスタンス化します。したがって、セグメントルーティングヘッダーは、MPLSラベルのスタックです。
When carrying an NSH within an SR-MPLS transport, the full encapsulation headers are as illustrated in Figure 5.
SR-MPLSトランスポート内でNSHを運ぶ場合、完全なカプセル化ヘッダーは図5に示されています。
+------------------+
~ SR-MPLS Labels ~
+------------------+
| NSH Base Hdr |
+------------------+
| Service Path Hdr |
+------------------+
~ Metadata ~
+------------------+
Figure 5: NSH Using SR-MPLS Transport
図5：SR-MPLS輸送を使用したNSH
As described in [RFC8402], "[t]he IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID." When an NSH is carried beneath SR-MPLS, it is necessary to terminate the NSH-based SFC at the tail-end node of the SR-MPLS label stack. This can be achieved using either the NEXT or CONTINUE operation.
[rfc8402]で説明されているように、「[t] [t] he Igp-prefixセグメントのIGPシグナル伝達拡張は、プレフィックスが接続されているノードの直接接続された隣接するフラグが含まれています。sid。」NSHがSR-MPLSの下に運ばれる場合、SR-MPLSラベルスタックのテールエンドノードでNSHベースのSFCを終了する必要があります。これは、次の操作または継続操作のいずれかを使用して実現できます。
If the NEXT operation is to be used, then at the end of the SR-MPLS path, it is necessary to provide an indication to the tail end that the NSH follows the SR-MPLS label stack as described by [RFC8596].
次の操作を使用する場合、SR-MPLSパスの最後に、[RFC8596]で記載されているように、NSHがSR-MPLSラベルスタックに従うことをテールエンドに示す必要があります。
If the CONTINUE operation is to be used, this is the equivalent of MPLS Ultimate Hop Popping (UHP); therefore, it is necessary to ensure that the penultimate hop node does not pop the top label of the SR-MPLS label stack and thereby expose the NSH to the wrong SFF. This is realized by setting the No Penultimate Hop Popping (No-PHP) flag in Prefix-SID Sub-TLV [RFC8667] [RFC8665]. It is RECOMMENDED that a specific Prefix-SID be allocated at each node for use by the SFC application for this purpose.
継続操作を使用する場合、これはMPLS Ultimate Hop Popping（UHP）に相当します。したがって、最後から2番目のホップノードがSR-MPLSラベルスタックのトップレーベルをポップしないようにし、それによりNSHを間違ったSFFに公開する必要があります。これは、プレフィックス-SID sub-TLV [RFC8667] [RFC8665]に、最後から2番目のホップポップ（NO-PHP）フラグを設定することで実現されます。この目的のためにSFCアプリケーションで使用するために、特定のプレフィックスシドを各ノードに割り当てることをお勧めします。
When carrying a NSH within an SRv6 transport, the full encapsulation is as illustrated in Figure 6.
SRV6輸送内でNSHを運ぶ場合、完全なカプセル化は図6に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
| | g
| Segment List[0] (128-bit IPv6 address) | m
| | e
| | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
| |
| | R
~ ... ~ o
| | u
| | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| | n
| Segment List[n] (128-bit IPv6 address) | g
| |
| | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
// // H
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Service Path Identifier | Service Index | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| |
~ Variable-Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NSH Using SRv6 Transport
図6：SRV6輸送を使用したNSH
Encapsulation of the NSH following SRv6 is indicated by the IP protocol number for the NSH in the Next Header of the SRH.
SRV6に続くNSHのカプセル化は、SRHの次のヘッダーのNSHのIPプロトコル番号によって示されます。
Generic SFC-related security considerations are discussed in [RFC7665].
一般的なSFC関連のセキュリティ上の考慮事項は、[RFC7665]で説明されています。
NSH-specific security considerations are discussed in [RFC8300].
NSH固有のセキュリティ上の考慮事項は[RFC8300]で説明されています。
Generic security considerations related to segment routing are discussed in Section 7 of [RFC8754] and Section 5 of [RFC8663].
セグメントルーティングに関連する一般的なセキュリティ上の考慮事項は、[RFC8754]のセクション7および[RFC8663]のセクション5で説明されています。
For SRv6/IPv6, if a processing node does not recognize the NSH, it should follow the procedures described in Section 4 of [RFC8200]. For SR-MPLS, if a processing node does not recognize the NSH, it should follow the procedures laid out in Section 3.18 of [RFC3031].
SRV6/IPv6の場合、処理ノードがNSHを認識しない場合、[RFC8200]のセクション4で説明されている手順に従う必要があります。SR-MPLSの場合、処理ノードがNSHを認識していない場合、[RFC3031]のセクション3.18に記載されている手順に従う必要があります。
The cache mechanism must remove cached entries at an appropriate time determined by the implementation. Further, an implementation MAY allow network operators to set the said time value. In the case where a packet arriving from an SF does not have a matching cached entry, the SFF SHOULD log this event and MUST drop the packet.
キャッシュメカニズムは、実装によって決定される適切な時期にキャッシュされたエントリを削除する必要があります。さらに、実装により、ネットワークオペレーターが当該時間値を設定できるようになる場合があります。SFから到着するパケットに一致するキャッシュエントリがない場合、SFFはこのイベントを記録し、パケットをドロップする必要があります。
Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it is RECOMMENDED for network operators to increase the underlying MTU so that SR/NSH traffic is forwarded within an SR domain without fragmentation.
[RFC8300]のセクション5および[RFC8754]のセクション5.3に沿って、ネットワークオペレーターが基礎となるMTUを増やして、SR/NSHトラフィックが断片化なしでSRドメイン内に転送されるようにすることをお勧めします。
IANA has assigned protocol number 145 for the NSH [RFC8300] in the "Assigned Internet Protocol Numbers" registry <https://www.iana.org/assignments/protocol-numbers/>.
IANAは、「割り当てられたインターネットプロトコル番号」レジストリ<https://www.iana.org/assignments/protocol-numbers/>に、NSH [RFC8300]のプロトコル番号145を割り当てました。
+=========+=========+================+================+===========+
| Decimal | Keyword | Protocol | IPv6 Extension | Reference |
| | | | Header | |
+=========+=========+================+================+===========+
| 145 | NSH | Network | N | RFC 9491 |
| | | Service Header | | |
+---------+---------+----------------+----------------+-----------+
Table 1: Assigned Internet Protocol Numbers Registry
表1：割り当てられたインターネットプロトコル番号レジストリ
IANA has allocated the following value in the "SRv6 Endpoint Behaviors" subregistry under the "Segment Routing" registry:
IANAは、「セグメントルーティング」レジストリの下で「SRV6エンドポイント動作」サブレジストリに次の値を割り当てました。
+=======+========+===================+===========+============+
| Value | Hex | Endpoint Behavior | Reference | Change |
| | | | | Controller |
+=======+========+===================+===========+============+
| 84 | 0x0054 | End.NSH - NSH | RFC 9491 | IETF |
| | | Segment | | |
+-------+--------+-------------------+-----------+------------+
Table 2: SRv6 Endpoint Behaviors Subregistry
表2：SRV6エンドポイント動作サブレジストリ
[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>.
[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>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
DOI 10.17487/RFC8663, December 2019,
<https://www.rfc-editor.org/info/rfc8663>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>.
[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>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
[SERVICE-PROGRAMMING]
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, Internet-Draft, draft-ietf-
spring-sr-service-programming-08, 21 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-08>.
The following coauthors provided valuable inputs and text contributions to this document.
次の共著者は、この文書への貴重なインプットとテキストの貢献を提供しました。
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Joel Halpern
Ericsson
Email: joel.halpern@ericsson.com
Syed Hassan
Cisco System, inc.
Email: shassan@cisco.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Haoyu Song
Futurewei Technologies
Email: haoyu.song@futurewei.com
James N Guichard (editor)
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA
United States of America
Email: james.n.guichard@futurewei.com
Jeff Tantsura (editor)
Nvidia
United States of America
Email: jefftant.ietf@gmail.com