[要約] RFC 8924は、サービス機能連鎖（SFC）の運用、管理、保守（OAM）フレームワークに関する文書です。この文書の目的は、SFC環境内でのサービス品質、パフォーマンス、障害管理をサポートするためのガイドラインを提供することです。利用場面としては、ネットワークの効率化、セキュリティ強化、および障害発生時の迅速な対応が挙げられます。
Internet Engineering Task Force (IETF) S. Aldrin
Request for Comments: 8924 Google
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 N. Kumar, Ed.
Cisco
R. Krishnan
VMware
A. Ghanwani
Dell
October 2020
Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework
サービス機能連鎖（SFC）運用、管理、保守（OAM）フレームワーク
Abstract
概要
This document provides a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC).
この資料は、サービス機能連鎖（SFC）の運用、管理、および保守（OAM）のための参照フレームワークを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8924.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc8924で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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. Document Scope
1.2. Acronyms and Terminology
1.2.1. Acronyms
1.2.2. Terminology
2. SFC Layering Model
3. SFC OAM Components
3.1. The SF Component
3.1.1. SF Availability
3.1.2. SF Performance Measurement
3.2. The SFC Component
3.2.1. SFC Availability
3.2.2. SFC Performance Measurement
3.3. Classifier Component
3.4. Underlay Network
3.5. Overlay Network
4. SFC OAM Functions
4.1. Connectivity Functions
4.2. Continuity Functions
4.3. Trace Functions
4.4. Performance Measurement Functions
5. Gap Analysis
5.1. Existing OAM Functions
5.2. Missing OAM Functions
5.3. Required OAM Functions
6. Operational Aspects of SFC OAM at the Service Layer
6.1. SFC OAM Packet Marker
6.2. OAM Packet Processing and Forwarding Semantic
6.3. OAM Function Types
7. Candidate SFC OAM Tools
7.1. ICMP
7.2. BFD / Seamless BFD
7.3. In Situ OAM
7.4. SFC Traceroute
8. Manageability Considerations
9. Security Considerations
10. IANA Considerations
11. Informative References
Acknowledgements
Contributors
Authors' Addresses
Service Function Chaining (SFC) enables the creation of composite services that consist of an ordered set of Service Functions (SFs) that are to be applied to any traffic selected as a result of classification [RFC7665]. SFC is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. The foundations of SFC are described in the following documents:
サービス機能連鎖（SFC）は、分類の結果として選択されたトラフィックに適用される順序付けられたサービス機能のセット（SFS）からなる複合サービスの作成を可能にします[RFC7665]。SFCは、選択されたトラフィックに対するSFの順序付けられたセットの適用だけを提供する概念です。むしろ、それは、それらのSFSの動的順序付けおよびトポロジ化を可能にする方法、ならびに参加したエンティティ間のメタデータの交換を可能にする方法でSFSを展開するための方法を説明する。SFCの基礎は以下の文書に記載されています。
* SFC Problem Statement [RFC7498]
* SFC問題ステートメント[RFC7498]
* SFC Architecture [RFC7665]
* SFCアーキテクチャ[RFC7665]
The reader is assumed to be familiar with the material in [RFC7665].
リーダーは[RFC7665]の材料に精通していると見なされます。
This document provides a reference framework for Operations, Administration, and Maintenance (OAM) [RFC6291] of SFC. Specifically, this document provides:
この文書では、SFCの操作、管理、メンテナンス（OAM）[RFC6291]の参照フレームワークを提供します。具体的には、このドキュメントは次のとおりです。
* an SFC layering model (Section 2),
* SFC階層化モデル（セクション2）
* aspects monitored by SFC OAM (Section 3),
* SFC OAMによって監視された側面（セクション3）
* functional requirements for SFC OAM (Section 4),
* SFC OAMの機能要件（セクション4）、
* a gap analysis for SFC OAM (Section 5),
* SFC OAMのギャップ解析（セクション5）
* operational aspects of SFC OAM at the service layer (Section 6),
* サービス層におけるSFC OAMの動作面（セクション6）
* applicability of various OAM tools (Section 7), and
* さまざまなOAMツールの適用性（セクション7）
* manageability considerations for SF and SFC (Section 8).
* SFおよびSFCの管理性の考慮事項（セクション8）。
SFC OAM solution documents should refer to this document to indicate the SFC OAM component and the functionality they target.
SFC OAMソリューション文書は、SFC OAMコンポーネントとターゲットを示す機能を示すためにこのドキュメントを参照してください。
OAM controllers are SFC-aware network devices that are capable of generating OAM packets. They should be within the same administrative domain as the target SFC-enabled domain.
OAMコントローラは、OAMパケットを生成することができるSFC対応ネットワークデバイスです。それらはターゲットSFC対応ドメインと同じ管理ドメイン内にあるべきです。
The focus of this document is to provide an architectural framework for SFC OAM, particularly focused on the aspect of the Operations component within OAM. Actual solutions and mechanisms are outside the scope of this document.
この文書の焦点は、特にOAM内の運用コンポーネントの側面に焦点を当てているSFC OAMのための建築枠組みを提供することです。実際の解決策とメカニズムはこの文書の範囲外です。
BFD Bidirectional Forwarding Detection
BFD双方向転送検出
CLI Command-Line Interface
CLIコマンドラインインタフェース
DWDM Dense Wavelength Division Multiplexing
DWDM高密度波長分割多重化
E-OAM Ethernet OAM
E-OAMイーサネットOAM.
hSFC Hierarchical Service Function Chaining
HSFC階層サービス機能連鎖
IBN Internal Boundary Node
IBN内部境界ノード
IPPM IP Performance Metrics
IPPM IPパフォーマンスメトリック
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
MPLS_PM MPLS Performance Measurement
MPLS_PM MPLSパフォーマンス測定
NETCONF Network Configuration Protocol
NetConfネットワーク構成プロトコル
NSH Network Service Header
NSHネットワークサービスヘッダー
NVO3 Network Virtualization over Layer 3
レイヤ3上のNVO3ネットワーク仮想化
OAM Operations, Administration, and Maintenance
OAMの操作、管理、および保守
POS Packet over SONET
SONET上のPOSパケット
RSP Rendered Service Path
RSPレンダリングされたサービスパス
SF Service Function
SFサービス機能
SFC Service Function Chain
SFCサービス機能チェーン
SFF Service Function Forwarder
SFFサービス機能フォワーダ
SFP Service Function Path
SFPサービス機能パス
SNMP Simple Network Management Protocol
SNMP単純なネットワーク管理プロトコル
TRILL Transparent Interconnection of Lots of Links
たくさんのリンクの透明な相互接続をトリル
VM Virtual Machine
VM仮想マシン
This document uses the terminology defined in [RFC7665] and [RFC8300], and readers are expected to be familiar with it.
この文書は[RFC7665]と[RFC8300]で定義されている用語を使用し、読者はそれに精通していると予想されます。
Multiple layers come into play for implementing the SFC. These include the service layer and the underlying layers (network layer, link layer, etc.).
SFCを実装するために複数の層が再生されます。これらには、サービス層と基礎となる層（ネットワーク層、リンク層など）が含まれます。
* The service layer consists of SFC data-plane elements that include classifiers, Service Functions (SFs), Service Function Forwarders (SFF), and SFC Proxies. This layer uses the overlay network layer for ensuring connectivity between SFC data-plane elements.
* サービス層は、分類子、サービス機能（SFS）、サービス機能フォワーダ（SFF）、およびSFCプロキシを含むSFCデータプレーン要素で構成されています。このレイヤは、SFCデータプレーン要素間の接続性を確保するためにオーバーレイネットワーク層を使用します。
* The overlay network layer leverages various overlay network technologies (e.g., Virtual eXtensible Local Area Network (VXLAN)) for interconnecting SFC data-plane elements and allows establishing Service Function Paths (SFPs). This layer is mostly transparent to the SFC data-plane elements, as not all the data-plane elements process the overlay header.
* オーバーレイネットワーク層は、SFCデータプレーン要素を相互接続するための様々なオーバーレイネットワーク技術（例えば、仮想拡張ローカルエリアネットワーク（VXLAN））を利用し、サービス機能パス（SFP）を確立することを可能にする。このレイヤは、すべてのデータプレーン要素がオーバーレイヘッダを処理するわけではないため、SFCデータプレーン要素に対してほとんど透過的です。
* The underlay network layer is dictated by the networking technology deployed within a network (e.g., IP, MPLS).
* アンダーレイネットワーク層は、ネットワーク内に展開されたネットワーク技術（例えば、IP、MPL）によって決定される。
* The link layer is tightly coupled with the physical technology used. Ethernet is one such choice for this layer, but other alternatives may be deployed (e.g., POS and DWDM). In a virtual environment, virtualized I/O technologies, such as Single Root I/O Virtualization (SR-IOV) or similar, are also applicable for this layer. The same or distinct link layer technologies may be used in each leg shown in Figure 1.
* リンク層は使用される物理技術と密接に結合されている。イーサネットはこの層のためのそのような選択肢の1つですが、他の代替案を展開することができます（例えば、POS、DWDM）。仮想環境では、単一ルートI / O仮想化（SR-IOV）などの仮想化I / Oテクノロジもこのレイヤに適用可能です。図1に示す各脚で同じまたは異なるリンク層技術を使用することができる。
o----------------------Service Layer----------------------o
+------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7|
|fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+
+------+
<------VM1------> <--VM2--> <--VM3-->
^-----------------^-------------------^---------------^ Overlay
Network
o-----------------o-------------------o---------------o Underlay
Network
o--------o--------o--------o----------o-------o-------o Link
Figure 1: SFC Layering Example
図1：SFC階層化例
In Figure 1, the service-layer elements, such as classifier and SF, are depicted as virtual entities that are interconnected using an overlay network. The underlay network may comprise multiple intermediate nodes not shown in the figure that provide underlay connectivity between the service-layer elements.
図1では、分類子やSFなどのサービス層要素は、オーバーレイネットワークを使用して相互接続されている仮想エンティティとして描かれています。アンダーレイネットワークは、サービス層要素間のアンダーレイ接続を提供する図に示されていない複数の中間ノードを含むことができる。
While Figure 1 depicts an example where SFs are enabled as virtual entities, the SFC architecture does not make any assumptions on how the SFC data-plane elements are deployed. The SFC architecture is flexible and accommodates physical or virtual entity deployment. SFC OAM accounts for this flexibility, and accordingly it is applicable whether SFC data-plane elements are deployed directly on physical hardware, as one or more virtual entities, or any combination thereof.
図1は、SFSが仮想エンティティとして有効になっている例を示していますが、SFCアーキテクチャはSFCデータプレーン要素のデプロイ方法についての仮定をしません。SFCアーキテクチャは柔軟で、物理的または仮想エンティティの展開に対応しています。SFC OAMはこの柔軟性を説明するため、SFCデータプレーン要素が物理ハードウェア上に直接展開されているか、またはその任意の組み合わせであるかどうかが適用可能です。
The SFC operates at the service layer. For the purpose of defining the OAM framework, the service layer is broken up into three distinct components:
SFCはサービス層で動作します。OAMフレームワークを定義する目的で、サービス層は3つの異なるコンポーネントに分割されています。
SF component: OAM functions applicable at this component include testing the SFs from any SFC-aware network device (e.g., classifiers, controllers, and other service nodes). Testing an SF may be more expansive than just checking connectivity to the SF, such as checking if the SF is providing its intended service. Refer to Section 3.1.1 for a more detailed discussion.
SFコンポーネント：OAM機能このコンポーネントに適用可能な機能は、任意のSFC対応ネットワークデバイス（例えば、分類子、コントローラ、およびその他のサービスノード）からのSFSをテストすることを含む。SFのテストは、SFがその意図されたサービスを提供しているかどうかを確認するなど、SFへの接続性をチェックするだけではより広く拡張され得る。より詳細な説明については、3.1.1項を参照してください。
SFC component: OAM functions applicable at this component include (but are not limited to) testing the SFCs and the SFPs, validation of the correlation between an SFC and the actual forwarding path followed by a packet matching that SFC, i.e., the Rendered Service Path (RSP). Some of the hops of an SFC may not be visible when Hierarchical Service Function Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the responsibility of the Internal Boundary Node (IBN) to glue the connectivity between different levels for end-to-end OAM functionality.
SFCコンポーネント：OAM機能このコンポーネントに適用可能な機能には、SFCとSFPのテスト、SFCと実際の転送パスとの間の相関の検証、つまりSFC、すなわちレンダリングされたサービスパスとの間の相関の検証が含まれます。（RSP）。SFCのホップのいくつかは、階層型サービス機能Chaining（HSFC）[RFC8459]が使用中の場合には見えない場合があります。そのような方式では、エンドツーエンドのOAM機能のための異なるレベル間の接続性を接着することが内部境界ノード（IBN）の責任です。
Classifier component: OAM functions applicable at this component include testing the validity of the classification rules and detecting any incoherence among the rules installed when more than one classifier is used, as explained in Section 2.2 of [RFC7665].
分類子コンポーネント：OAM関数このコンポーネントに適用される機能には、[RFC7665]のセクション2.2で説明されているように、複数の分類子が使用されている場合にインストールされているルール間の矛盾を検出することが含まれます。
Figure 2 illustrates an example where OAM for the three defined components are used within the SFC environment.
図2は、3つの定義されたコンポーネントのOAMがSFC環境内で使用されている例を示しています。
+-Classifier +-Service Function Chain OAM
| OAM |
| | ___________________________________________
| \ /\ Service Function Chain \
| \ / \ +---+ +---+ +-----+ +---+ \
| \ / \ |SF1| |SF2| |Proxy|--|SF3| \
| +------+ \/ \ +---+ +---+ +-----+ +---+ \
+----> | |...(+-> ) | | | )
|Classi| \ / +-----+ +-----+ +-----+ /
|fier | \ / | SFF1|----| SFF2|----| SFF3| /
| | \ / +--^--+ +-----+ +-----+ /
+----|-+ \/_________|________________________________/
| |
+-------SF_OAM-------+
+---+ +---+
+SF_OAM>|SF3| |SF5|
| +-^-+ +-^-+
+------|---+ | |
|Controller| +-SF_OAM+
+----------+
Service Function OAM (SF_OAM)
Figure 2: SFC OAM Components
図2：SFC OAMコンポーネント
It is expected that multiple SFC OAM solutions will be defined, each targeting one specific component of the service layer. However, it is critical that SFC OAM solutions together provide the coverage of all three SFC OAM components: the SF component, the SFC component, and the classifier component.
複数のSFC OAMソリューションが定義され、それぞれがサービス層の特定のコンポーネントを1つターゲティングします。ただし、SFC OAMソリューションが一緒になって、SFコンポーネント、SFCコンポーネント、および分類子コンポーネントすべてのSFC OAMコンポーネントのすべてのカバレッジを提供することが重要です。
One SFC OAM requirement for the SF component is to allow an SFC-aware network device to check the availability of a specific SF (instance), located on the same or different network device(s). For cases where multiple instances of an SF are used to realize a given SF for the purpose of load sharing, SF availability can be performed by checking the availability of any one of those instances, or the availability check may be targeted at a specific instance. SF availability is an aspect that raises an interesting question: How does one determine that an SF is available? At one end of the spectrum, one might argue that an SF is sufficiently available if the service node (physical or virtual) hosting the SF is available and is functional. At the other end of the spectrum, one might argue that the SF's availability can only be deduced if the packet, after passing through the SF, was examined and it was verified that the packet did indeed get the expected service.
SFコンポーネントに対する1つのSFC OAM要件は、SFC対応ネットワークデバイスが、同じまたは異なるネットワークデバイス上にある特定のSF（インスタンス）の可用性を確認できるようにすることです。SFの複数のインスタンスを負荷分散のために実現するために使用される場合、これらのインスタンスのいずれかのインスタンスの可用性を確認することによってSFの可用性を実行することができます。または可用性チェックを特定のインスタンスでターゲットにすることができます。SFの可用性は、興味深い質問を提起する側面である：SFが利用可能であると判断するのはどうですか？スペクトルの一端で、SFをホストするサービスノード（物理的または仮想）が利用可能で機能している場合、SFが十分に利用可能であると主張するかもしれません。スペクトルのもう一方の端には、SFを通過した後にSFの可用性が検査された場合にのみSFの可用性が推論でき、パケットが確かに予想されるサービスを受けることが確認されました。
The former approach will likely not provide sufficient confidence about the actual SF availability, i.e., a service node and an SF are two different entities. The latter approach is capable of providing an extensive verification but comes at a cost. Some SFs make direct modifications to packets, while others do not. Additionally, the purpose of some SFs may be to drop certain packets intentionally. In such cases, it is normal behavior that certain packets will not be egressing out from the SF. The OAM mechanism needs to take into account such SF specifics when assessing SF availability. Note that there are many flavors of SFs available and many more that are likely be introduced in the future. Even a given SF may introduce a new functionality (e.g., a new signature in a firewall). The cost of this approach is that the OAM mechanism for some SF will need to be continuously modified in order to "keep up" with new functionality being introduced.
前者のアプローチは、実際のSFの可用性、すなわちサービスノードとSFが2つの異なるエンティティについての十分な信頼を提供しないでしょう。後者のアプローチは、広範囲の検証を提供することができますが、コストがかかる。一部のSFSはパケットを直接変更するが、他のものはそうではありません。さらに、一部のSFSの目的は、特定のパケットを意図的に削除することです。そのような場合は、特定のパケットがSFから出力されないことが通常の動作です。OAMメカニズムは、SFの可用性を評価するときにSFの詳細を考慮する必要があります。利用可能なSFSの多くの香りがあり、将来紹介される可能性が高くなっていることに注意してください。所与のSFでさえも新しい機能（例えば、ファイアウォール内の新しい署名）を導入することができる。このアプローチのコストは、新しい機能が導入されていると「追いつく」ために、一部のSFのOAMメカニズムを継続的に変更する必要があることです。
The SF availability check can be performed using a generalized approach, i.e., at an adequate granularity to provide a basic SF service. The task of evaluating the true availability of an SF is a complex activity, currently having no simple, unified solution. There is currently no standard means of doing so. Any such mechanism would be far from a typical OAM function, so it is not explored as part of the analysis in Sections 4 and 5.
SF可用性チェックは、一般化されたアプローチ、すなわち適切な粒度で基本的なSFサービスを提供することを使用して実行することができる。SFの真の可用性を評価するというタスクは、現在単純な統一されたソリューションを持っていない複雑なアクティビティです。現在標準的な手段はありません。そのようなメカニズムは典型的なOAM機能からはるかに遠いので、セクション4および5の分析の一部として検討されていません。
The second SFC OAM requirement for the SF component is to allow an SFC-aware network device to check the performance metrics, such as loss and delay induced by a specific SF for processing legitimate traffic. Performance measurement can be passive by using live traffic, an active measurement by using synthetic probe packets, or a hybrid method that uses a combination of active and passive measurement. More details about this OAM function is explained in Section 4.4.
SFコンポーネントの2番目のSFC OAM要件は、SFC対応ネットワークデバイスが、正当なトラフィックを処理するために特定のSFによって誘起された損失と遅延などのパフォーマンスメトリックをチェックすることを可能にすることです。性能測定は、ライブトラフィック、合成プローブパケットを使用することによる能動的測定、またはアクティブとパッシブ測定の組み合わせを使用するハイブリッドメソッドを使用してパッシブ化できます。このOAM機能に関する詳細は4.4節で説明されています。
On the one hand, the performance of any specific SF can be quantified by measuring the loss and delay metrics of the traffic from the SFF to the respective SF, while on the other hand, the performance can be measured by leveraging the loss and delay metrics from the respective SFs. The latter requires SF involvement to perform the measurement, while the former does not. For cases where multiple instances of an SF are used to realize a given SF for the purpose of load sharing, SF performance can be quantified by measuring the metrics for any one instance of SF or by measuring the metrics for a specific instance.
一方では、SFFから各SFへのトラフィックの損失と遅延メトリックを測定することによって、特定のSFの性能を定量化することができますが、損失と遅延測定基準を活用することで性能を測定できます。各SFSから。後者は測定を実行するためのSFの関与を必要としますが、前者はそうではありません。SFの複数のインスタンスを使用して負荷分散の目的で特定のSFを実現する場合は、SFのメトリックを測定することによって、または特定のインスタンスのメトリックを測定することによってSF性能を定量化することができます。
The metrics measured to quantify the performance of the SF component are not just limited to loss and delay. Other metrics, such as throughput, also exist and the choice of metrics for performance measurement is outside the scope of this document.
SFコンポーネントの性能を定量化するために測定されたメトリックは、損失と遅延に限定されない。スループットなどの他のメトリックも存在し、パフォーマンス測定のためのメトリックの選択はこの文書の範囲外です。
An SFC could comprise varying SFs, and so the OAM layer is required to perform validation and verification of SFs within an SFP, in addition to connectivity verification and fault isolation.
SFCはさまざまなSFSを備えることができ、したがって、OAM層は、接続性検証と障害分離に加えて、SFP内のSFS内の検証と検証を実行する必要があります。
In order to perform service connectivity verification of an SFC/SFP, the OAM functions could be initiated from any SFC-aware network device of an SFC-enabled domain for end-to-end paths, or partial paths terminating on a specific SF, within the SFC/SFP. The goal of this OAM function is to ensure the SFs chained together have connectivity, as was intended at the time when the SFC was established. The necessary return codes should be defined for sending back in the response to the OAM packet, in order to complete the verification.
SFC / SFPのサービス接続の検証を実行するために、OAM関数は、エンドツーエンドのパスのSFC対応ドメインのSFC対応ネットワークデバイスから、または特定のSFで終了する部分パスから開始できます。SFC / SFP。このOAM機能の目的は、SFCが確立された時点で意図されているように、連鎖されたSFSが接続性を持つようになることです。検証を完了するために、必要な戻りコードは、OAMパケットへの応答を送信するために定義されます。
When ECMP is in use at the service layer for any given SFC, there must be the ability to discover and traverse all available paths.
ECMPが特定のSFCのサービス層で使用されている場合、利用可能なすべてのパスを発見して通過する機能がある必要があります。
A detailed explanation of the mechanism is outside the scope of this document and is expected to be included in the actual solution document.
このメカニズムの詳細な説明はこの文書の範囲外であり、実際のソリューション文書に含まれる予定です。
Any SFC-aware network device should have the ability to make performance measurements over the entire SFC (i.e., end-to-end) or on a specific segment of SFs within the SFC.
SFC対応ネットワークデバイスは、SFC全体（すなわち、エンドツーエンド）またはSFC内のSFSの特定のセグメントにわたってパフォーマンス測定を行うことができるはずである。
A classifier maintains the classification rules that map a flow to a specific SFC. It is vital that the classifier is correctly configured with updated classification rules and is functioning as expected. The SFC OAM must be able to validate the classification rules by assessing whether a flow is appropriately mapped to the relevant SFC and detect any misclassification. Sample OAM packets can be presented to the classifiers to assess the behavior with regard to a given classification entry.
分類子は、フローを特定のSFCにマッピングする分類規則を維持します。分類器が更新された分類規則で正しく構成され、期待通りに機能していることが不可欠です。SFC OAMは、フローが関連するSFCに適切にマッピングされ、誤分類を検出するかどうかを評価することによって分類規則を検証できる必要があります。サンプルOAMパケットは、特定の分類エントリに関して行動を評価するために分類子に提示されます。
The classifier availability check may be performed to check the availability of the classifier to apply the rules and classify the traffic flows. Any SFC-aware network device should have the ability to perform availability checking of the classifier component for each SFC.
分類子の可用性チェックは、規則を適用し、トラフィックフローを分類するために分類子の可用性をチェックするために実行されてもよい。SFC対応ネットワークデバイスは、各SFCの分類子コンポーネントの可用性チェックを実行する機能を持つ必要があります。
Any SFC-aware network device should have the ability to perform performance measurement of the classifier component for each SFC. The performance can be quantified by measuring the performance metrics of the traffic from the classifier for each SFC/SFP.
SFC対応ネットワークデバイスは、各SFCに対して分類子コンポーネントのパフォーマンス測定を実行する機能を持つ必要があります。パフォーマンスは、各SFC / SFPごとに分類子からのトラフィックのパフォーマンスメトリックを測定することによって定量化できます。
The underlay network provides connectivity between the SFC components, so the availability or the performance of the underlay network directly impacts the SFC OAM.
アンダーレイネットワークはSFCコンポーネント間の接続性を提供しますので、利用可能性またはアンダーレイネットワークの性能はSFC OAMに直接影響します。
Any SFC-aware network device may have the ability to perform an availability check or performance measurement of the underlay network using any existing OAM functions listed in Section 5.1.
SFC対応ネットワークデバイスは、セクション5.1にリストされている既存のOAM関数を使用して、アンダーレイネットワークの可用性チェックまたはパフォーマンス測定を実行することができます。
The overlay network provides connectivity for the service plane between the SFC components and is mostly transparent to the SFC data-plane elements.
オーバーレイネットワークは、SFCコンポーネント間のサービスプレーンに対して接続性を提供し、SFCデータプレーン要素に対してほとんど透過的です。
Any SFC-aware network device may have the ability to perform an availability check or performance measurement of the overlay network using any existing OAM functions listed in Section 5.1.
SFC対応ネットワークデバイスは、セクション5.1にリストされている既存のOAM関数を使用して、オーバーレイネットワークの可用性チェックまたはパフォーマンス測定を実行することができます。
Section 3 described SFC OAM components and the associated OAM operations on each of them. This section explores SFC OAM functions that are applicable for more than one SFC component.
セクション3は、SFC OAMコンポーネントとそれぞれの関連OAM操作を説明しました。このセクションでは、複数のSFCコンポーネントに適用可能なSFC OAM関数を検討しています。
The various SFC OAM requirements listed in Section 3 highlight the need for various OAM functions at the service layer. As listed in Section 5.1, various OAM functions are in existence that are defined to perform OAM functionality at different layers. In order to apply such OAM functions at the service layer, they need to be enhanced to operate on a single SF/SFF or multiple SFs/SFFs spanning across one or more SFCs.
セクション3にリストされているさまざまなSFC OAM要件は、サービス層でさまざまなOAM機能の必要性を強調表示します。セクション5.1にリストされているように、さまざまなOAM機能が異なる層でOAM機能を実行するように定義されている存在しています。そのようなOAM機能をサービス層に適用するためには、1つまたは複数のSFCにわたる単一のSF / SFFまたは複数のSFS / SFFS上で動作するように強化する必要がある。
Connectivity is mainly an on-demand function to verify that connectivity exists between certain network elements and that the SFs are available. For example, Label Switched Path (LSP) Ping [RFC8029] is a common tool used to perform this function for an MPLS network. Some of the OAM functions performed by connectivity functions are as follows:
接続性は主に、特定のネットワーク要素間で接続性が存在し、SFSが利用可能であることを確認するためのオンデマンド機能です。たとえば、LABEL Switched Path（LSP）PING [RFC8029]は、MPLSネットワークに対してこの機能を実行するために使用される一般的なツールです。接続機能によって実行されるOAM関数のいくつかは次のとおりです。
* Verify the Path MTU from a source to the destination SF or through the SFC. This requires the ability for the OAM packet to be of variable length.
* ソースから宛先SFまたはSFCを介してパスMTUを確認してください。これには、OAMパケットが可変長になる機能が必要です。
* Detect any packet reordering and corruption.
* パケットの並べ替えと破損を検出します。
* Verify that an SFC or SF is applying the expected policy.
* SFCまたはSFが予想されるポリシーを適用していることを確認してください。
* Verify and validate forwarding paths.
* 転送パスを確認して検証します。
* Proactively test alternate or protected paths to ensure reliability of network configurations.
* ネットワーク構成の信頼性を確保するために、代替パスまたは保護されたパスを積極的にテストします。
Continuity is a model where OAM messages are sent periodically to validate or verify the reachability of a given SF within an SFC or for the entire SFC. This allows a monitoring network device (such as the classifier or controller) to quickly detect failures, such as link failures, network element failures, SF outages, or SFC outages. BFD [RFC5880] is one such protocol that helps in detecting failures quickly. OAM functions supported by continuity functions are as follows:
継続性は、SFC内の特定のSFまたはSFC全体の到達可能性を検証または検証するために、OAMメッセージが定期的に送信されるモデルです。これにより、リンク障害、ネットワーク要素の障害、SF停止、またはSFC停止などの障害を迅速に検出することができます。BFD [RFC5880]は、障害を迅速に検出するのに役立つそのようなプロトコルの1つです。継続関数でサポートされているOAM関数は次のとおりです。
* Provision a continuity check to a given SF within an SFC or for the entire SFC.
* SFC内またはSFC全体の特定のSFに継続性チェックを提供します。
* Proactively test alternate or protected paths to ensure reliability of network configurations.
* ネットワーク構成の信頼性を確保するために、代替パスまたは保護されたパスを積極的にテストします。
* Notifying other OAM functions or applications of the detected failures so they can take appropriate action.
* 他のOAMの機能や検出された障害のアプリケーションを適切にすることができるように通知してください。
Tracing is an OAM function that allows the operation to trigger an action (e.g., response generation) from every transit device (e.g., SFF, SF, and SFC Proxy) on the tested layer. This function is typically useful for gathering information from every transit device or for isolating the failure point to a specific SF within an SFC or for an entire SFC. Some of the OAM functions supported by trace functions are:
トレースは、テスト済みレイヤ上のすべてのトランジットデバイス（例えば、SFF、SF、およびSFCプロキシ）から動作（例えば、応答生成）を起動することを可能にするOAM関数です。この機能は通常、すべてのトランジットデバイスから情報を収集するため、またはSFC内の特定のSFまたはSFC全体の障害点を特定のSFに分離するのに役立ちます。トレース関数でサポートされているOAM関数の一部は次のとおりです。
* the ability to trigger an action from every transit device at the SFC layer, using TTL or other means,
* TTLまたは他の手段を使用して、SFCレイヤーのすべてのトランジットデバイスからアクションをトリガーする機能
* the ability to trigger every transit device at the SFC layer to generate a response with OAM code(s) using TTL or other means,
* TTLまたは他の手段を使用してOAMコードを使用して応答を生成するためにSFCレイヤーですべてのトランジットデバイスをトリガーする機能。
* the ability to discover and traverse ECMP paths within an SFC, and
* SFC内のECMPパスを発見して通過する機能
* the ability to skip SFs that do not support OAM while tracing SFs in an SFC.
* SFSをSFCにトレースしながらOAMをサポートしないSFSをスキップする機能。
Performance measurement functions involve measuring of packet loss, delay, delay variance, etc. These performance metrics may be measured proactively or on demand.
性能測定機能は、パケット損失、遅延、遅延分散などの測定を含みます。これらの性能メトリックは、積極的またはオンデマンドで測定できます。
SFC OAM should provide the ability to measure packet loss for an SFC. On-demand measurement can be used to estimate packet loss using statistical methods. To ensure accurate estimations, one needs to ensure that OAM packets are treated the same and also share the same fate as regular data traffic.
SFC OAMは、SFCのパケット損失を測定する機能を提供する必要があります。オンデマンド測定は、統計的方法を使用してパケット損失を推定するために使用できます。正確な推定を確実にするためには、OAMパケットが同じように扱われ、通常のデータトラフィックと同じ運命を共有することを確認する必要があります。
Delay within an SFC could be measured based on the time it takes for a packet to traverse the SFC from the ingress SFC node to the egress SFF. Measurement protocols, such as the One-Way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357], can be used to measure delay characteristics. As SFCs are unidirectional in nature, measurement of one-way delay [RFC7679] is important. In order to measure one-way delay, time synchronization must be supported by means such as NTP, GPS, Precision Time Protocol (PTP), etc.
SFC内の遅延は、パケットが入力SFCノードから出力SFFへのSFCを横断するのにかかる時間に基づいて測定することができる。一方向アクティブ測定プロトコル（OWAMP）[RFC4656]および双方向アクティブ測定プロトコル（TWAMP）[RFC5357]などの測定プロトコルを使用して遅延特性を測定できます。SFCが本質的に一方向であるので、一方向遅延[RFC7679]の測定は重要です。一方向の遅延を測定するためには、NTP、GPS、精密時間プロトコル（PTP）などの手段で時間同期をサポートする必要があります。
One-way delay variation [RFC3393] could also be calculated by sending OAM packets and measuring the jitter for traffic passing through an SFC.
一方向遅延バリエーション[RFC3393]は、OAMパケットを送信し、SFCを通過するトラフィックのジッタを測定することによっても計算できます。
Some of the OAM functions supported by the performance measurement functions are:
パフォーマンス測定機能でサポートされているOAM機能の一部は次のとおりです。
* the ability to measure the packet processing delay induced by a single SF or the one-way delay to traverse an SFP bound to a given SFC, and
* 単一のSFによって引き起こされるパケット処理遅延を測定する能力または特定のSFCにバインドされたSFPを通過する能力
* the ability to measure the packet loss [RFC7680] within an SF or an SFP bound to a given SFC.
* 特定のSFCにバインドされたSFまたはSFP内のパケット損失[RFC7680]を測定する機能。
This section identifies various OAM functions available at different layers introduced in Section 2. It also identifies various gaps that exist within the current toolset for performing OAM functions required for SFC.
このセクションは、セクション2で導入されたさまざまなレイヤで利用可能なさまざまなOAM機能を識別します.SFCに必要なOAM機能を実行するための現在のツールセット内に存在するさまざまなギャップも識別します。
There are various OAM toolsets available to perform OAM functions within various layers. These OAM functions may be used to validate some of the underlay and overlay networks. Tools like ping and trace are in existence to perform connectivity checks and trace intermediate hops in a network. These tools support different network types, like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) [Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] offer OAM mechanisms, such as a continuity check for Ethernet links. There is an effort around NVO3 OAM to provide connectivity and continuity checks for networks that use NVO3. BFD is used for the detection of data-plane forwarding failures. The IPPM framework [RFC2330] offers tools such as OWAMP [RFC4656] and TWAMP [RFC5357] (collectively referred to as IPPM in this section) to measure various performance metrics. MPLS Packet Loss Measurement (LM) and Packet Delay Measurement (DM) (collectively referred to as MPLS_PM in this section) [RFC6374] offer the ability to measure performance metrics in MPLS networks. There is also an effort to extend the toolset to provide connectivity and continuity checks within overlay networks. BFD is another tool that helps in detecting data forwarding failures. Table 1 below is not exhaustive.
さまざまなレイヤー内にOAM機能を実行するために利用可能なさまざまなOAMツールセットがあります。これらのOAM関数は、アンダーレイネットワークとオーバーレイネットワークの一部を検証するために使用されます。 PINGやトレースのようなツールは、ネットワーク内の接続チェックとトレース中間ホップを実行するために存在します。これらのツールは、IP、MPLS、TRILLなどのような異なるネットワークタイプをサポートしています。イーサネットOAM（E-OAM）[Y.1731] [EFM]と接続障害管理（CFM）[DOT1Q]は、継続性チェックなどのOAMメカニズムを提供します。イーサネットリンクの場合。 NVO3を使用するネットワークの接続性と継続性チェックを提供するためのNVO3 OAMの労力があります。 BFDはデータプレーン転送障害の検出に使用されます。 IPPM Framework [RFC2330]は、さまざまなパフォーマンスメトリックを測定するために、OWAMP [RFC4656]やTWAMP [RFC5357]（このセクションではまとめてIPPMと呼びます）などのツールを提供します。 MPLSパケット損失測定（LM）とパケット遅延測定（DM）（このセクションではまとめてMPLS_PMと呼ばれます）[RFC6374] MPLSネットワークのパフォーマンスメトリックを測定できます。オーバーレイネットワーク内の接続性および継続性チェックを提供するためにツールセットを拡張するための努力もあります。 BFDは、データ転送障害の検出に役立つ別のツールです。以下の表1は網羅的ではありません。
+============+==============+============+=======+=============+
| Layer | Connectivity | Continuity | Trace | Performance |
+============+==============+============+=======+=============+
| Underlay | Ping | E-OAM, BFD | Trace | IPPM, |
| network | | | | MPLS_PM |
+------------+--------------+------------+-------+-------------+
| Overlay | Ping | BFD, NVO3 | Trace | IPPM |
| network | | OAM | | |
+------------+--------------+------------+-------+-------------+
| Classifier | Ping | BFD | Trace | None |
+------------+--------------+------------+-------+-------------+
| SF | None | None | None | None |
+------------+--------------+------------+-------+-------------+
| SFC | None | None | None | None |
+------------+--------------+------------+-------+-------------+
Table 1: OAM Tool Gap Analysis
表1：OAMツールギャップ分析
As shown in Table 1, there are no standards-based tools available at the time of this writing that can be used natively (i.e., without enhancement) for the verification of SFs and SFCs.
表1に示すように、SFSおよびSFCの検証のために（すなわち、強調されていない）この書き込み時に利用可能な標準ベースのツールはない。
Primary OAM functions exist for underlying layers. Tools like ping, trace, BFD, etc. exist in order to perform these OAM functions.
基礎となる層には一次OAM関数が存在します。これらのOAM機能を実行するために、PING、TRACE、BFDなどのツールがあります。
As depicted in Table 1, toolsets and solutions are required to perform the OAM functions at the service layer.
表1に示すように、サービス層でOAM機能を実行するためにツールセットおよび解決策が必要である。
This section describes the operational aspects of SFC OAM at the service layer to perform the SFC OAM function defined in Section 4 and analyzes the applicability of various existing OAM toolsets in the service layer.
このセクションでは、セクション4で定義されているSFC OAM関数を実行するためのSFC OAMの動作態様について説明し、サービス層内の様々な既存のOAMツールセットの適用性を分析します。
SFC OAM messages should be encapsulated with the necessary SFC header and with OAM markings when testing the SFC component. SFC OAM messages may be encapsulated with the necessary SFC header and with OAM markings when testing the SF component.
SFC OAMメッセージは、SFCコンポーネントをテストするときに必要なSFCヘッダーとOAMのマーキングでカプセル化されるべきです。SFC OAMメッセージは、SFコンポーネントをテストするときに必要なSFCヘッダーとOAMマーキングを使用してカプセル化できます。
The SFC OAM function described in Section 4 performed at the service layer or overlay network layer must mark the packet as an OAM packet so that relevant nodes can differentiate OAM packets from data packets. The base header defined in Section 2.2 of [RFC8300] assigns a bit to indicate OAM packets. When NSH encapsulation is used at the service layer, the O bit must be set to differentiate the OAM packet. Any other overlay encapsulations used at the service layer must have a way to mark the packet as an OAM packet.
サービス層またはオーバーレイネットワーク層で実行されたセクション4で説明されているSFC OAM機能は、そのようなノードがデータパケットからのOAMパケットを区別できるように、パケットをOAMパケットとしてマークする必要がある。[RFC8300]のセクション2.2で定義されているベースヘッダーは、OAMパケットを示すビットを割り当てます。NSHカプセル化がサービス層で使用されるとき、OAMパケットを区別するためにOビットを設定する必要があります。サービス層で使用される他のオーバーレイカプセル化は、パケットをOAMパケットとしてマークする方法が必要です。
Upon receiving an OAM packet, an SFC-aware SF may choose to discard the packet if it does not support OAM functionality or if the local policy prevents it from processing the OAM packet. When an SF supports OAM functionality, it is desirable to process the packet and provide an appropriate response to allow end-to-end verification. To limit performance impact due to OAM, SFC-aware SFs should rate-limit the number of OAM packets processed.
OAMパケットを受信すると、SFC対応SFは、OAM機能をサポートしていない場合、またはローカルポリシーがOAMパケットを処理するのを防止した場合にパケットを破棄することを選択することができる。SFがOAM機能をサポートするとき、パケットを処理し、エンドツーエンドの検証を可能にするために適切な応答を提供することが望ましい。OAMによるパフォーマンスの影響を制限するために、SFC対応SFSは処理されたOAMパケットの数をrate-制限する必要があります。
An SFF may choose to not forward the OAM packet to an SF if the SF does not support OAM or if the policy does not allow the forwarding of OAM packets to that SF. The SFF may choose to skip the SF, modify the packet's header, and forward the packet to the next SFC node in the chain. It should be noted that skipping an SF might have implications on some OAM functions (e.g., the delay measurement may not be accurate). The method by which an SFF detects if the connected SF supports or is allowed to process OAM packets is outside the scope of this document. It could be a configuration parameter instructed by the controller, or it can be done by dynamic negotiation between the SF and SFF.
SFがOAMがOAMをサポートしていない場合、またはポリシーがそのSFへのOAMパケットの転送を許可しない場合、SFFはOAMパケットをSFに転送することを選択できます。SFFはSFをスキップし、パケットのヘッダーを変更し、チェーン内の次のSFCノードにパケットを転送することを選択できます。SFをスキップすると、いくつかのOAM関数（例えば、遅延測定が正確ではないかもしれない）に影響を与える可能性があることに留意されたい。接続されているSFがサポートしているかOAMパケットを処理することを許可されているかどうかをSFFが検出する方法は、この文書の範囲外です。これはコントローラによって指示された構成パラメータであるか、またはSFとSFFの間の動的ネゴシエーションによって行うことができます。
If the SFF receiving the OAM packet bound to a given SFC is the last SFF in the chain, it must send a relevant response to the initiator of the OAM packet. Depending on the type of OAM solution and toolset used, the response could be a simple response (such as ICMP reply) or could include additional data from the received OAM packet (like statistical data consolidated along the path). The details are expected to be covered in the solution documents.
特定のSFCにバインドされたOAMパケットを受信したSFFがチェーン内の最後のSFFである場合は、OAMパケットのイニシエータに関連する応答を送信する必要があります。使用されるOAMソリューションとツールセットの種類に応じて、応答は単純な応答（ICMP応答など）でもかまいません。また、受信したOAMパケットからの追加データ（統計データに沿って統合された統計データなど）を含めることができます。詳細はソリューション文書で覆われると予想されます。
Any SFC-aware node that initiates an OAM packet must set the OAM marker in the overlay encapsulation.
OAMパケットを開始するSFC対応ノードは、オーバーレイカプセル化にOAMマーカーを設定する必要があります。
As described in Section 4, there are different OAM functions that may require different OAM solutions. While the presence of the OAM marker in the overlay header (e.g., O bit in the NSH header) indicates it as an OAM packet, it is not sufficient to indicate what OAM function the packet is intended for. The Next Protocol field in the NSH header may be used to indicate what OAM function is intended or what toolset is used. Any other overlay encapsulations used at the service layer must have a similar way to indicate the intended OAM function.
セクション4に記載されているように、異なるOAMソリューションを必要とする可能性がある異なるOAM機能があります。オーバーレイヘッダ（例えば、NSHヘッダ内のOビット）内のOAMマーカーの存在は、それをOAMパケットとして示しているが、パケットがどのようなOAM機能を対象としているかを示すのに十分ではない。NSHヘッダーの次のプロトコルフィールドを使用して、どのOAM機能が意図されているか、またはどのツールセットが使用されるかを示すことができます。サービス層で使用される他のオーバーレイカプセル化は、意図されたOAM機能を示すと同様の方法でなければなりません。
As described in Section 5.1, there are different toolsets available to perform OAM functions at different layers. This section describe the applicability of some of the available toolsets in the service layer.
セクション5.1で説明されているように、異なるレイヤでOAM機能を実行するために利用可能なさまざまなツールセットがあります。このセクションでは、サービス層の利用可能なツールセットの一部の適用性について説明します。
[RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6 networks respectively. It explains how ICMP messages can be used to test the network reachability between different end points and perform basic network diagnostics.
[RFC0792]および[RFC4443] IPv4ネットワークとIPv6ネットワークのICMPの使用方法について説明します。ICMPメッセージを使用して、さまざまなエンドポイント間のネットワーク到達可能性をテストして基本的なネットワーク診断を実行する方法について説明します。
ICMP could be leveraged for connectivity functions (defined in Section 4.1) to verify the availability of an SF or SFC. The initiator can generate an ICMP echo request message and control the service-layer encapsulation header to get the response from the relevant node. For example, a classifier initiating OAM can generate an ICMP echo request message, set the TTL field in the NSH header [RFC8300] to 63 to get the response from the last SFF, and thereby test the SFC availability. Alternatively, the initiator can set the TTL to some other value to get the response from a specific SF and thereby partially test SFC availability, or the initiator could send OAM packets with sequentially incrementing TTL in the NSH to trace the SFP.
ICMPは、SFまたはSFCの可用性を確認するために、接続機能（セクション4.1で定義）のために活用できます。イニシエータはICMPエコー要求メッセージを生成し、関連するノードからの応答を得るためにサービス層のカプセル化ヘッダを制御することができる。たとえば、OAMがICMPエコー要求メッセージを生成でき、NSHヘッダー[RFC8300]にTTLフィールドを63に設定して、最後のSFFからの応答を取得し、SFCの可用性をテストします。あるいは、イニシエータは、特定のSFからの応答を取得するためにTTLを他の値に設定し、それによってSFCの可用性を部分的にテストするか、またはイニシエータがNSHにTTLを順次インクリメントしてSFPをトレースすることができるOAMパケットを送信することができる。
It could be observed that ICMP as currently defined may not be able to perform all required SFC OAM functions, but as explained above, it can be used for some of the connectivity functions.
現在定義されているICMPはすべての必要なSFC OAM機能を実行できないかもしれないが、上で説明したように、いくつかの接続機能に使用することができることが観察され得る。
[RFC5880] defines the Bidirectional Forwarding Detection (BFD) mechanism for failure detection. [RFC5881] and [RFC5884] define the applicability of BFD in IPv4, IPv6, and MPLS networks. [RFC7880] defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. [RFC7881] explains its applicability in IPv4, IPv6, and MPLS networks.
[RFC5880]故障検出のための双方向転送検出（BFD）メカニズムを定義します。[RFC5881]および[RFC5884] IPv4、IPv6、およびMPLSネットワークにおけるBFDの適用性を定義します。[RFC7880] Seamless BFD（S-BFD）、BFDを使用する簡素化されたメカニズムである。[RFC7881] IPv4、IPv6、およびMPLSネットワークにおけるその適用性について説明します。
BFD or S-BFD could be leveraged to perform the continuity function for SF or SFC. An initiator could generate a BFD control packet and set the "Your Discriminator" value in the control packet to identify the last SFF. Upon receiving the control packet, the last SFF in the SFC will reply back with the relevant DIAG code. The TTL field in the NSH header could be used to perform a partial SFC availability check. For example, the initiator can set the "Your Discriminator" value to identify the SF that is intended to be tested and set the TTL field in the NSH header in a way that it expires at the relevant SF. How the initiator gets the Discriminator value to identify the SF is outside the scope of this document.
BFDまたはS-BFDは、SFまたはSFCの連続機能を実行するために活用できます。イニシエータはBFD制御パケットを生成し、最後のSFFを識別するために制御パケット内の「あなたの識別子」値を設定することができる。制御パケットを受信すると、SFC内の最後のSFFは関連するダイアグコードで返信します。NSHヘッダーのTTLフィールドを使用して、部分的なSFCの可用性チェックを実行できます。たとえば、イニシエータは、テストされることを意図したSFを識別し、関連するSFで期限切れになるように、NSHヘッダーのTTLフィールドを設定することを目的としたSFを識別できます。イニシエータが識別子の値を取得する方法SFを識別する方法は、この文書の範囲外です。
[IOAM-NSH] defines how In situ OAM data fields [IPPM-IOAM-DATA] are transported using the NSH header. [PROOF-OF-TRANSIT] defines a mechanism to perform proof of transit to securely verify if a packet traversed the relevant SFP or SFC. While the mechanism is defined inband (i.e., it will be included in data packets), IOAM Option-Types, such as IOAM Trace Option-Types, can also be used to perform other SFC OAM functions, such as SFC tracing.
[IOAM-NSH] NSHヘッダーを使用して、その場OAMデータフィールド[IPPM-IOAM-DATA]がどのように転送されるかを定義します。[遷移証明]パケットが関連するSFPまたはSFCを通過したかどうかを安全に検証するための輸送証明を実行するためのメカニズムを定義します。メカニズムはインバンド（すなわち、データパケットに含まれます）は、IOAMトレースオプションタイプなどのIOAMオプションタイプを使用して、SFCトレースなどの他のSFC OAM関数を実行することもできます。
In situ OAM could be leveraged to perform SF availability and SFC availability or performance measurement. For example, if SFC is realized using NSH, the O bit in the NSH header could be set to indicate the OAM traffic, as defined in Section 4.2 of [IOAM-NSH].
SFの可用性とSFCの可用性やパフォーマンス測定を実行するために、その場OAMを活用することができます。たとえば、SFCがNSHを使用して実現されている場合、NSHヘッダーのOビットは[IOAM-NSH]のセクション4.2で定義されているように、OAMトラフィックを示すように設定できます。
[SFC-TRACE] defines a protocol that checks for path liveliness and traces the service hops in any SFP. Section 3 of [SFC-TRACE] defines the SFC trace packet format, while Sections 4 and 5 of [SFC-TRACE] define the behavior of SF and SFF respectively. While [SFC-TRACE] has expired, the proposal is implemented in Open Daylight and is available.
[SFC-TRACE]パスの動きをチェックし、どのSFPのサービスホップをトレースするプロトコルを定義します。[SFC-TRACE]のセクション3はSFCトレースパケットフォーマットを定義し、[SFC-TRACE]のセクション4,5はそれぞれSFとSFFの動作を定義します。[SFC-TRACE]が期限切れになっている間、プロポーザルはOpen Daylightで実装されています。
An initiator can control the Service Index Limit (SIL) in an SFC trace packet to perform SF and SFC availability tests.
イニシエータはSFCトレースパケット内のサービスインデックス制限（SIL）を制御してSFおよびSFCの可用性テストを実行できます。
This document does not define any new manageability tools but consolidates the manageability tool gap analysis for SF and SFC. Table 2 below is not exhaustive.
この文書は新しい管理ツールを定義していませんが、SFとSFCの管理容易性ツールギャップ分析を統合します。下記の表2は網羅的ではありません。
+===========+===============+===============+========+==============+
|Layer | Configuration | Orchestration |Topology|Notification |
+===========+===============+===============+========+==============+
|Underlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, |
|network | | | |NETCONF |
+-----------+---------------+---------------+--------+--------------+
|Overlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, |
|network | | | |NETCONF |
+-----------+---------------+---------------+--------+--------------+
|Classifier | CLI, NETCONF | CLI, NETCONF |None |None |
+-----------+---------------+---------------+--------+--------------+
|SF | CLI, NETCONF | CLI, NETCONF |None |None |
+-----------+---------------+---------------+--------+--------------+
|SFC | CLI, NETCONF | CLI, NETCONF |None |None |
+-----------+---------------+---------------+--------+--------------+
Table 2: OAM Tool Gap Analysis
表2：OAMツールギャップ分析
Configuration, orchestration, and other manageability tasks of SF and SFC could be performed using CLI, NETCONF [RFC6241], etc.
SFおよびSFCの構成、オーケストレーション、およびその他の管理性タスクは、CLI、NetConf [RFC6241]などを使用して実行できます。
While the NETCONF capabilities are readily available, as depicted in Table 2, the information and data models are needed for configuration, manageability, and orchestration for SFC. With virtualized SF and SFC, manageability needs to be done programmatically.
NETCONF機能は容易に入手可能であるが、表2に示すように、情報モデルおよびデータモデルは、SFCの構成、管理性、およびオーケストレーションに必要である。仮想化されたSFとSFCを使用すると、管理性はプログラムで行う必要があります。
Any security considerations defined in [RFC7665] and [RFC8300] are applicable for this document.
[RFC7665]と[RFC8300]で定義されているセキュリティ上の考慮事項は、この文書に適用されます。
The OAM information from the service layer at different components may collectively or independently reveal sensitive information. The information may reveal the type of service functions hosted in the network, the classification rules and the associated service chains, specific service function paths, etc. The sensitivity of the information from the SFC layer raises a need for careful security considerations.
異なる構成要素におけるサービス層からのOAM情報は、集合的または独立して機密情報を明らかにすることがある。この情報は、ネットワーク内でホストされているサービス機能の種類、分類規則、および関連するサービスチェーン、特定のサービス機能パスなどを明らかにしてもよい.SFC層からの情報の感度は、慎重なセキュリティ上の考慮事項に対する必要性を高める。
The mapping and the rules information at the classifier component may reveal the traffic rules and the traffic mapped to the SFC. The SFC information collected at an SFC component may reveal the SFs associated within each chain, and this information together with classifier rules may be used to manipulate the header of synthetic attack packets that may be used to bypass the SFC and trigger any internal attacks.
マッピングと分類子コンポーネントの規則情報は、トラフィックルールとSFCにマッピングされたトラフィックを明らかにするかもしれません。SFCコンポーネントで収集されたSFC情報は、各チェーン内に関連付けられているSFSを明らかにすることがあり、この情報は、SFCを迂回して内部攻撃を引き起こすために使用され得る合成攻撃パケットのヘッダを操作するために使用されてもよい。
The SF information at the SF component may be used by a malicious user to trigger a Denial of Service (DoS) attack by overloading any specific SF using rogue OAM traffic.
SFコンポーネントのSF情報は、悪意のあるユーザーが不正なOAMトラフィックを使用して特定のSFを過負荷にすることで、サービス拒否（DOS）攻撃を引き起こすために使用されます。
To address the above concerns, SFC and SF OAM should provide mechanisms for mitigating:
上記の懸念に対処するために、SFCおよびSF OAMは軽減のためのメカニズムを提供するべきです。
* misuse of the OAM channel for denial of services,
* サービス拒否のためのOAMチャネルの誤用、
* leakage of OAM packets across SFC instances, and
* SFCインスタンスを越えたOAMパケットの漏洩、および
* leakage of SFC information beyond the SFC domain.
* SFCドメインを超えたSFC情報の漏洩
The documents proposing the OAM solution for SF components should provide rate-limiting the OAM probes at a frequency guided by the implementation choice. Rate-limiting may be applied at the classifier, SFF, or the SF. The OAM initiator may not receive a response for the probes that are rate-limited resulting in false negatives, and the implementation should be aware of this. To mitigate any attacks that leverage OAM packets, future documents proposing OAM solutions should describe the use of any technique to detect and mitigate anomalies and various security attacks.
SFコンポーネント用のOAMソリューションを提案する文書は、実装選択によって導かれた周波数でOAMプローブを速度制限する必要があります。レート制限は、分類器、SFF、またはSFに適用することができる。OAMイニシエータは、誤ったネガティブをもたらすプローブの応答を受け取らず、実装はこれを認識するべきです。OAMパケットを活用する攻撃を軽減するために、OAMソリューションを提案する将来の文書は、異常とさまざまなセキュリティ攻撃を検出および軽減するための任意の技術の使用を説明する必要があります。
The documents proposing the OAM solution for any service-layer components should consider some form of message filtering to control the OAM packets entering the administrative domain or prevent leaking any internal service-layer information outside the administrative domain.
任意のサービス層コンポーネントのOAMソリューションを提案する文書は、管理ドメインに入力されたOAMパケットを制御するためのメッセージフィルタリングの一形態を検討するか、管理ドメインの外部の内部サービス層情報を漏らすのを防ぐべきです。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[DOT1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, November 2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[DOT1Q] IEEE、「地元の地域と首都圏ネットワークのIEEE規格 - ブリッジとブリッジネットワーク」、IEEE 802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014年11月、<https：//doi.org/10.1109/ieeeestd.2014.6991462>。
[EFM] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, DOI 10.1109/IEEESTD.2018.8457469, June 2018, <https://doi.org/10.1109/IEEESTD.2018.8457469>.
[EFM] IEEE、「イーサネットのためのIEEE規格」、IEEE 802.3-2018、DOI 10.1109 / IEEESTD.2018.8457469、2018年6月、<https：//doi.org/10.1109/ieeeestd.2018.8457469>。
[IOAM-NSH] Brockners, F. and S. Bhandari, "Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16 June 2020, <https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04>.
[IOAM-NSH] Brockners、F.およびS.Bhandari、「IOAM）の「ネットワークサービスヘッダー（NSH）カプセル化」、進行中の作業、インターネットドラフト、草案-IETF-SFC-IOAM-NSH-04,2020 6月16日、<https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04>。
[IPPM-IOAM-DATA] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-10, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-10>.
[IPPM-IOAM-DATA]ブロック、F.、Bhandari、S.、T.Mizrahi、「その場OAMのデータフィールド」、進行中の作業、インターネットドラフト、ドラフトIETF-IPPM-IOAM - データ - 2020年7月13日、<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-10>。
[PROOF-OF-TRANSIT] Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Youell, "Proof of Transit", Work in Progress, Internet-Draft, draft-ietf-sfc-proof-of-transit-06, 16 June 2020, <https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-06>.
[輸送証明]ブロック、F.、Bhandari、S.、Mizrahi、T.、Dara、S. Youell、「トランジットの証明」、進行中の作業、インターネットドラフト、ドラフト - IETF-SFC - Transit-06,206,16 6月16日、<https://tools.ietf.org/html/draft-ietf-sfc-proof-th-transit-06>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.
[RFC3393] Demichelis、C.およびP. Chimento、IPパフォーマンスメトリック（IPPM）のIPパケット遅延バリエーションメトリック、RFC 3393、DOI 10.17487 / RFC3393、2002年11月、<https：//www.rfc-editor.org/ info / rfc3393>。
[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>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、KARP、A.、Boote、J.、およびM.Zekauskas、「一方向アクティブ測定プロトコル（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006年、<https：//www.rfc-editor.org/info/rfc4656>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A。、YUM、K。、およびJ.Babiarz、「双方向アクティブ測定プロトコル（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008年、<https://www.rfc-editor.org/info/rfc5357>。
[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>.
[RFC5880] Katz、D.およびD.ワード、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.
[RFC5881] Katz、D.およびD. Ward、IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<https：///www.rfc-編集者.org / info / rfc5881>。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC5884] Aggarwal、R.、Kompella、K。、Nadeau、T.、およびG.ツバメ、「MPLSラベルスイッチパス（LSPS）」（LSP）の双方向転送検出（BFD） "、RFC 5884、DOI 10.17487 / RFC5884、2010年6月<https：//www.rfc-editor.org/info/rfc5884>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、Van Helvoort、H.、Bonica、R.、Romascanu、D.、およびS. Mansfield、「IETFのOAM「頭字語を使用するためのガイドライン」、BCP 161、RFC 6291、DOI 10.17487 / RFC6291、2011年6月、<https：//www.rfc-editor.org/info/rfc6291>。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374] Frost、D.およびS.ブライアント、「MPLSネットワークのパケット損失および遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<https：//www.rfc-editor.org/info/rfc6374>。
[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>。
[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>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向遅延メトリック（IPPM）」、STD 81、RFC 7679、DOI 10.17487/ RFC7679、2016年1月、<https://www.rfc-editor.org/info/rfc7679>。
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向損失測定基準（IPPM）」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<https://www.rfc-editor.org/info/rfc7680>。
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/info/rfc7880>.
[RFC7880] Pignataro、C、Ward、D.、Akiya、N.、Bhatia、M.、S. Pallagatti、「シームレス双方向転送検出（S-BFD）」、RFC 7880、DOI 10.17487 / RFC7880、2016年7月<https://www.rfc-editor.org/info/rfc7880>。
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, <https://www.rfc-editor.org/info/rfc7881>.
[RFC7881] PIGNATARO、C、WARD、D.、およびN.AKIYA、「IPv4、IPv6、およびMPLSのシームレス双方向転送検出（S-BFD）、RFC 7881、DOI 10.17487 / RFC7881、<HTTPS：//www.rfc-editor.org/info/rfc7881>。
[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>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、およびM. Chen、「マルチプロトコルラベルスイッチ付き（MPLS）データプレーン障害の検出」、RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https：//www.rfc-editor.org/info/rfc8029>。
[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>。
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>.
[RFC8459] Dolson、D.、Homma、S.、Lopez、D.、およびM. Boucadair、「階層サービス機能連鎖（HSFC）」、RFC 8459、DOI 10.17487 / RFC8459、2018年9月、<HTTPS：// WWW.rfc-editor.org / info / rfc8459>。
[SFC-TRACE] Penno, R., Quinn, P., Pignataro, C., and D. Zhou, "Services Function Chaining Traceroute", Work in Progress, Internet-Draft, draft-penno-sfc-trace-03, 30 September 2015, <https://tools.ietf.org/html/draft-penno-sfc-trace-03>.
[SFC-TRACE] Penno、R.、Quinn、P.、Pignataro、C.、およびD. Zhou、「サービス機能チェーンTraceroute」、進行中の作業、インターネットドラフト、ドラフト - Penno-SFC-TRACE-03、2015年9月30日、<https://tools.ietf.org/html/draft-penno-sfc-trace-03>。
[Y.1731] ITU-T, "G.8013: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", August 2015, <https://www.itu.int/rec/T-REC-G.8013-201508-I/en>.
[Y.1731] ITU-T、「G.8013：オペレーション、管理およびメンテナンス（OAM）機能とイーサネットベースネットワークのメカニズム "、2015年8月、<https：//www.itu.int/rec/t-REC-G.8013-201508-I / E>。
Acknowledgements
謝辞
We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados, Martin Duke, Barry Leiba, Éric Vyncke, Roman Danyliw, Erik Kline, Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray Kucherawy, and Alissa Cooper for their review and comments.
Mohamed Boucadair、Adrian Farrel、Greg Mirsky、Martin Vigouri、Tirumaleswar Reddy、Martin Bernados、Martin Duke、Barry Leiba、Barry Leiba、Robert Wilton、Frank Brockner、Martin Mizrahi、Tirumaleswar Reddy、Martin Duke、Barry LeibaAlvaro Retana、Murray Kucherawy、Alissa Cooperのレビューやコメント。
Contributors
貢献者
Nobo Akiya Ericsson
秋谷エリクソンなし
Email: nobo.akiya.dev@gmail.com
Authors' Addresses
著者の住所
Sam K. Aldrin Google
サムK. Aldrin Google
Email: aldrin.ietf@gmail.com
Carlos Pignataro (editor) Cisco Systems, Inc.
Carlos Pignataro（編集）Cisco Systems、Inc。
Email: cpignata@cisco.com
Nagendra Kumar (editor) Cisco Systems, Inc.
Nagendra Kumar（編集）Cisco Systems、Inc。
Email: naikumar@cisco.com
Ram Krishnan VMware
Ram Krishnan VMware
Email: ramkri123@gmail.com
Anoop Ghanwani Dell
Anoop Ghanwani Dell.
Email: anoop@alumni.duke.edu