[要約] RFC 9015は、サービス機能チェーン内でのネットワークサービスヘッダー(NSH)の制御プレーンをBGPを使用して実現する方法について記述しています。この文書の目的は、サービス機能の効率的な配信と管理を可能にするための標準化された方法を提供することです。利用場面としては、データセンターやサービスプロバイダー環境でのネットワーク機能仮想化(NFV)やサービスチェーンの最適化と管理に適用されます。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 9015 Old Dog Consulting
Category: Standards Track J. Drake
ISSN: 2070-1721 E. Rosen
Juniper Networks
J. Uttaro
AT&T
L. Jalil
Verizon
June 2021
BGP Control Plane for the Network Service Header in Service Function Chaining
サービス機能連鎖におけるネットワークサービスヘッダのBGP制御プレーン
Abstract
概要
This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.
この文書では、サービス機能連鎖をサポートするネットワークのためのコントロールプレーンとしてのBGPの使用について説明します。この文書では、「サービス機能チェーン（SFC）アドレスファミリ識別子/後続のアドレスファミリ識別子」（SFC AFI / SAFI）と呼ばれる新しいBGPアドレスファミリを2つのルートタイプで紹介します。1つの経路タイプは、ノードによって発信されて、指定されたサービス機能の特定のインスタンスをホストすることをアドバタイズします。このルートタイプはまた、サービス機能をパケットに適用する必要があることを示す方法で、パケットをホスティングノードに送信する方法についての「指示」を提供します。他の経路タイプは、サービス機能の「チェーン」の経路をアドバタイズし、そのような各経路に固有の指定子を宣伝して、RFC 8300で定義されたネットワークサービスヘッダ（NSH）と組み合わせて使用できるようにする。
This document adopts the service function chaining architecture described in RFC 7665.
この文書は、RFC 7665に記載されているサービス機能連鎖アーキテクチャを採用しています。
Status of This Memo
本文書の位置付け
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/rfc9015.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9015で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Overview
2.1. Overview of Service Function Chaining
2.2. Control Plane Overview
3. BGP SFC Routes
3.1. Service Function Instance Route (SFIR)
3.1.1. SFIR Pool Identifier Extended Community
3.1.2. MPLS Mixed Swapping/Stacking Extended Community
3.2. Service Function Path Route (SFPR)
3.2.1. The SFP Attribute
3.2.2. General Rules for the SFP Attribute
4. Mode of Operation
4.1. Route Targets
4.2. Service Function Instance Routes
4.3. Service Function Path Routes
4.4. Classifier Operation
4.5. Service Function Forwarder Operation
4.5.1. Processing with "Gaps" in the SI Sequence
5. Selection within Service Function Paths
6. Looping, Jumping, and Branching
6.1. Protocol Control of Looping, Jumping, and Branching
6.2. Implications for Forwarding State
7. Advanced Topics
7.1. Correlating Service Function Path Instances
7.2. Considerations for Stateful Service Functions
7.3. VPN Considerations and Private Service Functions
7.4. Flow Specification for SFC Classifiers
7.5. Choice of Data Plane SPI/SI Representation
7.5.1. MPLS Representation of the SPI/SI
7.6. MPLS Label Swapping/Stacking Operation
7.7. Support for MPLS-Encapsulated NSH Packets
8. Examples
8.1. Example Explicit SFP with No Choices
8.2. Example SFP with Choice of SFIs
8.3. Example SFP with Open Choice of SFIs
8.4. Example SFP with Choice of SFTs
8.5. Example Correlated Bidirectional SFPs
8.6. Example Correlated Asymmetrical Bidirectional SFPs
8.7. Example Looping in an SFP
8.8. Example Branching in an SFP
8.9. Examples of SFPs with Stateful Service Functions
8.9.1. Forward and Reverse Choice Made at the SFF
8.9.2. Parallel End-to-End SFPs with Shared SFF
8.9.3. Parallel End-to-End SFPs with Separate SFFs
8.9.4. Parallel SFPs Downstream of the Choice
8.10. Examples Using IPv6 Addressing
8.10.1. Example Explicit SFP with No Choices
8.10.2. Example SFP with Choice of SFIs
8.10.3. Example SFP with Open Choice of SFIs
8.10.4. Example SFP with Choice of SFTs
9. Security Considerations
10. IANA Considerations
10.1. New BGP AF/SAFI
10.2. "SFP attribute" BGP Path Attribute
10.3. "SFP Attribute TLVs" Registry
10.4. "SFP Association Type" Registry
10.5. "Service Function Chaining Service Function Types"
Registry
10.6. Flow Specification for SFC Classifiers
10.7. New BGP Transitive Extended Community Type
10.8. "SFC Extended Community Sub-Types" Registry
10.9. New SPI/SI Representation Sub-TLV
10.10. "SFC SPI/SI Representation Flags" Registry
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
As described in [RFC7498], the delivery of end-to-end services can require a packet to pass through a series of Service Functions (SFs) -- e.g., WAN and application accelerators, Deep Packet Inspection (DPI) engines, firewalls, TCP optimizers, and server load balancers -- in a specified order; this is termed "service function chaining". There are a number of issues associated with deploying and maintaining service function chaining in production networks, which are described below.
[RFC7498]で説明されているように、エンドツーエンドサービスの配信では、パケットが一連のサービス機能（SF）を通過する必要があります。たとえば、WANおよびアプリケーションアクセラレータ、ディープパケットインスペクション（DPI）エンジン、ファイアウォール、 TCPオプティマイザー、およびサーバーロードバランサー-指定された順序で。 これは「サービス機能チェーン」と呼ばれます。 本番ネットワークでのサービス機能チェーンの展開と維持に関連する問題がいくつかあります。これらについては、以下で説明します。
Historically, if a packet needed to travel through a particular service chain, the nodes hosting the service functions of that chain were placed in the network topology in such a way that the packet could not reach its ultimate destination without first passing through all the service functions in the proper order. This need to place the service functions at particular topological locations limited the ability to adapt a service function chain to changes in network topology (e.g., link or node failures), network utilization, or offered service load. These topological restrictions on where the service functions could be placed raised the following issues:
歴史的には、特定のサービスチェーンを通過するのに必要なパケットが、そのチェーンのサービス機能をホストするノードは、最初にすべてのサービス機能を通過することなく、パケットがその最終的な宛先に到達できないようにネットワークトポロジに配置されました。正しい順序で。これは、サービス機能を特定のトポロジーの場所に配置する必要があり、サービス機能チェーンをネットワークトポロジー（例えば、リンクまたはノードの障害）、ネットワーク使用率、または提供されたサービス負荷の変更にサービス機能チェーンを適応させる機能を制限する必要があります。サービス機能がどこに配置される可能性がある場所のこれらのトポロジでは、次の問題が発生しました。
1. The process of configuring or modifying a service function chain is operationally complex and may require changes to the network topology.
1. サービス機能チェーンを構成または変更するプロセスは、動作上複雑であり、ネットワークトポロジへの変更が必要になる場合があります。
2. Alternate or redundant service functions may need to be co-located with the primary service functions.
2. 代替または冗長サービス機能は、プライマリサービス機能と同じ場所に配置する必要があるかもしれません。
3. When there is more than one path between source and destination, forwarding may be asymmetric, and it may be difficult to support bidirectional service function chains using simple routing methodologies and protocols without adding mechanisms for traffic steering or traffic engineering.
3. 送信元と目的地との間に複数の経路がある場合、転送は非対称であり得、交通ステアリングまたはトラフィックエンジニアリングのためのメカニズムを追加することなく単純なルーティング方法論およびプロトコルを使用して双方向サービス機能チェーンをサポートすることは困難であり得る。
In order to address these issues, the service function chaining architecture describes service function chains that are built in their own overlay network (the service function overlay network), coexisting with other overlay networks, over a common underlay network [RFC7665]. A service function chain is a sequence of service functions through which packet flows that satisfy specified criteria will pass.
これらの問題に対処するために、サービス機能連鎖アーキテクチャは、共通のアンダーレイネットワーク上で他のオーバーレイネットワークと共存し、他のオーバーレイネットワークと共存する、自身のオーバーレイネットワーク（サービス機能オーバーレイネットワーク）に構築されているサービス機能チェーンを記述しています[RFC7665]。サービス機能チェーンは、指定された基準を満たすパケットフローがどのパケットフローを渡す一連のサービス機能です。
This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller (a centralized network component responsible for planning and coordinating service function chaining within the network) to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) [RFC8300].
この文書では、サービス機能連鎖をサポートするネットワークのためのコントロールプレーンとしてのBGPの使用について説明します。この文書では、「サービス機能チェーン（SFC）アドレスファミリ識別子/後続のアドレスファミリ識別子」（SFC AFI / SAFI）と呼ばれる新しいBGPアドレスファミリを2つのルートタイプで紹介します。1つの経路タイプは、ノードによって発信されて、指定されたサービス機能の特定のインスタンスをホストすることをアドバタイズします。このルートタイプはまた、サービス機能をパケットに適用する必要があることを示す方法で、パケットをホスティングノードに送信する方法についての「指示」を提供します。他の経路タイプは、サービス機能の「チェーン」の経路を宣伝し、それぞれのそのような経路に固有の指定子を提供するために、コントローラ（ネットワーク内でサービス機能連鎖と調整する集中ネットワークコンポーネント）によって使用されます。ネットワークサービスヘッダ（NSH）[RFC8300]と組み合わせて使用する。
This document adopts the service function chaining architecture described in [RFC7665].
この文書は[RFC7665]に記載されているサービス機能連鎖アーキテクチャを採用しています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following terms from [RFC7665]:
このドキュメントは[RFC7665]から次の用語を使用します。
* Bidirectional Service Function Chain
* 双方向サービス機能チェーン
* Classifier
* 区切り
* Service Function (SF)
* サービス機能（SF）
* Service Function Chain (SFC)
* サービス機能チェーン（SFC）
* Service Function Forwarder (SFF)
* サービス機能フォワーダ（SFF）
* Service Function Instance (SFI)
* サービス機能インスタンス（SFI）
* Service Function Path (SFP)
* サービス機能パス（SFP）
* SFC branching
* SFC分岐
Additionally, this document uses the following terms from [RFC8300]:
さらに、この文書では[RFC8300]から次の用語を使用しています。
* Network Service Header (NSH)
* ネットワークサービスヘッダ（NSH）
* Service Index (SI)
* サービスインデックス（SI）
* Service Path Identifier (SPI)
* サービスパス識別子（SPI）
This document introduces the following terms:
この文書は次の条件を紹介します。
Service Function Instance Route (SFIR): A new BGP Route Type advertised by the node that hosts an SFI to describe the SFI and to announce the way to forward a packet to the node through the underlay network.
サービスファンクションインスタンスルート（SFIR）：SFIをホストするノードによってアドバタイズされた新しいBGPルートタイプ、およびアンダーレイネットワークを介してパケットをノードに転送する方法をアナウンスする。
Service Function Overlay Network: The logical network comprised of classifiers, SFFs, and SFIs that are connected by paths or tunnels through underlay transport networks.
サービス機能オーバーレイネットワーク：アンダーレイトランスポートネットワークを介してパスまたはトンネルによって接続されている分類子、SFFS、およびSFIからなる論理ネットワーク。
Service Function Path Route (SFPR): A new BGP Route Type originated by controllers to advertise the details of each SFP.
サービス機能パスルート（SFPR）：コントローラによって発信された新しいBGPルート型は、各SFPの詳細をアドバタイズします。
Service Function Type (SFT): An indication of the function and features of an SFI.
サービス機能タイプ（SFT）：SFIの機能と機能の表示。
This section provides an overview of service function chaining in general and the control plane defined in this document. After reading this section, readers may find it helpful to look through Section 8 for some simple worked examples.
このセクションでは、一般的なサービス機能連鎖の概要とこの文書で定義されているコントロールプレーンについて説明します。このセクションを読んだ後、読者はいくつかの簡単な作業例でセクション8を見ても役立つかもしれません。
In [RFC8300], a Service Function Chain (SFC) is an ordered list of Service Functions (SFs). A Service Function Path (SFP) is an indication of which instances of SFs are acceptable to be traversed in an instantiation of an SFC in a service function overlay network. The Service Path Identifier (SPI) is a 24-bit number that identifies a specific SFP, and a Service Index (SI) is an 8-bit number that identifies a specific point in that path. In the context of a particular SFP (identified by an SPI), an SI represents a particular service function and indicates the order of that SF in the SFP.
[RFC8300]では、サービス機能チェーン（SFC）はサービス機能の順序付きリスト（SFS）です。サービス機能経路（SFP）は、サービス関数オーバーレイネットワーク内のSFCのインスタンス化においてSFSのインスタンスを通過することが許容されるかの指標である。サービスパス識別子（SPI）は、特定のSFPを識別する24ビット数であり、サービスインデックス（SI）はそのパス内の特定のポイントを識別する8ビット番号です。特定のSFP（SPIによって識別される）の文脈では、SIは特定のサービス機能を表し、SFP内のそのSFの順序を示す。
Within the context of a specific SFP, an SI references a set of one or more SFs. Each of those SFs may be supported by one or more Service Function Instances (SFIs). Thus, an SI may represent a choice of SFIs of one or more service function types. By deploying multiple SFIs for a single SF, one can provide load balancing and redundancy.
特定のSFPのコンテキスト内で、SIは1つ以上のSFSのセットを参照します。これらのSFのそれぞれは、1つ以上のサービス機能インスタンス（SFI）によってサポートされてもよい。したがって、SIは、1つまたは複数のサービス機能タイプのSFIの選択を表すことができる。単一のSFに対して複数のSFIを展開することで、負荷分散と冗長性を提供できます。
A special functional element, called a "classifier", is located at each ingress point to a service function overlay network. It assigns the packets of a given packet flow to a specific SFP. This may be done by comparing specific fields in a packet's header with local policy, which may be customer/network/service specific. The classifier picks an SFP and sets the SPI accordingly; it then sets the SI to the value of the SI for the first hop in the SFP, and then prepends a Network Service Header (NSH) [RFC8300] containing the assigned SPI/SI to that packet. Note that the classifier and the node that hosts the first SF in an SFP need not be located at the same point in the service function overlay network.
「分類子」と呼ばれる特別な機能要素は、各入力ポイントにサービス機能オーバーレイネットワークに配置されています。特定のパケットフローのパケットを特定のSFPに割り当てます。これは、パケットのヘッダー内の特定のフィールドをローカルポリシーと比較することによって行うことができます。これは、顧客/ネットワーク/サービス固有である可能性があります。分類器はSFPを選択し、それに応じてSPIを設定します。その後、SFPの最初のホップのSIの値にSIを設定し、そのパケットに割り当てられたSPI / SIを含むネットワークサービスヘッダー（NSH）[RFC8300]を追加します。SFP内の最初のSFをホストする分類子とノードは、サービス関数オーバーレイネットワーク内の同じポイントに配置される必要はないことに注意してください。
Note that the presence of the NSH can make it difficult for nodes in the underlay network to locate the fields in the original packet that would normally be used to constrain equal-cost multipath (ECMP) forwarding. Therefore, it is recommended that the node prepending the NSH also provide some form of entropy indicator that can be used in the underlay network. How this indicator is generated and supplied, and how an SFF generates a new entropy indicator when it forwards a packet to the next SFF, are out of the scope of this document.
NSHの存在は、アンダーレイネットワーク内のノードが、通常のパケット内のフィールドを、等価コストマルチパス（ECMP）転送を制限するために使用されるフィールドを見つけることが困難になることに注意してください。したがって、NSHを先頭のノードは、アンダーレイネットワークで使用できるエントロピーインジケータの何らかの形式を提供することをお勧めします。このインジケータがどのように生成され提供されるか、およびSFFがパケットを次のSFFに転送するときに新しいエントロピーインジケータを生成する方法は、この文書の範囲外です。
The Service Function Forwarder (SFF) receives a packet from the previous node in an SFP, removes the packet's link layer or tunnel encapsulation, and hands the packet and the NSH to the SFI for processing. The SFI has no knowledge of the SFP.
サービス機能フォワーダ（SFF）は、SFP内の前のノードからパケットを受信し、パケットのリンクレイヤまたはトンネルカプセル化を削除し、パケットとNSHを処理するためにSFIに渡します。SFIにはSFPに関する知識がありません。
When the SFF receives the packet and the NSH back from the SFI, it must select the next SFI along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs (possibly of different SFTs), as described in Section 5. In the normal case, the SPI remains unchanged, and the SI will have been decremented to indicate the next SF along the path. But other possibilities exist if the SF makes other changes to the NSH through a process of reclassification:
SFFがSFIからパケットを受信し、NSFをSFIから戻すと、NSHのSPIとSIを使用してパスに沿って次のSFIを選択し、セクション5で説明したように、複数のSFI（おそらく異なるSFT）の間で潜在的に選択する必要があります。通常の場合、SPIは変更されず、SIはパスに沿った次のSFを示すために減分されました。しかし、SFが再分類のプロセスを通じて他の変更をNSHにする場合、他の可能性が存在します。
* The SI in the NSH may indicate:
* NSHのSIは次のことを示している可能性があります。
- A previous SF in the path; this is known as "looping" (see Section 6).
- パス内の以前のSF。これは「ループ」として知られています（セクション6を参照）。
- An SF further down the path; this is known as "jumping" (again see Section 6).
- パスをさらにダウンします。これは「ジャンプ」として知られています（また、セクション6を参照）。
* The SPI and the SI may point to an SF on a different SFP; this is known as "branching" (see Section 6).
* SPIとSIは異なるSFP上のSFを指すことがある。これは「分岐」として知られています（6章を参照）。
Such modifications are limited to within the same service function overlay network. That is, an SPI is known within the scope of service function overlay network. Furthermore, the new SI value is interpreted in the context of the SFP identified by the SPI.
そのような修正は、同じサービス関数オーバーレイネットワーク内に制限されている。すなわち、SPIはサービス機能オーバーレイネットワークの範囲内で知られている。さらに、新しいSI値は、SPIによって識別されたSFPのコンテキストで解釈されます。
As described in [RFC8300], an SPI that is unknown or not valid is treated as an error, and the SFF drops the packet; such errors should be logged, and such logs are subject to rate limits.
[RFC8300]で説明されているように、不明または無効なSPIはエラーとして扱われ、SFFはパケットを降下します。そのようなエラーはログに記録されるべきであり、そのようなログはレート制限の対象となります。
Also, as described in [RFC8300], an SFF receiving an SI that is unknown in the context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by the SPI. If no such value exists, or if the SFF does not support reducing the SI, the SFF drops the packet and should log the event; such logs are also subject to rate limits.
また、[RFC8300]に記載されているように、SPIのコンテキストで未知のSISを受信するSFFは、SPIによって示されるSFP内の次の意味のあるSI値への値を減らすことができる。そのような値が存在しない場合、またはSFFがSIの短縮をサポートしていない場合、SFFはパケットをドロップしてイベントを記録する必要があります。そのようなログはレート制限の対象となる。
The SFF then selects an SFI that provides the SF denoted by the SPI/ SI and forwards the packet to the SFF that supports that SFI.
その後、SFFはSPI / SIによって示されるSFを提供し、そのSFIをサポートするSFFにパケットを転送するSFIを選択する。
[RFC8300] makes it clear that the intended scope is for use within a single provider's operational domain.
[RFC8300]は、単一のプロバイダの運用ドメイン内で使用するための目的の範囲が使用することを明らかにします。
This document adopts the service function chaining architecture described in [RFC7665] and adds a control plane to support the functions, as described in Section 2.2. An essential component of this solution is the controller. This is a network component responsible for planning SFPs within the network. It gathers information about the availability of SFIs and SFFs, instructs the control plane about the SFPs to be programmed, and instructs the classifiers how to assign traffic flows to individual SFPs.
この文書は[RFC7665]に記載されているサービス機能連鎖アーキテクチャを採用し、セクション2.2で説明したように機能をサポートするための制御プレーンを追加します。この解決策の必須要素はコントローラです。これは、ネットワーク内のSFPの計画を担当するネットワークコンポーネントです。SFISとSFFSの可用性に関する情報を収集し、プログラムされるSFPに関するコントロールプレーンに指示し、分類子に個々のSFPにトラフィックフローを割り当てる方法を指示します。
To accomplish the function described in Section 2.1, this document introduces the Service Function Type (SFT), which is the category of SF that is supported by an SFF (such as "firewall"). An IANA registry of service function types is introduced in Section 10.5 and is consistent with types used in other work, such as [BGP-LS-SR]. An SFF may support SFs of multiple different SFTs, and it may support multiple SFIs of each SF.
セクション2.1で説明されている機能を実現するために、この文書では、SFFによってサポートされているSFのカテゴリであるサービス機能タイプ（SFT）を紹介します（「ファイアウォール」など）。サービス機能タイプのIANAレジストリは、10.5項で紹介され、[BGP-LS-SR]など、他の作業で使用されている型と一致しています。SFFは複数の異なるSFTのSFSをサポートすることができ、各SFの複数のSFIをサポートすることができる。
The registry of SFT values (see Section 10.5) is split into three ranges with assignment policies per [RFC8126]:
SFT値のレジストリ（セクション10.5を参照）は、[RFC8126]ごとに割り当てポリシーを持つ3つの範囲に分割されています。
* The special-purpose SFT values range is assigned through Standards Action. Values in that range are used for special SFC operations and do not apply to the types of SF that may form part of the SFP.
* 専用のSFT値の範囲は、標準アクションによって割り当てられます。その範囲内の値は特殊なSFC操作に使用され、SFPの一部を形成する可能性があるSFの種類には適用されません。
* The First Come First Served range tracks assignments of SFT values made by any party that defines an SF type. Reference through an Internet-Draft is desirable, but not required.
* 最初のサーブレンジは、SFタイプを定義する任意の当事者によって行われたSFT値の割り当てを追跡します。インターネットドラフトによる参照が望ましいが、必須ではない。
* The Private Use range is not tracked by IANA and is primarily intended for use in private networks where the meaning of the SFT values is locally tracked and under the control of a local administrator.
* プライベート使用範囲はIANAによって追跡されず、主にSFT値の意味がローカルに追跡され、ローカル管理者の制御下にあるプライベートネットワークでの使用を目的としています。
It is envisaged that the majority of SFT values used will be assigned from the First Come First Served space in the registry. This will ensure interoperability, especially in situations where software and hardware from different vendors are deployed in the same networks, or when networks are merged. However, operators of private networks may choose to develop their own SFs and manage the configuration and operation of their network through their own list of SFT values.
使用されたSFT値の大部分は、最初に最初の最初のサービススペースからレジストリ内の最初のサービススペースを割り当てることが考えられます。これにより、異なるベンダからのソフトウェアとハードウェアが同じネットワークに展開されている場合、またはネットワークがマージされている場合、これは特に相互運用性を確保します。ただし、プライベートネットワークの演算子は独自のSFSを開発し、自分のSFT値のリストを通じてネットワークの構成と操作を管理することを選択できます。
This document also introduces a new BGP AFI/SAFI (values 31 and 9, respectively) for "SFC Routes". Two SFC Route Types are defined by this document: the Service Function Instance Route (SFIR) and the Service Function Path Route (SFPR). As detailed in Section 3, the Route Type is indicated by a subfield in the Network Layer Reachability Information (NLRI).
この文書には、「SFCルート」の新しいBGP AFI / SAFI（それぞれ値31と9）も紹介します。このドキュメントでは、サービス機能インスタンスルート（SFIR）とサービス機能パスルート（SFPR）によって2つのSFCルートタイプが定義されています。セクション3に詳述されるように、経路タイプは、ネットワーク層到達可能性情報（NLRI）内のサブフィールドによって示される。
* The SFIR is advertised by the node that provides access to the service function instance (i.e., the SFF). The SFIR describes a particular instance of a particular SF (i.e., an SFI) and the way to forward a packet to it through the underlay network, i.e., IP address and encapsulation information.
* SFIRは、サービス機能インスタンス（すなわちSFF）へのアクセスを提供するノードによってアドバタイズされます。SFIRは、特定のSF（すなわち、SFI）の特定のインスタンス、およびアンダーレイネットワーク、すなわちIPアドレスおよびカプセル化情報を介してパケットをそれに転送する方法を記述する。
* The SFPRs are originated by controllers. One SFPR is originated for each SFP. The SFPR specifies:
* SFPRSはコントローラによって発信されます。1つのSFPRが各SFPに対して発信されます。SFPRは次のものを指定します。
A. the SPI of the path,
A.パスのSPI、
B. the sequence of SFTs and/or SFIs of which the path consists, and
B.経路が構成されているSFTおよび/またはSFIのシーケンス
C. for each such SFT or SFI, the SI that represents it in the identified path.
C.そのようなSFTまたはSFIごとに、識別された経路でそれを表すSi。
This approach assumes that there is an underlay network that provides connectivity between SFFs and controllers and that the SFFs are grouped to form one or more service function overlay networks through which SFPs are built. We assume that the controllers have BGP connectivity to all SFFs and all classifiers within each service function overlay network.
このアプローチは、SFFとコントローラ間の接続性を提供し、SFFSがグループ化されてSFPが構築されている1つ以上のサービス機能オーバーレイネットワークを形成するようにグループ化されている、アンダーレイネットワークがあると仮定しています。コントローラは、すべてのSFFと各サービス関数オーバーレイネットワーク内のすべての分類子にBGP接続を持つと仮定します。
When choosing the next SFI in a path, the SFF uses the SPI and SI as well as the SFT to choose among the SFIs, applying, for example, a load-balancing algorithm or direct knowledge of the underlay network topology, as described in Section 4.
パス内の次のSFIを選択すると、SFFはSFIとSFIを使用してSFIを使用して、セクションで説明したように、SFIの中から選択します。4。
The SFF then encapsulates the packet using the encapsulation specified by the SFIR of the selected SFI and forwards the packet. See Figure 1.
その後、SFFは、選択されたSFIのSFIRによって指定されたカプセル化を使用してパケットをカプセル化してパケットを転送する。図1を参照してください。
Thus, the SFF can be seen as a portal in the underlay network through which a particular SFI is reached.
したがって、SFFは、特定のSFIに達するアンダーレイネットワーク内のポータルと見なすことができます。
Figure 1 shows a reference model for the service function chaining architecture. There are four SFFs (SFF-1 through SFF-4) connected by tunnels across the underlay network. Packets arrive at a classifier and are channeled along SFPs to destinations reachable through SFF-4.
図1は、サービス機能連鎖アーキテクチャの参照モデルを示しています。アンダーレイネットワーク全体にトンネルで接続されている4つのSFFS（SFF-1からSFF-4）があります。パケットは分類子に到着し、SFPに沿ってSFF-4を通じて到達可能な宛先にチャネル化されます。
SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFe). SFF-2 has two types of SF attached: one instance of one (SFc) and three instances of the other (SFb). SFF-3 has just one instance of an SF (SFd), but in this case, the type of SFd is the same type as SFb (SFTx).
SFF-1とSFF-4には、1つのSFが接続されている（SFAとSFE）の1つのインスタンスがあります。SFF-2には、2種類のSFが接続されています.1つのインスタンス（SFC）ともう1つのインスタンス（SFB）。SFF-3 SF（SFD）のインスタンスは1つだけですが、この場合、SFDの種類はSFB（SFTX）と同じタイプです。
This figure demonstrates how load balancing can be achieved by creating several SFPs that satisfy the same SFC. Suppose an SFC needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs can be constructed using any instance of SFb or using SFd. Load balancing may be applied at two places:
この図は、同じSFCを満たすいくつかのSFPを作成することによって、ロードバランシングをどのように実現できるかを示しています。SFCがSFA、SFTX型のSF、およびSFCを含める必要があるとします。SFBの任意のインスタンスを使用して、またはSFDを使用して、いくつかのSFPを構築することができます。負荷分散は2か所に適用される場合があります。
* The classifier may distribute different flows onto different SFPs to share the load in the network and across SFIs.
* 分類器は、ネットワーク内およびSFIを介して負荷を共有するために、異なるSFPに異なるフローを配布することができる。
* SFF-2 may distribute different flows (on the same SFP) to different instances of SFb to share the processing load.
* SFF-2は、処理負荷を共有するために異なるSFBのインスタンスに異なるフロー（同じSFP上で）を配布することができます。
Note that, for convenience and clarity, Figure 1 shows only a few tunnels between SFFs. There could be a full mesh of such tunnels, or more likely, a selection of tunnels connecting key SFFs to enable the construction of SFPs and balance load and traffic in the network. Further, the figure does not show any controllers; these would each have BGP connectivity to the classifier and all of the SFFs.
なお、便宜上、明確にするために、図1はSFF間のトンネルのみのみを示しています。そのようなトンネルのフルメッシュは、SFPSの構築を可能にし、ネットワーク内の負荷とトラフィックのバランスを可能にするためにキーSFFを接続するトンネルの選択が可能です。さらに、図はコントローラを示していません。これらはそれぞれ分類子およびすべてのSFFへのBGP接続を持つでしょう。
Packets
| | |
------------
| |
| Classifier |
| |
------+-----
|
---+--- --------- -------
| | Tunnel | | | |
| SFF-1 |===============| SFF-2 |=========| SFF-4 |
| | | | | |
| | -+-----+- | |
| | ,,,,,,,,,,,,,,/,, \ | |
| | ' .........../. ' ..\...... | |
| | ' : SFb / : ' : \ SFc : | |
| | ' : ---+- : ' : --+-- : | |
| | ' : -| SFI | : ' : | SFI | : | |
| | ' : -| ----- : ' : ----- : | |
| | ' : | ----- : ' ......... | |
| | ' : ----- : ' | |
| | ' ............. ' | |--- Dests
| | ' ' | |--- Dests
| | ' ......... ' | |
| | ' : ----- : ' | |
| | ' : | SFI | : ' | |
| | ' : --+-- : ' | |
| | ' :SFd | : ' | |
| | ' ....|.... ' | |
| | ' | ' | |
| | ' SFTx | ' | |
| | ',,,,,,,,|,,,,,,,,' | |
| | | | |
| | ---+--- | |
| | | | | |
| |======| SFF-3 |====================| |
---+--- | | ---+---
| ------- |
....|.... ....|....
: | SFa: : | SFe:
: --+-- : : --+-- :
: | SFI | : : | SFI | :
: ----- : : ----- :
......... .........
Figure 1: The Service Function Chaining Architecture Reference Model
図1：サービス機能連鎖アーキテクチャ参照モデル
As previously noted, [RFC8300] makes it clear that the mechanisms it defines are intended for use within a single provider's operational domain. This reduces the requirements on the control plane function.
前述のように、[RFC8300]は、それが定義するメカニズムが単一のプロバイダの運用ドメイン内での使用を意図していることを明らかにします。これにより、コントロールプレーン機能に関する要件が軽減されます。
Section 5.2 of [RFC7665] sets out the functions provided by a control plane for a service function chaining network. The functions are broken down into six items, the first four of which are completely covered by the mechanisms described in this document:
[RFC7665]のセクション5.2は、サービス機能チェンジネットワークの制御プレーンによって提供される機能を設定します。関数は6つの項目に分割されているので、最初の4つはこの文書に記載されているメカニズムによって完全にカバーされています。
1. Visibility of all SFs and the SFFs through which they are reached.
1. すべてのSFSとそれらが到達するSFFの可視性。
2. Computation of SFPs and programming into the network.
2. SFPの計算とネットワークへのプログラミング
3. Selection of SFIs explicitly in the SFP or dynamically within the network.
3. SFP内のSFIの選択またはネットワーク内で動的に選択されます。
4. Programming of SFFs with forwarding path information.
4. 転送パス情報を持つSFFSのプログラミング。
The fifth and sixth items in the list in RFC 7665 concern the use of metadata. These are more peripheral to the control plane mechanisms defined in this document but are discussed in Section 4.4.
RFC 7665のリスト内の5番目と6番目の項目は、メタデータの使用に関するものです。これらはこの文書で定義されているコントロールプレーンメカニズムのより多くの周辺性ですが、4.4節で説明します。
This document defines a new AFI/SAFI for BGP, known as "SFC", with an NLRI that is described in this section.
このドキュメントでは、このセクションで説明されているNLRIを使用して、「SFC」と呼ばれるBGP用の新しいAFI / SAFIを定義します。
The format of the SFC NLRI is shown in Figure 2.
SFC NLRIの形式を図2に示します。
+---------------------------------------+
| Route Type (2 octets) |
+---------------------------------------+
| Length (2 octets) |
+---------------------------------------+
| Route Type specific (variable) |
+---------------------------------------+
Figure 2: The Format of the SFC NLRI
図2：SFC NLRIのフォーマット
The "Route Type" field determines the encoding of the rest of the Route Type specific SFC NLRI.
「経路タイプ」フィールドは、Route Type Spc NLRIの残りの部分のエンコードを決定します。
The "Length" field indicates the length, in octets, of the "Route Type specific" field of the SFC NLRI.
「Length」フィールドは、SFC NLRIの「経路型固有」フィールドの長さをオクテットで示します。
This document defines the following Route Types:
このドキュメントは次のルートタイプを定義します。
1. Service Function Instance Route (SFIR)
1. サービス機能インスタンスルート（SFIR）
2. Service Function Path Route (SFPR)
2. サービス機能パスルート（SFPR）
An SFIR is used to identify an SFI. An SFPR defines a sequence of SFs (each of which has at least one instance advertised in an SFIR) that form an SFP.
SFIを使用してSFIを識別します。SFPRは、SFPのシーケンスを定義します（それぞれがSFIRでアドバタイズされた少なくとも1つのインスタンスを持つ）SFPを形成する。
The detailed encoding and procedures for these Route Types are described in subsequent sections.
これらの経路タイプの詳細な符号化と手順は、後続のセクションで説明されています。
The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of 31 and a Subsequent Address Family Identifier (SAFI) of 9. The "NLRI" field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC NLRI, encoded as specified above.
SFC NLRIは、BGP Multiprotocol Extensions [RFC4760]を使用してBGP [RFC4271]で搭載されています。上記で指定されたようにエンコードされたSFC NLRIを含みます。
In order for two BGP speakers to exchange SFC NLRIs, they MUST use BGP capabilities advertisements to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI of 31 and a SAFI of 9.
2つのBGPスピーカーがSFC NLRIを交換するためには、それらが両方がそのようなNLRIを適切に処理することができるようにBGP機能の広告を使用する必要があります。これは、AFIのAFIと9のSAFIを持つ能力コード1（Multiprotocol BGP）を使用することによって、[RFC4760]で指定されています。
The "nexthop" field of the MP_REACH_NLRI attribute of the SFC NLRI MUST be set to a loopback address of the advertising SFF.
SFC NLRIのMP_REACH_NLRI属性の「Nexthop」フィールドは、広告SFFのループバックアドレスに設定する必要があります。
Figure 3 shows the Route Type specific NLRI of the SFIR.
図3は、SFIRの経路タイプ固有のNLRIを示しています。
+--------------------------------------------+
| Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+
| Service Function Type (2 octets) |
+--------------------------------------------+
Figure 3: SFIR Route Type Specific NLRI
図3：SFIRルートタイプ固有のNLRI
[RFC4364] defines a Route Distinguisher (RD) as consisting of a two-byte "Type" field and a six-byte "Value" field, and it defines RD types 0, 1, and 2. In this specification, the RD (used for the SFIR) MUST be of type 0, 1, or 2.
[RFC4364]は、2バイトの「タイプ」フィールドと6バイトの「値」フィールドで構成され、RDタイプ0,1、および2を定義し、RDタイプを定義します。SFIRに使用されている）は、0,1、または2型でなければなりません。
If two SFIRs are originated from different administrative domains (within the same provider's operational domain), they MUST have different RDs. In particular, SFIRs from different VPNs (for different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFIRs.
2つのSFIRが異なる管理ドメインから発生した場合（同じプロバイダの運用ドメイン内）、それらは異なるRDSを持つ必要があります。特に、異なるVPNからのSFIR（異なるサービス機能オーバーレイネットワーク用）は異なるRDSを持ち、これらのRDSはVPN以外のSFIRとは異なる必要があります。
The SFT identifies the functions/features an SF can offer, e.g., classifier, firewall, load balancer. There may be several SFIs that can perform a given service function. Each node hosting an SFI MUST originate an SFIR for each type of SF that it hosts (as indicated by the SFT value), and it MAY advertise an SFIR for each instance of each type of SF. A minimal advertisement allows construction of valid SFPs and leaves the selection of SFIs to the local SFF; a detailed advertisement may have scaling concerns but allows a controller that constructs an SFP to make an explicit choice of SFI.
SFTは、SFが提供することができる機能/特徴を識別する、例えば、分類子、ファイアウォール、ロードバランサー。特定のサービス機能を実行できるSFIがいくつかあります。SFIをホストする各ノードは、（SFT値で示すように）ホストがホストする各タイプのSFにSFIRを発信しなければならず、各タイプのSFの各インスタンスに対してSFIRをアドバタイズすることができます。最小限の広告は有効なSFPの構築を可能にし、SFIの選択をローカルSFFに残す。詳細な広告は懸念を絞り込むかもしれませんが、SFPを構築するためにSFPを構築するコントローラを使用することができます。
Note that a node may advertise all its SFIs of one SFT in one shot using normal BGP UPDATE packing. That is, all of the SFIRs in an Update share a common Tunnel Encapsulation and Route Target (RT) attribute. See also Section 3.2.1.
ノードは、通常のBGP更新パッキングを使用して、1つのSFTのすべてのSFIのすべてのSFIを宣伝することができます。つまり、アップデート内のすべてのSFIRは共通トンネルカプセル化とルートターゲット（RT）属性を共有しています。セクション3.2.1も参照してください。
The SFIR representing a given SFI will contain an NLRI with "RD" field set to an RD as specified above, and with the "SFT" field set to identify that SFI's SFT. The values for the "SFT" field are taken from a registry administered by IANA (see Section 10). A BGP UPDATE containing one or more SFIRs MUST also include a tunnel encapsulation attribute [RFC9012]. If a data packet needs to be sent to an SFI identified in one of the SFIRs, it will be encapsulated as specified by the tunnel encapsulation attribute and then transmitted through the underlay network.
特定のSFIを表すSFIRは、上で指定されたように "RD"フィールドがRDに設定されているNLRIを含み、「SFT」フィールドはSFIのSFTを識別するように設定されます。「SFT」フィールドの値は、IANAによって管理されているレジストリから取得されます（セクション10を参照）。1つ以上のSFIRを含むBGPアップデートには、トンネルカプセル化属性[RFC9012]も含まれている必要があります。データパケットをいずれかのSFIRで識別されたSFIに送信する必要がある場合は、トンネルのカプセル化属性によって指定されているとおりにカプセル化され、次にアンダーレイネットワークを介して送信されます。
Note that the tunnel encapsulation attribute MUST contain sufficient information to allow the advertising SFF to identify the overlay or VPN network that a received packet is transiting. This is because the [SPI, SI] in a received packet is specific to a particular overlay or VPN network.
トンネルカプセル化属性には、広告SFFがオーバーレイまたはVPNネットワークを識別できるように十分な情報を含める必要があります。これは、受信したパケット内の[SPI、SI]が特定のオーバーレイまたはVPNネットワークに固有のものであるためである。
This document defines a new transitive Extended Community [RFC4360] of type 0x0b called the "SFC Extended Community". When used with Sub-Type 1, this is called the "SFIR Pool Identifier extended community". It MAY be included in SFIR advertisements, and it is used to indicate the identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR may be a member of more than one pool, multiple of these extended communities may be present on a single SFIR advertisement.
このドキュメントは、 "SFC Extended Community"と呼ばれるタイプ0x0bの新しい推移的拡張コミュニティ[RFC4360]を定義しています。サブタイプ1で使用すると、これは「SFIR Pool Identifier Extended Community」と呼ばれます。SFIR広告に含めることができ、SFIRが属するSFIRのプールのIDを示すために使用されます。SFIRは複数のプールのメンバーであり得るので、これらの拡張コミュニティのうちの倍数が単一のSFIR広告に存在してもよい。
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses include control plane scalability and stability. A pool identifier may be included in an SFPR to indicate a set of SFIs that are acceptable at a specific point on an SFP (see Sections 3.2.1.3 and 4.3).
SFIRプールでは、SFIRをすべての目的のためにグループ化できます。可能な用途には、制御面のスケーラビリティと安定性が含まれます。プール識別子は、SFP上の特定の点で許容されるSFIのセットを示すためにSFPRに含まれていてもよい（セクション3.2.1.3および4.3を参照）。
The SFIR Pool Identifier Extended Community is encoded in 8 octets as shown in Figure 4.
SFIRプール識別子拡張コミュニティは、図4に示すように8オクテットでエンコードされています。
+--------------------------------------------+
| Type = 0x0b (1 octet) |
+--------------------------------------------+
| Sub-Type = 1 (1 octet) |
+--------------------------------------------+
| SFIR Pool Identifier value (6 octets) |
+--------------------------------------------+
Figure 4: The SFIR Pool Identifier Extended Community
図4：SFIRプール識別子拡張コミュニティ
The SFIR Pool Identifier value is encoded in a 6-octet field in network byte order, and the value is unique within the scope of an overlay network. This means that pool identifiers need to be centrally managed, which is consistent with the assignment of SFIs to pools.
SFIRプール識別子値は、ネットワークバイト順の6オクテットフィールドでエンコードされ、値はオーバーレイネットワークの範囲内で一意です。これは、プール識別子を集中管理する必要があることを意味します。これは、プールへのSFIの割り当てと一致しています。
As noted in Section 3.1.1, this document defines a new transitive Extended Community of type 0x0b called the "SFC Extended Community". When used with Sub-Type 2, this is called the "MPLS Mixed Swapping/ Stacking Labels Extended Community". The community is encoded as shown in Figure 5. It contains a pair of MPLS labels: an SFC Context Label and an SF Label, as described in [RFC8595]. Each label is 20 bits encoded in a 3-octet (24-bit) field with 4 trailing bits that MUST be set to zero.
3.1.1項で述べたように、この文書は「SFC拡張コミュニティ」と呼ばれるタイプ0x0bの新しい推移的拡張コミュニティを定義しています。サブタイプ2と共に使用する場合、これは「MPLS混合スワッピング/スタッキングラベル拡張コミュニティ」と呼ばれます。コミュニティは図5に示すようにエンコードされています。[RFC8595]で説明されているように、SFCコンテキストラベルとSFラベルのペアが含まれています。各ラベルは、ゼロに設定する必要がある4つの末尾ビットを持つ3オクテット（24ビット）フィールドで符号化された20ビットです。
+--------------------------------------------+
| Type = 0x0b (1 octet) |
+--------------------------------------------|
| Sub-Type = 2 (1 octet) |
+--------------------------------------------|
| SFC Context Label (3 octets) |
+--------------------------------------------|
| SF Label (3 octets) |
+--------------------------------------------+
Figure 5: The MPLS Mixed Swapping/Stacking Labels Extended Community
図5：MPLS混合スワッピング/スタッキングラベル拡張コミュニティ
Note that it is assumed that each SFF has one or more globally unique SFC Context Labels and that the context-label space and the SPI-address space are disjoint. In other words, a label value cannot be used to indicate both an SFC context and an SPI, and it can be determined from knowledge of the label spaces whether a label indicates an SFC context or an SPI.
各SFFは、1つ以上のグローバルに固有のSFCコンテキストラベルを持ち、コンテキストラベルスペースとSPIアドレス空間が互いに素であると仮定されていることに注意してください。言い換えれば、ラベル値を使用してSFCコンテキストとSPIの両方を示すことができず、ラベルスペースの知識からラベルがSFCコンテキストまたはSPIを示すかどうかを決定することができます。
If an SFF supports SFP Traversal with an MPLS Label Stack, it MUST include this Extended Community with the SFIRs that it advertises.
SFFがMPLSラベルスタックを使用してSFPトラバーサルをサポートしている場合は、その拡張コミュニティをアドバタイズするSFIRを含める必要があります。
See Section 7.6 for a description of how this Extended Community is used.
この拡張コミュニティがどのように使用されるかについては、7.6項を参照してください。
Figure 6 shows the Route Type specific NLRI of the SFPR.
図6は、SFPRの経路タイプ固有のNLRIを示しています。
+-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+
Figure 6: SFPR Route Type Specific NLRI
図6：SFPRルートタイプ固有のNLRI.
[RFC4364] defines a Route Distinguisher (RD) as consisting of a two-byte "Type" field and a six-byte "Value" field, and it defines RD types 0, 1, and 2. In this specification, the RD (used for the SFPR) MUST be of type 0, 1, or 2.
[RFC4364]は、2バイトの「タイプ」フィールドと6バイトの「値」フィールドで構成され、RDタイプ0,1、および2を定義し、RDタイプを定義します。SFPRに使用される）は、0,1、または2型でなければなりません。
All SFPs MUST be associated with an RD. The association of an SFP with an RD is determined by provisioning. If two SFPRs are originated from different controllers, they MUST have different RDs. Additionally, SFPRs from different VPNs (i.e., in different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFPRs.
すべてのSFPはRDに関連付けられている必要があります。SFPとRDとの関連付けは、プロビジョニングによって決定されます。2つのSFPRが異なるコントローラから発生した場合、それらは異なるRDSを持つ必要があります。さらに、さまざまなVPNからのSFPR（すなわち、異なるサービス関数オーバーレイネットワークにおける）は異なるRDを持たなければならず、それらのRDSはVPN以外のSFPRとは異なる必要があります。
The Service path identifier is defined in [RFC8300] and is the value to be placed in the "Service Path Identifier" field of the NSH of any packet sent on this SFP. It is expected that one or more controllers will originate these routes in order to configure a service function overlay network.
サービスパス識別子は[RFC8300]で定義され、このSFPで送信されたパケットのNSHの「サービスパス識別子」フィールドに配置される値です。サービス機能オーバーレイネットワークを構成するために、1つ以上のコントローラがこれらのルートを発信することが予想されます。
The SFP is described in a new BGP Path attribute, the SFP attribute. Section 3.2.1 shows the format of that attribute.
SFPは、SFP属性の新しいBGPパス属性で説明されています。セクション3.2.1にその属性の形式を示します。
[RFC4271] defines BGP Path attributes. This document introduces a new Optional Transitive Path attribute called the "SFP attribute", with value 37. The first SFP attribute MUST be processed, and subsequent instances MUST be ignored.
[RFC4271] BGPパス属性を定義します。このドキュメントでは、値37を持つ "SFP属性"という新しいオプションの推移パス属性が紹介されています。最初のSFP属性は処理されなければならず、後続のインスタンスは無視されなければなりません。
The common fields of the SFP attribute are set as follows:
SFP属性の共通フィールドは次のように設定されています。
* The Optional bit is set to 1 to indicate that this is an optional attribute.
* オプションのビットは1に設定されており、これはオプションの属性であることを示します。
* The Transitive bit is set to 1 to indicate that this is a transitive attribute.
* 推移的ビットは1に設定されており、これは推移的属性であることを示します。
* The Extended Length bit is set if the length of the SFP attribute is encoded in one octet (set to 0) or two octets (set to 1), as described in [RFC4271].
* [RFC4271]で説明されているように、SFP属性の長さが1つのオクテット（0に設定）または2つのオクテット（1に設定）内にエンコードされている場合は、拡張長ビットが設定されます。
* The Attribute Type Code is set to 37.
* 属性タイプコードは37に設定されています。
The content of the SFP attribute is a series of Type-Length-Value (TLV) constructs. Some TLVs may include Sub-TLVs. All TLVs and Sub-TLVs have a common format:
SFP属性の内容は一連のタイプ長値（TLV）構成です。いくつかのTLVはサブTLVを含み得る。すべてのTLVSとSUB-TLVには共通のフォーマットがあります。
Type: A single octet indicating the type of the SFP attribute TLV. Values are taken from the registry described in Section 10.3.
型：SFP属性TLVの型を示す単一のオクテット。値は、セクション10.3で説明されているレジストリから取得されます。
Length: A two-octet field indicating the length of the data following the "Length" field, counted in octets.
長さ：オクテットでカウントされた「長さ」フィールドに続くデータの長さを示す2オクテットフィールド。
Value: The contents of the TLV.
値：TLVの内容。
The formats of the TLVs defined in this document are shown in the following sections. The presence rules and meanings are as follows.
この文書で定義されているTLVの形式は、次のセクションに示されています。プレゼンスルールと意味は以下の通りです。
* The SFP attribute contains a sequence of zero or more Association TLVs. That is, the Association TLV is OPTIONAL. Each Association TLV provides an association between this SFPR and another SFPR. Each associated SFPR is indicated using the RD with which it is advertised (we say the SFPR-RD to avoid ambiguity).
* SFP属性には、ゼロ以上のアソシエーションTLVSのシーケンスが含まれています。つまり、関連TLVはオプションです。各協会TLVは、このSFPRと別のSFPRの間の関連付けを提供します。関連する各SFPRは、それが宣伝されているRDを使用して示されます（あいまいさを避けるためにSFPR-RDと言う）。
* The SFP attribute contains a sequence of one or more Hop TLVs. Each Hop TLV contains all of the information about a single hop in the SFP.
* SFP属性には、1つ以上のホップTLVのシーケンスが含まれています。各ホップTLVには、SFP内のシングルホップに関するすべての情報が含まれています。
* Each Hop TLV contains an SI value and a sequence of one or more SFT TLVs. Each SFT TLV contains an SFI reference for each instance of an SF that is allowed at this hop of the SFP for the specific SFT. Each SFI is indicated using the RD with which it is advertised (we say the SFIR-RD to avoid ambiguity).
* 各ホップTLVには、Si値と1つ以上のSFT TLVのシーケンスが含まれています。各SFT TLVには、特定のSFTのSFPのこのホップで許可されているSFの各インスタンスのSFI参照が含まれています。各SFIは、それが宣伝されているRDを使用して示されます（あいまいさを避けるためにSFIR-RDと言う）。
Section 6 of [RFC4271] describes the handling of malformed BGP attributes, or those that are in error in some way. [RFC7606] revises BGP error handling specifically for the UPDATE message, provides guidelines for the authors of documents defining new attributes, and revises the error-handling procedures for a number of existing attributes. This document introduces the SFP attribute and so defines error handling as follows:
[RFC4271]のセクション6は、不正なBGP属性の処理、あるいは何らかの方法で誤っているものを説明しています。[RFC7606]具体的には、更新メッセージのために特にBGPエラー処理を修正し、新しい属性の定義文書の作成者のガイドラインを提供し、既存の属性の数のエラー処理手順を修正します。この文書ではSFP属性を紹介しているので、次のようにエラー処理を定義します。
* When parsing a message, an unknown Attribute Type Code or a length that suggests that the attribute is longer than the remaining message is treated as a malformed message, and the "treat-as-withdraw" approach is used as per [RFC7606].
* メッセージを解析するとき、未知の属性タイプコードまたは属性が残りのメッセージより長いことを示唆している長さは不正な形式のメッセージとして扱われ、[RFC7606]として「扱いAS撤回」アプローチが使用されます。
* When parsing a message that contains an SFP attribute, the following cases constitute errors:
* SFP属性を含むメッセージを解析するときは、次のような場合がエラーを構成します。
1. Optional bit is set to 0 in the SFP attribute.
1. SFP属性ではオプションのビットが0に設定されています。
2. Transitive bit is set to 0 in the SFP attribute.
2. SFP属性では、推移的ビットが0に設定されています。
3. Unknown "TLV Type" field found in the SFP attribute.
3. SFP属性にある不明な「TLV Type」フィールド。
4. TLV length that suggests the TLV extends beyond the end of the SFP attribute.
4. TLVの長さTLVがSFP属性の末尾を超えて拡張されていることを示唆しています。
5. Association TLV contains an unknown SFPR-RD.
5. 関連TLVには、未知のSFPR-RDが含まれています。
6. No Hop TLV found in the SFP attribute.
6. SFP属性にHop TLVが見つかりませんでした。
7. No Sub-TLV found in a Hop TLV.
7. HOP TLVにサブTLVが見つかりませんでした。
8. Unknown SFIR-RD found in an SFT TLV.
8. SFT TLVで見つかった未知のSFIR-RD。
* The errors listed above are treated as follows:
* 上記のエラーは次のように扱われます。
1, 2, 4, 6, 7: The attribute MUST be treated as malformed and the "treat-as-withdraw" approach used as per [RFC7606].
1,2,4,6,7：属性は不正なものとして扱われなければならず、[RFC7606]と同じ「「扱いas撤回」アプローチを使用します。
3: Unknown TLVs MUST be ignored, and message processing MUST continue.
3：不明なTLVSは無視される必要があり、メッセージ処理は続行される必要があります。
5, 8: The absence of an RD with which to correlate is nothing more than a soft error. The receiver SHOULD store the information from the SFP attribute until a corresponding advertisement is received.
5,8：相関するためのRDが存在しないことは、ソフトエラーに他ならない。受信者は、対応する広告が受信されるまでSFP属性から情報を格納する必要があります。
The Association TLV is an optional TLV in the SFP attribute. It MAY be present multiple times. Each occurrence provides an association with another SFP as advertised in another SFPR. The format of the Association TLV is shown in Figure 7.
Association TLVはSFP属性のオプションのTLVです。それは複数回存在するかもしれません。各発生は、別のSFPRでアドバタイズされているように他のSFPとの関連付けを提供します。関連TLVのフォーマットを図7に示します。
+--------------------------------------------+
| Type = 1 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Association Type (1 octet) |
+--------------------------------------------|
| Associated SFPR-RD (8 octets) |
+--------------------------------------------|
| Associated SPI (3 octets) |
+--------------------------------------------+
Figure 7: The Format of the Association TLV
図7：協会TLVのフォーマット
The fields are as follows:
フィールドは次のとおりです。
* "Type" is set to 1 to indicate an Association TLV.
* 関連付けTLVを示すために「タイプ」が1に設定されています。
* "Length" indicates the length in octets of the "Association Type" and "Associated SFPR-RD" fields. The value of the "Length" field is 12.
* 「Length」は、「アソシエーションタイプ」と「関連するSFPR-RD」フィールドのオクテットの長さを示します。「長さ」フィールドの値は12です。
* The "Association Type" field indicates the type of association. The values are tracked in an IANA registry (see Section 10.4). Only one value is defined in this document: Type 1 indicates association of two unidirectional SFPs to form a bidirectional SFP. An SFP attribute SHOULD NOT contain more than one Association TLV with Association Type 1; if more than one is present, the first one MUST be processed, and subsequent instances MUST be ignored. Note that documents that define new association types must also define the presence rules for Association TLVs of the new type.
* 「Association Type」フィールドは、関連付けの種類を示します。値はIANAレジストリで追跡されます（10.4項を参照）。この文書で定義されている値は1つだけです。タイプ1は、2つの単方向SFPの関連付けを示し、双方向SFPを形成します。SFP属性には、関連付けタイプ1を持つ複数の関連TLVを含めるべきではありません。複数の場合は、最初のものを処理する必要があり、後続のインスタンスは無視されなければなりません。新しいアソシエーションタイプを定義する文書も、新しいタイプの関連TLVのプレゼンスルールを定義する必要があります。
* The Associated SFPR-RD contains the RD of the associated SFP as advertised in an SFPR.
* 関連付けられたSFPR-RDには、SFPRでアドバタイズされているように関連するSFPのRDが含まれています。
* The Associated SPI contains the SPI of the associated SFP as advertised in an SFPR.
* 関連するSPIには、SFPRでアドバタイズされているように関連するSFPのSPIが含まれています。
Association TLVs with unknown Association Type values SHOULD be ignored. Association TLVs that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are contained SHOULD be ignored. If the Associated SPI is not equal to the SPI advertised in the SFPR indicated by the Associated SFPR-RD, then the Association TLV SHOULD be ignored. In all three of these cases, an implementation MAY reject the SFP attribute as malformed and use the "treat-as-withdraw" approach per [RFC7606]; however, implementors are cautioned that such an approach may make an implementation less flexible in the event of future extensions to this protocol.
アソシエーションが不明のAssociation TLVSは無視されるべきです。それらが含まれているSFPRのRDに等しい関連SFPR-RD値を含む関連TLVは無視されるべきです。関連するSFPR-RDで示されるSFPRでアドバタイズされたSPIと等しくない場合、関連付けられているTLVは無視されるべきです。これら3つの場合すべての場合において、実装は不正な形式としてSFP属性を拒否し、[RFC7606]ごとの「扱いAS撤回」アプローチを使用することができます。しかしながら、このようなアプローチは、このプロトコルへの将来の拡張が発生した場合にそのようなアプローチが実装を少なくすることができると警告されている。
Note that when two SFPRs reference each other using the Association TLV, one SFPR advertisement will be received before the other. Therefore, processing of an association MUST NOT be rejected simply because the Associated SFPR-RD is unknown.
Association TLVを使用して2つのSFPRが互いに参照すると、もう1つのSFPRアドバタイズメントが受信されます。したがって、関連するSFPR-RDが不明なため、関連付けの処理を拒否しないでください。
Further discussion of correlation of SFPRs is provided in Section 7.1.
SFPRSの相関関係についてのさらなる説明はセクション7.1に提供されている。
There is one Hop TLV in the SFP attribute for each hop in the SFP. The format of the Hop TLV is shown in Figure 8. At least one Hop TLV MUST be present in an SFP attribute.
SFPの各ホップのSFP属性に1ホップTLVが1つあります。ホップTLVのフォーマットを図8に示します。少なくとも1ホップTLVはSFP属性に存在している必要があります。
+--------------------------------------------+
| Type = 2 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Service Index (1 octet) |
+--------------------------------------------|
| Hop Details (variable) |
+--------------------------------------------+
Figure 8: The Format of the Hop TLV
図8：ホップTLVのフォーマット
The fields are as follows:
フィールドは次のとおりです。
* "Type" is set to 2 to indicate a Hop TLV.
* ホップTLVを示すには、「タイプ」が2に設定されています。
* "Length" indicates the length, in octets, of the "Service Index" and "Hop Details" fields.
* 「Length」は、「サービスインデックス」と「ホップ詳細」フィールドの長さ、オクテットの長さを示します。
* The Service Index is defined in [RFC8300] and is the value found in the "Service Index" field of the NSH that an SFF will use to look up to which next SFI a packet is to be sent.
* サービスインデックスは[RFC8300]で定義され、SFFが次のSFIを送信するためにSFFが使用するNSHの「サービスインデックス」フィールドにある値です。
* The "Hop Details" field consists of a sequence of one or more Sub-TLVs.
* 「ホップ詳細」フィールドは、1つ以上のサブTLVのシーケンスで構成されています。
Each hop of the SFP may demand that a specific type of SF is executed, and that type is indicated in Sub-TLVs of the Hop TLV. At least one Sub-TLV MUST be present. This document defines the SFT Sub-TLV (see Section 3.2.1.3) and the MPLS Swapping/Stacking Sub-TLV (see Section 3.2.1.4); other Sub-TLVs may be defined in future. The SFT Sub-TLV provides a list of which types of SF are acceptable at a specific hop, and for each type it allows a degree of control to be imposed on the choice of SFIs of that particular type. The MPLS Swapping/Stacking Sub-TLV indicates the type of SFC encoding to use in an MPLS label stack.
SFPの各ホップは、特定の種類のSFが実行され、そのタイプがホップTLVのサブTLVに示されていることが要求される。少なくとも1つのサブTLVが存在している必要があります。この文書はSFTサブTLV（セクション3.2.1.3を参照）とMPLSスワッピング/スタッキングサブTLVを定義します（セクション3.2.1.4を参照）。他のサブTLVは将来定義されてもよい。SFTサブTLVは、特定のホップでどのタイプのSFが許容可能であり、各タイプに対して、その特定のタイプのSFIの選択にある程度の制御を課すことが可能になる。MPLSスワッピング/スタッキングSUB-TLVは、MPLSラベルスタックで使用するSFCエンコーディングのタイプを示します。
If no Hop TLV is present in an SFP attribute, it is a malformed attribute.
HOP TLVがSFP属性に存在しない場合は、不正な形式の属性です。
The SFT Sub-TLV MAY be included in the list of Sub-TLVs of the Hop TLV. The format of the SFT Sub-TLV is shown in Figure 9. The Hop Sub-TLV contains a list of SFIR-RD values each taken from the advertisement of an SFI. Together they form a list of acceptable SFIs of the indicated type.
SFTサブTLVは、ホップTLVのサブTLVのリストに含まれていてもよい。SFTサブTLVのフォーマットを図9に示します.HOPサブTLVには、それぞれSFIの広告から取得されたSFIR-RD値のリストが含まれています。それらは一緒に示されたタイプの許容可能なSFIのリストを形成する。
+--------------------------------------------+
| Type = 3 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Service Function Type (2 octets) |
+--------------------------------------------|
| SFIR-RD List (variable) |
+--------------------------------------------+
Figure 9: The Format of the SFT Sub-TLV
図9：SFTサブTLVの形式
The fields are as follows:
フィールドは次のとおりです。
* "Type" is set to 3 to indicate an SFT Sub-TLV.
* SFTサブTLVを示すために「タイプ」が3に設定されています。
* "Length" indicates the length, in octets, of the "Service Function Type" and "SFIR-RD List" fields.
* 「長さ」は、「サービス関数タイプ」と「SFIR-RDリスト」フィールドの長さ、オクテットの長さを示します。
* The SFT value indicates the category (type) of SF that is to be executed at this hop. The types are as advertised for the SFs supported by the SFFs. SFT values in the range 1-31 are special-purpose SFT values and have meanings defined by the documents that describe them -- the value "Change Sequence" is defined in Section 6.1 of this document.
* SFT値は、このホップで実行されるSFのカテゴリ（Type）を示します。タイプは、SFFSでサポートされているSFSのアドバタイズ済みです。1~31の範囲のSFT値は、専用のSFT値で、それらを記述する文書で定義されている意味を持ちます。
* The hop description is further qualified beyond the specification of the SFTs by listing, for each SFT in each hop, the SFIs that may be used at the hop. The SFIs are identified using the SFIR-RDs from the advertisements of the SFIs in the SFIRs. Note that if the list contains one or more SFIR Pool Identifiers, then for each, the SFIR-RD list is effectively expanded to include the SFIR-RD of each SFIR advertised with that SFIR Pool Identifier. An SFIR-RD of value zero has special meaning, as described in Section 5. Each entry in the list is eight octets long, and the number of entries in the list can be deduced from the value of the "Length" field.
* ホップ記述は、各ホップの各SFTについて、ホップで使用され得るSFIをリストすることによって、SFTの仕様を超えてさらに修飾されています。SFISは、SFISのSFISの広告からSFIR-RDSを使用して識別されます。リストに1つ以上のSFIRプール識別子が含まれている場合は、それぞれにSFIR-RDリストが効果的に拡張され、そのSFIRプールIDでアドバタイズされた各SFIRのSFIR-RDが含まれています。セクション5で説明されているように、値ゼロのSFIR-RDには特別な意味があります。リスト内の各エントリは8オクテットの長さで、リスト内のエントリ数は「長さ」フィールドの値から推測できます。
* Note that an SFIR-RD is of type 0, 1, or 2 (as described in Section 3.1). Thus, the high-order octet of an RD found in an SFIR-RD List always has a value of 0x00. However, the high-order octet of an SFIR Pool Identifier (an Extended Community with "Type" field 0x0b) will always have a nonzero value. This allows the node processing the SFIR-RD list to distinguish between the two types of list entry.
* SFIR-RDは、（セクション3.1で説明されているように）タイプ0,1、または2のものです。したがって、SFIR-RDリストにあるRDの高次オクテットは常に0x00の値を持ちます。ただし、SFIRプール識別子の高次オクテット（「タイプ」フィールド0x0bを持つ拡張コミュニティ）は常にゼロ以外の値を持ちます。これにより、ノードはSFIR-RDリストを処理して2つのタイプのリストエントリを区別することができます。
The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero-length Sub-TLV that is OPTIONAL in the Hop TLV and is used when the data representation is MPLS (see Section 7.5). When present, it indicates to the classifier imposing an MPLS label stack that the current hop is to use an {SFC Context Label, SF label} rather than an {SPI, SF} label pair. See Section 7.6 for more details.
MPLSスワッピング/積載サブ-TLV（タイプ値4）は、ホップTLVでオプションであり、データ表現がMPLSの場合に使用されるゼロ長さのサブTLVです（セクション7.5を参照）。存在する場合、それは現在のホップが{SPI、SF}ラベルペアではなく、{SFCコンテキストラベルSF Label}を使用することであるMPLSラベルスタックを課す分類子を示す。詳細については7.6項を参照してください。
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero-length TLV that can be carried in the SFP attribute and indicates to the classifier and the SFFs on the SFP that an MPLS label stack with label swapping/stacking is to be used for packets traversing the SFP. All of the SFFs specified at each of the SFP's hops MUST have advertised an MPLS Mixed Swapping/Stacking Extended Community (see Section 3.1.2) for the SFP to be considered usable.
MPLSラベルスタックTLV（タイプ値5）を使用したSFPトラバーサルは、SFP属性で実行できるゼロ長TLVで、SFP上のSFP上のSFFのラベルスワッピング/スタック付きのSFFSを示します。SFPを横断するパケットに使用されます。SFPの各HOPで指定されたすべてのSFFは、SFPを使用可能と見なすためにMPLS混合スワップ/スタッキング拡張コミュニティ（セクション3.1.2を参照）をアドバタイズしている必要があります。
It is possible for the same SFI, as described by an SFIR, to be used in multiple SFPRs.
SFIRによって説明されているのと同じSFIが複数のSFPRSで使用されることが可能です。
When two SFPRs have the same SPI but different SFPR-RDs, there can be three cases:
2つのSFPRSが同じSPIだが異なるSFPR-RDSを持つ場合、3つのケースがあります。
1. Two or more controllers are originating SFPRs for the same SFP. In this case, the content of the SFPRs is identical, and the duplication is to ensure receipt and provide controller redundancy.
1. 2つ以上のコントローラが同じSFPのSFPRSを発信しています。この場合、SFPRSの内容は同一であり、複製は受信およびコントローラの冗長性を確保することです。
2. There is a transition in content of the advertised SFP, and the advertisements may originate from one or more controllers. In this case, the content of the SFPRs will be different.
2. 広告SFPの内容に遷移があり、広告は1つ以上のコントローラから発生する可能性があります。この場合、SFPRSの内容は異なります。
3. The reuse of an SPI may result from a configuration error.
3. SPIの再利用は設定エラーから生じる可能性があります。
There is no way in any of these cases for the receiving SFF to know which SFPR to process, and the SFPRs could be received in any order. At any point in time, when multiple SFPRs have the same SPI but different SFPR-RDs, the SFF MUST use the SFPR with the numerically lowest SFPR-RD when interpreting the RDs as 8-octet integers in network byte order. The SFF SHOULD log this occurrence to assist with debugging.
受信SFFがどのSFPRを処理するかを知るためのこれらのケースのいずれかには、SFPRを任意の順序で受信できるようにする方法はありません。任意の時点で、複数のSFPRSが同じSPIであるが異なるSFPR-RDSを持つ場合、SFFは、RDSをネットワークバイト順に8オクテットの整数として解釈するときにSFPRを数値的に最小のSFPR-RDで使用する必要があります。SFFは、デバッグを支援するためにこのオカレンスを記録する必要があります。
Furthermore, a controller that wants to change the content of an SFP is RECOMMENDED to use a new SPI and so create a new SFP onto which the classifiers can transition packet flows before the SFPR for the old SFP is withdrawn. This avoids any race conditions with SFPR advertisements.
さらに、SFPの内容を変更したいコントローラを新しいSPIを使用することをお勧めします。そのため、古いSFP用のSFPRが引き出される前に、分類子がパケットフローを遷移させることができる新しいSFPを作成します。これにより、SFPR広告を持つ競合条件が避けられます。
Additionally, a controller SHOULD NOT reuse an SPI after it has withdrawn the SFPR that used it until at least a configurable amount of time has passed. This timer SHOULD have a default of one hour.
さらに、コントローラは、少なくとも設定可能な時間が経過するまで使用したSFPRを使用した後にSPIを再利用しないでください。このタイマーは1時間のデフォルトを持つ必要があります。
This document describes the use of BGP as a control plane to create and manage a service function overlay network.
この文書では、サービス機能オーバーレイネットワークを作成および管理するためのコントロールプレーンとしてのBGPの使用について説明します。
The main feature introduced by this document is the ability to create multiple service function overlay networks through the use of Route Targets (RTs) [RFC4364].
この文書によって導入された主な機能は、ルート目標（RTS）[RFC4364]を使用して複数のサービス機能オーバーレイネットワークを作成することができます。
Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. The RT carried by a particular SFIR or SFPR is determined by the provisioning of the route's originator.
SFIRまたはSFPRを含むすべてのBGPアップデートは1つ以上のRTSを搬送します。特定のSFIRまたはSFPRによって運ばれるRTは、ルートの発信者のプロビジョニングによって決定されます。
Every node in a service function overlay network is configured with one or more import RTs. Thus, each SFF will import only the SFPRs with matching RTs, allowing the construction of multiple service function overlay networks or the instantiation of SFCs within a Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVPN) instance (see Section 7.3). An SFF that has a presence in multiple service function overlay networks (i.e., one that imports more than one RT) will usually maintain separate forwarding state for each overlay network.
サービス機能オーバーレイネットワーク内のすべてのノードは、1つ以上のインポートRTSで構成されています。したがって、各SFFはSFPRSのみをマッチングRTSでインポートし、複数のサービス機能オーバーレイネットワークの構築や、レイヤ3仮想プライベートネットワーク（L3VPN）またはイーサネットVPN（EVPN）インスタンス内のSFCのインスタンス化を可能にします（セクション7.3を参照）。複数のサービス機能オーバーレイネットワーク（すなわち、複数のRTをインポートするもの）に存在するSFFは、通常、各オーバーレイネットワークに対して別々の転送状態を維持する。
The SFIR (see Section 3.1) is used to advertise the existence and location of a specific SFI; it consists of:
SFIR（セクション3.1を参照）は、特定のSFIの存在と場所を宣伝するために使用されます。それは次のものです：
* The RT as just described.
* 述べたようにRT。
* A Service Function Type (SFT) that is the type of service function that is provided (such as "firewall").
* 提供されるサービス機能の種類（「ファイアウォール」など）であるサービス機能タイプ（SFT）。
* A Route Distinguisher (RD) that is unique to a specific overlay.
* 特定のオーバーレイに固有のルート識別器（RD）。
The SFPR (see Section 3.2) describes a specific path of an SFC. The SFPR contains the Service Path Identifier (SPI) used to identify the SFP in the NSH in the data plane. It also contains a sequence of Service Indexes (SIs). Each SI identifies a hop in the SFP, and each hop is a choice between one or more SFIs.
SFPR（セクション3.2を参照）はSFCの特定のパスを示しています。SFPRには、データプレーン内のNSH内のSFPを識別するために使用されるサービスパス識別子（SPI）が含まれています。一連のサービスインデックス（SIS）も含まれています。各SIはSFP内のホップを識別し、各ホップは1つ以上のSFI間の選択です。
As described in this document, each SFP route is identified in the service function overlay network by an RD and an SPI. The SPI is unique within a single VPN instance supported by the underlay network.
この文書に記載されているように、各SFPルートは、RDおよびSPIによってサービス機能オーバーレイネットワークにおいて識別される。SPIは、アンダーレイネットワークでサポートされている単一のVPNインスタンス内で一意です。
The SFPR advertisement comprises:
SFPR広告は以下を含む。
* An RT as described in Section 4.1.
* セクション4.1に記載されているようなRT。
* A tuple that identifies the SFPR.
* SFPRを識別するタプル。
- An RD that identifies an advertisement of an SFPR.
- SFPRの広告を識別するRD。
- The SPI that uniquely identifies this path within the VPN instance distinguished by the RD. This SPI also appears in the NSH.
- RDによって区別されるVPNインスタンス内のこのパスを一意に識別するSPI。このSPIはNSHにも表示されます。
* A series of SIs. Each SI is used in the context of a particular SPI and identifies one or more SFs (distinguished by their SFTs). For each SF, it identifies a set of SFIs that instantiate the SF. The values of the SI indicate the order in which the SFs are to be executed in the SFP that is represented by the SPI.
* 一連のSIS。各SIは特定のSPIの文脈で使用され、1つ以上のSFS（それらのSFTによって区別される）を識別する。各SFについて、SFをインスタンス化するSFIのセットを識別します。SIの値は、SFIがSPIで表されるSFPでSFSを実行する順序を示します。
* The SI is used in the NSH to identify the entries in the SFP. Note that the SI values have meaning only relative to a specific path. They have no semantic other than to indicate the order of SFs within the path and are assumed to be monotonically decreasing from the start to the end of the path [RFC8300].
* SFPのエントリを識別するためにNSHではSIが使用されます。SI値は特定のパスに対してのみ意味を持つことに注意してください。それらは、パス内のSFSの順序を示す以外に意味以上を持ち、パスの開始から終わりまで単調に減少すると仮定されています[RFC8300]。
* Each SI is associated with a set of one or more SFIs that can be used to provide the indexed SF within the path. Each member of the set comprises:
* 各SIは、パス付きSFをパス内に提供するために使用できる1つまたは複数のSFIのセットに関連付けられています。セットの各メンバーは次のとおりです。
- The RD used in an SFIR advertisement of the SFI.
- SFIのSFI広告で使用されているRD。
- The SFT that indicates the type of function as used in the same SFIR advertisement of the SFI.
- SFIの同じSFI広告で使用される機能の種類を示すSFT。
This may be summarized as follows, where the notations "SFPR-RD" and "SFIR-RD" are used to distinguish the two different RDs, and where "*" indicates a multiplier:
これは次のように要約されています。ここで、表記「SFPR-RD」と「SFIR-RD」とは、2つの異なるRDSを区別するために使用され、「*」が乗数を示す場合があります。
RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }
Where:
ただし：
RT: Route Target
RT：ルートターゲット
SFPR-RD: The Route Descriptor of the SFPR advertisement
SFPR-RD：SFPRアドバタイズメントのルートディスクリプタ
SPI: Service Path Identifier used in the NSH
SPI：NSHで使用されているサービスパス識別子
m: The number of hops in the SFP
M：SFPのホップ数
n: The number of choices of SFT for a specific hop
N：特定のホップのSFTの選択数
p: The number of choices of SFI for a given SFT in a specific hop
P：特定のホップにおける特定のSFTのSFIの選択数
SI: Service Index used in the NSH to indicate a specific hop
SI：特定のホップを示すためにNSHで使用されるサービスインデックス
SFT: The Service Function Type used in the same advertisement of the SFIR
SFT：SFIRの同じ広告で使用されるサービス機能タイプ
SFIR-RD: The Route Descriptor used in an advertisement of the SFIR
SFIR-RD：SFIRの広告で使用されているルートディスクリプタ
That is, there can be multiple SFTs at a given hop, as described in Section 5.
すなわち、セクション5で説明したように、所与のホップに複数のSFTがある可能性がある。
Note that the values of SI are from the set {255, ..., 1} and are monotonically decreasing within the SFP. SIs MUST appear in order within the SFPR (i.e., monotonically decreasing) and MUST NOT appear more than once. Gaps MAY appear in the sequence, as described in Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.
なお、Siの値は集合{255、...、1}からのものであり、SFP内で単調に減少している。SFPR内（すなわち単調減少）内にSISが順番に現れ、複数回表示されてはならない。セクション4.5.1に記載されているように、ギャップはシーケンスに表示されることがあります。不正な形式のSFPRは破棄されなければならず、SFPR（同じSFPR-RDおよびSPI）の以前のインスタンスを破棄する必要があります。
Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool Identifiers, then in the above expression, "p" is the sum of the number of individual SFIR-RD values and the sum for each SFIR Pool Identifier of the number of SFIRs advertised with that SFIR Pool Identifier. In other words, the list of SFIR-RD values is effectively expanded to include the SFIR-RD of each SFIR advertised with each SFIR Pool Identifier in the SFIR-RD list.
SFT TLVのSFIR-RDリストに1つ以上のSFIRプール識別子が含まれている場合、上記の式では、「P」は個々のSFIR-RD値の数と各SFIRプールIDの合計の合計です。そのSFIRプール識別子でアドバタイズされたSFIRの数。言い換えれば、SFIR-RD値のリストは、SFIR-RDリスト内の各SFIRプールIDでアドバタイズされた各SFIRのSFIR-RDを含むように効果的に拡張されます。
The choice of SFI is explained further in Section 5. Note that an SFIR-RD value of zero has special meaning, as described in that section.
SFIの選択については、セクション5でさらに説明されています。
As shown in Figure 1, the classifier is a component that is used to assign packets to an SFP.
図1に示すように、分類器は、パケットをSFPに割り当てるために使用されるコンポーネントです。
The classifier is responsible for determining to which packet flow a packet belongs. The mechanism it uses to achieve that classification is out of the scope of this document but might include inspection of the packet header. The classifier has been instructed (by the controller or through some other configuration mechanism -- see Section 7.4) which flows are to be assigned to which SFPs, and so it can impose an NSH on each packet and initialize the NSH with the SPI of the selected SFP and the SI of its first hop.
分類器は、パケットがどのパケットフローが属するかを決定する責任がある。分類を達成するために使用するメカニズムはこの文書の範囲外ですが、パケットヘッダーの検査を含めることができます。分類子は、（コントローラまたは他の構成メカニズムによって（7.4セクション7.4を参照）、どのフローがどのSFPに割り当てられているため、各パケットにNSHを課し、NSHをSPIに初期化することができます。選択されたSFPとその最初のホップのSI。
Note that instructions delivered to the classifier may include information about the metadata to encode (and the format for that encoding) on packets that are classified by the classifier to a particular SFP. As mentioned in Section 2.2, this corresponds to the fifth element of control plane functionality described in [RFC7665]. Such instructions fall outside the scope of this specification (but see Section 7.4), as do instructions to other service function chaining elements on how to interpret metadata (as described in the sixth element of control plane functionality described in [RFC7665]).
分類子に配信された命令は、分類子によって特定のSFPに分類されているパケット上の符号化するメタデータ（およびその符号化のフォーマット）に関する情報を含み得る。セクション2.2で述べたように、これは[RFC7665]に記載されている制御プレーン機能の5番目の要素に対応しています。そのような命令は、メタデータを解釈する方法についての他のサービス関数連鎖要素の指示を行うように、この仕様の範囲外に含まれています（ただし、[RFC7665]に記載されている制御プレーン機能の6番目の要素）。
Each packet sent to an SFF is transmitted encapsulated in an NSH. The NSH includes an SPI and SI: the SPI indicates the SFPR advertisement that announced the SFP; the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a particular SFIR advertisement.
SFFに送信された各パケットは、NSHにカプセル化されて送信されます。NSHにはSPIとSIが含まれています.SPIはSFPを発表したSFPR広告を示しています。タプルSPI / SIは特定のパス内の特定のホップを示し、特定のSFIR広告のRD / SFTにマッピングされます。
When an SFF gets an SFPR advertisement, it will first determine whether to import the route by examining the RT. If the SFPR is imported, the SFF then determines whether it is on the SFP by looking for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For each occurrence in the SFP, the SFF creates forwarding state for incoming packets and forwarding state for outgoing packets that have been processed by the specified SFI.
SFFSがSFPRアドバタイズメントを取得すると、RTを調べてルートをインポートするかどうかを最初に決定します。SFPRがインポートされている場合、SFFは、SFPR-RDSまたはSFPRでゼロのゼロを持つSFIR-RDまたはSFIR-RDを探してSFP上にあるかどうかを決定します。SFP内の発生ごとに、SFFは、指定されたSFIによって処理された発信パケットの着信パケットと転送状態の転送状態を作成します。
The SFF creates local forwarding state for packets that it receives from other SFFs. This state makes the association between the SPI/SI in the NSH of the received packet and one or more specific local SFIs, as identified by the SFIR-RD/SFT. If there are multiple local SFIs that match, this is because a single advertisement was made for a set of equivalent SFIs, and the SFF may use local policy (such as load balancing) to determine to which SFI to forward a received packet.
SFFは、他のSFFから受信したパケットのローカル転送状態を作成します。この状態は、SFIR - RD / SFTによって識別されるように、受信パケットのNSH内のSPI / SIと1つ以上の特定のローカルSFIとの間の関連付けを行う。一致する複数のローカルSFIがある場合、これは一連の同等のSFIに対して単一の広告が作成され、SFFはローカルポリシー（ロードバランシングなど）を使用して、受信したパケットを転送するためのSFIを決定することができます。
The SFF also creates next-hop forwarding state for packets received back from the local SFI that need to be forwarded to the next hop in the SFP. There may be a choice of next hops, as described in Section 4.3. The SFF could install forwarding state for all potential next hops or it could choose to only install forwarding state for a subset of the potential next hops. If a choice is made, then it will be as described in Section 5.
SFFは、SFPのネクストホップに転送される必要があるローカルSFIから返送されたパケットのネクストホップ転送状態も作成されます。セクション4.3に記載されているように、次のホップの選択があるかもしれません。SFFは、次のホップのすべての潜在的なホップに対して転送状態をインストールすることも、次のホップの潜在的なスカットのサブセットのための転送状態のみをインストールすることもできます。選択が行われた場合、それはセクション5で説明されているようになるでしょう。
The installed forwarding state may change over time, reacting to changes in the underlay network and the availability of particular SFIs. Note that the forwarding state describes how one SFF sends packets to another SFF, but not how those packets are routed through the underlay network. SFFs may be connected by tunnels across the underlay, or packets may be sent addressed to the next SFF and routed through the underlay. In any case, transmission across the underlay requires encapsulation of packets with a header for transport in the underlay network.
インストールされている転送状態は、アンダーレイネットワークの変化と特定のSFIの可用性に反応する時間とともに変化します。転送状態は、1つのSFFがパケットを別のSFFに送信するかを表していますが、それらのパケットがアンダーレイネットワークを介してどのようにルーティングされるかは示されません。SFFSはアンダーレイを横切ってトンネルによって接続されてもよく、またはパケットが次のSFFにアドレス指定され、アンダーレイを介してルーティングされてもよい。いずれにせよ、アンダーレイ全体の送信は、アンダーレイネットワーク内でのトランスポートのためのヘッダを有するパケットのカプセル化を必要とする。
Note that SFFs only create and store forwarding state for the SFPs on which they are included. They do not retain state for all SFPs advertised.
SFFSは、それらが含まれているSFPのための転送状態のみを作成および保存することに注意してください。それらはすべてのSFPSのための状態を保持しません。
An SFF may also install forwarding state to support looping, jumping, and branching. The protocol mechanism for explicit control of looping, jumping, and branching uses a specific reserved SFT value at a given hop of an SFPR and is described in Section 6.1.
SFFはまた、ループ、ジャンプ、および分岐をサポートするための転送状態をインストールすることができる。ループ、ジャンプ、および分岐の明示的制御のためのプロトコルメカニズムは、SFPRの所与のホップで特定の予約されたSFT値を使用し、6.1項で説明されている。
The behavior of an SF, as described in [RFC8300], is to decrement the value of the "SI" field in the NSH by one before returning a packet to the local SFF for further processing. This means that there is a good reason to assume that the SFP is composed of a series of SFs, each indicated by an SI value one less than the previous.
[RFC8300]に記載されているSFの動作は、さらなる処理のためにパケットをローカルSFFに返す前にNSH内の「SI」フィールドの値を1つ減らすことです。これは、SFPが一連のSFSで構成されていると仮定する理由があることを意味し、それぞれSI値が前のSF値で示されている。
However, there is an advantage to having nonsuccessive SIs in an SPI. Consider the case where an SPI needs to be modified by the insertion or removal of an SF. In the latter case, this would lead to a "gap" in the sequence of SIs, and in the former case, this could only be achieved if a gap already existed into which the new SF with its new SI value could be inserted. Otherwise, all "downstream" SFs would need to be renumbered.
しかしながら、SPIに必要なSISを有することの利点がある。SFの挿入または削除によってSPIを変更する必要がある場合を考える。後者の場合、これはSISのシーケンスで「ギャップ」をもたらし、前者の場合には、新しいSI値を有する新しいSFが挿入されたギャップが既に存在している場合にのみ達成され得る。それ以外の場合は、すべての "DownStream" SFSを参照する必要があります。
Now, of course, such renumbering could be performed, but it would lead to a significant disruption to the SFC as all the SFFs along the SFP were "reprogrammed". Thus, to achieve dynamic modification of an SFP (and even in-service modification), it is desirable to be able to make these modifications without changing the SIs of the elements that were present before the modification. This will produce much more consistent/predictable behavior during the convergence period, where otherwise the change would need to be fully propagated.
今、もちろん、そのような番号の下記は実行され得るが、SFPに沿ったすべてのSFFが「再プログラミング」されたので、SFCへの大きな混乱をもたらすであろう。したがって、SFPの動的な修正（およびサービス内修飾）を達成するためには、修正前に存在していた要素のSIを変えることなくこれらの修正を加えることができることが望ましい。これは、収束期間中にはるかに一貫した/予測可能な動作を生み出し、そうでなければ変更は完全に伝播する必要があるでしょう。
Another approach says that any change to an SFP simply creates a new SFP that can be assigned a new SPI. All that would be needed would be to give a new instruction to the classifier, and traffic would be switched to the new SFP that contains the new set of SFs. This approach is practical but neglects to consider that the SFP may be referenced by other SFPs (through "branch" instructions) and used by many classifiers. In those cases, the corresponding configuration resulting from a change in SPI may have wide ripples and create scope for errors that are hard to trace.
もう1つのアプローチは、SFPへの変更は新しいSPIを割り当てることができる新しいSFPを単純に作成することを述べています。必要とされるすべてのものは、クラシファに新しい命令を与えることであり、新しいSFSのセットを含む新しいSFPにトラフィックが切り替わることです。このアプローチは実用的ですが、SFPが他のSFP（「ブランチ」命令を通じて）によって参照され、多くの分類子によって使用されることを考慮すべきことを無視します。そのような場合、SPIの変化から生じる対応する構成は広い波紋を持ち、トレースするのに難しいエラーの範囲を作成することがあります。
Therefore, while this document requires that the SI values in an SFP are monotonically decreasing, it makes no assumption that the SI values are sequential. Configuration tools may apply that rule, but they are not required to. To support this, an SFF SHOULD process as follows when it receives a packet:
したがって、この文書では、SFP内のSI値が単調に減少している必要があるが、SI値が順次であると仮定することはない。構成ツールはそのルールを適用することができますが、必要ありません。これをサポートするために、SFFはパケットを受信したときに次のように処理する必要があります。
* If the SI indicates a known entry in the SFP, the SFF MUST process the packet as normal, looking up the SI and determining to which local SFI to deliver the packet.
* SIがSFP内の既知のエントリを示す場合、SFFは通常のようにパケットを処理し、SIを調べて、どのローカルSFIをパケットを配信するかを判断する必要があります。
* If the SI does not match an entry in the SFP, the SFF MUST reduce the SI value to the next (smaller) value present in the SFP and process the packet using that SI.
* SIがSFP内のエントリと一致しない場合、SFFはSFPに存在する次の（より小さく）値にSI値を下げ、そのSIを使用してパケットを処理する必要があります。
* If there is no smaller SI (i.e., if the end of the SFP has been reached), the SFF MUST treat the SI value as not valid, as described in [RFC8300].
* SIが小さい（すなわち、SFPの終わりに達した場合）、[RFC8300]で説明されているように、SFFは有効ではないようにSF値を扱う必要があります。
This makes the behavior described in this document a superset of the function in [RFC8300]. That is, an implementation that strictly follows RFC 8300 in performing SI decrements in units of one is perfectly in line with the mechanisms defined in this document.
これにより、この文書で説明されている動作は[RFC8300]の機能のスーパーセットを作成します。つまり、1つの単位でSiの減少を実行する際にRFC 8300を厳密に追跡する実装は、この文書で定義されているメカニズムと一致しています。
SFF implementations MAY choose to only support contiguous SI values in an SFP. Such an implementation will not support receiving an SI value that is not present in the SFP and will discard the packets as described in [RFC8300].
SFF実装は、SFP内の連続SI値のみをサポートすることを選択できます。このような実装は、SFPに存在しないSI値を受信し、[RFC8300]に記載されているようにパケットを破棄します。
As described in Section 2, the SPI/SI in the NSH passed back from an SFI to the SFF may leave the SFF with a choice of next-hop SFTs and a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in an SFPR is a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of these, identify the SFF that supports the chosen SFI, and send the packet to that next-hop SFF.
セクション2で説明されているように、SFIからSFFへと渡されたNSHのSPI / SIは、SFFからNEXTホップSFTの選択、および各SFTのSFIの選択を残すことがあります。つまり、SPIはSFPRを示し、SIはそのSFPRのエントリを示します。SFPR内の各エントリは、1つ以上のSFT / SFIR-RDペアのセットです。SFFはこれらのいずれかを選択し、選択されたSFIをサポートするSFFを識別し、そのパケットをそのネクストホップSFFに送信します。
The choice be may offered for load balancing across multiple SFIs, or for discrimination between different actions necessary at a specific hop in the SFP. Different SFT values may exist at a given hop in an SFP to support several cases:
選択は、複数のSFIにわたって負荷分散のために、またはSFP内の特定のホップで必要な異なる動作の間の差別のために提供され得る。いくつかのケースをサポートするためにSFPの特定のホップに異なるSFT値が存在する可能性があります。
* There may be multiple instances of similar service functions that are distinguished by different SFT values. For example, firewalls made by vendor A and vendor B may need to be identified by different SFT values because, while they have similar functionality, their behavior is not identical. Then, some SFPs may limit the choice of SF at a given hop by specifying the SFT for vendor A, but other SFPs might not need to control which vendor's SF is used and so can indicate that either SFT can be used.
* 異なるSFT値によって区別される同様のサービス機能の複数のインスタンスがあるかもしれません。たとえば、ベンダーAとベンダーBによって行われたファイアウォールは、異なるSFT値によって識別される必要があります。なぜなら、それらは同様の機能を持ち、それらの動作は同一ではありません。その後、ベンダAのSFTを指定することで、特定のホップでSFの選択を制限することがありますが、他のSFPはどのベンダーのSFを使用するかを制御する必要がない可能性があるため、SFTを使用できることを示します。
* There may be an obvious branch needed in an SFP, such as the processing after a firewall where admitted packets continue along the SFP, but suspect packets are diverted to a "penalty box". In this case, the next hop in the SFP will be indicated with two different SFT values.
* 認証されたパケットがSFPに沿って続くが、疑わしいパケットが「ペナルティボックス」に転用されている場合は、SFPに必要な明らかな分岐があるかもしれませんが、疑わしいパケットが転用されている可能性があります。この場合、SFP内のネクストホップは2つの異なるSFT値で示されます。
In the typical case, the SFF chooses a next-hop SFF by looking at the set of all SFFs that support the SFs identified by the SI (that set having been advertised in individual SFIR advertisements), finding the one or more that are "nearest" in the underlay network, and choosing between next-hop SFFs using its own load-balancing algorithm.
典型的な場合では、SFFは、SI（個々のSFIR広告で宣伝されているセット）によって識別されたSFSをサポートしているすべてのSFFのセットを調べて、「最も近い」の1つ以上を見つけることによって、次のホップSFFを選択する。「アンダーレイネットワークでは、独自のロードバランシングアルゴリズムを使用してネクストホップSFFを選択する。
An SFI may influence this choice process by passing additional information back, along with the packet and NSH. This information may influence local policy at the SFF to either cause it to favor a next-hop SFF (perhaps selecting one that is not nearest in the underlay) or influence the load-balancing algorithm.
SFIは、パケットとNSHとともに、追加情報を返すことによってこの選択プロセスに影響を与える可能性があります。この情報は、SFFのローカルポリシーに影響を与える可能性があります（おそらくアンダーレイに最も近いものではないものを選択する）、または負荷分散アルゴリズムに影響を与える可能性があります。
This selection applies to the normal case but also applies in the case of looping, jumping, and branching (see Section 6).
この選択は通常の場合に適用されますが、ループ、ジャンプ、および分岐の場合にも適用されます（セクション6を参照）。
Suppose an SFF in a particular service function overlay network (identified by a particular import RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y. It does the following:
特定のサービス機能オーバーレイネットワーク（特定のインポートRTによって識別された）がSPIがSPI - Xであり、そのSIがSi - YであるNSHカプセル化パケットを転送する必要があるとする。次のことがあります。
1. It looks for an installed SFPR that carries RT-z and has SPI-x in its NLRI. If there is none, then such packets cannot be forwarded.
1. RT-Zを搭載し、そのNLRIにSPI-Xを持つように設置されたSFPRを探します。何もない場合、そのようなパケットは転送できません。
2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI value set to SI-y. If there is no such Hop TLV, then such packets cannot be forwarded.
2. そのSFPRのSFP属性から、SI値に設定されたホップTLVがSI-Yに設定されます。そのようなホップTLVがない場合は、そのようなパケットを転送することはできません。
3. It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs contained in the Hop TLV as follows:
3. 次に、ホップTLVに含まれているSFT TLVのリストを次のように入力することで、「関連する」セットのSFIRのセットを見つけます。
A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI matches the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches an entry in the list of SFIR-RDs in that SFT TLV.
A. SFIRはRT-Zを搭載している場合、そのNLRIのSFTはSFT TLVSのSFT値と一致し、そのNLRIのRD値はSFT TLVのSFIR-RDSのリスト内のエントリと一致します。。
B. If an entry in the SFIR-RD list of an SFT TLV contains the value zero, then an SFIR is relevant if it carries RT-z and the SFT in its NLRI matches the SFT value in that SFT TLV. That is, any SFIR in the service function overlay network defined by RT-z and with the correct SFT is relevant.
B. SFT TLVのSFIR-RDリスト内のエントリが値ゼロを含む場合、RT-Zを搬送し、そのNLRIのSFTがSFT TLVのSFT値と一致する場合は、SFIRが関連しています。つまり、RT-Zと正しいSFTで定義されたサービス関数オーバーレイネットワーク内のSFIRは関連性があります。
C. If a pool identifier is in use, then an SFIR is relevant if it is a member of the pool.
C.プール識別子が使用されている場合、それがプールのメンバーである場合、SFIRは関連性があります。
Each of the relevant SFIRs identifies a single SFI and contains a tunnel encapsulation attribute that specifies how to send a packet to that SFI. For a particular packet, the SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according to local policy.
関連するSFIRの各々は単一のSFIを識別し、そのSFIにパケットを送信する方法を指定するトンネルカプセル化属性を含む。特定のパケットの場合、SFFは関連するSFIRのセットから特定のSFIを選択します。この選択は地元の方針に従って行われます。
A typical policy might be to figure out the set of SFIs that are closest and load balance among them. But this is not the only possible policy.
典型的なポリシーは、それらの中で最も近いSFIのセットを見つけることです。しかし、これは唯一の可能なポリシーではありません。
Thus, at any point in time when an SFF selects its next hop, it chooses from the intersection of the set of next-hop RDs contained in the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e., according to the determination of "relevance", above). If the intersection is null, the SFPR is unusable. Similarly, when this condition applies on the controller that originated the SFPR, it SHOULD either withdraw the SFPR or re-advertise it with a new set of RDs for the affected hop.
したがって、SFFがそのネクストホップを選択したときの任意の時点で、SFPRに含まれる次のホップRDのセットとSFFのローカルセットに含まれるRDSのセットからの（すなわち、決定に従って選択する）。上記の「関連性」の。交差点がNULLの場合、SFPRは使用できません。同様に、この条件がSFPRを発信したコントローラに適用されると、SFPRを引き出すか、影響を受けるホップの新しいRDSのセットで再アドバタイズする必要があります。
As described in Section 2, an SFI or an SFF may cause a packet to "loop back" to a previous SF on a path in order that a sequence of functions may be re-executed. This is simply achieved by replacing the SI in the NSH with a higher value, instead of decreasing it as would normally be the case, to determine the next hop in the path.
セクション2に記載されているように、SFIまたはSFFは、一連の機能が再実行され得るように、パケットが経路上の以前のSFに「ループバック」させることがある。これは、通常のホップを決定するために、通常、NSHの値をより高い値で置き換えることによって、NSHのSIをより高い値に置き換えることによって達成されます。
Section 2 also describes how an SFI or SFF may cause a packet to "jump forward" to an SF on a path that is not the immediate next SF in the SFP. This is simply achieved by replacing the SI in the NSH with a lower value than would be achieved by decreasing it by the normal amount.
また、SFIまたはSFFがSFP内のIMMEDIDE NEXT SFではないパス上のSFIまたはSFFの原因となる方法についても説明します。これは、通常の量だけ減少することによって達成されるよりも低い値でNSHのSIを置き換えることによって単純に達成される。
A more complex option to move packets from one SFP to another is described in [RFC8300] and Section 2, where it is termed "branching". This mechanism allows an SFI or SFF to make a choice of downstream treatments for packets based on local policy and the output of the local SF. Branching is achieved by changing the SPI in the NSH to indicate the new path and setting the SI to indicate the point in the path at which the packets enter.
PacketsをあるSFPから別のSFPに移動するためのより複雑なオプションは[RFC8300]とセクション2に記載されています。ここで、「分岐」と呼ばれます。このメカニズムにより、SFIまたはSFFがローカルポリシーとローカルSFの出力に基づいてパケットのダウンストリームトリートメントを選択できます。分岐は、新しいパスを示すためにSPIをNSHに変更し、SIを設定してパケットが入力されるパス内のポイントを示すことによって実現されます。
Note that the NSH does not include a marker to indicate whether a specific packet has been around a loop before. Therefore, the use of NSH metadata [RFC8300] may be required in order to prevent infinite loops.
NSHには、特定のパケットが以前のループの周囲になっているかどうかを示すマーカーは含まれていません。したがって、無限ループを防ぐために、NSHメタデータ[RFC8300]を使用することができます。
If the SFT value in an SFT TLV in an SFPR has the special-purpose SFT value "Change Sequence" (see Section 10), then this is an indication that the SFF may make a loop, jump, or branch according to local policy and information returned by the local SFI.
SFPR内のSFT TLV内のSFT値が専用のSFT値「変更シーケンス」を有する場合（セクション10参照）、これはSFFがローカルポリシーに従ってループ、ジャンプ、またはブランチを作ることができるという指示である。ローカルSFIによって返された情報。
In this case, the SPI and SI of the next hop are encoded in the eight bytes of an entry in the SFIR-RD list as follows:
この場合、次のホップのSPIとSIは、次のようにSFIR-RDリストの8バイトのエントリにエンコードされます。
3 bytes SPI
3バイトSpi.
1 byte SI
1バイトSi.
4 bytes Reserved (SHOULD be set to zero and ignored)
4バイト予約済み（ゼロに設定され、無視されるべきです）
If the SI in this encoding is not part of the SFPR indicated by the SPI in this encoding, then this is an explicit error that SHOULD be detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT cause any forwarding state to be installed in the SFF, and packets received with the SPI that indicates this SFPR SHOULD be silently discarded.
このエンコーディングのSIがSPIによって示されているSFPRの一部ではない場合、これはSFPRを解析したときにSFFによって検出されるべき明示的なエラーです。SFPRは、転送状態をSFFにインストールさせることはできません。このSFPRを示すSPIで受信したパケットは静かに破棄されるべきです。
If the SPI in this encoding is unknown, the SFF SHOULD NOT install any forwarding state for this SFPR but MAY hold the SFPR pending receipt of another SFPR that does use the encoded SPI.
このエンコーディング内のSPIが不明な場合、SFFはこのSFPRの転送状態をインストールしないでくださいが、エンコードされたSPIを使用している別のSFPRのSFPR保留受信を保持することがあります。
If the SPI matches the current SPI for the path, this is a loop or jump. In this case, if the SI is greater than or equal to the current SI, it is a loop. If the SPI matches and the SI is less than the next SI, it is a jump.
SPIがパスの現在のSPIと一致する場合、これはループまたはジャンプです。この場合、Siが現在のSi以上である場合、ループである。SPIが一致してSIが次のSIよりも小さい場合はジャンプです。
If the SPI indicates another path, this is a branch, and the SI indicates the point at which to enter that path.
SPIが別のパスを示している場合、これはブランチであり、SIはそのパスを入力するポイントを示します。
The Change Sequence SFT is just another SFT that may appear in a set of SFI/SFT tuples within an SI and is selected as described in Section 5.
変更シーケンスSFTは、SI内のSFI / SFTタプルのセットに現れることがあり、セクション5に記載されているように選択されているものである。
Note that special-purpose SFTs MUST NOT be advertised in SFIRs. If such an SFIR is received, it SHOULD be ignored.
特殊目的のSFTはSFIRSでアドバタイズしてはいけません。そのようなSFIRが受信された場合は、無視する必要があります。
Support for looping and jumping requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate SF. This means that the SFF must have seen the relevant SFIR advertisements and mush have known that it needed to create the forwarding state. This is a matter of local configuration and implementation; for example, an implementation could be configured to install forwarding state for specific looping/jumping.
ループとジャンプのサポートには、SFFが適切なSFのインスタンスへのアクセスを提供するSFFに確立された転送状態を持つ必要があります。これは、SFFが関連するSFIR広告を見たことがあることを意味し、偽り状態を作成する必要があることを知っている必要があります。これはローカル構成と実装の問題です。例えば、特定のループ/ジャンプのために転送状態をインストールするように実装を構成することができる。
Support for branching requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate entry SF on the other SFP. This means that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it needed to create the forwarding state. This is a matter of local configuration and implementation; for example, an implementation could be configured to install forwarding state for specific branching (identified by SPI and SI).
分岐のサポートでは、SFFが他のSFP上の適切なエントリSFのインスタンスへのアクセスを提供するSFFに確立された転送状態を持つ必要があります。これは、SFFが関連するSFIRおよびSFPRの広告を見たことがあり、転送状態を作成する必要があることを知らなければならないことを意味します。これはローカル構成と実装の問題です。例えば、実装は、特定の分岐（SPIおよびSIによって識別される）のために転送状態をインストールするように構成され得る。
This section highlights several advanced topics introduced elsewhere in this document.
このセクションでは、このドキュメントの他の場所で紹介されたいくつかの高度なトピックを強調表示します。
It is often useful to create bidirectional SFPs to enable packet flows to traverse the same set of SFs, but in the reverse order. However, packets on SFPs in the data plane (per [RFC8300]) do not contain a direction indicator, so each direction must use a different SPI.
パケットフローを有効にするための双方向SFPを作成することはしばしば有用であるが、逆の順序で。ただし、データプレーン内のSFP上のパケット（[RFC8300]）は方向インジケータを含まないので、各方向は別のSPIを使用しなければなりません。
As described in Section 3.2.1.1, an SFPR can contain one or more correlators encoded in Association TLVs. If the Association Type indicates "Bidirectional SFP", then the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs, where the other in the pair is advertised in the SFPR with RD as carried in the "Associated SFPR-RD" field of the Association TLV. The SPI carried in the "Associated SPI" field of the Association TLV provides a cross-check against the SPI advertised in the SFPR with RD as carried in the "Associated SFPR-RD" field of the Association TLV.
3.2.1.1項に記載されているように、SFPRは、関連TLVで符号化された1つ以上の相関器を含むことができる。関連付けタイプが「双方向SFP」を示す場合、SFPRでアドバタイズされたSFPは双方向ペアのSFPの一方向であり、ペア内の他方は「関連するSFPR-RD」で運ばれるようにRDでSFPRでアドバタイズされます。関連TLVの分野協会TLVの「関連するSPI」フィールドで運ばれるSPIは、関連付けられたTLVの「関連するSFPR - RD」フィールドで運ばれるようにSFPRで広告されているSPIに対するクロスチェックを提供する。
As noted in Section 3.2.1.1, when SFPRs reference each other, one SFPR advertisement will be received before the other. Therefore, processing of an association will require that the first SFPR not be rejected simply because the Associated SFPR-RD it carries is unknown. However, the SFP defined by the first SFPR is valid and SHOULD be available for use as a unidirectional SFP, even in the absence of an advertisement of its partner.
セクション3.2.1.1に記載されているように、SFPRS参照が互いに参照されると、もう1つのSFPR広告が受信されます。したがって、関連付けの処理は、それが搬送された関連するSFPR-RDが不明なので、最初のSFPRが単に拒否されないことを必要とするでしょう。ただし、最初のSFPRによって定義されたSFPは有効であり、そのパートナーの広告がない場合でも、単方向SFPとして使用できるはずです。
Furthermore, in error cases where SFPR-a associates with SFPR-b, but SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs cannot be formed, the individual SFPs are still valid and SHOULD be available for use as unidirectional SFPs. An implementation SHOULD log this situation, because it represents a controller error.
さらに、SFPR-AがSFPR-Bと関連付けられていますが、SFPR-BがSFPR-Cと関連付けられていますが、SFPR-Cと関連付けられているため、SFPR-Cと関連付けられているため、個々のSFPはまだ有効であり、一方向SFPSとして使用できるようになります。。これはコントローラエラーを表すため、実装はこの状況を記録する必要があります。
Usage of a bidirectional SFP may be programmed into the classifiers by the controller. Alternatively, a classifier may look at incoming packets on a bidirectional packet flow, extract the SPI from the received NSH, and look up the SFPR to find the reverse-direction SFP to use when it sends packets.
双方向SFPの使用は、コントローラによって分類子にプログラムされてもよい。あるいは、分類子が双方向パケットフロー上の着信パケットを調べ、受信したNSHからSPIを抽出し、SFPRを調べて、パケットを送信したときに使用する逆方向SFPを見つける。
See Section 8 for an example of how this works.
これがどのように機能するかの例についてはセクション8を参照してください。
Some service functions are stateful. That means that they build and maintain state derived from configuration or the packet flows that they handle. In such cases, it can be important or necessary that all packets from a flow continue to traverse the same instance of a service function so that the state can be leveraged and does not need to be regenerated.
一部のサービス機能はステートフルです。つまり、それらが構成またはそれらが処理するパケットフローから導き出された状態を構築し維持することを意味します。そのような場合、フローからのすべてのパケットがサービス関数の同じインスタンスを通過し続けることが重要か必要であり得、状態が活用され、再生される必要はない。
In the case of bidirectional SFPs, it may be necessary to traverse the same instances of a stateful service function in both directions. A firewall is a good example of such a service function.
双方向SFPSの場合、ステートフルサービス関数の同じインスタンスを両方向にトラバースする必要があるかもしれません。ファイアウォールはそのようなサービス機能の良い例です。
This issue becomes a concern where there are multiple parallel instances of a service function and a determination of which one to use could normally be left to the SFF as a load-balancing or local-policy choice.
この問題は、サービス機能の複数の並列インスタンスがある場合と、使用するものが通常、ロードバランシングまたはローカルポリシーの選択としてSFFに残されている可能性があるという問題になります。
For the forward-direction SFP, the concern is that the same choice of SF is made for all packets of a flow under normal network conditions. It may be possible to guarantee that the load-balancing functions applied in the SFFs are stable and repeatable, but a controller that constructs SFPs might not want to trust to this. The controller can, in these cases, build a number of more specific SFPs, each traversing a specific instance of the stateful SFs. In this case, the load-balancing choice can be left up to the classifier. Thus, the classifier selects which instance of a stateful SF is used by a particular flow by selecting the SFP that the flow uses.
順方向SFPの場合、懸念は、通常のネットワーク条件下でのフローのすべてのパケットに対してSFの同じ選択が行われることである。SFFSに適用された負荷分散関数が安定して再現可能であることを保証することが可能ですが、SFPSを構築するコントローラはこれを信頼したくないかもしれません。コントローラは、このような場合に、それぞれがステートフルSFSの特定のインスタンスを横切る特定のSFPをビルドします。この場合、負荷分散の選択は分類器に省略することができます。したがって、分類器は、フローが使用するSFPを選択することによって、ステートフルSFのどのインスタンスを特定のフローによって使用されるかを選択する。
For bidirectional SFPs where the same instance of a stateful SF must be traversed in both directions, it is not enough to leave the choice of SFI as a local choice, even if the load balancing is stable, because coordination would be required between the decision points in the forward and reverse directions, and this may be hard to achieve in all cases except where it is the same SFF that makes the choice in both directions.
ステートフルSFの同じインスタンスが両方向にトラバースされなければならない双方向SFPの場合、ロードバランスが安定していても、ロードバランシングが安定している場合でもSFIの選択を残すのに十分ではありません。順方向および逆方向の方向には、それが両方向に選択をするのと同じSFFである場合を除いて、すべての場合において達成するのが難しいかもしれません。
Note that this approach necessarily increases the amount of SFP state in the network (i.e., there are more SFPs). It is possible to mitigate this effect by careful construction of SFPs built from a concatenation of other SFPs.
このアプローチは、ネットワーク内のSFP状態の量を必ず増大させる（すなわち、より多くのSFPがある）。他のSFPの連結から構築されたSFPの慎重な構造によってこの効果を軽減することが可能です。
Section 8.9 includes some simple examples of SFPs for stateful SFs.
Section 8.9には、ステートフルSFS用のSFPの簡単な例が含まれています。
Likely deployments include reserving specific instances of SFs for specific customers or allowing customers to deploy their own SFs within the network. Building SFs in such environments requires that suitable identifiers be used to ensure that SFFs distinguish which SFIs can be used and which cannot.
展開では、特定の顧客にSFSの特定のインスタンスを予約すること、または顧客がネットワーク内で独自のSFを展開できるようになります。そのような環境でのSFSの構築は、SFFSがどのSFIを使用することができ、そしてそれができないことを確実にするために適切な識別子を使用することを必要とする。
This problem is similar to a problem in the way that VPNs are supported and is solved in a similar way. The "RT" field is used to indicate a set of SFs from which all choices must be made.
この問題は、VPNがサポートされており、同様に解決されるように問題と似ています。"RT"フィールドは、すべての選択肢を作成する必要があるSFSのセットを示すために使用されます。
[RFC8955] defines a set of BGP routes that can be used to identify the packets in a given flow using fields in the header of each packet, and a set of actions -- encoded as Extended Communities -- that can be used to disposition those packets. This document enables the use of these mechanisms by SFC classifiers by defining a new action Extended Community called "Flow Specification for SFC Classifiers", identified by the value 0x0d. Note that implementation of this section of this specification will be controllers or classifiers communicating with each other directly for the purpose of instructing the classifier how to place packets onto an SFP. So that the implementation of classifiers can be kept simple, and to avoid the confusion between the purposes of different Extended Communities, a controller MUST NOT include other action Extended Communities at the same time as a "Flow Specification for SFC Classifiers" Extended Community. A "Flow Specification for SFC Classifiers" Traffic Filtering Action Extended Community advertised with any other Traffic Filtering Action Extended Community MUST be treated as malformed in line with [RFC8955] and result in the flow-specification UPDATE message being handled as "treat-as-withdraw", according to [RFC7606], Section 2.
[RFC8955]各パケットのヘッダー内のフィールドを使用して特定のフロー内のパケットを識別するために使用できるBGPルートのセット、および拡張コミュニティとしてエンコードされた一連のBGPルートを定義します。パケットこのドキュメントでは、値0x0dによって識別される「SFC分類器のフロー仕様」という新しいアクション拡張コミュニティを定義することによって、SFC分類器によってこれらのメカニズムを使用することができます。この仕様書のこのセクションの実装は、分類器にパケットをSFPに配置する方法を指示する目的で、直接互いに通信するコントローラまたは分類子であろうことに注意してください。分類子の実装を簡単に保つことができ、異なる拡張コミュニティの目的との混乱を回避することができるように、コントローラは、「SFC分類器のフロー仕様」拡張コミュニティと同時に、他のアクション拡張コミュニティを含む必要はありません。他のトラフィックフィルタリングアクション拡張コミュニティ拡張コミュニティは、[RFC8955]に沿って不正行為として扱われ、「扱い区」として処理されているフロー仕様更新メッセージを実行する必要があります。 「RFC7606」、セクション2によると、撤回する。
To put the flow specification into context, when multiple service function chaining overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network for which it is intended.
フロー仕様をコンテキストにするために、複数のサービス関数連鎖オーバーレイが1つのネットワーク内に存在する場合、各FlowSpec更新は、それが意図されているオーバーレイまたはVPNネットワークの経路ターゲットでタグ付けされなければなりません。
This Extended Community is encoded as an 8-octet value, as shown in Figure 10.
この拡張コミュニティは、図10に示すように、8オクテット値としてエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x80 | Sub-Type=0x0d | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | SI | SFT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Format of the Flow Specification for SFC Classifiers Extended Community
図10：SFC分類器拡張コミュニティのフロー仕様の形式
The Extended Community contains the Service Path Identifier (SPI), Service Index (SI), and Service Function Type (SFT), as defined elsewhere in this document. Thus, each action extended community defines the entry point (not necessarily the first hop) into a specific SFP. This allows, for example, different flows to enter the same SFP at different points.
拡張コミュニティには、このドキュメントの他の場所で定義されているように、サービスパス識別子（SPI）、サービスインデックス（SI）、およびサービス機能タイプ（SFT）が含まれています。したがって、各アクション拡張コミュニティは、エントリポイント（必ずしも最初のホップではない）を特定のSFPに定義します。これにより、例えば異なるフローが異なる点で同じSFPに入ることができます。
Note that, according to [RFC8955], a given flow-specification update may include multiple of these action Extended Communities. If a given action extended community does not contain an installed SFPR with the specified {SPI, SI, SFT}, it MUST NOT be used for dispositioning the packets of the specified flow.
[RFC8955]によれば、所与のフロー仕様更新は、これらの動作拡張コミュニティの倍数を含むことができることに留意されたい。指定されたアクション拡張コミュニティに指定された{SPI、SI、SFT}を持つインストールされたSFPRが含まれていない場合は、指定されたフローのパケットを配置するために使用しないでください。
The normal case of packet classification for service function chaining will see a packet enter the SFP at its first hop. In this case, the SI in the Extended Community is superfluous, and the SFT may also be unnecessary. To allow these cases to be handled, a special meaning is assigned to an SI of zero (not a valid value) and an SFT of zero (a reserved value in the registry -- see Section 10.5).
サービス関数連鎖のためのパケット分類の通常の場合は、パケットが最初のホップでSFPを入力するのを見るでしょう。この場合、拡張コミュニティのSIは不要であり、SFTも不要である可能性がある。これらのケースを処理できるようにするために、特別な意味がSIのSI（有効値ではない）、SFT（レジストリ内の予約値 - セクション10.5を参照）に割り当てられます。
* If an SFC Classifiers Extended Community is received with SI = 0, then it means that the first hop of the SFP indicated by the SPI MUST be used.
* SFC分類器拡張コミュニティがSI = 0で受信された場合、SPIによって示されるSFPの最初のホップを使用する必要があることを意味します。
* If an SFC Classifiers Extended Community is received with SFT = 0, then there are two subcases:
* SFC分類器拡張コミュニティがSFT = 0で受信された場合、2つのサブケースがあります。
- If there is a choice of SFT in the hop indicated by the value of the SI (including SI = 0), then SFT = 0 means there is a free choice of which SFT to use, according to local policy).
- SI（Si = 0を含む）で示されるホップ内にSFTの選択がある場合、SFT = 0は、ローカルポリシーに従って使用するSFTの自由選択があることを意味する。
- If there is no choice of SFT in the hop indicated by the value of SI, then SFT = 0 means that the value of the SFT at that hop, as indicated in the SFPR for the indicated SPI, MUST be used.
- SIの値で示されるホップにSFTの選択肢がない場合、SFT = 0は、示されたSPIのSFPRに示されているように、そのホップのSFTの値が使用されなければならないことを意味します。
One of the filters that the flow specification may describe is the VPN to which the traffic belongs. Additionally, as noted above, to put the indicated SPI into context when multiple SFC overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network for which it is intended.
フロー仕様が記述できるフィルタの1つは、トラフィックが属するVPNです。さらに、上述したように、複数のSFCオーバーレイが1つのネットワーク内に存在するときに示されたSPIを文脈に置くためには、各FlowSpec更新は、それが意図されているオーバーレイまたはVPNネットワークの経路ターゲットでタグ付けされなければならない。
Note that future extensions might be made to the Flow Specification for SFC Classifiers Extended Community to provide instruction to the classifier about what metadata to add to packets that it classifies for forwarding on a specific SFP; however, that is outside the scope of this document.
SFC分類器拡張コミュニティのフロー仕様に対して、特定のSFP上での転送に分類されるパケットに追加するメタデータに命令を提供するための将来の拡張が行われる可能性があることに注意してください。しかし、それはこの文書の範囲外です。
This document ties together the control and data planes of a service function chaining overlay network through the use of the SPI/SI that is nominally carried in the NSH of a given packet. However, in order to handle situations in which the NSH is not ubiquitously deployed, it is also possible to use alternative data plane representations of the SPI/SI by carrying the identical semantics in other protocol fields, such as MPLS labels [RFC8595].
この文書は、指定されたパケットのNSHで名目上搬送されるSPI / SIを使用して、サービス機能チェンジオーバーレイネットワークの制御およびデータプレーンをまとめます。しかしながら、NSHが普遍的に展開されていない状況を処理するためには、MPLSラベル[RFC8595]などの他のプロトコルフィールドにおいて同一の意味論を搬送することによってSPI / SIの代替データプレーン表現を使用することも可能である。
This document defines a new Sub-TLV for the tunnel encapsulation attribute [RFC9012], the SPI/SI Representation Sub-TLV of type 16. This Sub-TLV MAY be present in each Tunnel TLV contained in a tunnel encapsulation attribute when the attribute is carried by an SFIR. The "Value" field of this Sub-TLV is a two-octet field of flags numbered counting from the most significant bit, each of which describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets carried in the tunnels described by the Tunnel TLV.
このドキュメントでは、Tunnel Encapsulation属性[RFC9012]、Type 16のSPI / SI表現サブTLVの新しいサブTLVを定義しています。このサブTLVは、属性がトンネルのカプセル化属性に含まれている各トンネルTLVに存在します。SFIRによって運ばれる。このSUB-TLVの「値」フィールドは、最上位ビットから数えられた数のフラグの2オクテットフィールドであり、それぞれが発信されたSFFが実行されたパケットのデータプレーンに表されているSPI / SIがどのように表示されるかを記述する。トンネルTLVによって記述されたトンネル。
The following bits are defined by this document and are tracked in an IANA registry described in Section 10.10:
次のビットはこの文書によって定義され、10.10項で説明されているIANAレジストリで追跡されます。
Bit 0: If this bit is set, the NSH is to be used to carry the SPI/SI in the data plane.
ビット0：このビットが設定されている場合は、NSHを使用してデータプレーン内のSPI / SIを搬送します。
Bit 1: If this bit is set, two labels in an MPLS label stack are to be used as described in Section 7.5.1.
ビット1：このビットが設定されている場合は、7.5.1項の説明に従って、MPLSラベルスタック内の2つのラベルを使用します。
If a given Tunnel TLV does not contain an SPI/SI Representation Sub-TLV, then it MUST be processed as if such a Sub-TLV is present with Bit 0 set and no other bits set. That is, the absence of the Sub-TLV SHALL be interpreted to mean that the NSH is to be used.
所与のトンネルTLVがSPI / SI表現サブTLVを含まない場合、そのようなサブTLVがビット0セットで存在するかのように処理されなければならない。すなわち、SUB-TLVの不在は、NSHが使用されることを意味すると解釈されなければならない。
If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV with a "Value" field that has no flag set, then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV with both bit 0 and bit 1 set, then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets. The meaning and rules for the presence of other bits is to be defined in future documents, but implementations of this specification MUST set other bits to zero and ignore them on receipt.
フラグが設定されていない「値」フィールドを持つSPI / SI表現サブTLVを含む場合は、TRVがSFCパケットを転送するために使用してはいけません。所与のトンネルTLVがビット0とビット1を設定したSPI / SI表現サブTLVを含む場合、トンネルTLVで示されるトンネルはSFCパケットの転送に使用してはいけません。他のビットの存在の意味と規則は将来の文書で定義されますが、この仕様の実装は他のビットをゼロに設定し、受信時にそれらを無視する必要があります。
If a given Tunnel TLV contains more than one SPI/SI Representation Sub-TLV, then the first one MUST be considered and subsequent instances MUST be ignored.
特定のトンネルTLVに複数のSPI / SI表現サブTLVが含まれている場合、最初のものを考慮しなければならず、後続のインスタンスは無視されなければなりません。
Note that the MPLS representation of the logical NSH may be used even if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself). It is a requirement that both ends of a tunnel over the underlay network know that the tunnel is used for service function chaining and know what form of NSH representation is used. The signaling mechanism described here allows coordination of this information.
トンネルがMPLSトンネルではない場合でも、論理NSHのMPLS表現を使用することができることに注意してください。逆に、MPLSトンネルを使用して、論理NSHの他のエンコーディング（具体的にはNSH自体）を搬送することができます。アンダーレイネットワーク上のトンネルの両端の両端は、トンネルがサービス関数連鎖に使用され、どの形式のNSH表現が使用されているのか知っていることを知っているという要件です。ここに記載されているシグナリングメカニズムは、この情報の調整を可能にします。
If bit 1 is set in the SPI/SI Representation Sub-TLV, then labels in the MPLS label stack are used to indicate SFC forwarding and processing instructions to achieve the semantics of a logical NSH. The label stack is encoded as shown in [RFC8595].
ビット1がSPI / SI表現サブTLVに設定されている場合、MPLSラベルスタック内のラベルは、論理NSHのセマンティクスを達成するためのSFC転送と処理命令を示すために使用されます。ラベルスタックは[RFC8595]に示すようにエンコードされています。
When a classifier constructs an MPLS label stack for an SFP, it starts with that SFP's last hop. If the last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the last hop) and the SFP's SPI onto the MPLS label stack. If the last hop requires a {context label, SFI label} label pair for label stacking, it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack.
分類子がSFPのMPLSラベルスタックを構築するとき、それはそのSFPの最後のホップで始まります。最後のホップにラベルスワップに{SPI、SI}ラベルペアが必要な場合は、SI（最後のホップのSI値に設定）とSFPのSPIをMPLSラベルスタックにプッシュします。最後のホップに{コンテキストラベル、SFI Label}ラベルの設定が必要な場合は、特定のSFIRを選択し、そのSFIのSFIラベルとコンテキストラベルをMPLSラベルスタックにプッシュします。
The classifier then moves sequentially back through the SFP one hop at a time. For each hop, if the hop requires an {SPI, SI} and there is an {SPI, SI} at the top of the MPLS label stack, the SI is set to the SI value of the current hop. If there is not an {SPI, SI} at the top of the MPLS label stack, it pushes the SI (set to the SI value of the current hop) and the SFP's SPI onto the MPLS label stack.
その後、分類子は一度に1ホップ1ホップをSFPに順次戻って移動します。各ホップについて、ホップが{SPI、Si}を必要とし、MPLSラベルスタックの上部に{SPI、Si}がある場合、SIは現在のホップのSI値に設定される。MPLSラベルスタックの上部に{SPI、SI}がない場合は、SI（現在のホップのSI値に設定）とSFPのSPIをMPLSラベルスタックにプッシュします。
If the hop requires a {context label, SFI label}, it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack.
ホップに{コンテキストラベル、SFI Label}が必要な場合は、特定のSFIRを選択し、そのSFIRのSFIラベルとコンテキストラベルをMPLSラベルスタックにプッシュします。
[RFC8596] describes how to transport SFC packets using the NSH over an MPLS transport network. Signaling that this approach is in use is supported by this document as follows:
[RFC8596] MPLSトランスポートネットワーク上でNSHを使用してSFCパケットを転送する方法について説明します。このアプローチが使用中のシグナリングは、この文書によって次のようにサポートされています。
* A "BGP Tunnel Encapsulation Attribute" Sub-TLV is included with the codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry defined in [RFC9012].
* [RFC9012]で定義されている「BGPトンネルカプセル化属性サブTLVS」レジストリから、「BGPトンネルカプセル化属性」サブTLVがCodePoint 10（「MPLSラベルスタック」を表す）に含まれています。
* An "SFP Traversal With MPLS Label Stack" TLV is included containing an "SPI/SI Representation" Sub-TLV with bit 0 set and bit 1 cleared.
* 「MPLSラベルスタックを備えたSFPトラバーサル」TLVは、ビット0セットとビット1をクリアした「SPI / SI表現」サブTLVを含む。
In this case, the MPLS label stack constructed by the SFF to forward a packet to the next SFF on the SFP will consist of the labels needed to reach that SFF, and if label stacking is used, it will also include the labels advertised in the MPLS Label Stack Sub-TLV and the labels remaining in the stack needed to traverse the remainder of the SFP.
この場合、SFPでパケットを次のSFFに転送するためにSFFによって構築されたMPLSラベルスタックは、そのSFFに到達するのに必要なラベルで構成され、ラベルスタッキングが使用されている場合は、でアドバタイズされたラベルも含まれます。MPLSラベルスタックSUB-TLVとスタック内に残っているラベルは、SFPの残りの部分を通過するのに必要でした。
Most of the examples in this section use IPv4 addressing. But there is nothing special about IPv4 in the mechanisms described in this document, and they are equally applicable to IPv6. A few examples using IPv6 addressing are provided in Section 8.10.
このセクションの例のほとんどは、IPv4アドレッシングを使用しています。しかし、この文書に記載されているメカニズムにIPv4については特別なものは何もありません。IPv6アドレッシングを使用したいくつかの例は、8.10節で提供されています。
Assume we have a service function overlay network with four SFFs (SFF1, SFF2, SFF3, and SFF4). The SFFs have addresses in the underlay network as follows:
4つのSFFS（SFF1、SFF2、SFF3、およびSFF4）を持つサービス機能オーバーレイネットワークがあるとします。SFFSは、次のようにアンダーレイネットワーク内のアドレスを持っています。
SFF1 192.0.2.1 SFF2 192.0.2.2 SFF3 192.0.2.3 SFF4 192.0.2.4
SFF1 192.0.2.1 SFF2 192.0.2.2 SFF3 192.0.2.3 SFF4 192.0.2.4
Each SFF provides access to some SFIs from the four SFTs, SFT=41, SFT=42, SFT=43, and SFT=44, as follows:
各SFFは、4つのSFT、SFT = 41、SFT = 42、SFT = 43、およびSFT = 44、およびSFT = 44、およびSFT = 44からのSFIへのアクセスを提供する。
SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44
The service function network also contains a controller with address 198.51.100.1.
サービス機能ネットワークには、アドレス198.51.100.1のコントローラも含まれています。
This example service function overlay network is shown in Figure 11.
このサービス機能オーバーレイネットワークの例を図11に示します。
--------------
| Controller |
| 198.51.100.1 | ------ ------ ------ ------
-------------- | SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------
\ / \ /
--------- ---------
---------- | SFF1 | | SFF2 |
Packet --> | | |192.0.2.1| |192.0.2.2|
Flows --> |Classifier| --------- --------- -->Dest
| | -->
---------- --------- ---------
| SFF3 | | SFF4 |
|192.0.2.3| |192.0.2.4|
--------- ---------
/ \ / \
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------
Figure 11: Example Service Function Overlay Network
図11：サービス機能オーバーレイネットワークの例
The SFFs advertise routes to the SFIs they support. These advertisements contain RDs that are set according to the network operator's configuration model. In all of these IPv4 examples, we use RDs of Type 1 such that the available six octets are partitioned as four octets for the IPv4 address of the advertising SFF, and two octets that are a local index of the SFI. This scheme is chosen purely for convenience of documentation, and an operator is totally free to use any other scheme so long as it conforms to the definitions of SFIR and SFPR in Sections 3.1 and 3.2.
SFFSはそれらがサポートするSFIへのルートをアドバタイズします。これらの広告には、ネットワーク事業者の構成モデルに従って設定されているRDSが含まれています。これらのIPv4のすべての例では、使用可能な6オクテットが広告SFFのIPv4アドレスの4オクテット、およびSFIのローカルインデックスである2つのオクテットとしてパーティション化されるように、タイプ1のRDSを使用します。この方式は文書の利便性のために純粋に選択されており、セクション3.1および3.2のSFIRとSFPRの定義に準拠している限り、オペレータは他のスキームを完全に自由に使用できます。
Thus, we see the following SFIRs advertised:
したがって、次のSFIRが宣伝されているのを見ます。
RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44
Note that the addressing used for communicating between SFFs is taken from the tunnel encapsulation attribute of the SFIR and not from the SFIR-RD.
SFIR - RDからではなく、SFF間で通信するために使用されるアドレス指定は、SFIRのトンネルカプセル化属性から取得されることに注意してください。
Consider the following SFPR.
次のSFPRを検討してください。
SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
The SFP consists of an SF of Type 41 located at SFF1, followed by an SF of Type 43 located at SFF2. This path is fully explicit, and each SFF is offered no choice in forwarding packets along the path.
SFPは、SFF1に位置するタイプ41のSF、続いてSFF2にある43のSFからなる。このパスは完全に明示的であり、各SFFはパスに沿ってパケットを転送するのに選択肢がない。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (15). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受信し、SPI（15）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next-hop SFI and will forward the packet to SFF2, which will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、次のホップSFIをサポートするためのSFFの選択に柔軟性がありません。パケットをSFT 43に送信するSFIにパケットを送信します。
SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ]
In this example, the path also consists of an SF of Type 41 located at SFF1, and this is followed by an SF of Type 43. However, in this case, the SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4.
この例では、パスはSFF1に配置されたタイプ41のSFからなる。ただし、この場合、SI = 250はSFF2とSF1との間の選択を含む。SFIはSFF4にあります。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (16). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受信し、SPI（16）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a choice of next-hop SFFs to execute the next hop in the path. It can either forward packets to SFF2 or SFF4 to execute a function of Type 43. It uses its local load-balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内のネクストホップを実行するためにNext-Hop SFFの選択をしました。Packets 43の機能を実行するために、パケットをSFF2またはSFF4に転送することができます。この選択を行うためにそのローカル負荷分散アルゴリズムを使用します。選択されたSFFは、パケットをそれらの宛先に転送する前に、SFT43をサポートするSFIにパケットを送信する。
SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0]
In this example, the path also consists of an SF of Type 41 located at SFF1, and this is followed by an SI with an RD of zero and SF of Type 44. This means that a choice can be made between any SFF that supports an SFI of Type 44.
この例では、経路はSFF1に位置するタイプ41のSFからなり、その後に44のゼロおよびSFのSFが続く。これは、をサポートするSFFの間で選択ができます。44タイプのSFI。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (17). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受け取り、SPI（17）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support SFs of Type 44. Looking at the SFIRs it has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF4. SFF1 uses its local load-balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 44 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内の次のホップを実行するためにNext-Hop SFFのフリーの選択を行い、タイプ44のSFSをサポートするすべてのSFFを選択します。SFF4。SFF1はそのローカル負荷分散アルゴリズムを使用してこの選択を行います。選択されたSFFは、パケットをそれらの宛先に転送する前に、SFT44をサポートするSFIにパケットを送信する。
SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ]
This example provides a choice of SF type in the second hop in the path. The SI of 250 indicates a choice between SF Type 43 located at SF2 and SF Type 44 located at SF3.
この例では、パス内の2番目のホップ内のSFタイプの選択を提供します。250のSiは、SF 2に位置するSFタイプ43とSF 3との間の選択肢を示している。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (18). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上のパケットを受信し、SPI（18）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support an SF of Type 43 and SFF3, which supports an SF of Type 44. These may be completely different functions that are to be executed dependent on specific conditions, or they may be similar functions identified with different type identifiers (such as firewalls from different vendors). SFF1 uses its local policy and load-balancing algorithm to make this choice and may use additional information passed back from the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI that supports the chosen SFT before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内のネクストホップを実行するためにNext-Hop SFFSを自由に選択して、タイプ43とSFF3のSFをサポートするすべてのSFF間で選択されます。これは、44のSFをサポートします。特定の条件に応じて実行される場合、またはそれらは異なる型識別子（異なるベンダからのファイアウォールなど）で識別される類似の関数であり得る。SFF1は、そのローカルポリシーとロードバランシングアルゴリズムを使用してこの選択を行い、その選択に通知するためにローカルSFIから返された追加情報を使用することができます。選択されたSFFは、パケットをそれらの宛先に転送する前に、選択されたSFTをサポートするSFIにパケットを送信します。
SFP5: RD = 198.51.100.1/105, SPI = 19,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP6: RD = 198.51.100.1/106, SPI = 20,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19,
[SI = 254, SFT = 43, RD = 192.0.2.2/2],
[SI = 249, SFT = 41, RD = 192.0.2.1/1]
This example demonstrates correlation of two SFPs to form a bidirectional SFP, as described in Section 7.1.
この例では、セクション7.1に記載されているように、2つのSFPと双方向SFPを形成するための2つのSFPの相関関係を示します。
Two SFPRs are advertised by the controller. They have different SPIs (19 and 20), so they are known to be separate SFPs, but they both have Association TLVs with Association Type set to 1, indicating bidirectional SFPs. Each has an "Associated SFPR-RD" field containing the value of the other SFPR-RD to correlate the two SFPs as a bidirectional pair.
2つのSFPRがコントローラによってアドバタイズされています。それらは異なるSPI（19と20）を持っているので、それらは別々のSFPであることが知られていますが、両方ともアソシエーションタイプを1に設定し、双方向SFPSを示します。2つのSFPを双方向ペアとして相関させるために、他のSFPR-RDの値を含む「関連するSFPR-RD」フィールドがあります。
As can be seen from the SFPRs in this example, the paths are symmetric: the hops in SFP5 appear in the reverse order in SFP6.
この例ではSFPRSから分かるように、パスは対称的です.SFP5のホップはSFP6の逆の順序で現れます。
SFP7: RD = 198.51.100.1/107, SPI = 21,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP8: RD = 198.51.100.1/108, SPI = 22,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21,
[SI = 254, SFT = 44, RD = 192.0.2.4/6],
[SI = 249, SFT = 41, RD = 192.0.2.1/1]
Asymmetric bidirectional SFPs can also be created. This example shows a pair of SFPs with distinct SPIs (21 and 22) that are correlated in the same way as in the example in Section 8.5.
非対称双方向SFPを作成することもできます。この例は、セクション8.5の例と同じ方法で相関している異なるSPI（21と22）を持つ一対のSFPを示しています。
However, unlike in that example, the SFPs are different in each direction. Both paths include a hop of SF Type 41, but SFP7 includes a hop of SF Type 43 supported at SFF2, while SFP8 includes a hop of SF Type 44 supported at SFF4.
ただし、その例とは異なり、SFPは各方向において異なります。両方の経路はSFタイプ41のホップを含むが、SFP7はSFF2でサポートされているSFタイプ43のホップを含み、SFP8はSF4でサポートされているSFタイプ44のホップを含む。
SFP9: RD = 198.51.100.1/109, SPI = 23,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 192.0.2.4/5],
[SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0},
SFT = 42, RD = 192.0.2.3/7 } ]
Looping and jumping are described in Section 6. This example shows an SFP that contains an explicit loop-back instruction that is presented as a choice within an SFP hop.
ループとジャンプはセクション6で説明されています。この例は、SFPホップ内の選択として表示される明示的なループバック命令を含むSFPを示しています。
The first two hops in the path (SI = 255 and SI = 250) are normal. That is, the packets will be delivered to SFF1 and SFF4 in turn for execution of SFs of Type 41 and 44, respectively.
経路内の最初の2ホップ（Si = 255およびSi = 250）は正常である。つまり、パケットは、それぞれタイプ41および44のSFSの実行のためにSFF1およびSFF4にそれぞれ配信される。
The third hop (SI = 245) presents SFF4 with a choice of next hop. It can either forward the packets to SFF3 for an SF of Type 42 (the second choice) or it can loop back.
3番目のホップ（SI = 245）は、次のホップの選択でSFF4を提示します。PacketをSFF3に転送することもできます（2番目の選択）、またはループバックすることができます。
The loop-back entry in the SFPR for SI = 245 is indicated by the special-purpose SFT value 1 ("Change Sequence"). Within this hop, the RD is interpreted as encoding the SPI and SI of the next hop (see Section 6.1). In this case, the SPI is 23, which indicates that this is a loop or branch, i.e., the next hop is on the same SFP. The SI is set to 255; this is a higher number than the current SI (245), indicating a loop.
S1 = 245のSFPRのループバックエントリは、専用のSFT値1（「変更シーケンス」）で示されている。このホップ内では、RDは次のホップのSPIとSIをエンコードすると解釈されます（セクション6.1を参照）。この場合、SPIは23であり、これはループまたはブランチ、すなわち次のホップは同じSFP上にあることを示す。Siは255に設定されています。これは、ループを示す現在のSI（245）よりも高い数値である。
SFF4 must make a choice between these two next hops. The packet will be either forwarded to SFF3 with the NSH SI decreased to 245 or looped back to SFF1 with the NSH SI reset to 255. This choice will be made according to local policy, information passed back by the local SFI, and details in the packets' metadata that are used to prevent infinite looping.
SFF4はこれら2つの次のホップの間で選択をしなければなりません。パケットは、NSH SIが245に減少した状態でSFF3に転送されるか、またはNSH SIが255にリセットされた状態でSFF1にループバックされます。この選択は、ローカルポリシー、ローカルSFIによって渡された情報、および詳細に記載されています。無限ループを防ぐために使用されるパケットのメタデータ。
SFP10: RD = 198.51.100.1/110, SPI = 24,
[SI = 254, SFT = 42, RD = 192.0.2.3/7],
[SI = 249, SFT = 43, RD = 192.0.2.2/2]
SFP11: RD = 198.51.100.1/111, SPI = 25,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
Branching follows a similar procedure to that for looping (and jumping), as shown in Section 8.7. However, there are two SFPs involved.
セクション8.7に示すように、分岐はループ（そしてジャンプ）の同様の手順に従います。しかし、関与する2つのSFPがあります。
SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for execution of service functions of Type 42 and 43, respectively.
SFP10は、それぞれType 42および43のサービス機能を実行するためにSFF3およびSFF2に転送されたパケットを含む通常のパスを示す。
SFP11 starts as normal (SFF1 for an SF of Type 41), but then SFF1 processes the next hop in the path and finds a "Change Sequence" special-purpose SFT. The "SFIR-RD" field includes an SPI of 24, which indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and send the packets to the appropriate SFF, as advertised in the SFPR for SFP10 (that is, SFF3).
SFP11は正常に開始されます（タイプ41のSFのSF1のSF1）、SFF1はパス内のネクストホップを処理し、「シーケンスの変更」特殊用途SFTを見つけます。「SFIR - RD」フィールドは24のSPIを含み、これはSFP10を示し、現在のSFPではなくSFP10を示す。SFIR-RDのSIは254ですので、SFF1はNSHのSPI / SIを24/254に設定し、SFP10のSFP10（つまりSFF3）に宣伝されているように、パケットを適切なSFFに送信する必要があることを認識しています。。
This section provides some examples to demonstrate establishing SFPs when there is a choice of service functions at a particular hop, and where consistency of choice is required in both directions. The scenarios that give rise to this requirement are discussed in Section 7.2.
このセクションでは、特定のホップでサービス機能の選択がある場合、および選択の一貫性が両方向に必要な場合は、SFPSの確立を説明するためのいくつかの例を示します。この要件を引き起こすシナリオは、セクション7.2で説明されています。
Consider the topology shown in Figure 12. There are three SFFs arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of SFT 42. These three instances can be used by SFF2 to load balance so that no one instance is swamped.
図12に示すトポロジを検討します。沼地。
------ ------ ------ ------ ------
| SFI | | SFIa | | SFIb | | SFIc | | SFI |
|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|
------ ------\ ------ /------ ------
\ \ | / /
--------- --------- ---------
---------- | SFF1 | | SFF2 | | SFF3 |
--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
--> |Classifier| --------- --------- ---------
| |
----------
Figure 12: Example Where Choice Is Made at the SFF
図12：SFFで選択が行われた例
This leads to the following SFIRs being advertised.
これにより、次のSFIRが宣伝されています。
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42 (for SFIa)
RD = 192.0.2.2/12, SFT = 42 (for SFIb)
RD = 192.0.2.2/13, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43
The controller can create a single forward SFP (SFP12), giving SFF2 the choice of which SFI to use to provide a function of SFT 42, as follows. The load-balancing choice between the three available SFIs is assumed to be within the capabilities of the SFF, and if the SFs are stateful, it is assumed that the SFF knows this and arranges load balancing in a stable, flow-dependent way.
コントローラはシングルフォワードSFP（SFP12）を作成することができ、SFF2は次のようにSFT42の機能を提供するために使用するSFIの選択を可能にする。3つの利用可能なSFI間の負荷分散の選択はSFFの機能内にあると仮定され、SFSがステートフルである場合、SFFはこれを知っており、負荷分散を安定したフロー依存的に配置すると仮定されます。
SFP12: RD = 198.51.100.1/112, SPI = 26,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12,
192.0.2.2/13 }],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
The reverse SFP (SFP13) in this case may also be created as shown below, using association with the forward SFP and giving the load-balancing choice to SFF2. This is safe, even in the case that the SFs of Type 42 are stateful, because SFF2 is doing the load balancing in both directions and can apply the same algorithm to ensure that packets associated with the same flow use the same SFI regardless of the direction of travel.
この場合の逆SFP（SFP13）は、以下に示すように、フォワードSFPとの関連付けを使用し、ロードバランス選択をSFF2に与えるようにしても構わない。SFF2のSFF2が両方向に負荷分散を行っており、同じフローに関連するパケットが方向性にかかわらず同じSFIを使用するようにするために、タイプ42のSFSがステートフルである場合でも安全です。旅行の。
SFP13: RD = 198.51.100.1/113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12,
192.0.2.2/13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
How an SFF knows that an attached SFI is stateful is out of the scope of this document. It is assumed that this will form part of the process by which SFIs are registered as local to SFFs. Section 7.2 provides additional observations about the coordination of the use of stateful SFIs in the case of bidirectional SFPs.
添付のSFIがこの文書の範囲外であることをSFFがどのように知っているか。これは、SFIがLocal SFFSのように登録されているプロセスの一部を形成すると仮定されます。セクション7.2は、双方向SFPの場合のステートフルSFIの使用の調整に関するさらなる観察を提供します。
In general, the problems of load balancing and the selection of the same SFIs in both directions of a bidirectional SFP can be addressed by using sufficiently precisely specified SFPs (specifying the exact SFIs to use) and suitable programming of the classifiers at each end of the SFPs to make sure that the matching pair of SFPs are used.
一般に、双方向SFPの両方向における負荷分散と同じSFIの選択の問題は、十分に正確に指定されたSFP（使用するための正確なSFIを指定する）およびその両端における分類器の適切なプログラミングを使用することによって対処することができる。SFPの一致するセアが使用されていることを確認するためのSFPS。
The mechanism described in Section 8.9.1 might not be desirable because of the functional assumptions it places on SFF2 to be able to load balance with suitable flow identification, stability, and equality in both directions. Instead, it may be desirable to place the responsibility for flow classification in the classifier and let it determine load balancing with the implied choice of SFIs.
セクション8.9.1に記載されているメカニズムは、SFF2上に、適切な流れの識別、安定性、および両方向に平均をバランスさせることができるようにする機能の仮定のために望ましくないかもしれません。代わりに、分類器内のフロー分類に対する責任を配置し、それがSFIの暗黙の選択との負荷分散を決定することが望ましいかもしれない。
Consider the network graph as shown in Figure 12 and with the same set of SFIRs as listed in Section 8.9.1. In this case, the controller could specify three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional pair of SFPs uses a different SFI for the SF of Type 42. The controller can instruct the classifier how to place traffic on the three bidirectional SFPs, or it can treat them as a group, leaving the classifier responsible for balancing the load.
図12に示すようにネットワークグラフとセクション8.9.1にリストされているSFIRのセットを付けてください。この場合、コントローラは、対応する関連する逆SFPで3つの順方向SFPを指定できます。SFPの各双方向対のペアは、タイプ42のSFに対して異なるSFIを使用しています。コントローラは、3つの双方向SFPS上でトラフィックを配置する方法、あるいはそれらをグループとして扱うことができます。
SFP14: RD = 198.51.100.1/114, SPI = 28,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP15: RD = 198.51.100.1/115, SPI = 29,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP16: RD = 198.51.100.1/116, SPI = 30,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP17: RD = 198.51.100.1/117, SPI = 31,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP18: RD = 198.51.100.1/118, SPI = 32,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP19: RD = 198.51.100.1/119, SPI = 33,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
While the examples in Sections 8.9.1 and 8.9.2 place the choice of SFI as subtended from the same SFF, it is also possible that the SFIs are each subtended from a different SFF, as shown in Figure 13. In this case, it is harder to coordinate the choices for forward and reverse paths without some form of coordination between SFF1 and SFF3. Therefore, it would be normal to consider end-to-end parallel SFPs, as described in Section 8.9.2.
セクション8.9.1および8.9.2の例は、同じSFFからのSFIの選択を置きますが、図13に示すように、SFIが異なるSFFからそれぞれ副立案されている可能性があります。この場合、それはSFF1とSFF3の間の一部の形式の調整を行わずに、順方向と逆の経路の選択を調整するのが難しいです。したがって、セクション8.9.2で説明されているように、エンドツーエンドのパラレルSFPを考慮することは普通であろう。
------
| SFIa |
|SFT=42|
------
------ |
| SFI | ---------
|SFT=41| | SFF5 |
------ ..|192.0.2.5|..
| ..: --------- :..
---------.: :.---------
---------- | SFF1 | --------- | SFF3 |
--> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| -->
--> |Classifier| ---------: |192.0.2.6| :---------
| | : --------- : |
---------- : | : ------
: ------ : | SFI |
:.. | SFIb | ..: |SFT=43|
:.. |SFT=42| ..: ------
: ------ :
:.---------.:
| SFF7 |
|192.0.2.7|
---------
|
------
| SFIc |
|SFT=42|
------
Figure 13: Second Example with Parallel End-to-End SFPs
図13：並列エンドツーエンドSFPを備えた2番目の例
In this case, five SFIRs are advertised as follows:
この場合、5つのSFIRが次のように宣伝されています。
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.5/11, SFT = 42 (for SFIa)
RD = 192.0.2.6/11, SFT = 42 (for SFIb)
RD = 192.0.2.7/11, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43
In this case, the controller could specify three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional pair of SFPs uses a different SFF and SFI for the middle hop (for an SF of Type 42). The controller can instruct the classifier how to place traffic on the three bidirectional SFPs, or it can treat them as a group, leaving the classifier responsible for balancing the load.
この場合、コントローラは、対応する関連する逆SFPで3つの順方向SFPを指定できます。各双方向対のSFPは、ミドルホップに対して異なるSFFとSFIを使用します（タイプ42のSF用）。コントローラは、3つの双方向SFPS上でトラフィックを配置する方法を分類器に指示することができます。また、それらをグループとして扱うことができます。
SFP20: RD = 198.51.100.1/120, SPI = 34,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP21: RD = 198.51.100.1/121, SPI = 35,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP22: RD = 198.51.100.1/122, SPI = 36,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP23: RD = 198.51.100.1/123, SPI = 37,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP24: RD = 198.51.100.1/124, SPI = 38,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP25: RD = 198.51.100.1/125, SPI = 39,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
The mechanism of parallel SFPs demonstrated in Section 8.9.3 is perfectly functional and may be practical in many environments. However, there may be scaling concerns because of the large amount of state (knowledge of SFPs -- i.e., SFPR advertisements retained) if there is a very large number of possible SFIs (for example, tens of instances of the same stateful SF) or if there are multiple choices of stateful SF along a path. This situation may be mitigated using SFP fragments that are combined to form the end-to-end SFPs.
セクション8.9.3で実証された並列SFPのメカニズムは完全に機能しており、多くの環境では実用的かもしれません。しかし、非常に多数の可能なSFI（例えば、同じステートフルSFのインスタンスなど）がある場合、大量の状態（SFPSの知識（SFPR広告の知識）のためにスケーリングに関する懸念がある可能性があります。パスに沿ってステートフルSFの複数の選択肢がある場合。この状況は、エンドツーエンドのSFPを形成するために組み合わされるSFPフラグメントを使用して軽減され得る。
The example presented here is necessarily simplistic but should convey the basic principle. The example presented in Figure 14 is similar to that in Section 8.9.3 but with an additional first hop.
ここに提示された例は必然的に単純化されているが、基本原理を伝えるべきである。図14に示されている例は、8.9.3節のものと似ていますが、追加の最初のホップを使用しています。
------
| SFIa |
|SFT=43|
------
------ ------ |
| SFI | | SFI | ---------
|SFT=41| |SFT=42| | SFF5 |
------ ------ ..|192.0.2.5|..
| | ..: --------- :..
--------- ---------.: :.---------
------ | SFF1 | | SFF2 | --------- | SFF3 |
-->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|-->
-->| ifier| --------- ---------: |192.0.2.6| :---------
------ : --------- : |
: | : ------
: ------ : | SFI |
:.. | SFIb | ..: |SFT=44|
:.. |SFT=43| ..: ------
: ------ :
:.---------.:
| SFF7 |
|192.0.2.7|
---------
|
------
| SFIc |
|SFT=43|
------
Figure 14: Example with Parallel SFPs Downstream of Choice
図14：選択の下流の並列SFPを備えた例
The six SFIs are advertised as follows:
6つのSFIは次のように宣伝されています。
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42
RD = 192.0.2.5/11, SFT = 43 (for SFIa)
RD = 192.0.2.6/11, SFT = 43 (for SFIb)
RD = 192.0.2.7/11, SFT = 43 (for SFIc)
RD = 192.0.2.3/11, SFT = 44
SFF2 is the point at which a load-balancing choice must be made. So "tail-end" SFPs are constructed as follows. Each takes in a different SFF that provides access to an SF of Type 43.
SFF2は、負荷分散の選択を行う必要があるポイントです。そのため、「テールエンド」SFPは次のように構成されています。それぞれが43のSFへのアクセスを提供する別のSFFを取ります。
SFP26: RD = 198.51.100.1/126, SPI = 40,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44,
[SI = 255, SFT = 43, RD = 192.0.2.5/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP27: RD = 198.51.100.1/127, SPI = 41,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45,
[SI = 255, SFT = 43, RD = 192.0.2.6/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP28: RD = 198.51.100.1/128, SPI = 42,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46,
[SI = 255, SFT = 43, RD = 192.0.2.7/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]
Now an end-to-end SFP with load-balancing choice can be constructed as follows. The choice made by SFF2 is expressed in terms of entering one of the three "tail-end" SFPs.
これで、ロードバランシング選択を備えたエンドツーエンドのSFPを次のように構築できます。SFF2によって行われた選択は、3つの「テールエンド」SFPのうちの1つを入力するという点で表される。
SFP29: RD = 198.51.100.1/129, SPI = 43,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
RD = {SPI=41, SI=255, Rsv=0},
RD = {SPI=42, SI=255, Rsv=0} } ]
Now, despite the load-balancing choice being made elsewhere than at the initial classifier, it is possible for the reverse SFPs to be well constructed without any ambiguity. The three reverse paths appear as follows.
現在、ロードバランス選択が最初の分類子であるよりも他の場所で行われているにもかかわらず、逆SFPがあいまいさずに十分に構築されることが可能である。3つのリバースパスは次のように表示されます。
SFP30: RD = 198.51.100.1/130, SPI = 44,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.5/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP31: RD = 198.51.100.1/131, SPI = 45,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.6/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP32: RD = 198.51.100.1/132, SPI = 46,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.7/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]
This section provides several examples using IPv6 addressing. As will be seen from the examples, there is nothing special or clever about using IPv6 addressing rather than IPv4 addressing.
このセクションでは、IPv6アドレッシングを使用していくつかの例を示します。例から分かるように、IPv4アドレッシングではなくIPv6アドレス指定を使用することについて特別または賢いものは何もありません。
The reference network for these IPv6 examples is based on that described at the top of Section 8 and shown in Figure 11.
これらのIPv6の例の参照ネットワークは、セクション8の上部に記載されており、図11に示すものに基づいています。
Assume we have a service function overlay network with four SFFs (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the underlay network as follows:
4つのSFFS（SFF1、SFF3、SFF3、およびSFF4）を搭載したサービス機能オーバーレイネットワークがあるとします。SFFSは、次のようにアンダーレイネットワーク内のアドレスを持っています。
SFF1 2001:db8::192:0:2:1
SFF2 2001:db8::192:0:2:2
SFF3 2001:db8::192:0:2:3
SFF4 2001:db8::192:0:2:4
Each SFF provides access to some SFIs from the four service function types SFT=41, SFT=42, SFT=43, and SFT=44, just as before:
各SFFは、4つのサービス機能タイプSFT = 41、SFT = 42、SFT = 43、およびSFT = 43、およびSFT = 44からのSFIへのアクセスを提供する。
SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44
The service function network also contains a controller with address 2001:db8::198:51:100:1.
サービス機能ネットワークには、アドレス2001のコントローラも含まれています.DB8 :: 198：51：100：1。
This example service function overlay network is shown in Figure 15.
このサービス機能オーバーレイネットワークの例を図15に示します。
------------------------
| Controller |
| 2001:db8::198:51:100:1 |
------------------------
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------
\ / \ /
------------------- -------------------
| SFF1 | | SFF2 |
|2001:db8::192:0:2:1| |2001:db8::192:0:2:2|
------------------- -------------------
----------
Packet --> | | -->
Flows --> |Classifier| -->Dest
| | -->
----------
------------------- -------------------
| SFF3 | | SFF4 |
|2001:db8::192:0:2:3| |2001:db8::192:0:2:4|
------------------- -------------------
/ \ / \
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------
Figure 15: Example Service Function Overlay Network
図15：サービス機能オーバーレイネットワークの例
The SFFs advertise routes to the SFIs they support. These advertisements contain RDs that are set according to the network operator's configuration model. Note that in an IPv6 network, the RD is not large enough to contain the full IPv6 address, as only six octets are available. So, in all of these IPv6 examples, we use RDs of Type 1 such that the available six octets are partitioned as four octets for an IPv4 address of the advertising SFF, and two octets that are a local index of the SFI. Furthermore, we have chosen an IPv6 addressing scheme so that the low-order four octets of the IPv6 address match an IPv4 address of the advertising node. This scheme is chosen purely for convenience of documentation, and an operator is totally free to use any other scheme so long as it conforms to the definitions of SFIR and SFPR in Sections 3.1 and 3.2.
SFFSはそれらがサポートするSFIへのルートをアドバタイズします。これらの広告には、ネットワーク事業者の構成モデルに従って設定されているRDSが含まれています。IPv6ネットワークでは、RDは、6オクテットが入手可能であるため、完全なIPv6アドレスを含めるのに十分な大きさではありません。したがって、これらのIPv6のすべての例では、使用可能な6オクテットが広告SFFのIPv4アドレスの4オクテット、およびSFIのローカルインデックスである2つのオクテットとしてパーティション化されるように、タイプ1のRDSを使用します。さらに、IPv6アドレスの下位4オクテットが広告ノードのIPv4アドレスと一致するように、IPv6アドレス指定方式を選択しました。この方式は文書の利便性のために純粋に選択されており、セクション3.1および3.2のSFIRとSFPRの定義に準拠している限り、オペレータは他のスキームを完全に自由に使用できます。
Observant readers will notice that this makes the BGP advertisements shown in these examples exactly the same as in the previous examples. All that is different is that the advertising SFFs and controller have IPv6 addresses.
観察者の読者は、これがこれらの例に示されているBGP広告を前の例と全く同じにすることに気付くでしょう。広告SFFSとコントローラにIPv6アドレスが異なることは違っています。
Thus, we see the following SFIRs advertised.
したがって、次のSFIRが宣伝されているのを見ます。
The SFFs advertise routes to the SFIs they support. So we see the following SFIRs:
SFFSはそれらがサポートするSFIへのルートをアドバタイズします。そのため、以下のSFIRが表示されます。
RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44
Note that the addressing used for communicating between SFFs is taken from the tunnel encapsulation attribute of the SFIR and not from the SFIR-RD.
SFIR - RDからではなく、SFF間で通信するために使用されるアドレス指定は、SFIRのトンネルカプセル化属性から取得されることに注意してください。
Consider the following SFPR similar to that in Section 8.1.
セクション8.1と同様の次のSFPRを考えてみましょう。
SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
The SFP consists of an SF of Type 41 located at SFF1, followed by an SF of Type 43 located at SFF2. This path is fully explicit, and each SFF is offered no choice in forwarding a packet along the path.
SFPは、SFF1に位置するタイプ41のSF、続いてSFF2にある43のSFからなる。このパスは完全に明示的であり、各SFFはパスに沿ってパケットを転送する際に選択されていません。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (15). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受信し、SPI（15）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next-hop SFI and will forward the packet to SFF2, which will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、次のホップSFIをサポートするためのSFFの選択に柔軟性がありません。パケットをSFT 43に送信するSFIにパケットを送信します。
SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ]
In this example, like that in Section 8.2, the path also consists of an SF of Type 41 located at SFF1, and this is followed by an SF of Type 43; but in this case, the SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4.
この例では、セクション8.2のように、パスはSFF1にあるタイプ41のSFからなり、これに続く43のSFが続く。しかし、この場合、Si = 250は、SFF2にあるSFIとSFIに位置するSFIとの間の選択肢を含む。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (16). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受信し、SPI（16）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a choice of next-hop SFFs to execute the next hop in the path. It can either forward packets to SFF2 or SFF4 to execute a function of Type 43. It uses its local load-balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内のネクストホップを実行するためにNext-Hop SFFの選択をしました。Packets 43の機能を実行するために、パケットをSFF2またはSFF4に転送することができます。この選択を行うためにそのローカル負荷分散アルゴリズムを使用します。選択されたSFFは、パケットをそれらの宛先に転送する前に、SFT43をサポートするSFIにパケットを送信する。
SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0]
In this example, like that in Section 8.3, the path also consists of an SF of Type 41 located at SFF1, and this is followed by an SI with an RD of zero and SF of Type 44. This means that a choice can be made between any SFF that supports an SFI of Type 44.
この例では、セクション8.3のように、パスはSFF1に配置されたタイプ41のSFからなる。これは、タイプ44のゼロおよびSFのRDを有するSIが続く。これは選択が可能であることを意味する。タイプ44のSFIをサポートする任意のSFF間。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (17). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上にパケットを受け取り、SPI（17）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support SFs of Type 44. Looking at the SFIRs it has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF4. SFF1 uses its local load-balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 44 before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内の次のホップを実行するためにNext-Hop SFFのフリーの選択を行い、タイプ44のSFSをサポートするすべてのSFFを選択します。SFF4。SFF1はそのローカル負荷分散アルゴリズムを使用してこの選択を行います。選択されたSFFは、パケットをそれらの宛先に転送する前に、SFT44をサポートするSFIにパケットを送信する。
SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ]
This example, similar to that in Section 8.4, provides a choice of SF type in the second hop in the path. The SI of 250 indicates a choice between SF Type 43 located through SF2 and SF Type 44 located at SF3.
この例では、セクション8.4と同様に、パス内の2番目のホップ内のSFタイプの選択を提供します。250のSiは、SF 2およびSFタイプ44に位置するSFタイプ43の間の選択肢をSF 3に位置する選択肢を示す。
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (18). The initial SI will be 255, and so SFF1 will deliver the packets to the SFI for SFT 41.
SFF1は分類子からパス上のパケットを受信し、SPI（18）からのパスを識別します。初期SIは255になるので、SFF1はパケットをSFI 41のSFIに供給する。
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support an SF of Type 43 and SFF3, which supports an SF of Type 44. These may be completely different functions that are to be executed dependent on specific conditions, or they may be similar functions identified with different type identifiers (such as firewalls from different vendors). SFF1 uses its local policy and load-balancing algorithm to make this choice, and it may use additional information passed back from the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI that supports the chosen SFT before forwarding the packets to their destinations.
SFIによってパケットがSFF1に戻ると、次のホップについてSIは250に減少します。SFF1は、パス内のネクストホップを実行するためにNext-Hop SFFSを自由に選択して、タイプ43とSFF3のSFをサポートするすべてのSFF間で選択されます。これは、44のSFをサポートします。特定の条件に応じて実行される場合、またはそれらは異なる型識別子（異なるベンダからのファイアウォールなど）で識別される類似の関数であり得る。SFF1は、そのローカルポリシーと負荷分散アルゴリズムを使用してこの選択を行い、その選択に通知するためにローカルSFIから返された追加情報を使用することができます。選択されたSFFは、パケットをそれらの宛先に転送する前に、選択されたSFTをサポートするSFIにパケットを送信します。
The mechanisms in this document use BGP for the control plane. Hence, techniques such as those discussed in [RFC5925] can be used to help authenticate BGP sessions and, thus, the messages between BGP peers, making it harder to spoof updates (which could be used to install bogus SFPs or advertise false SIs) or withdrawals.
この文書のメカニズムは、制御面に対してBGPを使用します。したがって、[RFC5925]で説明されているもののような技術を使用して、BGPセッションを認証するのに役立ち、したがってBGPピア間のメッセージ、したがってアップデート（Bogus SFPSまたは宣伝または宣言SISをインストールするために使用される可能性がある）を困難にすることができます。引き出し
Further discussion of security considerations for BGP may be found in the BGP specification itself [RFC4271] and the security analysis for BGP [RFC4272]. [RFC5925] contains a discussion of the inappropriateness of the TCP MD5 signature option for protecting BGP sessions. [RFC6952] includes an analysis of BGP keying and authentication issues.
BGPのセキュリティ上の考慮事項についてのさらなる議論は、BGP仕様自体[RFC4271]およびBGP [RFC4272]のセキュリティ分析に見出すことができる。[RFC5925] BGPセッションを保護するためのTCP MD5署名オプションの不適切な説明について説明します。[RFC6952] BGPキーイングと認証の問題の分析を含みます。
Additionally, this document depends on other documents that specify BGP Multiprotocol Extensions and the documents that define the attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. [RFC4760] observes that the use of AFI/SAFI does not change the underlying security issues inherent in the existing BGP. Relevant additional security measures are considered in [RFC9012].
さらに、このドキュメントは、BGP Multiprotocol拡張機能とSFC AFI / SAFIのBGP更新によって伝送される属性を定義する文書を指定する他の文書に依存します。[RFC4760] AFI / SAFIの使用が既存のBGPに固有の基になるセキュリティ問題を変更しないことを確認します。[RFC9012]に関連する追加のセキュリティ対策が考慮されています。
This document does not fundamentally change the security behavior of BGP deployments, which depend considerably on the network operator's perception of risk in their network. It may be observed that the application of the mechanisms described in this document is scoped to a single domain, as implied by [RFC8300] and noted in Section 2.1 of this document. Applicability of BGP within a single domain may enable a network operator to make easier and more consistent decisions about what security measures to apply, and the domain boundary, which BGP enforces by definition, provides a safeguard that prevents leakage of SFC programming in either direction at the boundary.
この文書では、BGP展開のセキュリティ動作を基本的に変更していません。これは、ネットワーク事業者のネットワークにおけるリスクの認識にかなり依存しています。この文書に記載されているメカニズムの適用は、[RFC8300]によって暗示され、この文書のセクション2.1に記載されているように、単一のドメインにスコープされていることが観察されるかもしれません。単一ドメイン内のBGPの適用性は、ネットワークオペレータが適用するセキュリティ対策について、どのようなセキュリティ対策を適用するか、および定義によってどのBGPを適用するか、どの方向のいずれの方向へのSFCプログラミングの漏洩を防止するセーフガードを提供することができる。境界
Service function chaining provides a significant attack opportunity; packets can be diverted from their normal paths through the network, packets can be made to execute unexpected functions, and the functions that are instantiated in software can be subverted. However, this specification does not change the existence of service function chaining, and security issues specific to service function chaining are covered in [RFC7665] and [RFC8300].
サービス機能チェーンは重要な攻撃の機会を提供します。パケットはネットワークを介して通常のパスから転送でき、パケットを予期しない機能を実行し、ソフトウェアでインスタンス化されている機能を超えることができます。ただし、この仕様はサービス機能連鎖の存在を変更しません。サービス機能連鎖に固有のセキュリティ問題は[RFC7665]と[RFC8300]で説明されています。
This document defines a control plane for service function chaining. Clearly, this provides an attack vector for a service function chaining system, as an attack on this control plane could be used to make the system misbehave. Thus, the security of the BGP system is critically important to the security of the whole service function chaining system. The control plane mechanisms are very similar to those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the security considerations in that document (Section 13) provide good guidance for securing service function chaining systems reliant on this specification. Of particular relevance is the need to securely distinguish between messages intended for the control of different SFC overlays, which is similar to the need to distinguish between different VPNs. Section 19 of [RFC7432] also provides useful guidance on the use of BGP in a similar environment.
この文書は、サービス機能連鎖のためのコントロールプレーンを定義します。明らかに、これはシステムの誤動作を行うために使用されるように、サービス機能連鎖システムのための攻撃ベクトルを提供する。したがって、BGPシステムのセキュリティは、サービス機能連鎖システム全体のセキュリティにとって非常に重要です。制御プレーンメカニズムは[RFC4364]で説明されているようにBGP / MPLS IP VPNに使用されるものと非常によく似ています。そのため、その文書内のセキュリティ上の考慮事項（セクション13）は、この仕様に依存してサービス機能連鎖システムを保護するための優れたガイダンスを提供します。特定の関連性は、異なるVPNを区別する必要性と似ている、異なるSFCオーバーレイの制御を意図したメッセージを安全に区別する必要性である。[RFC7432]の第19節も、同様の環境でのBGPの使用に関する有用なガイダンスを提供します。
Note that a component of a service function chaining system that uses the procedures described in this document also requires communications between a controller and the service function chaining network elements (specifically the SFFs and classifiers). This communication covers instructing the classifiers using BGP mechanisms (see Section 7.4); therefore, the use of BGP security is strongly recommended. But it also covers other mechanisms for programming the classifier and instructing the SFFs and SFs (for example, to bind SFs to an SFF, and to cause the establishment of tunnels between SFFs). This document does not cover these latter mechanisms, and so their security is out of scope, but it should be noted that these communications provide an attack vector on the service function chaining system, and so attention must be paid to ensuring that they are secure.
この文書に記載されている手順を使用するサービス機能連鎖システムの構成要素はまた、コントローラとサービス関数連鎖ネットワーク要素（具体的にはSFFと分類器）との間の通信も必要となる。この通信は、BGPメカニズムを使用して分類子に指示することをカバーしています（セクション7.4を参照）。したがって、BGPセキュリティの使用を強くお勧めします。しかし、それはまた、分類子をプログラミングし、SFFとSFSを指示するための他のメカニズムをカバーしています（たとえば、SFSをSFFにバインドし、SFF間でトンネルの確立を引き起こす）。この文書はこれらの後者のメカニズムをカバーしていないため、セキュリティが範囲外ですが、これらの通信はサービス機能連鎖システムで攻撃ベクトルを提供することに注意してください。
There is an intrinsic assumption in service function chaining systems that nodes that announce support for specific SFs actually offer those functions and that SFs are not, themselves, attacked or subverted. This is particularly important when the SFs are implemented as software that can be updated. Protection against this sort of concern forms part of the security of any service function chaining system and so is outside the scope of the control plane mechanisms described in this document.
特定のSFSに対するサポートをアナウンスするノードが実際にそれらの機能が提供され、SFSが攻撃または攻撃されていないことを確認する、サービス機能連鎖システムに固有の仮定があります。これは、SFSが更新できるソフトウェアとして実装されている場合に特に重要です。この種の懸念に対する保護は、どのサービス機能連鎖システムのセキュリティの一部を形成しているので、この文書に記載されている制御プレーンメカニズムの範囲外です。
Similarly, there is a vulnerability if a rogue or subverted controller announces SFPs, especially if that controller "takes over" an existing SFP and changes its contents. This corresponds to a rogue BGP speaker entering a routing system, or even a Route Reflector becoming subverted. Protection mechanisms, as above, include securing BGP sessions and protecting software loads on the controllers.
同様に、特にそのコントローラが既存のSFPを「引き継ぐ」の場合に、不正または縮合コントローラがSFPを発表し、その内容を変更する場合には、不正や脆弱なコントローラが発表されている場合に脆弱性があります。これは、ルーティングシステムに入るローグBGPスピーカー、あるいはルートリフレクタでさえ縮小されています。上記のように、保護メカニズムは、BGPセッションを保護し、コントローラのソフトウェア負荷を保護することを含みます。
In an environment where there is concern that rogue controllers might be introduced to the network and inject false SFPRs or take over and change existing SFPRs, it is RECOMMENDED that each SFF and classifier be configured with the identities of authorized controllers. Thus, the announcement of an SFPR by any other BGP peer would be rejected.
不正コントローラがネットワークに導入され、誤ったSFPRSを挿入して既存のSFPRを引き継ぐことができるという環境では、各SFFおよび分類子を許可されたコントローラのIDで構成することをお勧めします。したがって、他のBGPピアによるSFPRの発表は拒否されます。
Lastly, note that Section 3.2.2 makes two operational suggestions that have implications for the stability and security of the mechanisms described in this document:
最後に、セクション3.2.2はこの文書に記載されているメカニズムの安定性とセキュリティに影響を与える2つの操作上の提案を行うことに注意してください。
* That modifications to active SFPs not be made.
* アクティブSFPへの変更はできません。
* That SPIs not be immediately reused.
* そのspisはすぐに再利用されません。
IANA maintains the "Address Family Numbers" registry. IANA has assigned a new Address Family Number from the "Standards Action" range called "BGP SFC" (31), with this document as a reference.
IANAは「住所の家族番号」レジストリを管理しています。IANAは、「BGP SFC」（31）と呼ばれる「標準アクション」範囲から新しいアドレスファミリ番号を割り当てました。このドキュメントは参考文献です。
IANA maintains the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. IANA has assigned a new SAFI value from the "Standards Action" range called "BGP SFC" (9), with this document as a reference.
IANAは「後続のアドレスファミリID（SAFI）パラメータ」レジストリを管理します。IANAは、この文書を参照として、「BGP SFC」（9）と呼ばれる「標準アクション」範囲から新しいSAFI値を割り当てました。
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Path Attributes". IANA has assigned a new Path attribute called "SFP attribute" with a value of 37 and with this document as a reference.
IANAは、「BGPパス属性」のサブレクシストで「ボーダーゲートウェイプロトコル（BGP）パラメータ」のレジストリを維持しています。IANAは、「SFP属性」という新しいパス属性を37の値、およびこの文書を参照として割り当てました。
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA has created a new subregistry called the "SFP Attribute TLVs" registry.
IANAは、「ボーダーゲートウェイプロトコル（BGP）パラメータ」のレジストリを維持しています。IANAは、「SFP属性TLVS」レジストリと呼ばれる新しいサブレジストリを作成しました。
Valid values are in the range 0 to 65535.
有効な値は0から65535の範囲です。
* Values 0 and 65535 are marked "Reserved".
* 値0と65535は「予約済み」とマークされています。
* Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126].
* 値1~65534は、「最初のサービス」ポリシー[RFC8126]に従って割り当てられます。
This document is a reference for this registry.
この文書はこのレジストリの参照です。
The registry tracks:
レジストリトラック
* Type
* タイプ
* Name
* 名前
* Reference
* 参照
* Registration Date
* 登録日
The registry is initially populated as follows:
レジストリは最初次のように入力されています。
+======+=========================+===========+===================+
| Type | Name | Reference | Registration Date |
+======+=========================+===========+===================+
| 1 | Association TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 2 | Hop TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 3 | SFT TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 4 | MPLS Swapping/Stacking | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 5 | SFP Traversal With MPLS | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
Table 1: SFP Attribute TLVs Subregistry Initial Contents
表1：SFP属性TLVSサブリュジストの初期コンテンツ
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA has created a new subregistry called the "SFP Association Type" registry.
IANAは、「ボーダーゲートウェイプロトコル（BGP）パラメータ」のレジストリを維持しています。IANAは、「SFPアソシエーションタイプ」レジストリと呼ばれる新しいサブレジストを作成しました。
Valid values are in the range 0 to 65535.
有効な値は0から65535の範囲です。
* Values 0 and 65535 are marked "Reserved".
* 値0と65535は「予約済み」とマークされています。
* Values 1 through 65534 are assigned according to the "First Come First Served" policy [RFC8126].
* 値1~65534は、「最初の最初のサービス」ポリシー[RFC8126]に従って割り当てられています。
This document is given as a reference for this registry.
この文書はこのレジストリの参照として与えられています。
The new registry tracks:
新しいレジストリトラック
* Association Type
* アソシエーションタイプ
* Name
* 名前
* Reference
* 参照
* Registration Date
* 登録日
The registry should initially be populated as follows:
レジストリは最初は次のように入力されます。
+==================+===================+===========+============+
| Association Type | Name | Reference | Date |
+==================+===================+===========+============+
| 1 | Bidirectional SFP | RFC 9015 | 2020-09-02 |
+------------------+-------------------+-----------+------------+
Table 2: SFP Association Type Subregistry Initial Contents
表2：SFPアソシエーションタイプサブリュージスト初期コンテンツ
IANA has created a new top-level registry called "Service Function Chaining Service Function Types".
IANAは、「サービス機能連鎖サービス機能タイプ」という新しい最上位レジストリを作成しました。
Valid values are in the range 0 to 65535.
有効な値は0から65535の範囲です。
* Values 0 and 65535 are marked "Reserved".
* 値0と65535は「予約済み」とマークされています。
* Values 1 through 31 are to be assigned by "Standards Action" [RFC8126] and are referred to as the "special-purpose SFT values".
* 値1~31は、「標準アクション」[RFC8126]によって割り当てられ、「専用のSFT値」と呼ばれます。
* Values 32 through 64495 are to be assigned according to the "First Come First Served" policy [RFC8126].
* 値32から64495は、「最初のサービス」ポリシー[RFC8126]に従って割り当てられます。
* Values 64496 through 65534 are for Private Use and are not to be recorded by IANA.
* 値64496から65534は個人的な使用のためのものであり、IANAによって記録されるべきではありません。
This document is given as a reference for this registry.
この文書はこのレジストリの参照として与えられています。
The registry tracks:
レジストリトラック
* Value
* 値
* Name
* 名前
* Reference
* 参照
* Registration Date
* 登録日
The registry is initially populated as follows.
レジストリは最初は次のように入力されます。
+=============+===================+=============+============+
| Value | Name | Reference | Date |
+=============+===================+=============+============+
| 0 | Reserved | RFC 9015 | 2020-09-02 |
+-------------+-------------------+-------------+------------+
| 1 | Change Sequence | RFC 9015 | 2020-09-02 |
+-------------+-------------------+-------------+------------+
| 2-31 | Unassigned | | |
+-------------+-------------------+-------------+------------+
| 32 | Classifier | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 33 | Firewall | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 34 | Load balancer | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 35 | Deep packet | RFC 9015, | 2020-09-02 |
| | inspection engine | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 36 | Penalty box | RFC 9015, | 2020-09-02 |
| | | [RFC8300] | |
+-------------+-------------------+-------------+------------+
| 37 | WAN accelerator | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC8300] | |
+-------------+-------------------+-------------+------------+
| 38 | Application | RFC 9015, | 2020-09-02 |
| | accelerator | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 39 | TCP optimizer | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 40 | Network Address | RFC 9015, | 2020-09-02 |
| | Translator | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 41 | NAT44 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC3022] | |
+-------------+-------------------+-------------+------------+
| 42 | NAT64 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC6146] | |
+-------------+-------------------+-------------+------------+
| 43 | NPTv6 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC6296] | |
+-------------+-------------------+-------------+------------+
| 44 | Lawful intercept | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 45 | HOST_ID injection | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 46 | HTTP header | RFC 9015, | 2020-09-02 |
| | enrichment | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 47 | Caching engine | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 48-64495 | Unassigned | | |
+-------------+-------------------+-------------+------------+
| 64496-65534 | Reserved for | | |
| | Private Use | | |
+-------------+-------------------+-------------+------------+
| 65535 | Reserved, not to | RFC 9015 | 2020-09-02 |
| | be allocated | | |
+-------------+-------------------+-------------+------------+
Table 3: Service Function Chaining Service Function Types Registry Initial Contents
表3：サービス機能連鎖サービス機能タイプレジストリ初期コンテンツ
IANA maintains a registry of "Border Gateway Protocol (BGP) Extended Communities" with a subregistry of "Generic Transitive Experimental Use Extended Community Sub-Types". IANA has assigned a new subtype as follows:
IANAは、「一般的な推移的実験的使用拡大コミュニティサブタイプ」のサブレクツで「ボーダーゲートウェイプロトコル（BGP）拡張コミュニティ」のレジストリを維持しています。IANAは次のように新しいサブタイプを割り当てました。
"Flow Specification for SFC Classifiers" with a value of 0x0d and with this document as the reference.
「SFC分類器のフロー仕様」は、0x0Dの値と参照としてこの文書を含む「SFC分類器のフロー仕様」。
IANA maintains a registry of "Border Gateway Protocol (BGP) Extended Communities" with a subregistry of "BGP Transitive Extended Community Types". IANA has assigned a new type as follows:
IANAは、「BGP推移的拡張コミュニティタイプ」のサブレジストで「ボーダーゲートウェイプロトコル（BGP）拡張コミュニティ」のレジストリを維持しています。IANAは次のように新しい型を割り当てました。
SFC (Sub-Types are defined in the "SFC Extended Community Sub-Types" registry) with a value of 0x0b and with this document as the reference.
SFC（サブタイプは、SFC拡張コミュニティサブタイプ "レジストリ）0x0bの値と参照としてこのドキュメントを持つ" SFC拡張コミュニティサブタイプ "に定義されています。
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA has created a new subregistry called the "SFC Extended Community Sub-Types" registry.
IANAは、「ボーダーゲートウェイプロトコル（BGP）パラメータ」のレジストリを維持しています。IANAは、「SFC拡張コミュニティサブタイプ」レジストリと呼ばれる新しいサブレジストリを作成しました。
IANA has included the following note:
IANAは次の注意事項を含めました。
| This registry contains values of the second octet (the "Sub-
| Type" field) of an extended community when the value of the
| first octet (the "Type" field) is set to 0x0b.
The allocation policy for this registry is First Come First Served.
このレジストリの割り当てポリシーが最初にサービス提供されています。
Valid values are 0 to 255. The value 0 is reserved and should not be allocated.
有効な値は0から255です。値0は予約されており、割り当てられないでください。
IANA has populated this registry with the following entries:
IANAはこのレジストリを次のように入力しました。
+==========+==========================+===========+============+
| Sub-Type | Name | Reference | Date |
| Value | | | |
+==========+==========================+===========+============+
| 0 | Reserved | RFC 9015 | |
+----------+--------------------------+-----------+------------+
| 1 | SFIR pool identifier | RFC 9015 | 2020-09-02 |
+----------+--------------------------+-----------+------------+
| 2 | MPLS Label Stack Mixed | RFC 9015 | 2020-09-02 |
| | Swapping/Stacking Labels | | |
+----------+--------------------------+-----------+------------+
| 3-255 | Unassigned | | |
+----------+--------------------------+-----------+------------+
Table 4: SFC Extended Community Sub-Types Subregistry Initial Contents
表4：SFC拡張コミュニティサブタイプサブレジスト初期コンテンツ
IANA has assigned a codepoint from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV" with a value of 16 and with this document as the reference.
IANAは、「BGP Tunnel Encapsulation属性SUB-TLV」の「SPI / SI表現サブTLV」とは、値16の値を参照して、この文書を参照として割り当てました。
IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry and has created an associated registry called the "SFC SPI/ SI Representation Flags" registry.
IANAは、「BGP Tunnel Encapsulation属性サブTLVS」レジストリを管理し、「SFC SPI / SI表現フラグ」レジストリと呼ばれる関連レジストリを作成しました。
Bits are to be assigned by Standards Action. The field is 16 bits long, and bits are counted from the most significant bit as bit zero.
ビットは標準アクションによって割り当てられます。フィールドは16ビット長で、ビットはビットゼロとして最上位ビットからカウントされます。
IANA has populated the registry as follows:
IANAはレジストリを次のように入力しました。
+=======+=================+===========+
| Value | Name | Reference |
+=======+=================+===========+
| 0 | NSH data plane | RFC 9015 |
+-------+-----------------+-----------+
| 1 | MPLS data plane | RFC 9015 |
+-------+-----------------+-----------+
Table 5: SFC SPI/SI Representation Flags Registry Initial Contents
表5：SFC SPI / SI表現フラグレジストリ初期コンテンツ
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D.、およびY.Rekhter、「BGP Extended Communities属性」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<https：//www.rfc-editor.org/info/ RFC4360>。
[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] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T.、Chandra、R.、Katz、D.、およびY.Rekhter、「BGP-4」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW.HenderickX、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https：//www.rfc-editor.org/info/rfc7432>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK。Patel、「BGP更新メッセージの修正エラー処理」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[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。「サービス機能連鎖（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487 / RFC7665、<https：//www.rfc-editor.org/info/rfc7665>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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。、およびC. Pignataro、Ed。、「ネットワークサービスヘッダ（NSH）」、RFC 8300、DOI 10.17487 / RFC8300、2018年1月、<https：//www.rfc-editor.org/info/rfc8300>。
[RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Forwarding Plane for Service Function Chaining", RFC 8595, DOI 10.17487/RFC8595, June 2019, <https://www.rfc-editor.org/info/rfc8595>.
[RFC8595] Farrel、A.、Bryant、S.、J. Drake、「サービス機能連鎖のためのMPLSベースの転送面」、RFC 8595、DOI 10.17487 / RFC8595、2019年6月、<https：//www.rfc-editor.org/info/rfc8595>。
[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>.
[RFC8596] Malis、A.、Bryant、S.、Halpern、J.、およびW.Henderickx、「サービス機能連鎖のためのMPLSトランスポートカプセル化（SFC）ネットワークサービスヘッダ（NSH）」、RFC 8596、DOI 10.17487 / RFC85962019年6月、<https：//www.rfc-editor.org/info/rfc8596>。
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8955] LOIBL、C.、HARES、S.、Raszuk、R.、Mcpherson、D.、およびM. Bacher、「フロー仕様規則の普及」、RFC 8955、DOI 10.17487 / RFC8955、2020年12月2020日、<HTTPS：//www.rfc-editor.org/info/rfc8955>。
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9012]聖母、K.、Van de Velde、G.、Sangli、S.、およびJ.Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487 / RFC9012、2021年4月、<https：// www.rfc-editor.org / info / rfc9012>。
[BGP-LS-SR] Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Advertisement of Segment Routing Service Segments", Work in Progress, Internet-Draft, draft-dawra-idr-bgp-ls-sr-service-segments-05, 15 February 2021, <https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-05>.
[BGP-LS-SR] Dawra、G.、Filsfils、C、C.、Talaulikar、K.、Clad、F.、Bernier、D.、Uttaro、J.、Decraene、B.、Elmalky、H.、X。、GUICHARD、J。、およびC. LI、「BGP - LS広告」、「セグメントルーティングサービスセグメントの広告」、進行中の作業、インターネットドラフト、ドラフト - Dawra-IDR-BGP-LS-SR-SERVICE-SEGMENTS-05、2021年2月15日、<https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-05>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] SRISURESH、P.およびK。EGEVANG、「伝統的なIPネットワークアドレス翻訳者（伝統的なIPネットワークアドレス翻訳者（伝統的なNAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https：//www.rfc-editor.org/info/RFC3022>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S.、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https：//www.rfc-editor.org/info/rfc4272>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P.、I。van Beijnum、 "IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https：//www.rfc-editor.org/info/rfc6146>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M.およびF. Baker、 "IPv6-to-ipv6ネットワークプレフィックス翻訳"、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296>。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL.Zheng、「ルーティングプロトコル（KARP）設計ガイド」、RFC 6952、DOIのためのキーイング・認証によるBGP、LDP、PCE、およびMSDP問題の分析10.17487 / RFC6952、2013年5月、<https：//www.rfc-editor.org/info/rfc6952>。
[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>.
[RFC7498] Quinn、P.、ED。2015年4月、<https://www.rfc-editor.org/info/rfc7498、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc7498、<https://ww.rfc-editor.org/info/rfc7498>。
Acknowledgements
謝辞
Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful comments, and to Joel Halpern for discussions that improved this document. Yuanlong Jiang provided a useful review and caught some important issues. Stephane Litkowski did an exceptionally good and detailed Document Shepherd review.
Tony Przygienda、Jeff Haas、Andy Malis、そしてこの文書を改善した議論のためのJoel Halpernに感謝します。Yuanlong Jiangは有用なレビューを提供し、いくつかの重要な問題を捉えました。Stephane Litkowskiは、非常に良くて詳細な文書の羊飼いのレビューをしました。
Andy Malis contributed text that formed the basis of Section 7.7.
Andy Malisはセクション7.7の基礎を形成したテキストを寄付しました。
Brian Carpenter and Martin Vigoureux provided useful reviews during IETF Last Call. Thanks also to Sheng Jiang, Med Boucadair, Ravi Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, Barry Leiba, and Murray Kucherawy for review comments. Ketan Talaulikar provided helpful discussion of the SFT codepoint registry. Ron Bonica kept us honest on the difference between an RD and an RT; Benjamin Kaduk kept us on message about the difference between an RD and an Extended Community.
Brian CarpenterとMartin Vigoueuxは、IETFの最後の呼び出し中に有用レビューを提供しました。Sheng Jiang、Med Boucadair、Ravi Singh、Benjamin Kaduk、Roman Danyylw、Adam Roach、Alvaro Retana、Barry Leiba、およびMurry Kucherawyのレビューコメント。Ketan Talaulikarは、SFT Codepointレジストリについての役立ち議論を提供しました。Ron Bonicaは、RDとRTの違いについて正直に留意しました。Benjamin Kadukは、RDと拡張コミュニティとの違いについてのメッセージに留まりました。
Contributors
貢献者
Stuart Mackie Juniper Networks
Stuart Mackie Juniperネットワーク
Email: wsmackie@juinper.net
Keyur Patel Arrcus, Inc.
Keyur Patel Arrcus、Inc。
Email: keyur@arrcus.com
Avinash Lingala AT&T
Avinash Lingala At＆T.
Email: ar977m@att.com
Authors' Addresses
著者の住所
Adrian Farrel Old Dog Consulting
エイドリアンファーレルオールドドッグコンサルティング
Email: adrian@olddog.co.uk
John Drake Juniper Networks
John Drake Juniperネットワーク
Email: jdrake@juniper.net
Eric Rosen Juniper Networks
Eric Rosen Juniperネットワーク
Email: erosen52@gmail.com
Jim Uttaro AT&T
Jim Uttaro At＆T.
Email: ju1738@att.com
Luay Jalil Verizon
Luay Jalil Verizon
Email: luay.jalil@verizon.com