[要約] RFC 8592は、ネットワークサービスヘッダ（NSH）のためのキーパフォーマンスインジケータ（KPI）スタンピングに関するものです。その目的は、NSHパケットにKPI情報を追加することで、ネットワークサービスのパフォーマンスを監視および最適化することです。
Independent Submission R. Browne
Request for Comments: 8592 A. Chilikin
Category: Informational Intel
ISSN: 2070-1721 T. Mizrahi
Huawei Network.IO Innovation Lab
May 2019
Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)
ネットワークサービスヘッダー（NSH）の主要業績評価指標（KPI）スタンピング
Abstract
概要
This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.
このドキュメントでは、ネットワークサービスヘッダー（NSH）を使用して主要業績評価指標（KPI）を伝達する方法について説明します。これらの方法は、たとえば、レイテンシとQoSマーキングを監視して、一部のリンクまたはサービス機能の問題を特定するために使用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8592.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8592で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
2.2. Definition of Terms ........................................3
2.2.1. Terms Defined in This Document ......................4
2.3. Abbreviations ..............................................5
3. NSH KPI Stamping: An Overview ...................................6
3.1. Prerequisites ..............................................7
3.2. Operation ..................................................9
3.2.1. Flow Selection ......................................9
3.2.2. SCP Interface ......................................10
3.3. Performance Considerations ................................11
4. NSH KPI-Stamping Encapsulation .................................12
4.1. KPI-Stamping Extended Encapsulation .......................13
4.1.1. NSH Timestamping Encapsulation (Extended Mode) .....15
4.1.2. NSH QoS-Stamping Encapsulation (Extended Mode) .....17
4.2. KPI-Stamping Encapsulation (Detection Mode) ...............20
5. Hybrid Models ..................................................22
5.1. Targeted VNF Stamping .....................................23
6. Fragmentation Considerations ...................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................25
Acknowledgments ...................................................27
Contributors ......................................................27
Authors' Addresses ................................................27
The Network Service Header (NSH), as defined by [RFC8300], specifies a method for steering traffic among an ordered set of Service Functions (SFs) using an extensible service header. This allows for flexibility and programmability in the forwarding plane to invoke the appropriate SFs for specific flows.
[RFC8300]で定義されているネットワークサービスヘッダー（NSH）は、拡張可能なサービスヘッダーを使用して、順序付けられたサービス機能（SF）のセット間でトラフィックをステアリングする方法を指定します。これにより、転送プレーンで柔軟性とプログラマビリティを実現し、特定のフローに適切なSFを呼び出すことができます。
The NSH promises a compelling vista of operational flexibility. However, many service providers are concerned about service and configuration visibility. This concern increases when considering that many service providers wish to run their networks seamlessly in "hybrid mode", whereby they wish to mix physical and virtual SFs and run services seamlessly between the two domains.
NSHは、運用の柔軟性に関する説得力のある展望を約束します。ただし、多くのサービスプロバイダーは、サービスと構成の可視性を懸念しています。多くのサービスプロバイダーが「ハイブリッドモード」でシームレスにネットワークを実行し、物理および仮想SFを混在させ、2つのドメイン間でサービスをシームレスに実行することを望んでいることを考えると、この懸念は高まります。
This document describes generic methods to monitor and debug Service Function Chains (SFCs) in terms of latency and QoS marking of the flows within an SFC. These are referred to as "detection mode" and "extended mode" and are explained in Section 4.
このドキュメントでは、SFC内のフローのレイテンシとQoSマーキングの観点からService Function Chain（SFC）を監視およびデバッグする一般的な方法について説明します。これらは「検出モード」および「拡張モード」と呼ばれ、セクション4で説明されています。
The methods described in this document are compliant with hybrid architectures in which Virtual Network Functions (VNFs) and Physical Network Functions (PNFs) are freely mixed in the SFC. These methods also provide flexibility for monitoring the performance and configuration of an entire chain or parts thereof as desired. These methods are extensible to monitoring other Key Performance Indicators (KPIs). Please refer to [RFC7665] for an architectural context for this document.
このドキュメントで説明する方法は、仮想ネットワーク機能（VNF）と物理ネットワーク機能（PNF）がSFCで自由に混在するハイブリッドアーキテクチャに準拠しています。これらの方法は、必要に応じてチェーン全体またはその一部のパフォーマンスと構成を監視する柔軟性も提供します。これらの方法は、他の主要業績評価指標（KPI）の監視に拡張できます。このドキュメントのアーキテクチャのコンテキストについては、[RFC7665]を参照してください。
The methods described in this document are not Operations, Administration, and Maintenance (OAM) protocols such as [Y.1731]. As such, they do not define new OAM packet types or operations. Rather, they monitor the SFC's performance and configuration for subscriber payloads and indicate subscriber QoE rather than out-of-band infrastructure metrics. This document differs from [In-Situ-OAM] in the sense that it is specifically tied to NSH operations and is not generic in nature.
このドキュメントで説明されている方法は、[Y.1731]などの運用、管理、および保守（OAM）プロトコルではありません。そのため、それらは新しいOAMパケットタイプまたは操作を定義しません。むしろ、サブスクライバーペイロードのSFCのパフォーマンスと構成を監視し、帯域外インフラストラクチャメトリックではなくサブスクライバーQoEを示します。このドキュメントは、NSH操作に具体的に関連付けられており、本質的に一般的ではないという点で[In-Situ-OAM]とは異なります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section presents the main terms used in this document. This document also makes use of the terms defined in [RFC7665] and [RFC8300].
このセクションでは、このドキュメントで使用される主な用語について説明します。このドキュメントでは、[RFC7665]と[RFC8300]で定義されている用語も使用しています。
First Stamping Node (FSN): The first node along an SFC that stamps packets using KPI stamping. The FSN matches each packet with a Stamping Controller (SC) flow based on (but not limited to) a stamping classification criterion such as transport 5-tuple coordinates.
First Stamping Node（FSN）：KPIスタンピングを使用してパケットにスタンプを付けるSFCに沿った最初のノード。 FSNは、トランスポート5タプル座標などのスタンピング分類基準に基づいて（ただし、これに限定されません）、スタンピングコントローラー（SC）フローと各パケットを照合します。
Last Stamping Node (LSN): The last node along an SFC that stamps packets using KPI stamping. From a forwarding point of view, the LSN removes the NSH and forwards the raw IP packet to the next hop. From a control-plane point of view, the LSN reads all the metadata (MD) and exports it to a system performance statistics agent or repository. The LSN should use the NSH Service Index (SI) to indicate if an SF was at the end of the chain. The LSN may change the Service Path Identifier (SPI) to a preconfigured value so that the network underlay forwards the MD back directly to the KPI database (KPIDB) based on this value.
最終スタンピングノード（LSN）：KPIスタンピングを使用してパケットにスタンプを付けるSFCの最後のノード。転送の観点から、LSNはNSHを削除し、生のIPパケットをネクストホップに転送します。コントロールプレーンの観点から見ると、LSNはすべてのメタデータ（MD）を読み取り、それをシステムパフォーマンス統計エージェントまたはリポジトリにエクスポートします。 LSNはNSHサービスインデックス（SI）を使用して、SFがチェーンの最後にあるかどうかを示す必要があります。 LSNはService Path Identifier（SPI）を事前構成された値に変更し、ネットワークアンダーレイがこの値に基づいてMDを直接KPIデータベース（KPIDB）に転送するようにします。
Key Performance Indicator Database (KPIDB): Denotes the external storage of MD for reporting, trend analysis, etc.
主要業績評価指標データベース（KPIDB）：レポート、傾向分析などのためのMDの外部ストレージを示します。
KPI stamping: The insertion of latency-related and/or QoS-related information into a packet using NSH MD.
KPIスタンピング：NSH MDを使用してパケットに遅延関連および/またはQoS関連情報を挿入します。
Flow ID: A unique 16-bit identifier written into the header by the classifier. This allows 65536 flows to be concurrently stamped on any given NSH service chain.
フローID：分類子によってヘッダーに書き込まれた一意の16ビット識別子。これにより、任意のNSHサービスチェーンで65536のフローを同時にスタンプできます。
QoS stamping: The insertion of QoS-related information into a packet using NSH MD.
QoSスタンピング：NSH MDを使用してパケットにQoS関連情報を挿入します。
Stamping Controller (SC): The central logic that decides what packets to stamp and how to stamp them. The SC instructs the classifier on how to build the parts of the NSH that are specific to KPI stamping.
スタンピングコントローラ（SC）：スタンプするパケットとスタンプ方法を決定する中央ロジック。 SCは、KPIスタンピングに固有のNSHの部分を構築する方法を分類子に指示します。
Stamping Control Plane (SCP): The control plane between the FSN and the SC.
スタンピングコントロールプレーン（SCP）：FSNとSC間のコントロールプレーン。
DEI Drop Eligible Indicator
DEIドロップ適格インジケーター
DSCP Differentiated Services Code Point
DSCP DiffServコードポイント
FSN First Stamping Node
FSN最初のスタンピングノード
KPI Key Performance Indicator
KPI主要業績評価指標
KPIDB Key Performance Indicator Database
KPIDB主要業績評価指標データベース
LSN Last Stamping Node
LSN最終スタンピングノード
MD Metadata
MDメタデータ
NFV Network Function Virtualization
NFVネットワーク機能の仮想化
NSH Network Service Header
NSHネットワークサービスヘッダー
OAM Operations, Administration, and Maintenance
OAMの運用、管理、保守
PCP Priority Code Point
PCP優先コードポイント
PNF Physical Network Function
PNF物理ネットワーク機能
PNFN Physical Network Function Node
PNFN物理ネットワーク機能ノード
QoE Quality of Experience
QoE Quality of Experience
QoS Quality of Service
QoS QoS
RSP Rendered Service Path
RSPレンダリングサービスパス
SC Stamping Controller
SCスタンピングコントローラ
SCL Service Classifier
SCLサービス分類子
SCP Stamping Control Plane
SCPスタンピングコントロールプレーン
SF Service Function
SFサービス機能
SFC Service Function Chain
SFCサービス機能チェーン
SI Service Index
SIサービスインデックス
SSI Stamp Service Index TS Timestamp
SSIスタンプサービスインデックスTSタイムスタンプ
VLAN Virtual Local Area Network
VLAN仮想ローカルエリアネットワーク
VNF Virtual Network Function
VNF仮想ネットワーク機能
A typical KPI-stamping architecture is presented in Figure 1.
典型的なKPIスタンプアーキテクチャを図1に示します。
Stamping
Controller
| KPIDB
| SCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( SFn )
\ FSN / \ / \ / \ LSN /
`---' `---' `---' `---'
Figure 1: Logical Roles in NSH KPI Stamping
図1：NSH KPIスタンピングの論理ロール
The SC will be part of the SFC control-plane architecture, but it is described separately in this document for clarity.
SCはSFCコントロールプレーンアーキテクチャの一部になりますが、明確にするために、このドキュメントでは個別に説明しています。
The SC is responsible for initiating start/stop stamp requests to the SCL or FSN and also for distributing the NSH-stamping policy into the service chain via the SCP interface.
SCは、SCLまたはFSNへの開始/停止スタンプ要求を開始し、SCPインターフェースを介してNSHスタンプポリシーをサービスチェーンに配信します。
The FSN will typically be part of the SCL but is called out as a separate logical entity for clarity.
FSNは通常SCLの一部ですが、明確にするために個別の論理エンティティとして呼び出されます。
The FSN is responsible for marking NSH MD fields; this tells nodes in the service chain how to behave in terms of stamping at the SF ingress, the SF egress, or both, or ignoring the stamp NSH MD completely.
FSNはNSH MDフィールドのマーキングを担当します。これは、サービスチェーン内のノードに、SF入力、SF出力、またはその両方でのスタンプ、またはスタンプNSH MDを完全に無視することに関して動作する方法を指示します。
The FSN also writes the Reference Time value, a (possibly inaccurate) estimate of the current time of day, into the header, allowing the "SPI:Flow ID" performance to be compared to previous samples for offline analysis.
また、FSNは現在時刻の（おそらく不正確な）推定値である参照時間値をヘッダーに書き込み、「SPI：Flow ID」のパフォーマンスをオフライン分析のために以前のサンプルと比較できるようにします。
The FSN should return an error to the SC if not synchronized to the current time of day and forward the packet along the service chain unchanged. The code and format of the error are specific to the protocol used between the FSN and SC; these considerations are out of scope.
現在の時刻に同期されていない場合、FSNはSCにエラーを返し、サービスチェーンに沿ってパケットを変更せずに転送します。エラーのコードと形式は、FSNとSCの間で使用されるプロトコルに固有です。これらの考慮事項は範囲外です。
SF1 and SF2 stamp the packets as dictated by the FSN and process the payload as per normal.
SF1とSF2は、FSNの指示に従ってパケットにスタンプを付け、通常どおりにペイロードを処理します。
Note 1: The exact location of the stamp creation may not be in the SF itself and may be applied by a hardware device -- for example, as discussed in Section 3.3.
注1：スタンプ作成の正確な場所はSF自体ではなく、ハードウェアデバイスによって適用される場合があります（たとえば、セクション3.3で説明）。
Note 2: Special cases exist where some of the SFs are NSH unaware. This is covered in Section 5.
注2：一部のSFがNSHを認識しない特殊なケースが存在します。これについては、セクション5で説明します。
The LSN should strip the entire NSH and forward the raw packet to the IP next hop as per [RFC8300]. The LSN also exports NSH-stamping information to the KPIDB for offline analysis; the LSN may export the stamping information of either (1) all packets or (2) a subset based on packet sampling.
LSNはNSH全体を取り除き、[RFC8300]のように生のパケットをIPネクストホップに転送する必要があります。 LSNは、オフライン分析のためにNSHスタンプ情報をKPIDBにエクスポートします。 LSNは、（1）すべてのパケットまたは（2）パケットサンプリングに基づくサブセットのいずれかのスタンピング情報をエクスポートできます。
In fully virtualized environments, the LSN is likely to be co-located with the SF that decrements the NSH SI to zero. Corner cases exist where this is not the case; see Section 5.
完全に仮想化された環境では、LSNは、NSH SIをゼロにデクリメントするSFと同じ場所に配置される可能性があります。これが当てはまらないコーナーケースが存在します。セクション5を参照してください。
Timestamping has its own set of prerequisites; however, these prerequisites are not required for QoS stamping. In order to guarantee MD accuracy, all servers hosting VNFs should be synchronized from a centralized stable clock. As it is assumed that PNFs do not timestamp (as this would involve a software change and a probable impact on throughput performance), there is no need for them to synchronize. There are two possible levels of synchronization:
タイムスタンプには独自の前提条件があります。ただし、これらの前提条件はQoSスタンピングには必要ありません。 MDの精度を保証するために、VNFをホストするすべてのサーバーは、集中化された安定したクロックから同期する必要があります。 PNFはタイムスタンプを付けないと想定されているため（ソフトウェアの変更やスループットパフォーマンスへの影響が考えられるため）、PNFを同期する必要はありません。同期には、次の2つのレベルがあります。
Level A: Low-accuracy time-of-day synchronization, based on NTP [RFC5905].
レベルA：NTP [RFC5905]に基づく、低精度の時刻同期。
Level B: High-accuracy synchronization (typically on the order of microseconds), based on [IEEE1588].
レベルB：[IEEE1588]に基づく高精度の同期（通常はマイクロ秒のオーダー）。
Each SF SHOULD have Level A synchronization and MAY have Level B synchronization.
各SFにはレベルAの同期があり、レベルBの同期があってもよい（MAY）。
Level A requires each platform (including the SC) to synchronize its system real-time clock to an NTP server. This is used to mark the MD in the chain, using the Reference Time field in the NSH KPI stamp header (Section 4.1). This timestamp is inserted into the NSH by the first SF in the chain. NTP accuracy can vary by several milliseconds between locations. This is not an issue, as the Reference Time is merely being used as a time-of-day reference inserted into the KPIDB for performance monitoring and MD retrieval.
レベルAでは、各プラットフォーム（SCを含む）がシステムのリアルタイムクロックをNTPサーバーに同期する必要があります。これは、NSH KPIスタンプヘッダー（セクション4.1）のReference Timeフィールドを使用して、チェーン内のMDをマークするために使用されます。このタイムスタンプは、チェーンの最初のSFによってNSHに挿入されます。 NTPの精度は、場所によって数ミリ秒異なる場合があります。これは問題ではありません。参照時間は、パフォーマンスの監視とMDの取得のためにKPIDBに挿入される時刻参照として使用されているだけだからです。
Level B synchronization requires each platform to be synchronized to a Primary Reference Clock (PRC) using the Precision Time Protocol (PTP) [IEEE1588]. A platform MAY also use Synchronous Ethernet [G.8261] [G.8262] [G.8264], allowing more accurate frequency synchronization.
レベルBの同期では、各プラットフォームを高精度時間プロトコル（PTP）[IEEE1588]を使用してプライマリ基準クロック（PRC）に同期する必要があります。プラットフォームは、同期イーサネット[G.8261] [G.8262] [G.8264]も使用する場合があり、より正確な周波数同期を可能にします。
If an SF is not synchronized at the moment of timestamping, it should indicate its synchronization status in the NSH. This is described in more detail in Section 4.
タイムスタンプの時点でSFが同期されていない場合は、NSHで同期ステータスを示す必要があります。これについては、セクション4で詳しく説明します。
By synchronizing the network in this way, the timestamping operation is independent of the current RSP. Indeed, the timestamp MD can indicate where a chain has been moved due to a resource starvation event as indicated in Figure 2, between VNF3 and VNF4 at time B.
この方法でネットワークを同期することにより、タイムスタンプ操作は現在のRSPから独立しています。実際、タイムスタンプMDは、図2に示すように、リソース不足のイベントが原因でチェーンが移動した場所を、時間BのVNF3とVNF4の間で示すことができます。
Delay
| v
| v
| x
| x x = Reference Time A
| xv v = Reference Time B
| xv
| xv
|______|______|______|______|______|_____
VNF1 VNF2 VNF3 VNF4 VNF5
Figure 2: Flow Performance in a Service Chain
図2：サービスチェーンのフローパフォーマンス
For QoS stamping, it is desired that the SCL or FSN be synchronized in order to provide a Reference Time for offline analysis, but this is not a hard requirement (they may be in holdover or free-run state, for example). Other SFs in the service chain do not need to be synchronized for QoS-stamping operations, as described below.
QoSスタンピングの場合、オフライン分析の参照時間を提供するためにSCLまたはFSNを同期することが望まれますが、これは難しい要件ではありません（たとえば、ホールドオーバーまたはフリーラン状態である可能性があります）。次に説明するように、サービスチェーン内の他のSFは、QoSスタンプ操作のために同期する必要はありません。
QoS stamping can be used to check the consistency of configuration across the entire chain or parts thereof. By adding all potential Layer 2 and Layer 3 QoS fields into a QoS sum at the SF ingress or egress, this allows quick identification of QoS mismatches across multiple Layer 2 / Layer 3 fields, which otherwise is a manual, expert-led consuming process.
QoSスタンピングを使用して、チェーン全体またはその一部全体の構成の整合性をチェックできます。すべての潜在的なレイヤー2およびレイヤー3 QoSフィールドをSF入力または出力のQoS合計に追加することで、複数のレイヤー2 /レイヤー3フィールド間でのQoSの不一致を迅速に特定できます。
|
|
| xy
| xy x = ingress QoS sum
| xv v = egress QoS sum
| xv y = egress QoS sum mismatch
| xv
|______|______|______|______|______|_____
SF1 SF2 SF3 SF4 SF5
Figure 3: Flow QoS Consistency in a Service Chain
図3：サービスチェーン内のフローQoSの整合性
Referring to Figure 3, x, v, and y are notional sum values of the QoS marking configuration of the flow within a given chain. As the encapsulation of the flow can change from hop to hop in terms of VLAN header(s), MPLS labels, or DSCP(s), these values are used to compare the consistency of configuration from, for example, payload DSCP through overlay and underlay QoS settings in VLAN IEEE 802.1Q bits, MPLS bits, and infrastructure DSCPs.
図3を参照すると、x、v、およびyは、特定のチェーン内のフローのQoSマーキング構成の概念的な合計値です。フローのカプセル化は、VLANヘッダー、MPLSラベル、またはDSCPの観点からホップ間で変化する可能性があるため、これらの値は、たとえば、ペイロードDSCPからオーバーレイまでの構成の整合性を比較するために使用されます。 VLAN IEEE 802.1Qビット、MPLSビット、インフラストラクチャDSCPのアンダーレイQoS設定。
Figure 3 indicates that, at SF4 in the chain, the egress QoS marking is inconsistent. That is, the ingress QoS settings do not match the egress. The method described here will indicate which QoS field(s) is inconsistent and whether this is ingress (where the underlay has incorrectly marked and queued the packet) or egress (where the SF has incorrectly marked and queued the packet.
図3は、チェーンのSF4では、出力QoSマーキングに一貫性がないことを示しています。つまり、入力QoS設定が出力と一致しません。ここで説明する方法は、どのQoSフィールドが不整合であり、これが入力（アンダーレイが誤ってマークしてパケットをキューに入れた）であるか、出力（SFがパケットを誤ってマークしてキューに入れた）であるかを示します。
Note that the SC must be aware of cases when an SF re-marks QoS fields deliberately and thus does not flag an issue for desired behavior.
SCは、SFがQoSフィールドを意図的に再マークし、したがって、望ましい動作の問題にフラグを立てない場合を認識しなければならないことに注意してください。
KPI-stamping detection mode uses MD Type 2 as defined in [RFC8300]. This involves the SFC classifier stamping the flow at the chain ingress and no subsequent stamps being applied; rather, each upstream SF can compare its local condition with the ingress value and take appropriate action. Therefore, detection mode is very efficient in terms of header size that does not grow after the classification. This is further explained in Section 4.2.
KPIスタンプ検出モードは、[RFC8300]で定義されているMD Type 2を使用します。これには、チェーン入口でフローをスタンプするSFC分類子が含まれ、後続のスタンプは適用されません。むしろ、各アップストリームSFは、そのローカル状態を入力値と比較して、適切なアクションを実行できます。したがって、検出モードは、分類後に大きくならないヘッダーサイズの点で非常に効率的です。これについては、セクション4.2で詳しく説明します。
The SC should maintain a list of flows within each service chain to be monitored. This flow table should be in the format "SPI:Flow ID". The SC should map these pairs to unique values presented as Flow IDs per service chain within the NSH TLV specified in this document (see Section 4). The SC should instruct the FSN to initiate timestamping
SCは、監視対象の各サービスチェーン内のフローのリストを維持する必要があります。このフローテーブルは、「SPI：Flow ID」の形式にする必要があります。 SCは、これらのペアを、このドキュメントで指定されているNSH TLV内のサービスチェーンごとのフローIDとして提示される一意の値にマッピングする必要があります（セクション4を参照）。 SCはFSNにタイムスタンプを開始するように指示する必要があります
on flow table match. The SC may also tell the classifier the duration of the timestamping operation, by either the number of packets in the flow or a certain time duration.
フローテーブルの一致。 SCは、フロー内のパケット数または特定の期間のいずれかによって、タイムスタンプ操作の期間を分類子に通知することもできます。
In this way, the system can monitor the performance of all en-route traffic, an individual subscriber in a chain, or just a specific application or QoS class that is used in the network.
このようにして、システムはすべての途中トラフィック、チェーン内の個々のサブスクライバー、またはネットワークで使用される特定のアプリケーションまたはQoSクラスのパフォーマンスを監視できます。
The SC should write the list of monitored flows into the KPIDB for correlation of performance and configuration data. Thus, when the KPIDB receives data from the LSN, it understands to which flow the data pertains.
SCは、パフォーマンスと構成データを関連付けるために、監視対象フローのリストをKPIDBに書き込む必要があります。したがって、KPIDBはLSNからデータを受信すると、データが関係するフローを理解します。
The association of a source IP address with a subscriber identity is outside the scope of this document and will vary by network application. For example, the method of association of a source IP address with an International Mobile Subscriber Identity (IMSI) will be different from how a Customer Premises Equipment (CPE) entity with a Network Address Translation (NAT) function may be chained in an enterprise NFV application.
送信元IPアドレスとサブスクライバIDの関連付けは、このドキュメントの範囲外であり、ネットワークアプリケーションによって異なります。たとえば、ソースIPアドレスを国際モバイル加入者識別情報（IMSI）に関連付ける方法は、ネットワークアドレス変換（NAT）機能を備えた顧客宅内機器（CPE）エンティティをエンタープライズNFVでチェーンする方法とは異なります。応用。
An SCP interface is required between the SC and the FSN or classifier. This interface is used to:
SCとFSNまたは分類子の間にSCPインターフェイスが必要です。このインターフェースは次の目的で使用されます。
o Query the SFC classifier for a list of active chains and flows.
o アクティブなチェーンとフローのリストについてSFC分類子をクエリします。
o Communicate which chains and flows to stamp. This can be a specific "SPI:Flow ID" combination or can include wildcards for monitoring subscribers across multiple chains or multiple flows within one chain.
o スタンプするチェーンとフローを伝えます。これは、特定の「SPI：Flow ID」の組み合わせにすることも、複数のチェーンまたは1つのチェーン内の複数のフロー全体でサブスクライバーを監視するためのワイルドカードを含めることもできます。
o Instruct how the stamp should be applied (ingress, egress, both ingress and egress, or specific).
o スタンプの適用方法を指示します（入力、出力、入力と出力の両方、または特定）。
o Indicate when to stop stamping (after either a certain number of packets or a certain time duration).
o スタンプを停止するタイミングを示します（特定の数のパケットまたは特定の期間の後）。
Typically, SCP timestamps flows for a certain duration for trend analysis but only stamps one packet of each QoS class in a chain periodically (perhaps once per day or after a network change). Therefore, timestamping is generally applied to a much larger set of packets than QoS stamping.
通常、SCPタイムスタンプはトレンド分析のために一定の期間フローしますが、チェーン内の各QoSクラスの1つのパケットのみを定期的にスタンプします（おそらく1日1回またはネットワークの変更後）。したがって、タイムスタンプは一般に、QoSスタンピングよりもはるかに大きなパケットセットに適用されます。
The exact specification of SCP is left for further study.
SCPの正確な仕様は、今後の研究に残されます。
This document does not mandate a specific stamping implementation method; thus, NSH KPI stamping can be performed by either hardware mechanisms or software.
このドキュメントでは、特定のスタンピング実装方法を義務付けていません。したがって、NSH KPIスタンピングは、ハードウェアメカニズムまたはソフトウェアのどちらでも実行できます。
If software-based stamping is used, applying and operating on the stamps themselves incur an additional small delay in the service chain. However, it can be assumed that these additional delays are all relative for the flow in question. This is only pertinent for timestamping mode, and not for QoS-stamping mode. Thus, whilst the absolute timestamps may not be fully accurate for normal non-timestamped traffic, they can be assumed to be relative.
ソフトウェアベースのスタンピングが使用されている場合、スタンプ自体を適用して操作すると、サービスチェーンに追加の小さな遅延が発生します。ただし、これらの追加の遅延はすべて、問題のフローに関連していると想定できます。これは、タイムスタンプモードにのみ関係し、QoSスタンプモードには関係ありません。したがって、絶対タイムスタンプは通常のタイムスタンプなしのトラフィックでは完全に正確ではない可能性がありますが、それらは相対的であると見なすことができます。
It is assumed that the methods described in this document would only operate on a small percentage of user flows.
このドキュメントで説明する方法は、ユーザーフローのごく一部でのみ機能すると想定されています。
The service provider may choose a flexible policy in the SC to timestamp a selection of a user plane every minute -- for example, to highlight any performance issues. Alternatively, the LSN may selectively export a subset of the KPI stamps it receives, based on a predefined sampling method. Of course, the SC can stress-test an individual flow or chain should a deeper analysis be required. We can expect that this type of deep analysis will have an impact on the performance of the chain itself whilst under investigation. This impact will be dependent on vendor implementations and is outside the scope of this document.
サービスプロバイダーは、SCで柔軟なポリシーを選択して、たとえばパフォーマンスの問題を強調するために、ユーザープレーンの選択に毎分タイムスタンプを付けることができます。あるいは、LSNは、事前定義されたサンプリング方法に基づいて、LSNが受信したKPIスタンプのサブセットを選択的にエクスポートできます。もちろん、より深い分析が必要な場合、SCは個々のフローまたはチェーンのストレステストを行うことができます。このタイプの詳細な分析は、調査中のチェーン自体のパフォーマンスに影響を与えると予想できます。この影響はベンダーの実装に依存し、このドキュメントの範囲外です。
For QoS stamping, the methods described here are even less intrusive, as typically packets are only QoS stamped periodically (perhaps once per day) to check service chain configuration per QoS class.
QoSスタンピングの場合、ここで説明する方法はさらに煩雑ではありません。通常、パケットには定期的に（おそらく1日に1回）QoSスタンプが付けられるだけなので、QoSクラスごとのサービスチェーン構成がチェックされます。
KPI stamping uses NSH MD Type 0x2 for detection of anomalies and extended mode for root-cause analysis of KPI violations. These are further explained in this section.
KPIスタンピングは、異常の検出にNSH MD Type 0x2を使用し、KPI違反の根本原因分析に拡張モードを使用します。これらについては、このセクションで詳しく説明します。
The generic NSH MD Type 2 TLV for KPI stamping is shown below.
KPIスタンピング用の汎用NSH MDタイプ2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|Type=2 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length KPI Metadata header and TLV(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Generic NSH KPI Encapsulation
図4：一般的なNSH KPIカプセル化
Relevant fields in the header that the FSN must implement are as follows:
FSNが実装する必要があるヘッダーの関連フィールドは次のとおりです。
o The O bit must not be set.
o Oビットをセットしないでください。
o The MD type must be set to 0x2.
o MDタイプは0x2に設定する必要があります。
o The Metadata Class must be set to a value from the experimental range 0xfff6 to 0xfffe according to an agreement by all parties to the experiment.
o メタデータクラスは、実験のすべての当事者による合意に従って、実験範囲0xfff6から0xfffeの値に設定する必要があります。
o Unassigned bits: All fields marked "U" are unassigned and available for future use [RFC8300].
o 割り当てられていないビット：「U」とマークされたすべてのフィールドは割り当てられておらず、将来使用するために使用できます[RFC8300]。
o The Type field may have one of the following values; the content of the Variable Length KPI Metadata header and TLV(s) field depends on the Type value:
o Typeフィールドには、次のいずれかの値を指定できます。可変長KPIメタデータヘッダーとTLV（s）フィールドの内容は、タイプの値によって異なります。
* Type = 0x01 (Det): Detection
* タイプ= 0x01（Det）：検出
* Type = 0x02 (TS): Timestamp Extended
* タイプ= 0x02（TS）：タイムスタンプ拡張
* Type = 0x03 (QoS): QoS stamp Extended
* タイプ= 0x03（QoS）：拡張QoSスタンプ
The Type field determines the type of KPI-stamping format. The supported formats are presented in the following subsections.
Typeフィールドは、KPIスタンプ形式のタイプを決定します。サポートされている形式は、次のサブセクションに示されています。
The generic NSH MD Type 2 KPI-stamping header (extended mode) is shown in Figure 5. This is the format for performance monitoring of service chain issues with respect to QoS configuration and latency.
一般的なNSH MD Type 2 KPIスタンプヘッダー（拡張モード）を図5に示します。これは、QoS構成と遅延に関するサービスチェーンの問題のパフォーマンス監視の形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|Type=2 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length KPI Configuration Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length KPI Value (LSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length KPI Value (FSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Generic KPI Encapsulation (Extended Mode)
図5：汎用KPIカプセル化（拡張モード）
As mentioned above, two types are defined under the experimental MD class to indicate the extended KPI MD: a timestamp type and a QoS-stamp type.
上記のように、実験的なMDクラスの下で、拡張KPI MDを示す2つのタイプが定義されています。タイムスタンプタイプとQoSスタンプタイプです。
The KPI Encapsulation Configuration Header format is shown below.
KPIカプセル化構成ヘッダーの形式を以下に示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|K|K|T|K|K|K|K|K| Stamping SI | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: KPI Encapsulation Configuration Header
図6：KPIカプセル化構成ヘッダー
The bits marked "K" are reserved for specific KPI type use and are described in the subsections below.
「K」とマークされたビットは、特定のKPIタイプの使用のために予約されており、以下のサブセクションで説明されています。
The T bit should be set if Reference Time follows the KPI Encapsulation Configuration Header.
参照時間がKPIカプセル化構成ヘッダーに続く場合は、Tビットを設定する必要があります。
The SSI (Stamping SI) contains the SI used for KPI stamping and is described in the subsections below.
SSI（スタンピングSI）には、KPIスタンピングに使用されるSIが含まれており、以下のサブセクションで説明されています。
The Flow ID is a unique 16-bit identifier written into the header by the classifier. This allows 65536 flows to be concurrently stamped on any given NSH service chain (SPI). Flow IDs are not written by subsequent SFs in the chain. The FSN may export monitored Flow IDs to the KPIDB for correlation.
フローIDは、分類子によってヘッダーに書き込まれる一意の16ビット識別子です。これにより、任意のNSHサービスチェーン（SPI）で65536のフローを同時にスタンプできます。フローIDは、チェーン内の後続のSFによって書き込まれません。 FSNは、相関のために監視対象のフローIDをKPIDBにエクスポートする場合があります。
Reference Time is the wall clock of the FSN and may be used for historical comparison of SC performance. If the FSN is not Level A synchronized (see Section 3.1), it should inform the SC over the SCP interface. The Reference Time is represented in 64-bit NTP format [RFC5905], as presented in Figure 7:
基準時間はFSNの壁時計であり、SCパフォーマンスの履歴比較に使用できます。 FSNがレベルA同期化されていない場合（セクション3.1を参照）、SCPインターフェースを介してSCに通知する必要があります。参照時間は、図7に示すように、64ビットNTP形式[RFC5905]で表されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: NTP 64-Bit Timestamp Format (RFC 5905)
図7：NTP 64ビットタイムスタンプ形式（RFC 5905）
The NSH timestamping extended encapsulation is shown below.
NSHタイムスタンプ拡張カプセル化を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|U|U|U|U|U|U| Length |U|U|U|U|Type=2 | NextProto |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type=TS(2) |U| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|E|T|U|U|U|SSI| Stamping SI | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Reference Time (T bit is set) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|E|U|U|U| SYN | Stamping SI | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Ingress Timestamp (I bit is set) (LSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Timestamp (E bit is set) (LSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|E|U|U|U| SYN | Stamping SI | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Ingress Timestamp (I bit is set) (FSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Timestamp (E bit is set) (FSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: NSH Timestamp Encapsulation (Extended Mode)
図8：NSHタイムスタンプカプセル化（拡張モード）
The FSN KPI stamp MD starts with the Stamping Configuration Header. This header contains the I, E, and T bits, and the SSI.
FSN KPIスタンプMDは、スタンピング構成ヘッダーで始まります。このヘッダーには、I、E、およびTビットとSSIが含まれています。
The I bit should be set if the Ingress stamp is requested.
入力スタンプが要求された場合、Iビットを設定する必要があります。
The E bit should be set if the Egress stamp is requested.
出力スタンプが要求される場合は、Eビットを設定する必要があります。
The SSI field must be set to one of the following values:
SSIフィールドは、次のいずれかの値に設定する必要があります。
o 0x0: KPI stamp mode. No SI is specified in the Stamping SI field.
o 0x0：KPIスタンプモード。スタンピングSIフィールドにSIが指定されていません。
o 0x1: KPI stamp hybrid mode is selected. The Stamping SI field contains the LSN SI. This is used when PNFs or NSH-unaware SFs are used at the tail of the chain. If SSI=0x1, then the value in the Type field informs the chain regarding which SF should act as the LSN.
o 0x1：KPIスタンプハイブリッドモードが選択されています。スタンピングSIフィールドにはLSN SIが含まれます。これは、チェーンの末尾でPNFまたはNSH非対応SFが使用されている場合に使用されます。 SSI = 0x1の場合、Typeフィールドの値は、どのSFがLSNとして機能するかに関してチェーンに通知します。
o 0x2: KPI stamp Specific mode is selected. The Stamping SI field contains the targeted SI. In this case, the Stamping SI field indicates which SF is to be stamped. Both Ingress stamps and Egress stamps are performed when the SI=SSI in the chain. For timestamping mode, the FSN will also apply the Reference Time and Ingress Timestamp. This will indicate the delay along the entire service chain to the targeted SF. This method may also be used as a light implementation to monitor end-to-end service chain performance whereby the targeted SF is the LSN. This is not applicable to QoS-stamping mode.
o 0x2：KPIスタンプ固有モードが選択されています。スタンピングSIフィールドには、ターゲットSIが含まれています。この場合、Stamping SIフィールドは、どのSFにスタンプするかを示します。チェーンでSI = SSIの場合、入力スタンプと出力スタンプの両方が実行されます。タイムスタンプモードの場合、FSNは参照時間と入力タイムスタンプも適用します。これは、対象のSFへのサービスチェーン全体の遅延を示します。この方法は、エンドツーエンドのサービスチェーンのパフォーマンスを監視するための簡単な実装としても使用できます。これにより、対象のSFはLSNになります。これは、QoSスタンプモードには適用されません。
Each stamping node adds stamp MD that consists of the Stamping Reporting Header and timestamps.
各スタンピングノードは、スタンピングレポートヘッダーとタイムスタンプで構成されるスタンプMDを追加します。
The E bit should be set if the Egress stamp is reported.
出力スタンプが報告される場合は、Eビットを設定する必要があります。
The I bit should be set if the Ingress stamp is reported.
入力スタンプが報告される場合は、Iビットを設定する必要があります。
With respect to timestamping mode, the SYN bits are an indication of the synchronization status of the node performing the timestamp and must be set to one of the following values:
タイムスタンプモードに関して、SYNビットは、タイムスタンプを実行するノードの同期ステータスの指標であり、次のいずれかの値に設定する必要があります。
o In synch: 0x00
o 同期：0x00
o In holdover: 0x01
o ホールドオーバー中：0x01
o In free run: 0x02
o フリーラン：0x02
o Out of synch: 0x03
o 非同期：0x03
If the platform hosting the SF is out of synch or in free run, no timestamp is applied by the node, and the packet is processed normally.
SFをホストしているプラットフォームが同期していないか、フリーランである場合、ノードによってタイムスタンプは適用されず、パケットは正常に処理されます。
If the FSN is out of synch or in free run, the timestamp request is rejected and is not propagated through the chain. In such an event, the FSN should inform the SC over the SCP interface. Similarly, if the KPIDB receives timestamps that are out of order (i.e., a timestamp of an "N+1" SF is prior to the timestamp of an "N" SF), it should notify the SC of this condition over the SCP interface.
FSNが同期していないか、フリーランである場合、タイムスタンプ要求は拒否され、チェーンを通じて伝播されません。そのような場合、FSNはSCPインターフェイスを介してSCに通知する必要があります。同様に、KPIDBが順不同のタイムスタンプを受信した場合（つまり、「N + 1」SFのタイムスタンプが「N」SFのタイムスタンプより前である場合）、SCPインターフェースを介してこの状態をSCに通知する必要があります。 。
The outer SI value is copied into the stamp MD as the Stamping SI to help cater to hybrid chains that are a mix of VNFs and PNFs or through NSH-unaware SFs. Thus, if a flow transits through a PNF or an NSH-unaware node, the delta in the inner SI between timestamps will indicate this.
外側のSI値は、スタンプMDとしてスタンプMDにコピーされ、VNFとPNFの混合であるハイブリッドチェーン、またはNSH非対応のSFに対応するのに役立ちます。したがって、フローがPNFまたはNSH非対応ノードを通過する場合、タイムスタンプ間の内部SIのデルタはこれを示します。
The Ingress Timestamp and Egress Timestamp are represented in 64-bit NTP format. The corresponding bits (I and E) are reported in the Stamping Reporting Header of the node's MD.
Ingress TimestampおよびEgress Timestampは64ビットNTP形式で表されます。対応するビット（IおよびE）は、ノードのMDのスタンピングレポートヘッダーで報告されます。
Packets have a variable QoS stack. For example, the same payload IP can have a very different stack in the access part of the network than the core. This is most apparent in mobile networks where, for example, in an access circuit we would have an infrastructure IP header (DSCP) composed of two layers -- one based on transport and the other based on IPsec -- in addition to multiple MPLS and VLAN tags. The same packet, as it leaves the Packet Data Network (PDN) Gateway Gi egress interface, may be very much simplified in terms of overhead and related QoS fields.
パケットには可変QoSスタックがあります。たとえば、同じペイロードIPは、コアとはネットワークのアクセス部分に非常に異なるスタックを持つことができます。これは、モバイルネットワークで最も顕著です。たとえば、アクセス回線では、複数のMPLSに加えて、トランスポートに基づくレイヤーとIPsecに基づくレイヤーの2つのレイヤーで構成されるインフラストラクチャIPヘッダー（DSCP）があります。 VLANタグ。同じパケットは、パケットデータネットワーク（PDN）ゲートウェイGi出力インターフェイスを出るので、オーバーヘッドと関連するQoSフィールドの点で非常に単純化される場合があります。
Because of this variability, we need to build extra meaning into the QoS headers. They are not, for example, all PTP timestamps of a fixed length, as in the case of timestamping; rather, they are of variable lengths and types. Also, they can be changed on the underlay at any time without the knowledge of the SFC system. Therefore, each SF must be able to ascertain and record its ingress and egress QoS configuration on the fly.
この可変性のため、QoSヘッダーに追加の意味を組み込む必要があります。たとえば、タイムスタンプの場合のように、固定長のすべてのPTPタイムスタンプではありません。むしろ、それらは可変長と型です。また、SFCシステムの知識がなくても、アンダーレイでいつでも変更できます。そのため、各SFは、入力と出力のQoS構成をオンザフライで確認および記録できる必要があります。
The suggested QoS Type (QT) and lengths are listed below.
推奨されるQoSタイプ（QT）と長さを以下に示します。
QoS Type Value Length Comment
----------------------------------------------------------
IVLAN 0x01 4 Bits Ingress VLAN (PCP + DEI)
EVLAN 0x02 4 Bits Egress VLAN
EVLAN 0x02 4ビット出力VLAN
IQINQ 0x03 8 Bits Ingress QinQ (2x (PCP + DEI))
IQINQ 0x03 8ビット入力QinQ（2x（PCP + DEI））
EQINQ 0x04 8 Bits Egress QinQ
EQINQ 0x04 8ビット出力QinQ
IMPLS 0x05 3 Bits Ingress Label
IMPLS 0x05 3ビット入力ラベル
EMPLS 0x06 3 Bits Egress Label
EMPLS 0x06 3ビット出力ラベル
IMPLS 0x07 6 Bits Two Ingress Labels (2x EXP)
IMPLS 0x07 6ビット2つの入力ラベル（2x EXP）
EMPLS 0x08 6 Bits Two Egress Labels
EMPLS 0x08 6ビット2つの出力ラベル
IDSCP 0x09 8 Bits Ingress DSCP
IDSCP 0x09 8ビット入力DSCP
EDSCP 0x0A 8 Bits Egress DSCP
EDSCP 0x0A 8ビット出力DSCP
For stacked headers such as MPLS and 802.1ad, we extract the relevant QoS data from the header and insert it into one QoS value in order to be more efficient in terms of packet size. Thus, for MPLS, we represent both experimental bits (EXP) fields in one QoS value, and both 802.1p priority and drop precedence in one QoS value, as indicated above.
MPLSや802.1adなどのスタックヘッダーの場合、関連するQoSデータをヘッダーから抽出し、1つのQoS値に挿入して、パケットサイズの効率を高めます。したがって、MPLSの場合、上記のように、両方のEXPビットフィールドを1つのQoS値で表し、802.1p優先度とドロップ優先度の両方を1つのQoS値で表します。
For stack types not listed here (for example, three or more MPLS tags), the SF would insert IMPLS/EMPLS several times, with each layer in the stack indicating EXP QoS for that layer.
ここに記載されていないスタックタイプ（3つ以上のMPLSタグなど）の場合、SFはIMPLS / EMPLSを数回挿入し、スタック内の各レイヤーがそのレイヤーのEXP QoSを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|U|U|U|U|U|U| Length |U|U|U|U|Type=2 | NextProto=0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type=QoS(3) |U| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|U|T|U|U|U|SSI| Stamping SI | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Reference Time (T bit is set) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|U|U|U|U|U|U|U| Stamping SI | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| QT | QoS Value |U|U|U|E| QT | QoS Value |U|U|U|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|U|U|U|U|U|U|U| Stamping SI | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| QT | QoS Value |U|U|U|E| QT | QoS Value |U|U|U|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: NSH QoS Configuration Encapsulation (Extended Mode)
図9：NSH QoS構成のカプセル化（拡張モード）
The encapsulation in Figure 9 is very similar to the encapsulation detailed in Section 4.1.1, with the following exceptions:
図9のカプセル化は、セクション4.1.1で詳述したカプセル化と非常に似ていますが、次の点が異なります。
o I and E bits are not required, as we wish to examine the full QoS stack at the ingress and egress at every SF.
o すべてのSFの入口と出口で完全なQoSスタックを調べたいので、IビットとEビットは必要ありません。
o SYN status bits are not required.
o SYNステータスビットは不要です。
o The QT and QoS values are as outlined in the list above.
o QTとQoSの値は、上記のリストで概説されているとおりです。
o The E bit at the tail of each QoS context field indicates if this is the last egress QoS stamp for a given SF. This should coincide with SI=0 at the LSN, whereby the packet is truncated, the NSH MD is sent to the KPIDB, and the subscriber's raw IP packet is forwarded to the underlay next hop.
o 各QoSコンテキストフィールドの末尾にあるEビットは、これが特定のSFの最後の出力QoSスタンプであるかどうかを示します。これは、LSNでSI = 0と一致する必要があります。これにより、パケットが切り捨てられ、NSH MDがKPIDBに送信され、サブスクライバーの未加工IPパケットがアンダーレイネクストホップに転送されます。
Note: It is possible to compress the frame structure to better utilize the header, but this would come at the expense of crossing byte boundaries. For ease of implementation, and so that QoS stamping is applied on an extremely small subset of user-plane traffic, we believe that the above structure is a pragmatic compromise between header efficiency and ease of implementation.
注：フレーム構造を圧縮してヘッダーをより有効に活用することは可能ですが、これはバイト境界を越えることを犠牲にして行われます。実装を容易にし、QoSスタンピングがユーザープレーントラフィックの非常に小さなサブセットに適用されるように、上記の構造はヘッダーの効率と実装の容易さの間の実用的な妥協であると考えています。
The format of the NSH MD Type 2 KPI-stamping TLV (detection mode) is shown in Figure 10.
NSH MDタイプ2 KPIスタンプTLV（検出モード）のフォーマットを図10に示します。
This TLV is used for KPI anomaly detection. Upon detecting a problem or an anomaly, it will be possible to enable the use of KPI-stamping extended encapsulations, which will provide more detailed analysis.
このTLVは、KPI異常検出に使用されます。問題または異常を検出すると、より詳細な分析を提供するKPIスタンプ拡張カプセル化を使用できるようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|Type=2 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type=Det(1) |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KPI Type | Stamping SI | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold KPI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress KPI stamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Generic NSH KPI Encapsulation (Detection Mode)
図10：汎用NSH KPIカプセル化（検出モード）
The following fields are defined in the KPIDB MD:
以下のフィールドがKPIDB MDで定義されています。
o KPI Type: This field determines the type of KPI stamp that is included in this MD. If a receiver along the path does not understand the KPI type, it will pass the packet on transparently and will not drop it. The supported values of KPI Type are:
o KPIタイプ：このフィールドは、このMDに含まれるKPIスタンプのタイプを決定します。パス上のレシーバーがKPIタイプを理解しない場合、パケットは透過的に渡され、ドロップされません。 KPIタイプのサポートされている値は次のとおりです。
* 0x0: Timestamp
* 0x0：タイムスタンプ
* 0x1: QoS stamp
* 0x1：QoSスタンプ
o Threshold KPI Value: In the first header, the SFC classifier may program a KPI threshold value. This is a value that, when exceeded, requires the SF to insert the current SI value into the SI field. The KPI type is the type of KPI stamp inserted into the header as per Figure 10.
o しきい値KPI値：最初のヘッダーで、SFC分類子はKPIしきい値をプログラムできます。これは、超過したときに、SFが現在のSI値をSIフィールドに挿入する必要がある値です。 KPIタイプは、図10のようにヘッダーに挿入されるKPIスタンプのタイプです。
o Stamping SI: This is the Service Identifier of the SF when the above threshold value is exceeded.
o スタンピングSI：これは、上記のしきい値を超えた場合のSFのサービスIDです。
o Flow ID: The Flow ID is inserted into the header by the SFC classifier in order to correlate flow data in the KPIDB for offline analysis.
o フローID：フロー分析は、オフライン分析のためにKPIDBのフローデータを関連付けるために、SFC分類子によってヘッダーに挿入されます。
o Ingress KPI stamp: The last 8 octets are reserved for the KPI stamp. This is the KPI value at the chain ingress at the SFC classifier. Depending on the KPI type, the KPI stamp includes either a timestamp or a QoS stamp. If the KPI type is Timestamp, then the Ingress KPI stamp field contains a timestamp in 64-bit NTP timestamp format. If the KPI type is QoS stamp, then the format of the 64-bit Ingress KPI stamp is as follows.
o 入力KPIスタンプ：最後の8オクテットはKPIスタンプ用に予約されています。これは、SFC分類器のチェーン入口でのKPI値です。 KPIタイプに応じて、KPIスタンプにはタイムスタンプまたはQoSスタンプのいずれかが含まれます。 KPIタイプがタイムスタンプの場合、入力KPIスタンプフィールドには64ビットNTPタイムスタンプ形式のタイムスタンプが含まれます。 KPIタイプがQoSスタンプの場合、64ビットの入力KPIスタンプの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QT | QoS Value | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: QoS-Stamp Format (Detection Mode)
図11：QoSスタンプ形式（検出モード）
As an example operation, let's say we are using KPI type 0x01 (Timestamp). When an SF (say SFn) receives the packet, it can compare the current local timestamp (it first checks that it is synchronized to the network's PRC) with the chain Ingress Timestamp to calculate the latency in the chain. If this value exceeds the timestamp threshold, it then inserts its SI and returns the NSH to the KPIDB. This effectively tells the system that at SFn the packet violated the KPI threshold. Please refer to Figure 8 for the timestamp format.
操作の例として、KPIタイプ0x01（タイムスタンプ）を使用しているとします。 SF（たとえばSFn）がパケットを受信すると、現在のローカルタイムスタンプ（ネットワークのPRCに同期されていることを最初に確認する）をチェーンのIngress Timestampと比較して、チェーンの待機時間を計算できます。この値がタイムスタンプしきい値を超えると、SIが挿入され、NSHがKPIDBに返されます。これは、SFnでパケットがKPIしきい値に違反したことをシステムに効果的に伝えます。タイムスタンプの形式については、図8を参照してください。
When this occurs, the SFC control-plane system would then invoke the KPI extended mode, which uses a more sophisticated (and intrusive) method to isolate the root cause of the KPI violation, as described below.
これが発生すると、次に説明するように、SFCコントロールプレーンシステムはKPI拡張モードを呼び出します。KPI拡張モードは、より洗練された（そして侵入的な）メソッドを使用して、KPI違反の根本原因を特定します。
Note: Whilst detection mode is a valuable tool for latency actions, the authors feel that building the logic into the KPI system for QoS configuration is not justified. As QoS stamping is done infrequently and on a tiny percentage of the user plane, it is more practical to use extended mode only for service chain QoS verification.
注：検出モードはレイテンシアクションの貴重なツールですが、QoS構成のためにロジックをKPIシステムに組み込むことは正当化されないと感じています。 QoSスタンピングはまれにしか行われず、ユーザープレーンのごく一部で行われるため、サービスチェーンのQoS検証にのみ拡張モードを使用する方が現実的です。
A hybrid chain may be defined as a chain whereby there is a mix of NSH-aware and NSH-unaware SFs.
ハイブリッドチェーンは、NSH対応のSFとNSH非対応のSFが混在するチェーンとして定義できます。
Figure 12 shows an example of a hybrid chain with a PNF in the middle.
図12は、中央にPNFがあるハイブリッドチェーンの例を示しています。
Stamping
Controller
| KPIDB
| SCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( SFn )
\ FSN / \ / \ PNF1/ \ LSN /
`---' `---' `---' `---'
Figure 12: Hybrid Chain with PNF in Middle
図12：PNFが中間にあるハイブリッドチェーン
In this example, the FSN begins its operation and sets the SI to 3. SF1 decrements the SI to 2 and passes the packet to an SFC proxy (not shown).
この例では、FSNが動作を開始し、SIを3に設定します。SF1は、SIを2にデクリメントし、パケットをSFCプロキシ（図示せず）に渡します。
The SFC proxy strips the NSH and passes the packet to the PNF. On receipt back from the PNF, the proxy decrements the SI and passes the packet to the LSN with SI=1.
SFCプロキシはNSHを取り除き、パケットをPNFに渡します。 PNFから受信すると、プロキシはSIをデクリメントし、パケットをLSNにSI = 1で渡します。
After the LSN processes the traffic, it knows from the SI value that it is the last node in the chain, and it exports the entire NSH and all MD to the KPIDB. The payload is forwarded to the next hop on the underlay minus the NSH. The stamping information packet may be given a new SPI to act as a homing tag to transport the stamp data back to the KPIDB.
LSNはトラフィックを処理した後、SI値からそれがチェーンの最後のノードであることを認識し、NSH全体とすべてのMDをKPIDBにエクスポートします。ペイロードは、アンダーレイからNSHを引いた次のホップに転送されます。スタンプ情報パケットには、スタンプデータをKPIDBに戻すためのホーミングタグとして機能する新しいSPIが与えられます。
Figure 13 shows an example of a hybrid chain with a PNF at the end.
図13は、最後にPNFを備えたハイブリッドチェーンの例を示しています。
Stamping
Controller
| KPIDB
| SCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( PNFN )
\ FSN / \ / \ LSN / \ /
`---' `---' `---' `---'
Figure 13: Hybrid Chain with PNF at End
図13：PNFが最後にあるハイブリッドチェーン
In this example, the FSN begins its operation and sets the SI to 3. The SSI field is set to 0x1, and the type is set to 1. Thus, when SF2 receives the packet with SI=1, it understands that it is expected to take on the role of the LSN, as it is the last NSH-aware node in the chain.
この例では、FSNが動作を開始し、SIを3に設定します。SSIフィールドは0x1に設定され、タイプは1に設定されます。したがって、SF2はSI = 1のパケットを受信すると、それが予期されていることを理解しますLSNはチェーンの最後のNSH認識ノードであるため、LSNの役割を引き受けます。
For the majority of flows within the service chain, stamps (Ingress stamps, Egress stamps, or both) will be carried out at each hop until the SI decrements to zero and the NSH and stamp MD are exported to the KPIDB. However, the need to just test a particular VNF may exist (perhaps after a scale-out operation, software upgrade, or underlay change, for example). In this case, the FSN should mark the NSH as follows:
サービスチェーン内の大部分のフローでは、SIがゼロに減少し、NSHとスタンプMDがKPIDBにエクスポートされるまで、スタンプ（入力スタンプ、出力スタンプ、またはその両方）が各ホップで実行されます。ただし、特定のVNFをテストするだけの必要性が存在する場合があります（たとえば、スケールアウト操作、ソフトウェアのアップグレード、またはアンダーレイの変更後など）。この場合、FSNはNSHを次のようにマークする必要があります。
o The SSI field is set to 0x2.
o SSIフィールドは0x2に設定されています。
o Type is set to the expected SI at the SF in question.
o タイプは、問題のSFで予想されるSIに設定されます。
o When the outer SI is equal to the SSI, stamps are applied at the SF ingress and egress, and the NSH and MD are exported to the KPIDB.
o 外側のSIがSSIと等しい場合、SFの入口と出口でスタンプが適用され、NSHとMDがKPIDBにエクスポートされます。
The methods described in this document do not support fragmentation. The SC should return an error should a stamping request from an external system exceed MTU limits and require fragmentation.
このドキュメントで説明されているメソッドは、断片化をサポートしていません。外部システムからのスタンピング要求がMTUの制限を超え、フラグメンテーションが必要な場合、SCはエラーを返す必要があります。
Depending on the length of the payload and the type of KPI stamp and chain length, this will vary for each packet.
ペイロードの長さ、KPIスタンプのタイプ、およびチェーンの長さに応じて、これはパケットごとに異なります。
In most service provider architectures, we would expect SI << 10, which may include some PNFs in the chain that do not add overhead. Thus, for typical Internet Mix (IMIX) packet sizes [RFC6985], we expect to be able to perform timestamping on the vast majority of flows without fragmentation. Thus, the classifier can apply a simple rule that only allows KPI stamping on packet sizes less than 1200 bytes, for example.
ほとんどのサービスプロバイダーアーキテクチャでは、SI << 10が予想されます。これには、オーバーヘッドを追加しないチェーンにPNFが含まれる場合があります。したがって、典型的なインターネットミックス（IMIX）パケットサイズ[RFC6985]では、断片化せずに大部分のフローでタイムスタンプを実行できると期待しています。したがって、分類子は、たとえば1200バイト未満のパケットサイズのKPIスタンプのみを許可する単純なルールを適用できます。
The security considerations for the NSH in general are discussed in [RFC8300].
NSHのセキュリティに関する一般的な考慮事項は、[RFC8300]で説明されています。
In-band timestamping, as defined in this document, can be used as a means for network reconnaissance. By passively eavesdropping on timestamped traffic, an attacker can gather information about network delays and performance bottlenecks.
このドキュメントで定義されているインバンドタイムスタンプは、ネットワーク偵察の手段として使用できます。タイムスタンプ付きのトラフィックを受動的に盗聴することにより、攻撃者はネットワークの遅延とパフォーマンスのボトルネックに関する情報を収集できます。
The NSH timestamp is intended to be used by various applications to monitor network performance and to detect anomalies. Thus, a man-in-the-middle attacker can maliciously modify timestamps in order to attack applications that use the timestamp values. For example, an attacker could manipulate the SFC classifier operation, such that it forwards traffic through "better-behaved" chains. Furthermore, if timestamping is performed on a fraction of the traffic, an attacker can selectively induce synthetic delay only to timestamped packets and can systematically trigger measurement errors.
NSHタイムスタンプは、さまざまなアプリケーションがネットワークパフォーマンスを監視し、異常を検出するために使用することを目的としています。したがって、中間者攻撃者は、タイムスタンプ値を使用するアプリケーションを攻撃するために、タイムスタンプを悪意を持って変更する可能性があります。たとえば、攻撃者はSFC分類子の操作を操作して、「より適切な」チェーンを介してトラフィックを転送することができます。さらに、トラフィックの一部でタイムスタンプが実行された場合、攻撃者はタイムスタンプ付きのパケットのみに合成遅延を選択的に誘導し、体系的に測定エラーをトリガーすることができます。
Similarly, if an attacker can modify QoS stamps, erroneous values may be imported into the KPIDB, resulting in further misconfiguration and subscriber QoE impairment.
同様に、攻撃者がQoSスタンプを変更できる場合、誤った値がKPIDBにインポートされる可能性があり、その結果、構成の誤りとサブスクライバーのQoE障害がさらに発生します。
An attacker that gains access to the SCP can enable timestamping and QoS stamping for all subscriber flows, thereby causing performance bottlenecks, fragmentation, or outages.
SCPにアクセスする攻撃者は、すべてのサブスクライバーフローのタイムスタンプとQoSスタンピングを有効にして、パフォーマンスのボトルネック、断片化、または停止を引き起こすことができます。
As discussed in previous sections, NSH timestamping relies on an underlying time synchronization protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity of the NSH timestamp. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384].
前のセクションで説明したように、NSHタイムスタンプは、基になる時刻同期プロトコルに依存しています。したがって、時間プロトコルを攻撃することにより、攻撃者はNSHタイムスタンプの整合性を危険にさらす可能性があります。時間プロトコルに対する脅威とそれらを緩和する方法についての詳細な議論は[RFC7384]で提示されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、and C. Pignataro、Ed。、 "Network Service Header（NSH）"、RFC 8300、DOI 10.17487 / RFC8300、January 2018、<https： //www.rfc-editor.org/info/rfc8300>。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, <https://standards.ieee.org/standard/1588-2008.html>.
[IEEE1588] IEEE、「ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588、<https://standards.ieee.org/standard/1588-2008.html>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <https://www.rfc-editor.org/info/rfc5905>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384]ミズラヒ、T。、「パケット交換ネットワークにおけるタイムプロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https://www.rfc-editor.org/info/rfc7384>。
[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, DOI 10.17487/RFC6985, July 2013, <https://www.rfc-editor.org/info/rfc6985>.
[RFC6985] Morton、A。、「IMIX Genome：Specification of Variable Packet Sizes for Additional Testing」、RFC 6985、DOI 10.17487 / RFC6985、2013年7月、<https://www.rfc-editor.org/info/rfc6985> 。
[Y.1731] ITU-T Recommendation G.8013/Y.1731, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", August 2015, <https://www.itu.int/rec/T-REC-G.8013/en>.
[Y.1731] ITU-T勧告G.8013 / Y.1731、「運用、管理および保守（OAM）機能およびイーサネットベースのネットワークのメカニズム」、2015年8月、<https://www.itu.int/ rec / T-REC-G.8013 / en>。
[G.8261] ITU-T Recommendation G.8261/Y.1361, "Timing and synchronization aspects in packet networks", August 2013, <https://www.itu.int/rec/T-REC-G.8261>.
[G.8261] ITU-T勧告G.8261 / Y.1361、「パケットネットワークにおけるタイミングと同期の側面」、2013年8月、<https://www.itu.int/rec/T-REC-G.8261 >。
[G.8262] ITU-T Recommendation G.8262/Y.1362, "Timing characteristics of a synchronous Ethernet equipment slave clock", November 2018, <https://www.itu.int/rec/T-REC-G.8262>.
[G.8262] ITU-T勧告G.8262 / Y.1362、「同期イーサネット機器のスレーブクロックのタイミング特性」、2018年11月、<https://www.itu.int/rec/T-REC-G .8262>。
[G.8264] ITU-T Recommendation G.8264/Y.1364, "Distribution of timing information through packet networks", August 2017, <https://www.itu.int/rec/T-REC-G.8264>.
[G.8264] ITU-T勧告G.8264 / Y.1364、「パケットネットワークを介したタイミング情報の配信」、2017年8月、<https://www.itu.int/rec/T-REC-G.8264 >。
[In-Situ-OAM] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., Bernier, D., and J. Lemon, "Data Fields for In-situ OAM", Work in Progress, draft-ietf-ippm-ioam-data-05, March 2019.
[In-Situ-OAM] Brockners、F.、Bhandari、S.、Pignataro、C.、Gredler、H.、Leddy、J.、Youell、S.、Mizrahi、T.、Mozes、D.、Lapukhov、P 。、Chang、R.、Bernie、D。、およびJ. Lemon、「In-situ OAMのデータフィールド」、Work in Progress、draft-ietf-ippm-ioam-data-05、2019年3月。
Acknowledgments
謝辞
The authors gratefully acknowledge Mohamed Boucadair, Martin Vigoureux, and Adrian Farrel for their thorough reviews and helpful comments.
著者は、徹底的なレビューと有益なコメントを提供してくれたMohamed Boucadair、Martin Vigoureux、Adrian Farrelに感謝の意を表します。
Contributors
貢献者
This document originated as draft-browne-sfc-nsh-timestamp-00; the following people were coauthors of that draft. We would like to thank them and recognize them for their contributions.
このドキュメントは、draft-browne-sfc-nsh-timestamp-00として作成されました。以下の人々はその草案の共著者でした。私たちは彼らに感謝し、彼らの貢献を認めたいと思います。
Yoram Moses Technion Email: moses@ee.technion.ac.il
Yoram Moses Technionメール：moses@ee.technion.ac.il
Brendan Ryan Intel Corporation Email: brendan.ryan@intel.com
Brendan Ryan Intel Corporationメール：brendan.ryan@intel.com
Authors' Addresses
著者のアドレス
Rory Browne Intel Dromore House Shannon Co. Clare Ireland
Rory Browne Intel Dromore House Shannon Co. Clareアイルランド
Email: rorybrowne@yahoo.com
Andrey Chilikin Intel Dromore House Shannon Co. Clare Ireland
Andrey Chilikin Intel Dromore House Shannon Co. Clareアイルランド
Email: andrey.chilikin@intel.com
Tal Mizrahi Huawei Network.IO Innovation Lab Israel
Tal Mizrahi Huawei Network.IO Innovation Lab Israel
Email: tal.mizrahi.phd@gmail.com