Internet Engineering Task Force (IETF) W. Cheng, Ed.
Request for Comments: 9714 China Mobile
Category: Standards Track X. Min, Ed.
ISSN: 2070-1721 ZTE Corp.
T. Zhou
Huawei
J. Dai
FiberHome
Y. Peleg
Broadcom
February 2025
This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow-based packet loss, delay, and jitter measurements on MPLS traffic.
このドキュメントでは、MPLSトラフィックのフローベースのパケット損失、遅延、およびジッター測定を実行する代替マークメソッドを使用したMPLSパフォーマンス測定のカプセル化を定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9714.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9714で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
2.1. Abbreviations
2.2. Requirements Language
3. Flow-Based PM Encapsulation in MPLS
3.1. Examples for Applying Flow-ID Label in a Label Stack
3.1.1. Layout of the Flow-ID Label when Applied to MPLS
Transport
3.1.2. Layout of the Flow-ID Label when Applied to MPLS
Service
3.1.3. Layout of the Flow-ID Label when Applied to both MPLS
Transport and MPLS Service
4. Procedures of Encapsulation, Look-Up, and Decapsulation
5. Procedures of Flow-ID Allocation
6. FLC and FRLD Considerations
7. Equal-Cost Multipath Considerations
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[RFC9341] describes a performance measurement method, which can be used to measure packet loss, delay, and jitter on data traffic. Since this method is based on marking consecutive batches of packets, it is referred to as the Alternate-Marking Method. [RFC8372] outlines key considerations for developing a solution for MPLS flow identification, intended for use in performance monitoring of MPLS flows.
[RFC9341]は、データトラフィックに関するパケットの損失、遅延、およびジッターの測定に使用できるパフォーマンス測定方法について説明します。この方法は、パケットの連続バッチをマークすることに基づいているため、代替マルキング方法と呼ばれます。[RFC8372]は、MPLSフローのパフォーマンス監視で使用することを目的としたMPLSフロー識別のソリューションを開発するための重要な考慮事項を概説しています。
This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow-based packet loss, delay, and jitter measurements on the MPLS traffic. The encapsulation defined in this document supports performance monitoring at the intermediate nodes and MPLS flow identification at both transport and service layers.
このドキュメントでは、MPLSトラフィックのフローベースのパケット損失、遅延、およびジッター測定を実行する代替マークメソッドを使用したMPLSパフォーマンス測定のカプセル化を定義します。このドキュメントで定義されているカプセル化は、輸送層とサービス層の両方で中間ノードとMPLSフロー識別でのパフォーマンス監視をサポートします。
Note that, at the time of writing, there is ongoing work on MPLS Network Actions (MNAs) [RFC9613]. The MPLS performance measurement with the Alternate-Marking Method can also be achieved by MNA encapsulation. In addition, MNA will provide a broader use-case applicability. That means the MNA encapsulation is expected to provide a more advanced solution. The MPLS Working Group has agreed that this document will be made Historic when that solution is published as an RFC.
執筆時点で、MPLSネットワークアクション（MNA）[RFC9613]に関する継続的な作業があることに注意してください。MNAカプセル化により、代替マークメソッドを使用したMPLSパフォーマンス測定も実現できます。さらに、MNAはより広いユースケースの適用性を提供します。つまり、MNAカプセル化は、より高度なソリューションを提供することが期待されています。MPLSワーキンググループは、そのソリューションがRFCとして公開されたときに、このドキュメントが歴史的になることに同意しました。
ACL:
ACL:
Access Control List
アクセス制御リスト
BoS:
BoS:
Bottom of Stack
スタックの底
cSPL:
CSPL：
Composite Special Purpose Label, the combination of the Extension Label (value 15) and an Extended Special Purpose Label
複合特別目的ラベル、拡張ラベル（値15）と拡張特殊目的ラベルの組み合わせ
DSCP:
DSCP：
Differentiated Services Code Point
差別化されたサービスコードポイント
ELC:
ELC:
Entropy Label Capability
エントロピーラベル機能
ERLD:
erld：
Entropy Readable Label Depth
エントロピー読み取り可能なラベルの深さ
eSPL:
Espl：
Extended Special Purpose Label, a special-purpose label that is placed in the label stack after the Extension Label (value 15)
拡張特殊目的ラベル、拡張ラベルの後にラベルスタックに配置された特別な目的ラベル（値15）
FL:
FL:
Flow-ID Label
Flow-IDラベル
FLC:
FLC:
Flow-ID Label Capability
Flow-IDラベル機能
FLI:
FLI:
Flow-ID Label Indicator
Flow-IDラベルインジケーター
FRLD:
FRLD：
Flow-ID Readable Label Depth
Flow-ID読み取り可能なラベルの深さ
IPFIX:
IPFIX：
IP Flow Information Export [RFC7011]
IPフロー情報エクスポート[RFC7011]
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
LSR:
LSR:
Label Switching Router
ラベルスイッチングルーター
MPLS:
MPLS：
Multi-Protocol Label Switching
マルチプロトコルラベルスイッチング
NMS:
NMS:
Network Management System
ネットワーク管理システム
PHP:
PHP:
Penultimate Hop Popping
最後から2番目のホップポップ
PM:
PM:
Performance Measurement
パフォーマンス測定
PW:
PW:
Pseudowire
擬似ワイヤー
SFL:
SFL:
Synonymous Flow Label
同義のフローラベル
SID:
SID:
Segment ID
セグメントID
SR:
SR:
Segment Routing
セグメントルーティング
TC:
TC:
Traffic Class
トラフィッククラス
TTL:
TTL:
Time to Live
生きる時間
VC:
VC:
Virtual Channel
仮想チャネル
VPN:
VPN:
Virtual Private Network
仮想プライベートネットワーク
XL:
XL:
Extension Label
拡張ラベル
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 document defines the Flow-based MPLS performance measurement encapsulation with the Alternate-Marking Method, as shown in Figure 1.
このドキュメントは、図1に示すように、代替マルキング方法を使用したフローベースのMPLSパフォーマンス測定カプセル化を定義しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Label (15) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID Label Indicator (18) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID Label |L|D|T|S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Flow-based PM Encapsulation in MPLS
図1：MPLSのフローベースのPMカプセル化
The Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label (eSPL), which is combined with the Extension Label (XL, value 15) to form a Composite Special Purpose Label (cSPL), as defined in [RFC9017]. The FLI is defined in this document as value 18.
Flow-IDラベルインジケーター（FLI）は、拡張特殊目的ラベル（ESPL）であり、[RFC9017]で定義されているように、拡張ラベル（XL、値15）と組み合わせて複合特殊目的ラベル（CSPL）を形成します。FLIは、このドキュメントで値18として定義されています。
The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI MUST use the same values of the label immediately preceding the XL. The Bottom of the Stack (BoS) bit [RFC3032] for the XL and FLI MUST be zero. If any XL or FLI processed by a node has the BoS bit set, the node MUST discard the packet and MAY log an error.
XLおよびFLIのトラフィッククラス（TC）とライブ（TTL）フィールドは、XLの直前のラベルの同じ値を使用する必要があります。XLおよびFLIのスタック（BOS）ビット[RFC3032]ビット[RFC3032]はゼロでなければなりません。ノードで処理されたXLまたはFLIにBOSビットが設定されている場合、ノードはパケットを破棄し、エラーを記録する必要があります。
The Flow-ID Label (FL) is used as an MPLS flow identification [RFC8372]. Its value MUST be unique within the administrative domain. The FL values MAY be allocated by an external NMS or controller based on the measurement object instances (such as LSP or PW). There is a one-to-one mapping between a Flow-ID and a flow. The specific method on how to allocate the FL values is described in Section 5.
Flow-IDラベル（FL）は、MPLSフロー識別[RFC8372]として使用されます。その価値は、管理ドメイン内で一意でなければなりません。FL値は、測定オブジェクトインスタンス（LSPやPWなど）に基づいて、外部NMSまたはコントローラーによって割り当てられる場合があります。フローIDとフローの間に1対1のマッピングがあります。FL値を割り当てる方法に関する特定の方法は、セクション5で説明されています。
The FL, preceded by a cSPL, can be placed either at the bottom or in the middle, but not at the top, of the MPLS label stack, and it MAY appear multiple times within a label stack. Section 3.1 of this document provides several examples to illustrate the application of FL in a label stack. The TTL for the FL MUST be zero to ensure that it is not used inadvertently for forwarding. The BoS bit for the FL depends on whether the FL is placed at the bottom of the MPLS label stack, i.e., the BoS bit for the FL is set only when the FL is placed at the bottom of the MPLS label stack.
CSPLが先行するFLは、MPLSラベルスタックの上部または中央に配置できますが、上部には配置できず、ラベルスタック内で複数回表示される場合があります。このドキュメントのセクション3.1は、ラベルスタックでのFLの適用を示すいくつかの例を示します。FLのTTLは、転送に不注意に使用されないようにするためにゼロでなければなりません。FLのBOSビットは、FLがMPLSラベルスタックの下部に配置されているかどうかによって異なります。つまり、FLのBOSビットは、FLがMPLSラベルスタックの下部に配置されている場合にのみ設定されます。
Besides the flow identification, a color-marking field is also necessary for the Alternate-Marking Method. To color the MPLS traffic and to distinguish between hop-by-hop measurement and edge-to-edge measurement, the TC for the FL is defined as follows:
フローの識別に加えて、代替マルキング方法にはカラーマーキングフィールドも必要です。MPLSトラフィックを着色し、ホップバイホップ測定とエッジツーエッジの測定値を区別するために、FLのTCは次のように定義されます。
* L(oss) bit is used for coloring the MPLS packets for loss measurement. Setting the bit means color 1, and unsetting the bit means color 0.
* L（OSS）BITは、損失測定のためにMPLSパケットを着色するために使用されます。ビットの設定は色1を意味し、ビットを設定することは色0を意味します。
* D(elay) bit is used for coloring the MPLS packets for delay/jitter measurement. Setting the bit means color for delay measurement.
* D（ELAY）BITは、遅延/ジッター測定のためにMPLSパケットを着色するために使用されます。ビットを設定すると、遅延測定のための色が意味されます。
* T(ype) bit is used to indicate the measurement type. When the T bit is set to 1, that means edge-to-edge performance measurement. When the T bit is set to 0, that means hop-by-hop performance measurement.
* T（YPE）ビットは、測定タイプを示すために使用されます。tビットが1に設定されている場合、エッジツーエッジのパフォーマンス測定を意味します。tビットが0に設定されている場合、それはホップバイホップのパフォーマンス測定を意味します。
Considering the FL is not used as a forwarding label, the repurposing of the TC for the FL is feasible and viable.
FLが転送ラベルとして使用されていないことを考慮すると、FLのTCの再利用は実行可能で実行可能です。
Three examples of different layouts of the FL (4 octets) are illustrated as follows. Note that more examples may exist.
FLの異なるレイアウト（4オクテット）の3つの例を次のように示します。より多くの例が存在する可能性があることに注意してください。
+----------------------+
| LSP |
| Label |
+----------------------+ <--+
| Extension | |
| Label | |
+----------------------+ |--- cSPL
| Flow-ID Label | |
| Indicator | |
+----------------------+ <--+
| Flow-ID |
| Label |
+----------------------+
| Application |
| Label |
+----------------------+ <= Bottom of stack
| |
| Payload |
| |
+----------------------+
Figure 2: Applying Flow-ID to MPLS Transport
図2：Flow-IDをMPLS輸送に適用します
With penultimate hop popping (PHP Section 3.16 of [RFC3031]), the top label is "popped at the penultimate LSR of the LSP, rather than at the LSP Egress". The final bullet of Section 4 of the present document requires that "[t]he processing node MUST pop the XL, FLI, and FL from the MPLS label stack when it needs to pop the preceding forwarding label", which implies that the penultimate Label Switching Router (LSR) needs to follow the requirement of Section 4 in order to support this specification. If this is done, the egress LSR is excluded from the performance measurement. Therefore, when this specification is in use, PHP should be disabled, unless the penultimate LSR is known to have the necessary support and unless it's acceptable to exclude the egress LSR.
最後から2番目のホップポップ（[RFC3031]のPHPセクション3.16）では、トップレーベルは「LSP Egressではなく、LSPの最後から2番目のLSRでポップされます」。現在のドキュメントのセクション4の最終弾丸では、「[t]が前の転送ラベルをポップする必要がある場合、MPLSラベルスタックからXL、FLI、およびFLをポップする必要がある」ことを要求します。スイッチングルーター（LSR）は、この仕様をサポートするためにセクション4の要件に従う必要があります。これが行われた場合、出力LSRはパフォーマンス測定から除外されます。したがって、この仕様が使用されている場合、PHPは必要なサポートを受けていることが知られていない場合を除き、Egress LSRを除外することが許容されない限り、PHPを無効にする必要があります。
Also note that in other examples of applying Flow-ID to MPLS transport, one LSP label can be substituted by multiple SID labels in the case of using SR Policy, and the combination of cSPL and FL can be placed between SID labels, as specified in Section 6.
また、Flow-IDをMPLSトランスポートに適用する他の例では、SRポリシーを使用する場合に1つのLSPラベルを複数のSIDラベルで置き換えることができ、CSPLとFLの組み合わせは、で指定されているSIDラベル間に配置できることに注意してください。セクション6。
+----------------------+
| LSP |
| Label |
+----------------------+
| Application |
| Label |
+----------------------+ <--+
| Extension | |
| Label | |
+----------------------+ |--- cSPL
| Flow-ID Label | |
| Indicator | |
+----------------------+ <--+
| Flow-ID |
| Label |
+----------------------+ <= Bottom of stack
| |
| Payload |
| |
+----------------------+
Figure 3: Applying Flow-ID to MPLS Service
図3：Flow-IDをMPLSサービスに適用します
Note that in this case, the application label can be an MPLS PW label, MPLS Ethernet VPN label, or MPLS IP VPN label, and it is also called a VC label as defined in [RFC4026].
この場合、アプリケーションラベルはMPLS PWラベル、MPLSイーサネットVPNラベル、またはMPLS IP VPNラベルであり、[RFC4026]で定義されているVCラベルとも呼ばれることに注意してください。
+----------------------+
| LSP |
| Label |
+----------------------+ <--+
| Extension | |
| Label | |
+----------------------+ |--- cSPL
| Flow-ID Label | |
| Indicator | |
+----------------------+ <--+
| Flow-ID |
| Label |
+----------------------+
| Application |
| Label |
+----------------------+ <--+
| Extension | |
| Label | |
+----------------------+ |--- cSPL
| Flow-ID Label | |
| Indicator | |
+----------------------+ <--+
| Flow-ID |
| Label |
+----------------------+ <= Bottom of stack
| |
| Payload |
| |
+----------------------+
Figure 4: Applying Flow-ID to both MPLS Transport and MPLS Service
図4：MPLSトランスポートとMPLSサービスの両方にFlow-IDを適用する
Note that for this example, the two FL values appearing in a label stack must be different. In other words, the FL applied to the MPLS transport and the FL applied to the MPLS service must be different. Also, note that the two FL values are independent of each other. For example, two packets can belong to the same VPN flow but different LSP flows, or two packets can belong to different VPN flows but the same LSP flow.
この例では、ラベルスタックに表示される2つのFL値が異なる必要があることに注意してください。言い換えれば、MPLS輸送に適用されたFLとMPLSサービスに適用されるFLは異なる必要があります。また、2つのFL値は互いに独立していることに注意してください。たとえば、2つのパケットは同じVPNフローに属することができますが、異なるLSPフロー、または2つのパケットが異なるVPNフローに属しますが、同じLSPフローに属します。
The procedures for FL encapsulation, look-up, and decapsulation are summarized as follows:
FLカプセル化、ルックアップ、および脱カプセル化の手順は、次のように要約されています。
* The MPLS ingress node [RFC3031] inserts the XL, FLI, and FL into the MPLS label stack. At the same time, the ingress node sets the FL value, the two color-marking bits, and the T bit, as defined in Section 3.
* MPLSイングレスノード[RFC3031]は、XL、FLI、およびFLをMPLSラベルスタックに挿入します。同時に、イングレスノードは、セクション3で定義されているように、FL値、2つのカラーマークビット、およびtビットを設定します。
* If edge-to-edge measurement is applied, i.e., the T bit is set to 1, then only the MPLS ingress/egress node [RFC3031] is the processing node; otherwise, all the MPLS nodes along the LSP are the processing nodes. The processing node looks up the FL with the help of the XL and FLI, and exports the collected data (such as the Flow-ID, block counters, and timestamps) to an external NMS/controller, referring to the Alternate-Marking Method. Section 6 of [ALT-MARK] describes protocols for collected data export; the details on how to export the collected data are outside the scope of this document. Note that while looking up the FL, the transit node needs to inspect beyond the label at the top of the label stack used to make forwarding decisions.
* エッジツーエッジ測定が適用される場合、つまりtビットが1に設定されている場合、MPLSイングレス/出口ノード[RFC3031]のみが処理ノードです。それ以外の場合、LSPに沿ったすべてのMPLSノードは処理ノードです。処理ノードは、XLとFLIの助けを借りてFLを検索し、収集されたデータ（フローID、ブロックカウンター、タイムスタンプなど）を外部NMS/コントローラーにエクスポートし、代替マークメソッドを参照します。[Alt-Mark]のセクション6では、収集されたデータエクスポートのプロトコルについて説明しています。収集されたデータをエクスポートする方法の詳細は、このドキュメントの範囲外です。FLを調べている間、トランジットノードは、転送の決定を下すために使用されるラベルスタックの上部にあるラベルを超えて検査する必要があることに注意してください。
* The processing node MUST pop the XL, FLI, and FL from the MPLS label stack when it needs to pop the preceding forwarding label. The egress node MUST pop the whole MPLS label stack. This document doesn't introduce any new process to the decapsulated packet.
* 処理ノードは、前の転送ラベルをポップする必要がある場合、MPLSラベルスタックからXL、FLI、およびFLをポップする必要があります。出力ノードは、MPLSラベルスタック全体をポップする必要があります。このドキュメントでは、脱カプセル化パケットに新しいプロセスが導入されていません。
There are at least two ways of allocating Flow-ID. One way is to allocate Flow-ID by a manual trigger from the network operator, and the other way is to allocate Flow-ID by an automatic trigger from the ingress node. Details are as follows:
Flow-IDを割り当てるには、少なくとも2つの方法があります。1つの方法は、ネットワークオペレーターからの手動トリガーによってFlow-IDを割り当てることです。もう1つの方法は、Ingressノードからの自動トリガーによってFlow-IDを割り当てることです。詳細は次のとおりです。
* In the case of a manual trigger, the network operator manually inputs the characteristics (e.g., IP five tuples and IP DSCP) of the measured flow; then the NMS/controller generates one or two Flow-IDs based on the input from the network operator and provisions the ingress node with the characteristics of the measured flow and the corresponding allocated Flow-ID(s).
* マニュアルトリガーの場合、ネットワークオペレーターは、測定されたフローの特性（IP 5タプルやIP DSCPなど）を手動で入力します。次に、NMS/コントローラーは、ネットワークオペレーターからの入力に基づいて1つまたは2つのフローIDを生成し、測定されたフローの特性と対応する割り当てられたフローIDの特性を侵入ノードに提供します。
* In the case of an automatic trigger, the ingress node identifies the flow entering the measured path and exports the characteristics of the identified flow to the NMS/controller by IPFIX [RFC7011]; then the NMS/controller generates one or two Flow-IDs based on the characteristics exported from the ingress node and provisions the ingress node with the characteristics of the identified flow and the corresponding allocated Flow-ID(s).
* 自動トリガーの場合、イングレスノードは測定されたパスに入るフローを識別し、IPFIX [RFC7011]によってNMS/コントローラーへの識別されたフローの特性をエクスポートします。次に、NMS/コントローラーは、イングレスノードからエクスポートされた特性に基づいて1つまたは2つのフローIDを生成し、識別されたフローの特性と対応する割り当てられたフローID（s）の特性をイングレスノードに提供します。
The policy preconfigured at the NMS/controller decides whether one Flow-ID or two Flow-IDs are generated. If the performance measurement on the MPLS service is enabled, then one Flow-ID applied to the MPLS service is generated. If the performance measurement on the MPLS transport is enabled, then one Flow-ID applied to the MPLS transport is generated. If both of them are enabled, then two Flow-IDs are respectively applied to the MPLS service and the MPLS transport are generated. In this case, a transit node needs to look up both of the two Flow-IDs by default. However, this behavior can be changed through configuration, such as by setting it to look up only the Flow-ID applied to the MPLS transport.
NMS/コントローラーで事前に設定されたポリシーは、1つのフローIDまたは2つのフローIDが生成されるかどうかを決定します。MPLSサービスのパフォーマンス測定が有効になっている場合、MPLSサービスに適用されるフローIDが1つ生成されます。MPLS輸送のパフォーマンス測定が有効になっている場合、MPLSトランスポートに適用されるフローIDが1つ生成されます。両方が有効になっている場合、2つのフローIDがそれぞれMPLSサービスに適用され、MPLS輸送が生成されます。この場合、トランジットノードは、デフォルトで2つのフローIDの両方を検索する必要があります。ただし、この動作は、MPLS輸送に適用されるフローIDのみを検索するように設定するなど、構成によって変更できます。
Whether using the two methods mentioned above or other methods to allocate Flow-ID, the NMS/controller MUST ensure that every generated Flow-ID is unique within the administrative domain and MUST NOT have any value in the reserved label space (0-15) [RFC3032]. Specifically, the statement of "Flow-ID is unique" means that the values of Flow-ID are distinct and non-redundant for any flow at any given time within an administrative domain, such that no two flows share the same Flow-ID. This uniqueness ensures that each flow can be individually identified, tracked, and differentiated from others for accurate performance monitoring and management.
上記の2つの方法を使用してフローIDを割り当てるために他の方法を使用するかどうかにかかわらず、NMS/コントローラーは、すべての生成されたフローIDが管理ドメイン内で一意であり、予約ラベルスペース（0-15）に価値がないことを確認する必要があります。[RFC3032]。具体的には、「Flow-ID」のステートメントは、Flow-IDの値が、管理ドメイン内の任意のフローに対して明確で非冗長であることを意味します。この一意性により、各フローを、正確なパフォーマンスの監視と管理のために、他のフローを個別に識別、追跡、区別できるようになります。
Analogous to the Entropy Label Capability (ELC) defined in Section 5 of [RFC6790] and the Entropy Readable Label Depth (ERLD) defined in Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the Flow-ID Readable Label Depth (FRLD) are defined in this document. Both FLC and FRLD have similar semantics with the ELC and ERLD to a router, except that the Flow-ID is used in its flow identification function while the Entropy is used in its load-balancing function.
[RFC6790]のセクション5で定義されているエントロピーラベル機能（ELC）および[RFC8662]のセクション4で定義されているエントロピー読み取り可能なラベル深度（ERLD）に類似しています。ラベル深度（FRLD）は、このドキュメントで定義されています。FLCとFRLDの両方は、ELCとERLDと同様のセマンティクスをルーターに持っています。ただし、フローIDはフロー識別関数で使用され、エントロピーは負荷バランス関数で使用されます。
The ingress node MUST insert each FL at an appropriate depth, which ensures the node to which the FL is exposed has the FLC. The ingress node SHOULD insert each FL within an appropriate FRLD, which is the minimum FRLD of all the on-path nodes that need to read and use the FL in question. How the ingress node knows the FLC and FRLD of all the on-path nodes is outside the scope of this document.
Ingressノードは、各FLを適切な深さに挿入する必要があります。これにより、FLが露出しているノードにFLCがあります。Ingressノードは、各FLを適切なFRLD内に挿入する必要があります。これは、問題のFLを読み取り、使用する必要があるすべてのオンパスノードの最小FRLDです。IngressノードがすべてのオンパスノードのFLCとFRLDをどのように知っているかは、このドキュメントの範囲外です。
When the SR paths are used for transport, the label stack grows as the number of on-path segments increases. If the number of on-path segments is high, that may become a challenge for the FL to be placed within an appropriate FRLD. To overcome this potential challenge, an implementation MAY allow the ingress node to place FL between SID labels. This means that multiple identical FLs at different depths MAY be interleaved with SID labels. When this occurs, sophisticated network planning may be needed, which is beyond the scope of this document.
SRパスが輸送に使用されると、ラベルスタックは、パス上のセグメントの数が増えると成長します。パス上のセグメントの数が高い場合、それはFLが適切なFRLD内に配置される課題になる可能性があります。この潜在的な課題を克服するために、実装により、イングレスノードがSIDラベルの間にFLを配置できる場合があります。これは、異なる深さの複数の同一のFLがSIDラベルとインターリーブされる可能性があることを意味します。これが発生すると、このドキュメントの範囲を超えた洗練されたネットワーク計画が必要になる場合があります。
Analogous to what's described in Section 5 of [RFC8957], under conditions of equal-cost multipath, the introduction of the FL may lead to the same problem that is caused by the Synonymous Flow Label (SFL) [RFC8957]. The two solutions proposed for SFL also apply here. Specifically, adding FL to an existing flow may cause that flow to take a different path. If the operator expects to resolve this problem, they can choose to apply entropy labels [RFC6790] or add FL to all flows.
[RFC8957]のセクション5で説明されていることと同様に、等コストのマルチパスの条件下では、FLの導入は、同義フローラベル（SFL）[RFC8957]によって引き起こされる同じ問題につながる可能性があります。SFL向けに提案されている2つのソリューションもここに適用されます。具体的には、FLを既存のフローに追加すると、その流れが異なるパスをとることがあります。オペレーターがこの問題を解決することを期待している場合、エントロピーラベル[RFC6790]を適用するか、すべてのフローにFLを追加することを選択できます。
As specified in Section 7.1 of [RFC9341], "for security reasons, the Alternate-Marking Method MUST only be applied to controlled domains." This requirement applies when the MPLS performance measurement with Alternate-Marking Method is taken into account, which means the MPLS encapsulation and related procedures defined in this document MUST only be applied to controlled domains; otherwise, the potential attacks discussed in Section 10 of [RFC9341] may be applied to the deployed MPLS networks.
[RFC9341]のセクション7.1で指定されているように、「セキュリティ上の理由から、代替マルキング方法は制御ドメインにのみ適用する必要があります。」この要件は、代替マルキング方法を使用したMPLSパフォーマンス測定が考慮される場合に適用されます。つまり、このドキュメントで定義されているMPLSのカプセル化および関連手順は、制御ドメインにのみ適用する必要があります。それ以外の場合、[RFC9341]のセクション10で説明されている潜在的な攻撃は、展開されたMPLSネットワークに適用される場合があります。
As specified in Section 3, the value of an FL MUST be unique within the administrative domain. In other words, the administrative domain is the scope of an FL. The method for achieving multi-domain performance measurement with the same FL is outside the scope of this document. The FL MUST NOT be signaled and distributed outside the administrative domain. Improper configuration that allows the FL to be passed from one administrative domain to another would result in Flow-ID conflicts.
セクション3で指定されているように、FLの値は管理ドメイン内で一意でなければなりません。言い換えれば、管理ドメインはFLの範囲です。同じFLでマルチドメインのパフォーマンス測定を実現する方法は、このドキュメントの範囲外です。FLは、管理ドメインの外側に信号を送って分布させてはなりません。FLをある管理ドメインから別の管理ドメインに渡すことを可能にする不適切な構成は、Flow-IDの競合につながります。
To prevent packets carrying FLs from leaking from one domain to another, domain boundary nodes MUST deploy policies (e.g., ACL) to filter out these packets. Specifically, at the sending edge, the domain boundary node MUST filter out the packets that carry the FLI and are sent to other domains. At the receiving edge, the domain boundary node MUST drop the packets that carry the FLI and are from other domains. Note that packet leakage is neither breaching privacy nor a source of DoS.
FLがあるドメインから別のドメインに漏れないようにするパケットを防ぐために、ドメイン境界ノードは、これらのパケットを除外するためにポリシー（ACLなど）を展開する必要があります。具体的には、送信エッジでは、ドメイン境界ノードがFLIを運ぶパケットを除外し、他のドメインに送信する必要があります。受信エッジでは、ドメイン境界ノードは、FLIを運ぶ、他のドメインからのパケットをドロップする必要があります。パケットの漏れは、プライバシーに違反したり、DOSのソースでもないことに注意してください。
IANA has assigned the following value in the "Extended Special-Purpose MPLS Label Values" registry within the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry group:
IANAは、「特別な多目的マルチプロトコルラベルスイッチング（MPLS）ラベル値」レジストリグループ内の「拡張特殊目的MPLSラベル値」レジストリに次の値を割り当てました。
+=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 18 | Flow-ID Label Indicator (FLI) | RFC 9714 |
+-------+-------------------------------+-----------+
Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID Label Indicator
表1：Flow-IDラベルインジケーターの新しい拡張特性MPLSラベル値
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[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>.
[RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special-
Purpose Label Terminology", RFC 9017,
DOI 10.17487/RFC9017, April 2021,
<https://www.rfc-editor.org/info/rfc9017>.
[ALT-MARK] Fioccola, G., Zhu, K., Graf, T., Nilo, M., and L. Zhang,
"Alternate Marking Deployment Framework", Work in
Progress, Internet-Draft, draft-ietf-ippm-alt-mark-
deployment-02, 9 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
alt-mark-deployment-02>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations",
RFC 8372, DOI 10.17487/RFC8372, May 2018,
<https://www.rfc-editor.org/info/rfc8372>.
[RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy Label for Source
Packet Routing in Networking (SPRING) Tunnels", RFC 8662,
DOI 10.17487/RFC8662, December 2019,
<https://www.rfc-editor.org/info/rfc8662>.
[RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G.
Mirsky, "Synonymous Flow Label Framework", RFC 8957,
DOI 10.17487/RFC8957, January 2021,
<https://www.rfc-editor.org/info/rfc8957>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
for Solutions that Support MPLS Network Actions (MNAs)",
RFC 9613, DOI 10.17487/RFC9613, August 2024,
<https://www.rfc-editor.org/info/rfc9613>.
The authors acknowledge Loa Andersson, Tarek Saad, Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping Zhan, Ming Ke, Wei He, Ximing Dong, Darren Dukes, Tony Li, James Guichard, Daniele Ceccarelli, Éric Vyncke, John Scudder, Gunter van de Velde, Roman Danyliw, Warren Kumari, Murray Kucherawy, Deb Cooley, Zaheduzzaman Sarker, and Deborah Brungard for their careful review and very helpful comments.
著者は、ロア・アンダーソン、タレク・サード、スチュワート・ブライアント、ラケシュ・ガンジー、グレッグ・ミルスキー、アイフア・リュー、シュアンピン・ザン、ミン・ケ、ウェイ・HE、Ximingドン、ダレン・デュケス、トニー・リー、ジェームズ・ギチャード、ダニエル・セッカレリ、エリック・ヴィンケ、ジョン・スケード、Gunter Van de Velde、Roman Danyliw、Warren Kumari、Murray Kucherawy、Deb Cooley、Zaheduzzaman Sarker、Deborah Brungardの慎重なレビューと非常に役立つコメント。
They also acknowledge Italo Busi and Chandrasekar Ramachandran for their insightful MPLS-RT review and constructive comments.
彼らはまた、彼らの洞察に富んだMPLS-RTレビューと建設的なコメントについて、イタロ・ブシとチャンドラセカル・ラマチャンドランを認めています。
Additionally, the authors thank Dhruv Dhody for the English grammar review.
さらに、著者は、英語の文法レビューについてDhruv Dhodyに感謝します。
Minxue Wang
China Mobile
Email: wangminxue@chinamobile.com
Wen Ye
China Mobile
Email: yewen@chinamobile.com
Weiqiang Cheng (editor)
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Xiao Min (editor)
ZTE Corp.
Nanjing
China
Email: xiao.min2@zte.com.cn
Tianran Zhou
Huawei
Beijing
China
Email: zhoutianran@huawei.com
Jinyou Dai
FiberHome
Wuhan
China
Email: djy@fiberhome.com
Yoav Peleg
Broadcom
United States of America
Email: yoav.peleg@broadcom.com