Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 9516 Ericsson
Category: Standards Track W. Meng
ISSN: 2070-1721 ZTE Corporation
T. Ao
China Mobile
B. Khasnabish
K. Leung
Individual Contributor
G. Mishra
Verizon Inc.
November 2023
A set of requirements for active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC) in a network is presented in this document. Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described.
ネットワーク内のサービス機能チェーン（SFC）のアクティブな運用、管理、およびメンテナンス（OAM）の要件のセットは、このドキュメントに示されています。これらの要件に基づいて、SFCでのアクティブなOAMメッセージのカプセル化と、欠陥を検出および局在するメカニズムについて説明します。
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/rfc9516.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9516で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology and Conventions
2.1. Requirements Language
2.2. Acronyms
3. Requirements for Active OAM in SFC
4. Active OAM Identification in the NSH
5. SFC Active OAM Header
6. Echo Request/Reply for SFC
6.1. Return Codes
6.2. Authentication in Echo Request/Reply
6.3. SFC Echo Request Transmission
6.3.1. Source ID TLV
6.4. Processing a Received SFC Echo Request
6.4.1. Errored TLVs TLV
6.5. SFC Echo Reply Transmission
6.5.1. Reply Service Function Path TLV
6.5.2. Theory of Operation
6.5.3. SFC Echo Reply Reception
6.5.4. Tracing an SFP
6.6. The Use of the Consistency Verification Request Message
6.6.1. SFF Information Record TLV
6.6.2. SF Information Sub-TLV
6.6.3. SF Information Sub-TLV Construction
7. Security Considerations
8. Operational Considerations
9. IANA Considerations
9.1. SFC Active OAM Protocol
9.2. SFC Active OAM
9.2.1. SFC Active OAM Message Types
9.2.2. SFC Echo Request Flags
9.2.3. SFC Echo Types
9.2.4. SFC Echo Reply Modes
9.2.5. SFC Echo Return Codes
9.2.6. SFC Active OAM TLV Types
9.2.7. SF Identifier Types
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
[RFC7665] defines data plane elements necessary to implement Service Function Chaining (SFC). These include the following:
[RFC7665]は、サービス関数チェーン（SFC）を実装するために必要なデータプレーン要素を定義します。これらには次のものが含まれます。
1. Classifiers that perform the classification of incoming packets. Such classification may result in associating a received packet to a service function chain.
1. 着信パケットの分類を実行する分類器。このような分類により、受信したパケットをサービス機能チェーンに関連付けることになります。
2. Service Function Forwarders (SFFs) that are responsible for forwarding traffic to one or more connected Service Functions (SFs) according to the information carried in the SFC encapsulation and handling traffic coming back from the SFs and forwarding it to the next SFF.
2. SFCのカプセル化に掲載された情報に従って、1つ以上の接続されたサービス関数（SFS）にトラフィックを転送し、SFSから戻ってきてトラフィックを処理し、次のSFFに転送するサービス関数フォワード（SFF）。
3. SFs that are responsible for executing specific service treatment on received packets.
3. 受信パケットで特定のサービストリートメントを実行する責任のあるSFS。
There are different views from different levels of SFC. One is the service function chain, an entirely abstract view, which defines an ordered set of SFs that must be applied to packets selected based on classification rules. But the service function chain doesn't specify the exact mapping between SFFs and SFs. Thus, another logical construct used in SFC is a Service Function Path (SFP). According to [RFC7665], an SFP is the instantiation of SFC in the network and provides a level of indirection between the entirely abstract SFCs and a fully specified, ordered list of SFF and SF identities that the packet will visit when it traverses SFC. The latter entity is referred to as Rendered Service Path (RSP). The main difference between an SFP and RSP is that the former is the logical construct, while the latter is the realization of the SFP via the sequence of specific SFC data plane elements.
さまざまなレベルのSFCからさまざまなビューがあります。1つは、分類ルールに基づいて選択されたパケットに適用する必要があるSFSの順序付けられたセットを定義する完全に抽象的なビューであるサービス機能チェーンです。ただし、サービス関数チェーンでは、SFFとSFS間の正確なマッピングは指定されていません。したがって、SFCで使用される別の論理コンストラクトは、サービス関数パス（SFP）です。[RFC7665]によれば、SFPはネットワーク内のSFCのインスタンス化であり、完全に抽象的なSFCと、SFCを横断するときにパケットが訪れるSFFおよびSFのアイデンティティの完全に指定された順序付けられたリストの間の間接レベルを提供します。後者のエンティティは、レンダリングされたサービスパス（RSP）と呼ばれます。SFPとRSPの主な違いは、前者が論理コンストラクトであることであり、後者は特定のSFCデータプレーン要素のシーケンスを介してSFPの実現であることです。
This document defines how active Operations, Administration, and Maintenance (OAM), per the definition of active OAM in [RFC7799], is implemented when the Network Service Header (NSH) [RFC8300] is used as the SFC encapsulation. Following the analysis of SFC OAM in [RFC8924], this document applies and, when necessary, extends requirements listed in Section 4 of [RFC8924] for the use of active OAM in an SFP supporting fault management and performance monitoring. Active OAM tools that are conformant to this specification improve OAM's ability for Fault Management (FM) by, for example, using the query mechanism to troubleshoot and localize defects, which conforms to the stateless character of transactions in SFC NSH [RFC8300]. Note that Performance Monitoring OAM, as required by [RFC8924], is not satisfied by this document and is out of scope. For the purpose of FM OAM in SFC, the SFC Echo Request and Echo Reply are specified in Section 6. These mechanisms enable on-demand continuity check and connectivity verification, among other operations, over SFC in networks and address functionalities discussed in Sections 4.1, 4.2, and 4.3 of [RFC8924]. The SFC Echo Request and Echo Reply can be used with encapsulations other than the NSH, for example, using MPLS encapsulation, as described in [RFC8595]. The applicability of the SFC Echo Request/Reply mechanism in SFC encapsulations other than the NSH is outside the scope of this document.
このドキュメントでは、[RFC7799]のアクティブOAMの定義に従って、アクティブオペレーション、管理、およびメンテナンス（OAM）が、ネットワークサービスヘッダー（NSH）[RFC8300]がSFCカプセル化として使用される場合に実装される方法を定義します。[RFC8924]のSFC OAMの分析に続いて、このドキュメントが適用され、必要に応じて、障害管理とパフォーマンスの監視をサポートするSFPでアクティブなOAMを使用するために、[RFC8924]のセクション4にリストされている要件を拡張します。この仕様に準拠しているアクティブなOAMツールは、たとえばクエリメカニズムを使用して、SFC NSHのトランザクションのステートレス特性に適合するクエリメカニズムを使用して欠陥をトラブルシューティングおよびローカライズすることにより、OAMの障害管理能力（FM）を改善します。[RFC8924]で要求されるパフォーマンス監視OAMは、このドキュメントで満たされず、範囲外であることに注意してください。SFCのFM OAMを目的として、SFCエコーリクエストとエコー応答をセクション6で指定します。これらのメカニズムにより、セクション4.1で説明されているネットワークおよびアドレス機能性のSFCを介して、需要の連続性チェックと接続検証を可能にします。[RFC8924]の4.2および4.3。[RFC8595]で説明されているように、SFCエコーリクエストとエコー応答は、NSH以外のカプセルで使用できます。たとえば、MPLSカプセル化を使用します。NSH以外のSFCカプセル化におけるSFCエコー要求/返信メカニズムの適用性は、このドキュメントの範囲外です。
The intended scope of SFC active OAM is for use within a single provider's operational domain. The SFC active OAM deployment scope is deliberately constrained, as explained in [RFC7665] and [RFC8300], and limited to a single network administrative domain.
SFC Active OAMの意図された範囲は、単一のプロバイダーの運用ドメイン内で使用するためのものです。[RFC7665]および[RFC8300]で説明されているように、SFCアクティブOAM展開スコープは意図的に制約され、単一のネットワーク管理ドメインに限定されています。
The terminology defined in [RFC7665] is used extensively throughout this document, and the reader is expected to be familiar with it.
[RFC7665]で定義されている用語は、このドキュメント全体で広く使用されており、読者はそれに精通していると予想されます。
In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC architecture. Additionally, "Echo Request/Reply" and "SFC Echo Request/Reply" are used interchangeably.
このドキュメントでは、SFC OAMはSFCアーキテクチャのアクティブなOAM [RFC7799]を指します。さらに、「エコーリクエスト/返信」と「SFCエコーリクエスト/返信」が同じ意味で使用されます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
E2E:
E2E：
End-to-End
端から端まで
FM:
FM：
Fault Management
障害管理
MAC:
マック：
Message Authentication Code
メッセージ認証コード
NSH:
NSH：
Network Service Header
ネットワークサービスヘッダー
OAM:
OAM：
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
RSP:
RSP：
Rendered Service Path
レンダリングされたサービスパス
SF:
SF：
Service Function
サービス機能
SFC:
SFC：
Service Function Chaining
サービス関数チェーン
SFF:
SFF：
Service Function Forwarder
サービス関数フォワーダー
SFI:
SFI：
Service Function Instance
サービス関数インスタンス
SFP:
SFP：
Service Function Path
サービス関数パス
As discussed in [RFC8924], SFC-specific means are needed to perform the FM OAM task in an SFC architecture, including failure detection, defect characterization, and localization. This document defines the set of requirements for active FM OAM mechanisms to be used in an SFC architecture.
[RFC8924]で説明したように、障害検出、欠陥の特性評価、ローカリゼーションなど、SFCアーキテクチャでFM OAMタスクを実行するには、SFC固有の手段が必要です。このドキュメントでは、SFCアーキテクチャで使用されるアクティブなFM OAMメカニズムの一連の要件を定義します。
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|SFI11| |SFI12| |SFI21| |SFI22| |SFI31| |SFI32|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ /
+----------+ +----+ +----+ +----+
|Classifier|---|SFF1|---------|SFF2|----------|SFF3|
+----------+ +----+ +----+ +----+
Figure 1: An Example of SFC Data Plane Architecture
図1：SFCデータプレーンアーキテクチャの例
The architecture example depicted in Figure 1 considers a service function chain that includes three distinct service functions. In this example, the SFP traverses SFF1, SFF2, and SFF3. Each SFF is connected to two Service Function Instances (SFIs) of the same SF. End-to-End (E2E) SFC OAM has the Classifier as the ingress and SFF3 as its egress. The scope of Segment SFC OAM is between two elements that are part of the same SFP. The following are the requirements for an FM SFC OAM, whether with the E2E or segment scope:
図1に示すアーキテクチャの例は、3つの異なるサービス関数を含むサービス関数チェーンを考慮しています。この例では、SFPはSFF1、SFF2、およびSFF3を通過します。各SFFは、同じSFの2つのサービス関数インスタンス（SFI）に接続されています。エンドツーエンド（E2E）SFC OAMには、侵入として分類器があり、sff3が出口としてsff3を持っています。セグメントSFC OAMの範囲は、同じSFPの一部である2つの要素の間にあります。E2Eであろうとセグメントの範囲であろうと、FM SFC OAMの要件は次のとおりです。
REQ1: Packets of SFC active OAM SHOULD be fate sharing with the monitored SFC data in the forward direction from ingress toward egress endpoint(s) of the OAM test.
REQ1：SFC Active OAMのパケットは、OAMテストの出口エンドポイントに向かって、監視されたSFCデータと監視されているSFCデータと共有する必要があります。
The fate sharing, in the SFC environment, is achieved when a test packet traverses the same path and receives the same treatment in the underlay network layer as an SFC-encapsulated packet.
SFC環境での運命共有は、テストパケットが同じパスを横断し、SFCカプセル化されたパケットと同じパスを通過し、アンダーレイネットワークレイヤーで同じ処理を受けると達成されます。
REQ2: SFC OAM MUST support monitoring of the continuity of the SFP between any of its elements.
REQ2：SFC OAMは、その要素のいずれかの間のSFPの連続性の監視をサポートする必要があります。
An SFC failure might be declared when several consecutive test packets are not received within a predetermined time. For example, in the E2E FM SFC OAM case, i.e., the egress, SFF3 (Figure 1) could be the entity that detects the SFP's failure by monitoring a flow of periodic test packets. The ingress may be capable of recovering from the failure, e.g., using redundant SFC elements. Thus, it is beneficial for the egress to signal the new defect state to the ingress, which in this example, is the Classifier, hence, the following requirement:
SFCの障害は、事前に決められた時間内にいくつかの連続したテストパケットが受信されない場合に宣言される場合があります。たとえば、E2E FM SFC OAMケース、つまり出口、SFF3（図1）は、周期的なテストパケットのフローを監視することによりSFPの障害を検出するエンティティである可能性があります。侵入は、冗長なSFC要素を使用して、障害から回復できる場合があります。したがって、出口が新しい欠陥状態を侵入に知らせることが有益です。これは、この例では分類器です。したがって、次の要件があります。
REQ3: SFC OAM MUST support Remote Defect Indication notification by the egress to the ingress.
REQ3：SFC OAMは、侵入への出口によるリモート欠陥の表示通知をサポートする必要があります。
REQ4: SFC OAM MUST support connectivity verification of the SFP. The definitions of the misconnection defect, entry, and exit criteria are outside the scope of this document.
REQ4：SFC OAMは、SFPの接続検証をサポートする必要があります。誤接続の欠陥、エントリ、および出口基準の定義は、このドキュメントの範囲外です。
Once an SFF detects the defect, the objective of the SFC OAM changes from the detection of a defect to defect characterization and localization.
SFFが欠陥を検出すると、SFC OAMの目的は、欠陥の検出から欠陥の特性評価と局在に変わります。
REQ5: SFC OAM MUST support fault localization of the loss of continuity check within an SFP.
REQ5：SFC OAMは、SFP内の連続性チェックの損失の障害のローカリゼーションをサポートする必要があります。
REQ6: SFC OAM MUST support an SFP tracing to discover the RSP.
REQ6：SFC OAMは、RSPを発見するためにSFPトレースをサポートする必要があります。
In the example presented in Figure 1, two distinct instances of the same SF share the same SFF. In this example, the SFP can be realized over several RSPs that use different instances of the SF of the same type, for instance, RSP1(SFI11--SFI21--SFI31) and RSP2(SFI12--SFI22-- SFI32). Available RSPs can be discovered using the trace function discussed in Section 4.3 of [RFC8924] or the procedure defined in Section 6.5.4.
図1に示す例では、同じSFの2つの異なるインスタンスが同じSFFを共有しています。この例では、SFPは、同じタイプのSFの異なるインスタンスを使用するいくつかのRSPで実現できます。たとえば、RSP1（SFI11 - SFI21 - SFI31）およびRSP2（SFI12-SFI22-- SFI32）。利用可能なRSPは、[RFC8924]のセクション4.3で説明したトレース関数またはセクション6.5.4で定義された手順を使用して発見できます。
REQ7: SFC OAM MUST have the ability to discover and exercise all available RSPs in the network.
REQ7：SFC OAMには、ネットワーク内で利用可能なすべてのRSPを発見して行使する機能が必要です。
The SFC OAM layer model described in [RFC8924] offers an approach for defect localization within a service function chain. As the first step, the SFP's continuity for SFFs that are part of the same SFP could be verified. After the reachability of SFFs has already been verified, SFFs that serve an SF may be used as a test packet source. In such a case, an SFF can act as a proxy for another element within the service function chain.
[RFC8924]で説明されているSFC OAM層モデルは、サービス機能チェーン内の欠陥局在化のアプローチを提供します。最初のステップとして、同じSFPの一部であるSFFに対するSFPの連続性を検証できます。SFFの到達可能性がすでに検証された後、SFを提供するSFFはテストパケットソースとして使用できます。そのような場合、SFFはサービス関数チェーン内の別の要素のプロキシとして機能します。
REQ8: SFC OAM MUST be able to trigger on-demand FM remotely with responses being directed toward the initiator of the remote request.
REQ8：SFC OAMは、リモートリクエストのイニシエーターに向けられた応答をリモートでオンデマンドFMをリモートでトリガーできる必要があります。
The conformance of the SFC Echo Request/Reply mechanism to these requirements is reflected below:
これらの要件に対するSFCエコー要求/返信メカニズムの適合性を以下に示します。
REQ1: Fate sharing via the SFC Echo Request/Reply defined in Section 6.
Req1：セクション6で定義されているSFCエコーリクエスト/返信を介した運命共有。
REQ2: Continuity monitoring via the SFP tracing defined in Section 6.5.4.
REQ2：セクション6.5.4で定義されたSFPトレースを介した連続性モニタリング。
REQ3: Remote defect detection via the SFC Echo Request/Reply defined in Section 6.
REQ3：セクション6で定義されているSFCエコー要求/返信を介したリモート欠陥検出。
REQ4: Connectivity verification via the SFP tracing defined in Section 6.5.4.
REQ4：セクション6.5.4で定義されたSFPトレースを介した接続検証。
REQ5: Fault localization via verification of the SFP consistency defined in Section 6.6.
REQ5：セクション6.6で定義されたSFP一貫性の検証による障害のローカリゼーション。
REQ6: SFP tracing as described in Section 6.5.4 and verification of SFP consistency as defined in Section 6.6.
REQ6：セクション6.5.4で説明されているSFPトレースおよびセクション6.6で定義されているSFP一貫性の検証。
REQ7: Discover and exercise available RSPs via trace defined in Section 6.5.4.
Req7：セクション6.5.4で定義されたトレースを介して利用可能なRSPを発見および運動します。
REQ8: Can be addressed by adding the proxying capability to the SFC Echo Request/Reply described in this document. [RFC7555] describes an example of a proxy function for an Echo Request. Specification of a proxy function for SFC Echo Request is outside the scope of this document.
REQ8：このドキュメントで説明されているSFCエコーリクエスト/返信にプロキシ機能を追加することで対処できます。[RFC7555]は、エコー要求のプロキシ関数の例を説明しています。SFCエコー要求のプロキシ関数の指定は、このドキュメントの範囲外です。
SFC active OAM combines OAM commands and/or data included in a message that immediately follows the NSH. To identify the SFC active OAM message, the Next Protocol field MUST be set to SFC Active OAM (0x07) (Section 9.1). The O bit in the NSH MUST be set, according to [RFC9451]. A case when the O bit is clear and the Next Protocol field value is set to SFC Active OAM (0x07) is considered an erroneous combination. An implementation MUST report it. Although the notification mechanism is outside the scope of this specification, note that it MUST include rate-limiting control. The packet SHOULD be dropped. An implementation MAY have control to enable the processing of the OAM payload.
SFC Active OAMは、NSHの直後のメッセージに含まれるOAMコマンドおよび/またはデータを組み合わせます。SFC Active OAMメッセージを特定するには、次のプロトコルフィールドをSFC Active OAM（0x07）（セクション9.1）に設定する必要があります。[RFC9451]に従って、NSHのOビットを設定する必要があります。O BITが明確で、次のプロトコルフィールド値がSFC Active OAM（0x07）に設定されている場合、誤った組み合わせと見なされます。実装はそれを報告する必要があります。通知メカニズムはこの仕様の範囲外ですが、レート制御制御を含める必要があることに注意してください。パケットをドロップする必要があります。実装には、OAMペイロードの処理を有効にするための制御がある場合があります。
SFC OAM is required to perform multiple tasks. Several active OAM protocols could be used to address all the requirements. When IP/UDP encapsulation of an SFC OAM control message is used, protocols can be demultiplexed using the destination UDP port number. But an extra IP/UDP header, especially in an IPv6 network, adds overhead compared to the length of an Active OAM Control Packet (e.g., BFD Control packet [RFC5880]). In some environments, for example, when measuring performance metrics, it is beneficial to transmit OAM packets in a broad range of lengths to emulate application traffic closer. This document defines an Active OAM Header (Figure 2) to demultiplex active OAM protocols on SFC.
SFC OAMは、複数のタスクを実行するために必要です。いくつかのアクティブなOAMプロトコルを使用して、すべての要件に対処できます。SFC OAMコントロールメッセージのIP/UDPカプセル化が使用されると、宛先UDPポート番号を使用してプロトコルを非難することができます。しかし、特にIPv6ネットワークでの追加のIP/UDPヘッダーは、アクティブなOAMコントロールパケットの長さと比較してオーバーヘッドを追加します（例：BFDコントロールパケット[RFC5880]）。たとえば、パフォーマンスメトリックを測定する場合、一部の環境では、OAMパケットを広範囲の長さで送信して、アプリケーショントラフィックをより近くにエミュレートすることが有益です。このドキュメントでは、SFCでアクティブなOAMプロトコルをDemultiplexにするアクティブなOAMヘッダー（図2）を定義しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Msg Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SFC Active OAM Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFC Active OAM Header
図2：SFCアクティブOAMヘッダー
V -
V-
a four-bit field that indicates the current version of the SFC Active OAM Header. The current value is 0. The version number is to be incremented whenever a change is made that affects the ability of an implementation to parse or process the SFC Active OAM Header correctly, for example, if syntactic or semantic changes are made to any of the fixed fields.
SFC Active OAMヘッダーの現在のバージョンを示す4ビットフィールド。現在の値は0です。バージョン番号は、実装がSFCアクティブOAMヘッダーを正しく処理または処理する能力に影響する変更が行われるたびに増分することです。固定フィールド。
Msg Type -
MSGタイプ -
a six-bit field that identifies the OAM protocol, e.g., the Echo Request/Reply.
OAMプロトコルを識別する6ビットフィールド、たとえば、エコーリクエスト/返信。
Reserved -
予約済み -
a six-bit field. It MUST be zeroed on transmission and ignored on receipt.
6ビットフィールド。送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
a two-octet field that is the length of the SFC Active OAM Control Packet in octets.
オクテットのSFCアクティブOAMコントロールパケットの長さである2オクセットフィールド。
The Echo Request/Reply is a well-known active OAM mechanism extensively used to verify a path's continuity, detect inconsistencies between a state in control and the data planes, and localize defects in the data plane. ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6 networks) and MPLS [RFC8029] are examples of broadly used active OAM protocols based on the Echo Request/Reply principle. The SFC Echo Request/Reply control message (format is presented in Figure 3) is an instance of the SFC Active OAM Control Packet that is a part of the SFC Active OAM Header (Figure 2).
エコーリクエスト/返信は、パスの連続性を検証し、制御状態とデータプレーンの間の矛盾を検出し、データプレーンの欠陥を局在化するために広範囲に使用されるよく知られているアクティブなOAMメカニズムです。IPv4および[RFC4443]のICMP（[RFC0792]および[RFC4443] IPv6ネットワークの[RFC443]およびMPLS [RFC8029]は、ECHO要求/返信原則に基づいて広く使用されているアクティブOAMプロトコルの例です。SFCエコーリクエスト/返信制御メッセージ（フォーマットは図3に示されています）は、SFCアクティブOAMヘッダーの一部であるSFCアクティブOAM制御パケットのインスタンスです（図2）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Echo Request Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Echo Type | Reply Mode | Return Code |Return Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFC Echo Request/Reply Format
図3：SFCエコーリクエスト/返信形式
The interpretation of the fields is as follows:
フィールドの解釈は次のとおりです。
Echo Request Flags -
エコーリクエストフラグ -
a two-octet bit vector field. Section 9.2.2 requests IANA to create a new registry for flags. This specification defines all flags for future use. Flags MUST be zeroed on transmission and ignored on receipt.
2オクテットのビットベクトルフィールド。セクション9.2.2は、IANAにフラグの新しいレジストリを作成するよう要求します。この仕様は、将来の使用のためにすべてのフラグを定義します。フラグは送信時にゼロになり、受領時に無視する必要があります。
Reserved -
予約済み -
a two-octet field. It MUST be zeroed on transmission and ignored on receipt.
2オクテットのフィールド。送信時にゼロになり、受領時に無視する必要があります。
Echo Type -
エコータイプ -
a one-octet field that reflects the packet type. SFC Echo Request/Reply Echo Types, defined in this document, are listed in Section 9.2.3.
パケットタイプを反映する1オクセットフィールド。このドキュメントで定義されているSFCエコーリクエスト/返信エコータイプは、セクション9.2.3にリストされています。
Reply Mode -
返信モード -
a one-octet field. It defines the type of the return path requested by the sender of the Echo Request.
ワンオクテットフィールド。エコーリクエストの送信者が要求したリターンパスのタイプを定義します。
Return Code and Return Subcode -
コードを返し、サブコードを返します -
one-octet fields each. These can be used to inform the sender about the result of processing its request. For all Return Code values defined in this document (Section 9.2.5), the value of the Return Subcode field MUST be set to zero.
それぞれ1オクセットフィールド。これらは、リクエストの処理の結果について送信者に通知するために使用できます。このドキュメント（セクション9.2.5）で定義されているすべての返品コード値について、返品サブコードフィールドの値をゼロに設定する必要があります。
Sender's Handle -
送信者のハンドル -
a four-octet field. It MUST be filled in by the sender of the Echo Request and returned unchanged by the Echo Reply sender (if a reply is being sent). The sender of the Echo Request SHOULD use a pseudorandom number generator [RFC4086] to set the value of the Sender's Handle field. In some use cases, an implementation MAY use the Sender's Handle for proprietary signaling as long as the system that receives the SFC Echo Request doesn't alter the value of the Sender's Handle field but copies it into the SFC Echo Reply.
4オクテットのフィールド。エコーリクエストの送信者が記入し、エコー応答送信者によって変更されずに返される必要があります（返信が送信されている場合）。Echo要求の送信者は、擬似ランダム番号ジェネレーター[RFC4086]を使用して、送信者のハンドルフィールドの値を設定する必要があります。一部のユースケースでは、SFCエコー要求を受信するシステムが送信者のハンドルフィールドの値を変更しない限り、SFCエコー応答にコピーする限り、実装は独自の信号に送信者のハンドルを使用する場合があります。
Sequence Number -
シーケンス番号 -
a four-octet field. It is assigned by the sender and can be, for example, used to detect missed replies. The initial Sequence Number contains an unsigned integer that wraps around. It MUST be pseudorandomly generated [RFC4086] and then SHOULD be monotonically increasing in the course of the test session. If a reply is sent, the sender of the SFC Echo Reply message MUST copy the value from the received SFC Echo Request.
4オクテットのフィールド。これは送信者によって割り当てられており、たとえば見逃した返信を検出するために使用できます。初期シーケンス番号には、包む署名のない整数が含まれています。それは擬似ランダムに生成され[RFC4086]、テストセッションの過程で単調に増加する必要があります。返信が送信された場合、SFCエコー応答メッセージの送信者は、受信したSFCエコーリクエストから値をコピーする必要があります。
TLV is a variable-length construct whose length is multiple four-octet words. Multiple TLVs MAY be placed in an SFC Echo Request/ Reply packet. None, one, or more sub-TLVs may be enclosed in the value part of a TLV, subject to the semantics of the (outer) TLV. If no TLVs are included in an SFC Echo Request/Reply, the value of the Length field in the SFC Active OAM Header MUST be 16 octets. Figure 4 presents the format of an SFC Echo Request/Reply TLV, where the fields are defined as follows:
TLVは、長さが複数の4オクテットワードである可変長コンストラクトです。複数のTLVをSFCエコーリクエスト/返信パケットに配置できます。（外側の）TLVのセマンティクスを条件として、TLVの値部分に囲まれている場合、1つ以上のサブTLVが囲まれている場合があります。SFCエコーリクエスト/返信にTLVが含まれていない場合、SFC Active OAMヘッダーの長さフィールドの値は16オクテットでなければなりません。図4は、SFCエコーリクエスト/返信TLVの形式を示しています。フィールドは次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SFC Echo Request/Reply TLV Format
図4：SFCエコーリクエスト/返信TLV形式
Type -
タイプ -
a one-octet field that characterizes the interpretation of the Value field. Type values are allocated according to Section 9.2.6.
値フィールドの解釈を特徴付ける1オクセットフィールド。タイプ値は、セクション9.2.6に従って割り当てられます。
Reserved -
予約済み -
a one-octet field. The field MUST be zeroed on transmission and ignored on receipt.
ワンオクテットフィールド。フィールドは送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
a two-octet field equal to the Value field's length in octets as an unsigned integer.
署名されていない整数としてのオクテットの値フィールドの長さに等しい2オクセットフィールド。
Value -
価値 -
a variable-length field. The value of the Type field determines its interpretation and encoding.
可変長いフィールド。タイプフィールドの値は、その解釈とエンコーディングを決定します。
The value of the Return Code field MUST be set to zero by the sender of an Echo Request. The receiver of said Echo Request MUST set it to one of the values in IANA's "SFC Echo Return Codes" registry (Section 9.2.5) in the corresponding Echo Reply that it generates.
エコーリクエストの送信者によって、返品コードフィールドの値をゼロに設定する必要があります。上記のエコー要求の受信者は、それを生成する対応するエコー応答のIANAの「SFCエコーリターンコード」レジストリ（セクション9.2.5）の値の1つに設定する必要があります。
Authentication can be used to protect the integrity of the information in the SFC Echo Request and/or Echo Reply. In [RFC9145], a variable-length Context Header has been defined to protect the integrity of the NSH and the payload. The header can also be used for the optional encryption of sensitive metadata. The MAC#1 Context Header is more suitable for the integrity protection of SFC active OAM, particularly of the SFC Echo Request and Echo Reply, as defined in this document. On the other hand, using the MAC#2 Context Header allows the detection of mishandling of the O bit by a transient SFC element.
認証を使用して、SFCエコーリクエストおよび/またはエコー応答の情報の整合性を保護できます。[RFC9145]では、NSHとペイロードの完全性を保護するために、可変長さのコンテキストヘッダーが定義されています。ヘッダーは、機密メタデータのオプションの暗号化にも使用できます。MAC＃1コンテキストヘッダーは、このドキュメントで定義されているように、SFCアクティブOAM、特にSFCエコーリクエストとエコー応答の整合性保護により適しています。一方、MAC＃2コンテキストヘッダーを使用すると、過渡的なSFC要素によるOビットの誤解を検出できます。
The SFC Echo Request control packet MUST use the appropriate underlay network encapsulation of the monitored SFP. The Echo Request MUST set the O bit in the NSH, as defined in [RFC9451]. The NSH MUST be immediately followed by the SFC Active OAM Header defined in Section 4. The Echo Type field's value in the SFC Active OAM Header MUST be set to the SFC Echo Request/Reply value (1), per Section 9.2.1.
SFCエコーリクエスト制御パケットは、監視されているSFPの適切なアンダーレイネットワークカプセル化を使用する必要があります。[RFC9451]で定義されているように、エコー要求はNSHにOビットを設定する必要があります。NSHは、セクション4で定義されたSFCアクティブOAMヘッダーがすぐに続く必要があります。SFCアクティブOAMヘッダーのエコータイプフィールドの値は、セクション9.2.1ごとにSFCエコーリクエスト/返信値（1）に設定する必要があります。
The value of the Reply Mode field MUST be set to one of the following:
応答モードフィールドの値は、次のいずれかに設定する必要があります。
Do Not Reply (1) -
返信しないでください（1） -
This is the value if one-way monitoring is desired. If the Echo Request is used to measure synthetic packet loss, the receiver may report loss measurement results to a remote node. Ways of learning the identity of that node are outside the scope of this specification.
これは、一元配置監視が必要な場合の値です。エコー要求を使用して合成パケット損失を測定する場合、受信機はリモートノードに損失測定結果を報告する場合があります。そのノードのアイデンティティを学習する方法は、この仕様の範囲外です。
Reply via an IPv4/IPv6 UDP Packet (2) -
IPv4/IPv6 UDPパケット（2）を介して返信
If an SFC Echo Request is not encapsulated in IP/UDP, then this value requests the use of the Source ID TLV Section 6.3.1).
SFCエコー要求がIP/UDPにカプセル化されていない場合、この値はソースID TLVセクション6.3.1の使用を要求します。
Reply via Specified Path (4) -
指定されたパス（4）を介して返信 -
This value requests the use of the particular return path specified in the included TLV to verify bidirectional continuity and may also increase the robustness of the monitoring by selecting a more stable path. Section 6.5.1 provides an example of communicating an explicit path for the Echo Reply.
この値は、付属のTLVで指定された特定のリターンパスを使用して双方向の連続性を検証することを要求し、より安定したパスを選択することで監視の堅牢性を高める可能性があります。セクション6.5.1は、エコー応答の明示的なパスを通信する例を示します。
Reply via an IPv4/IPv6 UDP Packet with the data integrity protection (5) -
データ整合性保護（5）を使用してIPv4/IPv6 UDPパケットを介して返信します -
This value requests the use of the MAC Context Header [RFC9145].
この値は、MACコンテキストヘッダー[RFC9145]の使用を要求します。
Reply via Specified Path with the data integrity protection (7) -
データ整合性保護（7）を使用して指定されたパス経由で返信します -
This value requests the use of the MAC Context Header [RFC9145].
この値は、MACコンテキストヘッダー[RFC9145]の使用を要求します。
The responder to the SFC Echo Request encapsulates the SFC Echo Reply message in the IP/UDP packet if the Reply Mode is "Reply via an IPv4/ IPv6 UDP Packet" or "Reply via an IPv4/IPv6 UDP Packet with the data integrity protection". Because the NSH does not identify the ingress node that generated the Echo Request, information that sufficiently identifies the source MUST be included in the message so that the IP destination address and destination UDP port number for IP/UDP encapsulation of the SFC Echo Reply could be derived. The sender of the SFC Echo Request MUST include the Source ID TLV (Figure 5).
SFCエコーリクエストへのレスポンダーは、IP/UDPパケットのSFCエコー応答メッセージをカプセル化します。返信モードが「IPv4/IPv6 UDPパケットを介して返信」または「データ整合性保護を備えたIPv4/IPv6 UDPパケットを介して返信」。NSHはエコー要求を生成したイングレスノードを識別しないため、SFCエコーの返信のIP/UDPカプセル化のIP宛先アドレスと宛先UDPポート番号が表示されるように、ソースを十分に識別する情報をメッセージに含める必要があるため、派生。SFCエコー要求の送信者には、ソースID TLVを含める必要があります（図5）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | Reserved1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SFC Source ID TLV
図5：SFCソースID TLV
The fields are defined as follows:
フィールドは次のように定義されています。
Source ID -
ソースID-
the value MUST be set to 1 (Section 9.2.6).
値は1（セクション9.2.6）に設定する必要があります。
Reserved1 -
予約1-
a one-octet field. The field MUST be zeroed on transmission and ignored on receipt.
ワンオクテットフィールド。フィールドは送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
the value equals the length of the data following the Length field counted in octets. The value of the Length field can be 8 or 20. If the value of the field is neither, the Source ID TLV is considered to be malformed.
値は、オクテットでカウントされた長さフィールドに続くデータの長さに等しくなります。長さフィールドの値は8または20になります。フィールドの値がいずれでもない場合、ソースID TLVは奇形と見なされます。
Port Number -
ポート番号 -
a two-octet field. It contains the UDP port number of the sender of the SFC OAM control message. The value of the field MUST be used as the destination UDP port number in the IP/UDP encapsulation of the SFC Echo Reply message.
2オクテットのフィールド。SFC OAMコントロールメッセージの送信者のUDPポート番号が含まれています。フィールドの値は、SFCエコー応答メッセージのIP/UDPカプセル化の宛先UDPポート番号として使用する必要があります。
Reserved2 -
予約2-
a two-octet field. The field MUST be zeroed on transmit and ignored on receipt.
2オクテットのフィールド。フィールドは送信時にゼロになり、受領時に無視する必要があります。
IP Address -
IPアドレス -
a field that contains the IP address of the sender of the SFC OAM control message, i.e., IPv4 or IPv6. The value of the field MUST be used as the destination IP address in the IP/UDP encapsulation of the SFC Echo Reply message.
SFC OAMコントロールメッセージの送信者のIPアドレス、つまりIPv4またはIPv6を含むフィールド。フィールドの値は、SFCエコー応答メッセージのIP/UDPカプセル化の宛先IPアドレスとして使用する必要があります。
A single Source ID TLV for each address family, i.e., IPv4 and IPv6, MAY be present in an SFC Echo Request message. If the Source ID TLVs for both address families are present in an SFC Echo Request message, the SFF MUST NOT replicate an SFC Echo Reply but choose the destination IP address for the one SFC Echo Reply it sends based on the local policy. The source IP address used in the IP/UDP encapsulation of the SFC Echo Reply is one of the IP addresses associated with the responder. The value of the Port Number field MUST be used as the destination UDP port number in the IP/UDP encapsulation of the SFC Echo Reply message. The responder selects the source UDP port number from the dynamic range of port numbers. If more than one Source ID TLV per the address family is present, the receiver MUST use the first TLV and ignore the rest. The Echo Reply message, including relevant TLVs, follows the IP/UDP headers immediately.
各アドレスファミリ、つまりIPv4およびIPv6の単一ソースID TLVは、SFCエコー要求メッセージに存在する場合があります。両方のアドレスファミリのソースID TLVがSFCエコーリクエストメッセージに存在する場合、SFFはSFCエコー返信を再現しないでください。SFCエコー応答のIP/UDPカプセル化で使用されるソースIPアドレスは、レスポンダーに関連付けられたIPアドレスの1つです。ポート番号フィールドの値は、SFCエコー応答メッセージのIP/UDPカプセル化の宛先UDPポート番号として使用する必要があります。レスポンダーは、ポート番号のダイナミックレンジからソースUDPポート番号を選択します。アドレスファミリごとに複数のソースID TLVが存在する場合、受信者は最初のTLVを使用し、残りを無視する必要があります。関連するTLVを含むEcho Replyメッセージは、IP/UDPヘッダーにすぐに続きます。
Punting a received SFC Echo Request to the control plane for validation and processing is triggered by one of the following packet processing exceptions: NSH TTL expiration, NSH Service Index expiration, or the receiver is the terminal SFF for an SFP.
検証と処理のためにコントロールプレーンに受信したSFCエコーリクエストをパンすることは、次のパケット処理の例外のいずれかによってトリガーされます。NSHTTLの有効期限、NSHサービスインデックスの有効期限、または受信機はSFPの端末SFFです。
An SFF that received the SFC Echo Request MUST validate the packet as follows:
SFCエコーリクエストを受け取ったSFFは、次のようにパケットを検証する必要があります。
1. If the SFC Echo Request is integrity protected, the receiving SFF first MUST verify the authentication.
1. SFCエコー要求が整合性保護されている場合、受信SFFは最初に認証を検証する必要があります。
1.1. Suppose the authentication validation has failed and the Source ID TLV is considered properly formatted. In that case, the SFF MUST send an SFC Echo Reply with the Return Code set to 3 ("Authentication failed") and the Subcode set to zero to the system identified in the Source ID TLV (see Section 6.5), according to a rate-limit control mechanism.
1.1. 認証検証が失敗し、ソースID TLVが適切にフォーマットされていると見なされるとします。その場合、SFFは、RETURN CODEを3（「認証が失敗した」）に設定されたSFCエコー応答を送信する必要があり、サブコードはソースID TLVで識別されたシステムにゼロに設定されています（セクション6.5を参照）。-limit制御メカニズム。
1.2. If the authentication is validated successfully, the SFF that has received an SFC Echo Request verifies the rest of the packet's general consistency.
1.2. 認証が正常に検証された場合、SFCエコーリクエストを受信したSFFは、パケットの一般的な一貫性の残りの部分を検証します。
1. Validate the Source ID TLV, as defined in Section 6.3.1.
1. セクション6.3.1で定義されているように、ソースID TLVを検証します。
2.1. If the Source ID TLV is determined to be malformed, the received SFC Echo Request processing is stopped, the message is dropped, and the event SHOULD be logged, according to a rate-limiting control for logging.
2.1. ソースID TLVが奇形であると判断された場合、受信したSFCエコー要求処理が停止し、メッセージが削除され、ログのレート制御コントロールに従ってイベントを記録する必要があります。
3. The Sender's Handle and Sequence Number fields are not examined but are copied in the SFC Echo Reply message.
3. 送信者のハンドルとシーケンス番号フィールドは検査されませんが、SFCエコー応答メッセージにコピーされます。
4. If the packet is not well formed, i.e., not formed according to this specification, the receiving SFF SHOULD send an SFC Echo Reply with the Return Code set to 1 ("Malformed Echo Request received") and the Subcode set to zero under the control of the rate-limiting mechanism to the system identified in the Source ID TLV (see Section 6.5).
4. パケットが十分に形成されていない場合、つまりこの仕様に従って形成されていない場合、受信SFFは1（「不正なエコーリクエストを受信した」）に設定されたreturnコードを使用してSFCエコー応答を送信する必要があります。ソースID TLVで特定されたシステムに対するレート制限メカニズムの（セクション6.5を参照）。
5. If there are any TLVs that the SFF does not understand, the SFF MUST send an SFC Echo Reply with the Return Code set to 2 ("One or more of the TLVs was not understood") and set the Subcode to zero. Also, the SFF MAY include an Errored TLVs TLV (Section 6.4.1) that, as sub-TLVs, contains only the misunderstood TLVs.
5. SFFが理解していないTLVがある場合、SFFはSFCエコーの返信を2（「1つ以上のTLVは理解されていません」）を2に設定し、サブコードをゼロに設定する必要があります。また、SFFには、サブTLVとして誤解されているTLVのみが含まれるエラーされたTLVS TLV（セクション6.4.1）が含まれる場合があります。
6. If the consistency check of the received Echo Request succeeded, i.e., the Echo Request is deemed properly formed, then the SFF at the end of the SFP MUST send an SFC Echo Reply with the Return Code set to 5 ("End of the SFP") and the Subcode set to zero.
6. 受信したエコーリクエストの一貫性チェックが成功した場合、つまりエコー要求が適切に形成されているとみなされた場合、SFPの最後のSFFは、5（「SFPの終わり」に設定された戻りコードでSFCエコー応答を送信する必要があります。）およびサブコードはゼロに設定されています。
7. If the SFF is not at the end of the SFP and the NSH TTL value is 1, the SFF MUST send an SFC Echo Reply with the Return Code set to 4 ("SFC TTL Exceeded") and the Subcode set to zero.
7. SFFがSFPの終わりになく、NSH TTL値が1の場合、SFFはSFCエコー応答を4（ "SFC TTLを超えた"）に設定し、サブコードをゼロに設定する必要があります。
8. In all other cases, for the validated Echo Request message, a transit, i.e., not at the end of the SFP, SFF MUST send an SFC Echo Reply with the Return Code set to 0 ("No Error") and the Subcode set to zero.
8. 他のすべてのケースでは、検証済みのエコー要求メッセージ、トランジット、つまりSFPの終わりではない場合、SFFはreturem codeを0（ "error"）に設定し、サブコードをに設定してSFCエコー応答を送信する必要があります。ゼロ。
If the Return Code for the Echo Reply is determined as 2 ("One or more of the TLVs was not understood"), the Errored TLVs TLV might be included in an Echo Reply. The use of this TLV is meant to inform the sender of an Echo Request of TLVs either not supported by an implementation or parsed and found to be in error.
エコー応答の返されたコードが2（「TLVの1つ以上が理解されていない」）として決定される場合、エラーされたTLVS TLVがエコー応答に含まれる可能性があります。このTLVの使用は、実装によってサポートされていないか、誤っていることが判明したTLVのエコー要求を送信者に通知することを目的としています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Errored TLVs | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Errored TLVs TLV
図6：エラーTLVS TLV
The fields are defined as follows:
フィールドは次のように定義されています。
Errored TLVs -
エラーされたTLVS-
the field MUST be set to 2 (Section 9.2.6).
フィールドは2（セクション9.2.6）に設定する必要があります。
Reserved -
予約済み -
the field MUST be zeroed on transmission and ignored on receipt.
フィールドは送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
the value equals to length of the Value field in octets.
値は、オクテットの値フィールドの長さに等しくなります。
Value -
価値 -
the field contains the TLVs, encoded as sub-TLVs (as shown in Figure 7), that were not understood or failed to be parsed correctly.
このフィールドには、サブTLVとしてエンコードされたTLVが含まれています（図7に示すように）、理解されていないか、正しく解析されなかった。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Reserved | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLV Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Not Understood or Failed TLV as a Sub-TLV
図7：サブTLVとしてTLVが理解されていないか失敗していない
The fields are defined as follows:
フィールドは次のように定義されています。
Sub-TLV Type -
sub -tlvタイプ -
a copy of the first octet of the TLV that is not understood or failed to be parsed.
理解されていない、または解析されないTLVの最初のオクテットのコピー。
Reserved -
予約済み -
MUST be zeroed on transmission and ignored on receipt.
送信時にゼロになり、受領時に無視する必要があります。
Sub-TLV Length -
サブTLV長さ -
the value equals the value of the Length field of the errored TLV.
値は、エラーされたTLVの長さフィールドの値に等しくなります。
Sub-TLV Value -
サブTLV値 -
the field contains data that follows the Length field in the errored TLV.
フィールドには、エラーされたTLVの長さフィールドに従うデータが含まれています。
The Reply Mode field directs whether and how the Echo Reply message should be sent. The Echo Request sender MAY use TLVs to request that the corresponding Echo Reply be transmitted over the specified path. For example, a TLV that specifies the return path of the Echo Reply if the Return Mode in the Echo Request is set to Reply via Specified Path (4) is described in Section 6.5.1. Value 1 is the "Do Not Reply" mode and suppresses the Echo Reply packet transmission. The value 2 of the Reply Mode field requests sending the Echo Reply packet out-of-band as an IPv4/IPv6 UDP packet.
返信モードフィールドは、Echo Replyメッセージを送信するかどうか、および方法を指示します。エコーリクエスト送信者は、TLVを使用して、対応するエコー応答を指定されたパス上に送信するよう要求する場合があります。たとえば、エコー要求のリターンモードが指定されたパス（4）を介して返信するように設定されている場合、エコー応答のリターンパスを指定するTLVは、セクション6.5.1で説明されています。値1は「返信しない」モードであり、エコー応答パケット送信を抑制します。Reply Modeフィールドの値2は、IPv4/IPv6 UDPパケットとしてEcho Reply Packetを送信します。
While the SFC Echo Request always traverses the SFP it is directed to by using the NSH, the corresponding Echo Reply usually is sent without the NSH. In some cases, an operator might choose to direct the responder to send and Echo Reply with the NSH over a particular SFP. This section defines a new TLV, i.e., Reply Service Function Path TLV, for Reply via Specified Path mode of the SFC Echo Reply.
SFCエコー要求は常にSFPを横断しますが、NSHを使用することで指示されますが、対応するエコー応答は通常NSHなしで送信されます。場合によっては、オペレーターは、特定のSFPを介してNSHに応答を送信してエコーするように応答者に指示することを選択する場合があります。このセクションでは、SFCエコー応答の指定されたパスモードを介して返信するために、新しいTLV、つまり応答サービス機能パスTLVを定義します。
The Reply Service Function Path TLV can provide an efficient mechanism to test SFCs, such as bidirectional and hybrid SFC, as defined in Section 2.2 of [RFC7665]. For example, it allows an operator to test both directions of the bidirectional or hybrid SFP with a single SFC Echo Request/Reply operation.
Reply Service Function Path TLVは、[RFC7665]のセクション2.2で定義されているように、双方向SFCやハイブリッドSFCなどのSFCをテストするための効率的なメカニズムを提供できます。たとえば、オペレーターは、単一のSFCエコーリクエスト/返信操作を使用して、双方向またはハイブリッドSFPの両方向をテストできます。
The Reply Service Function Path TLV carries the information that sufficiently identifies the return SFP that the SFC Echo Reply message is expected to follow. The format of Reply Service Function Path TLV is shown in Figure 8.
Reply Service Function Path TLVには、SFCエコーの返信メッセージが従うと予想されるリターンSFPを十分に識別する情報が含まれます。Reply Service Function Path TLVの形式を図8に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply SFP | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Service Function Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SFC Reply TLV Format
図8：SFC応答TLV形式
The fields are defined as follows:
フィールドは次のように定義されています。
Reply SFP (3) -
返信SFP（3） -
identifies the TLV that contains information about the SFC Reply path.
SFC応答パスに関する情報を含むTLVを識別します。
Reserved -
予約済み -
MUST be zeroed on transmission and ignored on receipt.
送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
the value MUST be equal to 4.
値は4に等しくなければなりません。
Reply Service Function Path Identifier -
返信サービス関数パス識別子 -
a three-octet field that contains the SFP identifier for the path that the SFC Echo Reply message is requested to be sent over.
SFCエコー応答メッセージが送信されるように要求されるパスのSFP識別子を含む3オクテットのフィールド。
Service Index -
サービスインデックス -
a one-octet field. The value is set to the value of the Service Index field in the NSH of the SFC Echo Reply message.
ワンオクテットフィールド。値は、SFCエコー応答メッセージのNSHのサービスインデックスフィールドの値に設定されます。
[RFC7110] defines a mechanism to control the return path for the MPLS Label Switched Path (LSP) Echo Reply. In the SFC's case, the return path is an SFP along which the SFC Echo Reply message MUST be transmitted. Hence, the Reply Service Function Path TLV included in the SFC Echo Request message MUST sufficiently identify the SFP that the sender of the Echo Request message expects the receiver to use for the corresponding SFC Echo Reply.
[RFC7110]は、MPLSラベルスイッチ付きパス（LSP）エコー応答のリターンパスを制御するメカニズムを定義します。SFCの場合、リターンパスはSFPであり、SFCエコー応答メッセージを送信する必要があります。したがって、SFCエコーリクエストメッセージに含まれるReply Service Function Path TLVは、Echo要求メッセージの送信者が受信者が対応するSFCエコー応答に使用することを期待するSFPを十分に識別する必要があります。
When sending an Echo Request, the sender MUST set the value of the Reply Mode field to "Reply via Specified Path", defined in Section 6.3, and if the specified path is an SFC path, the Request MUST include the Reply Service Function Path TLV. The Reply Service Function Path TLV consists of the identifier of the reverse SFP and an appropriate Service Index.
エコー要求を送信するとき、送信者は、セクション6.3で定義されている「指定されたパスを介して応答」に応答モードフィールドの値を設定する必要があり、指定されたパスがSFCパスである場合、リクエストには応答サービス機能パスTLVを含める必要があります。。Reply Service Function Path TLVは、逆SFPの識別子と適切なサービスインデックスで構成されています。
If the NSH of the received SFC Echo Request includes the MAC Context Header, the packet's authentication MUST be verified before using any data, as defined in Section 6.4.
受信したSFCエコー要求のNSHにMacコンテキストヘッダーが含まれている場合、セクション6.4で定義されているように、データを使用する前にパケットの認証を検証する必要があります。
The destination SFF of the SFP being tested and the SFF at which the NSH TTL expired (as per [RFC8300]) are referred to as responding SFFs. The processing described below equally applies to both cases.
テストされているSFPの宛先SFFとNSH TTLの有効期限が切れたSFF（[RFC8300]による）は、応答するSFFと呼ばれます。以下に説明する処理は、両方のケースに等しく適用されます。
If the Echo Request message with the Reply Service Function Path TLV received by the responding SFF has the Reply Mode value of "Reply via Specified Path" but no Reply Service Function Path TLV is present, then the responding SFF MUST send an Echo Reply with the Return Code set to 6 ("Reply Service Function Path TLV is missing"). If the responding SFF cannot find the requested SFP, it MUST send an Echo Reply with the Return Code set to 7 ("Reply SFP was not found") and include the Reply Service Function Path TLV from the Echo Request message.
応答するSFFが受信した返信サービス関数パスTLVを使用したエコー要求メッセージには、「指定されたパス経由の返信」の応答モード値があるが、返信サービスパスTLVが存在しない場合、応答するSFFはエコー応答を送信する必要があります。return code set set 6（ "Reply Service Function Path TLVがありません"）。応答するSFFが要求されたSFPを見つけることができない場合、return Codeを7に設定してエコー応答を送信する必要があります（「Reply SFPは見つかりませんでした」）。
Suppose the SFC Echo Request receiver cannot determine whether the specified return path SFP has the route to the initiator. In that case, it SHOULD set the value of the Return Code field to 8 ("Unverifiable Reply Service Function Path"). The receiver MAY drop the Echo Request when it cannot determine whether the SFP's return path has the route to the initiator. When sending the Echo Request, the sender SHOULD choose a proper source address according to the specified return path SFP to help the receiver find the viable return path.
SFCエコーリクエストレシーバーが、指定されたリターンパスSFPがイニシエーターへのルートを持っているかどうかを判断できないとします。その場合、返されるコードフィールドの値を8に設定する必要があります。SFPのリターンパスにイニシエーターへのルートがあるかどうかを判断できない場合、レシーバーはエコーリクエストをドロップする場合があります。エコーリクエストを送信するとき、送信者は、指定されたリターンパスSFPに従って適切なソースアドレスを選択して、受信者が実行可能なリターンパスを見つけるのを支援する必要があります。
The ability to specify the return path for an Echo Reply might be used in the case of bidirectional SFC. The egress SFF of the forward SFP might not be co-located with a classifier of the reverse SFP, and thus, the egress SFF has no information about the reverse path of SFC. Because of that, even for bidirectional SFC, a reverse SFP needs to be indicated in a Reply Service Function Path TLV in the Echo Request message.
エコー応答のリターンパスを指定する機能は、双方向SFCの場合に使用される場合があります。フォワードSFPの出口SFFは、逆SFPの分類器と共同では並んでいない可能性があるため、出口SFFにはSFCの逆パスに関する情報はありません。そのため、双方向SFCであっても、エコー要求メッセージの返信サービス関数パスTLVで逆SFPを示す必要があります。
An SFF SHOULD NOT accept the SFC Echo Reply unless the received message passes the following checks:
SFFは、受信したメッセージが次のチェックに合格しない限り、SFCエコー応答を受け入れないでください。
* the received SFC Echo Reply is well formed;
* 受信したSFCエコー応答はよく形成されています。
* the matching SFC Echo Request is found, that is, the value of the Sender's Handle in the Echo Request sent is equal to the value of Sender's Handle in the Echo Reply received;
* 一致するSFCエコー要求が見つかります。つまり、送信されたエコーリクエストの送信者のハンドルの値は、受信したエコー返信の送信者のハンドルの値に等しくなります。
* the Sequence Number in the Echo Reply received matches the Sequence Number of one of the outstanding transmitted Echo Requests; and
* 受信したエコー応答のシーケンス番号は、未解決の送信されたエコーリクエストの1つのシーケンス番号と一致します。そして
* all other checks passed.
* 他のすべてのチェックが合格しました。
The SFC Echo Request/Reply can be used to isolate a defect detected in the SFP and trace an RSP. As with the ICMP Echo Request/Reply [RFC0792] and the MPLS Echo Request/Reply [RFC8029], this mode is referred to as "traceroute". In the traceroute mode, the sender transmits a sequence of SFC Echo Request messages starting with the NSH TTL value set to 1 and is incremented by 1 in each next Echo Request packet. The sender stops transmitting SFC Echo Request packets when the Return Code in the received Echo Reply equals 5 ("End of the SFP").
SFCエコーリクエスト/返信を使用して、SFPで検出された欠陥を分離し、RSPをトレースできます。ICMPエコーリクエスト/返信[RFC0792]およびMPLSエコーリクエスト/返信[RFC8029]と同様に、このモードは「Traceroute」と呼ばれます。Tracerouteモードでは、送信者は、NSH TTL値が1に設定されているSFCエコーリクエストメッセージのシーケンスを送信し、次のエコーリクエストパケットで1個ずつ増加します。送信者は、受信したエコー応答の返信コードが5（「SFPの終わり」）に等しい場合、SFCエコー要求パケットを送信するのを停止します。
Suppose a specialized information element (e.g., IPv6 Flow Label [RFC6437] or Flow ID [RFC9263]) is used for distributing the load across Equal Cost Multipath or Link Aggregation Group paths. In that case, such an element SHOULD also be used for the SFC OAM traffic. Doing so is meant to induce the SFC Echo Request to follow the same RSP as the monitored flow.
特殊な情報要素（例：IPv6フローラベル[RFC6437]またはフローID [RFC9263]）が、等しいコストマルチパスまたはリンク集約グループパスに負荷を分配するために使用されると仮定します。その場合、そのような要素はSFC OAMトラフィックにも使用する必要があります。そうすることは、監視されたフローと同じRSPをたどるために、SFCエコー要求を誘導することを目的としています。
The consistency of an SFP can be verified by comparing the view of the SFP from the control or management plane with information collected from traversing by an SFC Echo Request/Reply message (Figure 3). The sender of an SFP Consistency Verification Request (CVReq) message MUST set the value of the SFC Echo Request/Reply Echo Type field to 3 ("SFP Consistency Verification Request"). The sender of an SFP Consistency Verification Reply (CVRep) message MUST set the value of the SFC Echo Request/Reply Echo Type field to 4 ("SFP Consistency Verification Reply"). All processing steps of SFC Echo Request and Echo Reply messages described in Sections 6.3 through 6.5 apply to the processing of CVReq and CVRep, respectively.
SFPの一貫性は、SFPのビューをコントロールまたは管理プレーンからのビューと、SFCエコーリクエスト/返信メッセージによってトラバースから収集された情報と比較することで検証できます（図3）。SFP一貫性検証要求（CVREQ）メッセージの送信者は、SFCエコー要求/返信エコータイプフィールドの値を3（「SFP一貫性検証要求」）に設定する必要があります。SFP一貫性検証応答（CVREP）メッセージの送信者は、SFCエコーリクエスト/返信エコータイプフィールドの値を4（「SFP一貫性検証応答」）に設定する必要があります。SFCエコーリクエストとエコーのすべての処理手順は、セクション6.3から6.5で説明されているメッセージをそれぞれCVREQおよびCVREPの処理に適用します。
Every SFF that receives a CVReq message MUST perform the following actions:
CVREQメッセージを受信するすべてのSFFは、次のアクションを実行する必要があります。
* Collect information about the SFs traversed by the CVReq packet and send it to the ingress SFF as a CVRep packet over an IP network.
* CVREQパケットによって通過したSFSに関する情報を収集し、IPネットワーク上のCVREPパケットとしてIngress SFFに送信します。
* Forward the CVReq to the next downstream SFF if the one exists.
* 存在する場合は、CVREQを次の下流のSFFに転送します。
As a result, the ingress SFF collects information about all traversed SFFs and SFs, i.e., information on the actual path the CVReq packet has traveled. That information can be used to verify the SFC's path consistency. The mechanism for the SFP consistency verification is outside the scope of this document.
その結果、Ingress SFFは、すべてのトラバースされたSFFおよびSFSに関する情報、つまりCVREQパケットが移動した実際のパスに関する情報を収集します。その情報は、SFCのパスの一貫性を検証するために使用できます。SFPの一貫性検証のメカニズムは、このドキュメントの範囲外です。
For the received CVReq, an SFF that supports this specification MUST include in the CVRep message the information about SFs that are available from that SFF instance for the specified SFP. The SFF MUST include the SFF Information Record TLV (Figure 9) in the CVRep message. Every SFF sends back a single CVRep message, including information on all the SFs attached to that SFF on the SFP, as requested in the received CVReq message using the SF Information Sub-TLV (Section 6.6.2).
受信したCVREQの場合、この仕様をサポートするSFFは、CVREPメッセージに、指定されたSFPのSFFインスタンスから入手可能なSFSに関する情報を含める必要があります。SFFは、CVREPメッセージにSFF情報レコードTLV（図9）を含める必要があります。すべてのSFFは、SF情報Sub-TLV（セクション6.6.2）を使用して受信したCVREQメッセージで要求されているように、SFP上のそのSFFに添付されたすべてのSFSに関する情報を含む、単一のCVREPメッセージを送り返します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SFF Record TLV | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SF Information Sub-TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SFF Information Record TLV
図9：SFF情報記録TLV
The SFF Information Record TLV is a variable-length TLV that includes the information of all SFs available from the particular SFF instance for the specified SFP. Figure 9 presents the format of an SFF Information Record TLV, where the fields are defined as follows:
SFF情報レコードTLVは、指定されたSFPの特定のSFFインスタンスから利用可能なすべてのSFの情報を含む可変長TLVです。図9は、SFF情報レコードTLVの形式を示しています。フィールドは次のように定義されています。
SFF Record TLV -
SFFレコードTLV-
the value is (4) (Section 9.2.6).
値は（4）（セクション9.2.6）です。
Reserved -
予約済み -
MUST be zeroed on transmission and ignored on receipt.
送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
the value equals the sum of lengths of the Service Path Identifier, reserved, and SF Information Sub-TLV fields in octets.
値は、オクテットのサービスパス識別子、予約、およびSF情報サブTLVフィールドの長さの合計に等しくなります。
Service Path Identifier (SPI) -
サービスパス識別子（SPI） -
the identifier of SFP to which all the SFs in this TLV belong.
このTLVのすべてのSFSが属するSFPの識別子。
SF Information Sub-TLV -
SF情報sub -tlv-
the sub-TLV is as defined in Section 6.6.2.
Sub-TLVは、セクション6.6.2で定義されています。
If the NSH of the received SFC Echo Reply includes the MAC Context Header [RFC9145], the authentication of the packet MUST be verified before using any data. If the verification fails, the receiver MUST stop processing the SFF Information Record TLV and notify an operator. The notification mechanism SHOULD include control of rate-limited messages. Specification of the notification mechanism is outside the scope of this document.
受信したSFCエコー応答のNSHにMACコンテキストヘッダー[RFC9145]が含まれている場合、データを使用する前にパケットの認証を検証する必要があります。検証が失敗した場合、受信者はSFF情報レコードTLVの処理を停止し、オペレーターに通知する必要があります。通知メカニズムには、レート制限メッセージの制御を含める必要があります。通知メカニズムの仕様は、このドキュメントの範囲外です。
Every SFF receiving a CVReq packet MUST include the SF characteristic data into the CVRep packet. The format of an SF Information Sub-TLV, included in a CVRep packet, is shown in Figure 10.
CVREQパケットを受信するすべてのSFFは、SF特性データをCVREPパケットに含める必要があります。CVREPパケットに含まれるSF情報Sub-TLVの形式を図10に示します。
After the CVReq message traverses the SFP, all the information about the SFs on the SFP is available from the TLVs included in CVRep messages.
CVREQメッセージがSFPを通過した後、SFP上のSFSに関するすべての情報は、CVREPメッセージに含まれるTLVから入手できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Sub-TLV | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Index | SF Type | SF ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Identifier |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Service Function Information Sub-TLV
図10：サービス関数情報Sub-TLV
SF Sub-TLV -
sf sub -tlv-
one-octet field. The value is (5) (Section 9.2.6).
ワンオクテットフィールド。値は（5）（セクション9.2.6）です。
Reserved -
予約済み -
one-octet field. The field MUST be zeroed on transmission and ignored on receipt.
ワンオクテットフィールド。フィールドは送信時にゼロになり、受領時に無視する必要があります。
Length -
長さ -
two-octet field. The value of this field is the length of the data following the Length field counted in octets.
2オクテットフィールド。このフィールドの値は、オクテットでカウントされる長さフィールドに続くデータの長さです。
Service Index -
サービスインデックス -
indicates the SF's position on the SFP.
SFP上のSFの位置を示します。
SF Type -
SFタイプ -
two-octet field. It is defined in [RFC9015] and indicates the type of SF, e.g., firewall, Deep Packet Inspection, WAN optimization controller, etc.
2オクテットフィールド。[RFC9015]で定義されており、SFのタイプ、たとえばファイアウォール、ディープパケット検査、WAN最適化コントローラーなどを示しています。
SF ID Type -
SF IDタイプ -
one-octet field with values defined as in Section 9.2.7.
セクション9.2.7のように定義された値を持つ1オクセットフィールド。
SF Identifier -
SF識別子 -
an identifier of the SF. The length of the SF Identifier depends on the type of the SF ID Type. For example, if the SF Identifier is its IPv4 address, the SF Identifier should be 32 bits.
SFの識別子。SF識別子の長さは、SF IDタイプのタイプに依存します。たとえば、SF識別子がIPv4アドレスの場合、SF識別子は32ビットでなければなりません。
Each SFF in the SFP MUST send one and only one CVRep corresponding to the CVReq. If only one SF is attached to the SFF in the SFP, only one SF Information Sub-TLV is included in the CVRep. If several SFs are attached to the SFF in the SFP, the SF Information Sub-TLV MUST be constructed as described below in either Section 6.6.3.1 or 6.6.3.2.
SFPの各SFFは、CVREQに対応する1つのCVREPのみを送信する必要があります。SFPのSFFに1つのSFのみが接続されている場合、CVREPには1つのSF情報Sub-TLVのみが含まれています。SFPのSFFにいくつかのSFが接続されている場合、セクション6.6.3.1または6.6.3.2で以下に説明するように、SF情報SUB-TLVを構築する必要があります。
Multiple SFs attached to the same SFF can be the hops of the SFP. The service indexes of these SFs on that SFP will be different. Service Function Types of these SFs could be different or be the same. Information about all SFs MAY be included in the CVRep message. Information about each SF MUST be listed as separate SF Information Sub-TLVs in the CVRep message. The same SF can even appear more than once in an SFP with a different service index.
同じSFFに接続された複数のSFSは、SFPのホップになる可能性があります。そのSFP上のこれらのSFSのサービスインデックスは異なります。これらのSFのサービス関数タイプは異なるか、同じである可能性があります。すべてのSFに関する情報は、CVREPメッセージに含まれる場合があります。各SFに関する情報は、CVREPメッセージの個別のSF情報サブTLVとしてリストする必要があります。同じSFは、異なるサービスインデックスを持つSFPに複数回表示される可能性があります。
An example of the SFP consistency verification procedure for this case is shown in Figure 11. The Service Function Path (SPI=x) is SF1->SF2->SF4->SF3. SF1, SF2, and SF3 are attached to SFF1, and SF4 is attached to SFF2. The CVReq message is sent to the SFFs in the sequence of the SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) replies with the information of SFs belonging to the SFP. The SF Information Sub-TLV in Figure 10 contains information for each SF (SF1, SF2, SF3, and SF4).
このケースのSFP一貫性検証手順の例を図11に示します。サービス関数パス（SPI = x）はSF1-> SF2-> SF4-> SF3です。SF1、SF2、およびSF3はSFF1に接続され、SF4はSFF2に接続されています。CVREQメッセージは、SFP（SFF1-> SFF2-> SFF1）のシーケンスでSFFSに送信されます。すべてのSFF（SFF1、SFF2）は、SFPに属するSFSの情報を返信します。図10のSF情報サブTLVには、各SF（SF1、SF2、SF3、およびSF4）の情報が含まれています。
SF1 SF2 SF4 SF3
+------+------+ | |
CVReq ......> SFF1 ......> SFF2 ......> SFF1
(SPI=x) . . .
<............ <.......... <...........
CVRep1(SF1,SF2) CVRep2(SF4) CVRep3(SF3)
Figure 11: Example 1 for CVRep with Multiple SFs
図11：複数のSFを持つCVREPの例1
Multiple SFs may be attached to the same SFF to spread the load; in other words, that means that the particular traffic flow will traverse only one of these SFs. These SFs have the same Service Function Type and Service Index. For this case, the SF ID Type, which must be the same for all of these SFs, appears once, but all the respective SF Identifiers will be listed sequentially in the SF Identifier field of the Service Function Information Sub-TLV (see Figure 10). The number of these SFs can be calculated from the SF ID Type and the value of the Length field of the sub-TLV.
複数のSFSを同じSFFに取り付けて、負荷を広げることができます。言い換えれば、それは特定のトラフィックフローがこれらのSFの1つのみを横断することを意味します。これらのSFは、同じサービス関数タイプとサービスインデックスを持っています。この場合、これらすべてのSFSで同じでなければならないSF IDタイプは1回表示されますが、それぞれのSF識別子はすべて、サービス関数情報Sub-TLVのSF識別子フィールドに順次リストされます（図10を参照してください。）。これらのSFの数は、SF IDタイプとサブTLVの長さフィールドの値から計算できます。
An example of the SFP consistency verification procedure for this case is shown in Figure 12. The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b. The Service Functions SF1a and SF1b are attached to SFF1, which balances the load among them. The Service Functions SF2a and SF2b are attached to SFF2, which in turn, balances its load between them. The CVReq message is sent to the SFFs in the sequence of the SFP (i.e., SFF1->SFF2). Every SFF (SFF1, SFF2) replies with the information of SFs belonging to the SFP. The SF Information Sub-TLV in Figure 10 contains information for all SFs at that hop.
この場合のSFP一貫性検証手順の例を図12に示します。サービス関数パス（SPI = x）はSF1A/SF1B-> SF2A/SF2Bです。サービス関数SF1AとSF1BはSFF1に取り付けられており、SFF1のバランスが取れています。サービス関数SF2AとSF2BはSFF2に取り付けられており、SFF2はそれらの間の負荷のバランスをとります。CVREQメッセージは、SFP（つまり、SFF1-> SFF2）のシーケンスでSFFSに送信されます。すべてのSFF（SFF1、SFF2）は、SFPに属するSFSの情報を返信します。図10のSF情報Sub-TLVには、そのホップのすべてのSFSの情報が含まれています。
/SF1a /SF2a
\SF1b \SF2b
| |
SFF1 SFF2
CVReq .........> . .........> .
(SPI=x) . .
<............ <...............
CVRep1(SF1a,SF1b) CVRep2(SF2a,SF2b)
Figure 12: Example 2 for CVRep with Multiple SFs
図12：複数のSFを持つCVREPの例2
As an element of SFC OAM and, specifically, based on the NSH, the Echo Request/Reply mechanism described in this document inherits security considerations discussed in [RFC7665] and [RFC8300].
SFC OAMの要素として、特にNSHに基づいて、このドキュメントで説明されているエコー要求/返信メカニズムは、[RFC7665]および[RFC8300]で説明されているセキュリティ上の考慮事項を継承します。
When the integrity protection for SFC active OAM, particularly the SFC Echo Request/Reply, is required, using one of the Context Headers defined in [RFC9145] is RECOMMENDED. The MAC#1 Context Header could be more suitable for SFC active OAM because it does not require recalculation of the MAC when the value of the NSH Base Header's TTL field is changed. Integrity protection for SFC active OAM can also be achieved using mechanisms in the underlay data plane. For example, if the underlay is an IPv6 network, i.e., an IP Authentication Header [RFC4302] or IP Encapsulating Security Payload Header [RFC4303], it can be used to provide integrity protection. Confidentiality for the SFC Echo Request/Reply exchanges can be achieved using the IP Encapsulating Security Payload Header [RFC4303]. Also, the security needs for the SFC Echo Request/Reply are similar to those of ICMP ping [RFC0792] [RFC4443] and MPLS LSP ping [RFC8029].
SFCアクティブOAM、特にSFCエコーリクエスト/返信の整合性保護が必要な場合、[RFC9145]で定義されているコンテキストヘッダーの1つを使用することをお勧めします。NSHベースヘッダーのTTLフィールドの値が変更された場合にMACの再計算を必要としないため、MAC＃1コンテキストヘッダーはSFCアクティブOAMにより適している可能性があります。SFCアクティブOAMの整合性保護は、アンダーレイデータプレーンのメカニズムを使用して達成することもできます。たとえば、アンダーレイがIPv6ネットワーク、つまりIP認証ヘッダー[RFC4302]またはIPカプセル化セキュリティペイロードヘッダー[RFC4303]である場合、整合性保護を提供するために使用できます。SFCエコーリクエスト/返信交換の機密性は、セキュリティペイロードヘッダー[RFC4303]をカプセル化するIPカプセル化を使用して達成できます。また、SFCエコーリクエスト/返信のセキュリティニーズは、ICMP Ping [RFC0792] [RFC4443]およびMPLS LSP Ping [RFC8029]のセキュリティと類似しています。
There are at least three approaches to attacking a node in the overlay network using the mechanisms defined in the document. One is a Denial-of-Service attack, i.e., sending SFC Echo Requests to overload an element of SFC. The second may use spoofing, hijacking, replying, or otherwise tampering with SFC Echo Requests and/or Replies to misrepresent and alter the operator's view of the state of the SFC. The third is an unauthorized source using an SFC Echo Request/Reply to obtain information about the SFC and/or its elements, e.g., SFFs and/or SFs.
ドキュメントで定義されているメカニズムを使用して、オーバーレイネットワーク内のノードを攻撃するには、少なくとも3つのアプローチがあります。1つは、サービス拒否攻撃です。つまり、SFCの要素を過負荷にするためのSFCエコーリクエストを送信します。2番目は、SFCの状態のオペレーターの見解を誤って伝えて変更するために、SFCエコー要求および/または返信をスプーフィング、ハイジャック、返信、または改ざんを使用する場合があります。3番目は、SFCエコーリクエスト/返信を使用して不正なソースであり、SFCおよび/またはその要素、例えばSFFやSFSに関する情報を取得します。
It is RECOMMENDED that implementations throttle the number of SFC Echo Request/Reply messages going to the control plane to mitigate potential Denial-of-Service attacks.
実装は、潜在的なサービス拒否攻撃を軽減するために、制御プレーンに送られるSFCエコーリクエスト/返信メッセージの数をスロットルすることをお勧めします。
Reply and spoofing attacks involving faking or replying to SFC Echo Reply messages would have to match the Sender's Handle and Sequence Number of an outstanding SFC Echo Request message, which is highly unlikely for off-path attackers. A non-matching reply would be discarded.
FAKINGまたはSFC ECHOへの返信を伴う返信およびスプーフィング攻撃は、送信者のハンドルとシーケンス番号の未解決のSFCエコーリクエストメッセージと一致する必要があります。一致しない返信が破棄されます。
To protect against unauthorized sources trying to obtain information about the overlay and/or underlay, an implementation MUST have means to check that the source of the Echo Request is part of the SFP.
オーバーレイおよび/またはアンダーレイに関する情報を取得しようとする不正な情報源から保護するには、実装には、エコー要求のソースがSFPの一部であることを確認する手段が必要です。
Also, since the SF Information Sub-TLV discloses information about the SFP, the spoofed CVReq packet may be used to obtain network information. Thus, implementations MUST provide a means of checking the source addresses of CVReq messages, as specified in Section 6.3.1 ("Source ID TLV"), against an access list before accepting the message.
また、SF情報Sub-TLVはSFPに関する情報を開示するため、スプーフィングされたCVREQパケットを使用してネットワーク情報を取得できます。したがって、実装は、メッセージを受け入れる前にアクセスリストに対して、セクション6.3.1（「ソースID TLV」）で指定されているように、CVREQメッセージのソースアドレスをチェックする手段を提供する必要があります。
This section provides information about operational aspects of the SFC NSH Echo Request/Reply according to recommendations in [RFC5706].
このセクションでは、[RFC5706]の推奨事項に従って、SFC NSHエコーリクエスト/返信の運用上の側面に関する情報を提供します。
The SFC NSH Echo Request/Reply provides essential OAM functions for network operators. The SFC NSH Echo Request/Reply is intended to detect and localize defects in SFC. For example, by comparing results of the trace function in operational and failed states, an operator can locate the defect, e.g., the connection between SFF1 and SFF2 (Figure 1). After narrowing down a failure to an overlay link, a more specific failure location can be determined using OAM tools in the underlay network. The mechanism defined in this document can be used on demand or for periodic validation of an SFP or RSP. Because the protocol makes use of the control plane, which may have limited capacity, an operator must be able to rate limit Echo Request and Echo Reply messages. A reasonably selected default interval between Echo Request control packets can provide additional benefit for an operator. If the protocol is incrementally deployed in the NSH domain, SFC elements, e.g., Classifier or SFF, that don't support SFC active OAM will discard the protocol's packets. If SFC uses a reclassification along the SFP or when the principle of load balancing is unknown, the fate sharing between data and active OAM packets cannot be guaranteed. As a result, the OAM outcome might not reflect the state of the entire SFC properly but only its segment. In general, it is an operational task to consider the cases where active OAM may not share fate with the monitored SFP. The SFC NSH Echo Request/Reply also can be used in combination with the existing mechanisms discussed in [RFC8924], filling the gaps and extending their functionalities.
SFC NSHエコーリクエスト/返信は、ネットワークオペレーターに不可欠なOAM関数を提供します。SFC NSHエコーリクエスト/返信は、SFCの欠陥を検出およびローカライズすることを目的としています。たとえば、動作状態と故障状態のTRACE関数の結果を比較することにより、演算子は、たとえばSFF1とSFF2の間の接続を欠損させることができます（図1）。オーバーレイリンクへの障害を絞り込んだ後、アンダーレイネットワークのOAMツールを使用して、より具体的な障害場所を決定できます。このドキュメントで定義されているメカニズムは、SFPまたはRSPの定期的な検証のために、オンデマンドで使用できます。プロトコルは容量が制限されている可能性があるコントロールプレーンを使用しているため、オペレーターはエコーリクエストを制限し、エコー応答メッセージを評価できる必要があります。Echo Request Controlパケット間の合理的に選択されたデフォルト間隔は、オペレーターに追加の利点を提供できます。SFC Active OAMをサポートしていないSFC要素、たとえばSFC要素、たとえばSFC要素、たとえばSFC要素、たとえばSFC要素が徐々に展開されている場合、プロトコルがプロトコルのパケットを破棄します。SFCがSFPに沿って再分類を使用する場合、またはロードバランスの原理が不明な場合、データとアクティブなOAMパケット間の運命の共有を保証することはできません。その結果、OAMの結果は、SFC全体の状態を適切に反映するのではなく、そのセグメントのみを反映している可能性があります。一般に、アクティブなOAMが監視されているSFPと運命を共有できない場合を考慮することは、運用上のタスクです。SFC NSHエコーリクエスト/返信は、[RFC8924]で説明されている既存のメカニズムと組み合わせて使用でき、ギャップを埋め、機能を拡張できます。
Management of the SFC NSH Echo Request/Reply protocol can be provided by a proprietary tool, e.g., command line interface, or based on a data model that is structured or standardized.
SFC NSH ECHOリクエスト/返信プロトコルの管理は、独自のツール、たとえばコマンドラインインターフェイス、または構造化または標準化されたデータモデルに基づいて提供できます。
The terms used in the IANA considerations below are intended to be consistent with [RFC8126].
以下のIANAの考慮事項で使用される用語は、[RFC8126]と一致することを目的としています。
IANA has assigned the following new type in the "NSH Next Protocol" registry within the "Network Service Header (NSH) Parameters" group of registries:
IANAは、「ネットワークサービスヘッダー（NSH）パラメーター」レジストリグループ内の「NSH Next Protocol」レジストリに次の新しいタイプを割り当てました。
+===============+================+===========+
| Next Protocol | Description | Reference |
+===============+================+===========+
| 0x07 | SFC Active OAM | RFC 9516 |
+---------------+----------------+-----------+
Table 1: SFC Active OAM Protocol
表1：SFCアクティブOAMプロトコル
IANA has created the "Service Function Chaining (SFC) Active Operations, Administration, and Maintenance (OAM)" group of registries, which contains the registries described in the following subsections.
IANAは、次のサブセクションで説明されているレジストリを含むレジストリグループのグループグループの「サービス関数チェーン（SFC）アクティブオペレーション、管理、およびメンテナンス（OAM）」を作成しました。
IANA has created the "SFC Active OAM Message Types" registry as follows:
IANAは、次のように「SFC Active OAMメッセージタイプ」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Active OAM Message Types
SFCアクティブOAMメッセージタイプ
Assignment Policy:
割り当てポリシー：
0 - 31
0-31
IETF Review
IETFレビュー
32 - 62
32-62
First Come First Served
早い者勝ち
0 - 31 IETF Review 32 - 62 First Come First Served
0-31 IETFレビュー32-62最初に来る
Reference:
参照：
RFC 9516
RFC 9516
+========+========================+===========+
| Value | Description | Reference |
+========+========================+===========+
| 0 | Reserved | RFC 9516 |
+--------+------------------------+-----------+
| 1 | SFC Echo Request/Reply | RFC 9516 |
+--------+------------------------+-----------+
| 2 - 62 | Unassigned | |
+--------+------------------------+-----------+
| 63 | Reserved | RFC 9516 |
+--------+------------------------+-----------+
Table 2: SFC Active OAM Message Types
表2：SFCアクティブOAMメッセージタイプ
IANA has created the "SFC Echo Request Flags" registry to track the assignment of the 16 flags in the SFC Echo Request Flags field of the SFC Echo Request message. The flags are numbered from 0 (the most significant bit is transmitted first) to 15.
IANAは、「SFCエコーリクエストフラグ」レジストリを作成して、SFCエコーエコーリクエストメッセージのSFCエコーリクエストフラグフィールドの16フラグの割り当てを追跡しました。フラグには0（最も重要なビットが最初に送信されます）から15に番号が付けられます。
IANA has created the "SFC Echo Request Flags" registry as follows:
IANAは、次のように「SFCエコーリクエストフラグ」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Echo Request Flags
SFCエコー要求フラグ
Assignment Policy:
割り当てポリシー：
0 - 15
0-15
Standards Action
標準アクション
0 - 15 Standards Action
0-15標準アクション
Reference:
参照：
RFC 9516
RFC 9516
+============+=============+===========+
| Bit Number | Description | Reference |
+============+=============+===========+
| 0 - 15 | Unassigned | |
+------------+-------------+-----------+
Table 3: SFC Echo Request Flags
表3：SFCエコー要求フラグ
IANA has created the "SFC Echo Types" registry as follows:
IANAは次のように「SFCエコータイプ」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Echo Types
SFCエコータイプ
Assignment Policy:
割り当てポリシー：
0 - 175
0-175
IETF Review
IETFレビュー
176 - 239
176-239
First Come First Served
早い者勝ち
240 - 251
240-251
Experimental Use
実験的使用
252 - 254
252-254
Private Use
私的使用
0 - 175 IETF Review 176 - 239 First Come First Served 240 - 251 Experimental Use 252 - 254 Private Use
0-175 IETFレビュー176-239最初に来る240-251実験的使用252-254私的使用
Reference:
参照：
RFC 9516
RFC 9516
+===========+======================================+===========+
| Value | Description | Reference |
+===========+======================================+===========+
| 0 | Reserved | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 1 | SFC Echo Request | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 2 | SFC Echo Reply | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 3 | SFP Consistency Verification Request | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 4 | SFP Consistency Verification Reply | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 5 - 239 | Unassigned | |
+-----------+--------------------------------------+-----------+
| 240 - 251 | Reserved for Experimental Use | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 252 - 254 | Reserved for Private Use | RFC 9516 |
+-----------+--------------------------------------+-----------+
| 255 | Reserved | RFC 9516 |
+-----------+--------------------------------------+-----------+
Table 4: SFC Echo Types
表4：SFCエコータイプ
IANA has created the "SFC Echo Reply Modes" registry as follows:
IANAは、次のように「SFCエコー応答モード」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Echo Reply Modes
SFCエコー応答モード
Assignment Policy:
割り当てポリシー：
0 - 175
0-175
IETF Review
IETFレビュー
176 - 239
176-239
First Come First Served
早い者勝ち
240 - 251
240-251
Experimental Use
実験的使用
252 - 254
252-254
Private Use
私的使用
0 - 175 IETF Review 176 - 239 First Come First Served 240 - 251 Experimental Use 252 - 254 Private Use
0-175 IETFレビュー176-239最初に来る240-251実験的使用252-254私的使用
Reference:
参照：
RFC 9516
RFC 9516
+=======+====================================+===========+
| Value | Description | Reference |
+=======+====================================+===========+
| 0 | Reserved | RFC 9516 |
+-------+------------------------------------+-----------+
| 1 | Do Not Reply | RFC 9516 |
+-------+------------------------------------+-----------+
| 2 | Reply via an IPv4/IPv6 UDP Packet | RFC 9516 |
+-------+------------------------------------+-----------+
| 3 | Unassigned | |
+-------+------------------------------------+-----------+
| 4 | Reply via Specified Path | RFC 9516 |
+-------+------------------------------------+-----------+
| 5 | Reply via an IPv4/IPv6 UDP Packet | RFC 9516 |
| | with the data integrity protection | |
+-------+------------------------------------+-----------+
| 6 | Unassigned | |
+-------+------------------------------------+-----------+
| 7 | Reply via Specified Path with the | RFC 9516 |
| | data integrity protection | |
+-------+------------------------------------+-----------+
| 8 - | Unassigned | |
| 239 | | |
+-------+------------------------------------+-----------+
| 240 - | Reserved for Experimental Use | RFC 9516 |
| 251 | | |
+-------+------------------------------------+-----------+
| 252 - | Reserved for Private Use | RFC 9516 |
| 254 | | |
+-------+------------------------------------+-----------+
| 255 | Reserved | RFC 9516 |
+-------+------------------------------------+-----------+
Table 5: SFC Echo Reply Modes
表5：SFCエコー応答モード
IANA has created the "SFC Echo Return Codes" registry as follows:
IANAは、次のように「SFCエコーリターンコード」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Echo Return Codes
SFCエコーリターンコード
Assignment Policy:
割り当てポリシー：
0 - 191
0-191
IETF Review
IETFレビュー
192 - 251
192-251
First Come First Served
早い者勝ち
252 - 254
252-254
Private Use
私的使用
0 - 191 IETF Review 192 - 251 First Come First Served 252 - 254 Private Use
0-191 IETFレビュー192-251最初に来る252-254私的使用
Reference:
参照：
RFC 9516
RFC 9516
+=========+============================================+===========+
| Value | Description | Reference |
+=========+============================================+===========+
| 0 | No Error | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 1 | Malformed Echo Request received | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 2 | One or more of the TLVs was not understood | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 3 | Authentication failed | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 4 | SFC TTL Exceeded | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 5 | End of the SFP | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 6 | Reply Service Function Path TLV is missing | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 7 | Reply SFP was not found | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 8 | Unverifiable Reply Service Function Path | RFC 9516 |
+---------+--------------------------------------------+-----------+
| 9 - 251 | Unassigned | |
+---------+--------------------------------------------+-----------+
| 252 - | Reserved for Private Use | RFC 9516 |
| 254 | | |
+---------+--------------------------------------------+-----------+
| 255 | Reserved | RFC 9516 |
+---------+--------------------------------------------+-----------+
Table 6: SFC Echo Return Codes
表6：SFCエコー戻りコード
IANA has created the "SFC Active OAM TLV Types" registry as follows:
IANAは、次のように「SFC Active OAM TLVタイプ」レジストリを作成しました。
Registry Name:
レジストリ名：
SFC Active OAM TLV Types
SFC Active OAM TLVタイプ
Assignment Policy:
割り当てポリシー：
0 - 175
0-175
IETF Review
IETFレビュー
176 - 239
176-239
First Come First Served
早い者勝ち
240 - 251
240-251
Experimental Use
実験的使用
252 - 254
252-254
Private Use
私的使用
0 - 175 IETF Review 176 - 239 First Come First Served 240 - 251 Experimental Use 252 - 254 Private Use
0-175 IETFレビュー176-239最初に来る240-251実験的使用252-254私的使用
Reference:
参照：
RFC 9516
RFC 9516
+===========+==================================+===========+
| Value | Description | Reference |
+===========+==================================+===========+
| 0 | Reserved | RFC 9516 |
+-----------+----------------------------------+-----------+
| 1 | Source ID TLV | RFC 9516 |
+-----------+----------------------------------+-----------+
| 2 | Errored TLVs | RFC 9516 |
+-----------+----------------------------------+-----------+
| 3 | Reply Service Function Path Type | RFC 9516 |
+-----------+----------------------------------+-----------+
| 4 | SFF Information Record Type | RFC 9516 |
+-----------+----------------------------------+-----------+
| 5 | SF Information | RFC 9516 |
+-----------+----------------------------------+-----------+
| 6 - 239 | Unassigned | |
+-----------+----------------------------------+-----------+
| 240 - 251 | Reserved for Experimental Use | RFC 9516 |
+-----------+----------------------------------+-----------+
| 252 - 254 | Reserved for Private Use | RFC 9516 |
+-----------+----------------------------------+-----------+
| 255 | Reserved | RFC 9516 |
+-----------+----------------------------------+-----------+
Table 7: SFC Active OAM TLV Types
表7：SFCアクティブOAM TLVタイプ
IANA has created the "SF Identifier Types" as follows:
IANAは次のように「SF識別子タイプ」を作成しました。
Registry Name:
レジストリ名：
SF Identifier Types
SF識別子タイプ
Assignment Policy:
割り当てポリシー：
0 - 191
0-191
IETF Review
IETFレビュー
192 - 251
192-251
First Come First Served
早い者勝ち
252 - 254
252-254
Private Use
私的使用
0 - 191 IETF Review 192 - 251 First Come First Served 252 - 254 Private Use
0-191 IETFレビュー192-251最初に来る252-254私的使用
Reference:
参照：
RFC 9516
RFC 9516
+===========+==========================+===========+
| Value | Description | Reference |
+===========+==========================+===========+
| 0 | Reserved | RFC 9516 |
+-----------+--------------------------+-----------+
| 1 | IPv4 | RFC 9516 |
+-----------+--------------------------+-----------+
| 2 | IPv6 | RFC 9516 |
+-----------+--------------------------+-----------+
| 3 | MAC | RFC 9516 |
+-----------+--------------------------+-----------+
| 4 - 251 | Unassigned | |
+-----------+--------------------------+-----------+
| 252 - 254 | Reserved for Private Use | RFC 9516 |
+-----------+--------------------------+-----------+
| 255 | Reserved | RFC 9516 |
+-----------+--------------------------+-----------+
Table 8: SF Identifier Types
表8：SF識別子タイプ
[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>.
[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>.
[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>.
[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>.
[RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for the Network Service Header
in Service Function Chaining", RFC 9015,
DOI 10.17487/RFC9015, June 2021,
<https://www.rfc-editor.org/info/rfc9015>.
[RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity
Protection for the Network Service Header (NSH) and
Encryption of Sensitive Context Headers", RFC 9145,
DOI 10.17487/RFC9145, December 2021,
<https://www.rfc-editor.org/info/rfc9145>.
[RFC9451] Boucadair, M., "Operations, Administration, and
Maintenance (OAM) Packet and Behavior in the Network
Service Header (NSH)", RFC 9451, DOI 10.17487/RFC9451,
August 2023, <https://www.rfc-editor.org/info/rfc9451>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
[RFC7555] Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo
Request", RFC 7555, DOI 10.17487/RFC7555, June 2015,
<https://www.rfc-editor.org/info/rfc7555>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[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>.
[RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan,
R., and A. Ghanwani, "Service Function Chaining (SFC)
Operations, Administration, and Maintenance (OAM)
Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020,
<https://www.rfc-editor.org/info/rfc8924>.
[RFC9263] Wei, Y., Ed., Elzur, U., Majee, S., Pignataro, C., and D.
Eastlake 3rd, "Network Service Header (NSH) Metadata Type
2 Variable-Length Context Headers", RFC 9263,
DOI 10.17487/RFC9263, August 2022,
<https://www.rfc-editor.org/info/rfc9263>.
The authors greatly appreciate the thorough review and the most helpful comments from Dan Wing, Dirk von Hugo, Mohamed Boucadair, Donald Eastlake 3rd, Carlos Pignataro, and Frank Brockners. The authors are thankful to John Drake for his review and the reference to the work on BGP control plane for NSH SFC. The authors express their appreciation to Joel M. Halpern for his suggestion about the load-balancing scenario. The authors greatly appreciate the thoroughness of comments and thoughtful suggestions by Darren Dukes that significantly improved the document.
著者は、Dan Wing、Dirk Von Hugo、Mohamed Boucadair、Donald Eastlake 3rd、Carlos Pignataro、およびFrank Brocknersからの徹底的なレビューと最も役立つコメントを非常に高く評価しています。著者は、NSH SFCのBGPコントロールプレーンの作業への参照と、John Drakeのレビューと言及に感謝しています。著者は、ロードバランスのシナリオについての彼の提案に対して、ジョエルM.ハルパーンに感謝を表明しています。著者は、ドキュメントを大幅に改善したダレンデュークスによるコメントの徹底と思慮深い提案に大いに感謝しています。
Cui Wang
Individual contributor
Email: lindawangjoy@gmail.com
Zhonghua Chen
China Telecom
No.1835, South PuDong Road
Shanghai
201203
China
Phone: +86 18918588897
Email: chenzhongh@chinatelecom.cn
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Wei Meng
ZTE Corporation
Yuhuatai District
No.50 Software Avenue
Nanjing,
China
Email: meng.wei2@zte.com.cn
Ting Ao
China Mobile
No.889, BiBo Road
Shanghai
201203
China
Phone: +86 17721209283
Email: 18555817@qq.com
Bhumip Khasnabish
Individual Contributor
Email: vumip1@gmail.com
Kent Leung
Individual Contributor
530 Showers Drive Ste 7
Mountain View, CA 94040
United States of America
Email: mail4kentl@gmail.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com