Internet Engineering Task Force (IETF) M. Bocci, Ed.
Request for Comments: 9613 Nokia
Category: Informational S. Bryant
ISSN: 2070-1721 University of Surrey ICS
J. Drake
Independent
August 2024
This document specifies requirements for the development of MPLS Network Actions (MNAs) that affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER).
このドキュメントは、MPLSパケットの転送またはその他の処理に影響を与えるMPLSネットワークアクション（MNA）の開発の要件を指定します。これらの要件は、ラベル付きパケット内のMPLS情報への追加に関する多くの提案によって通知され、そのようなアクションをトランジットまたは終了ラベルスイッチングルーター（つまり、ラベルエッジルーター-LER）によって実行できるようにします。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9613.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9613で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
1.1. Terminology
2. Requirements Language
3. MPLS Network Action Requirements
3.1. General Requirements
3.2. Requirements on the MNA Alert Mechanism
3.3. Requirements on Network Actions
3.4. Requirements on Network Action Indicators
3.5. Requirements on Ancillary Data
4. IANA Considerations
5. Security Considerations
6. Acknowledgements
7. References
7.1. Normative References
7.2. Informative References
Authors' Addresses
There is significant interest in developing the MPLS data plane to address the requirements of new use cases [MNA-USECASES]. This requires a general mechanism, termed MPLS Network Actions (MNAs), to allow the network to make a forwarding or processing decision based on information other than the top label and Traffic Class (TC) bits, and to also make use of the Network Action Indicator (NAI) and ancillary data (MNA information). These use cases require the definition of extensions to the MPLS architecture and label-stack operations that can be used across these use cases in order to minimize implementation complexity and promote interoperability and extensibility. These protocol extensions need to conform to the existing MPLS architecture as specified by [RFC3031], [RFC3032], and [RFC6790].
新しいユースケース[MNA-USECASES]の要件に対処するために、MPLSデータプレーンの開発に大きな関心があります。これには、MPLSネットワークアクション（MNA）と呼ばれる一般的なメカニズムが必要です。ネットワークは、トップレーベルとトラフィッククラス（TC）ビット以外の情報に基づいて転送または処理の決定を行い、ネットワークアクションを利用する必要があります。インジケータ（NAI）および補助データ（MNA情報）。これらのユースケースでは、実装の複雑さを最小限に抑え、相互運用性と拡張性を促進するために、これらのユースケースで使用できるMPLSアーキテクチャおよびラベルスタック操作への拡張の定義が必要です。これらのプロトコル拡張は、[RFC3031]、[RFC3032]、および[RFC6790]で指定されているように、既存のMPLSアーキテクチャに準拠する必要があります。
Note that the MPLS architecture specified in [RFC3031] describes a mechanism for forwarding MPLS packets through a network without requiring any analysis of the MPLS packet payload's network layer header by intermediate nodes (Label Switching Routers - LSRs). Formally, inspection may only occur at network ingress (the Label Edge Router - LER) where the MPLS packet is assigned to a Forwarding Equivalence Class (FEC).
[RFC3031]で指定されているMPLSアーキテクチャは、中間ノード（ラベルスイッチングルーター-LSR）によってMPLSパケットペイロードのネットワークレイヤーヘッダーの分析を必要とせずに、ネットワークを介してMPLSパケットを転送するメカニズムを説明していることに注意してください。正式には、検査は、MPLSパケットが転送等価クラス（FEC）に割り当てられているネットワークイングレス（ラベルエッジルーター-LER）でのみ発生する場合があります。
This document specifies the requirements for solutions that encode MNAs and ancillary data that may be needed to process those actions. These requirements are informed by a number of proposals to allow additions to the MPLS information in the labeled packet so that such actions can be performed, either by a transit or terminating LSR. It is anticipated that these will result in two types of solution specifications:
このドキュメントは、それらのアクションを処理するために必要なMNAと補助データをエンコードするソリューションの要件を指定します。これらの要件は、輸送または終了LSRによってそのようなアクションを実行できるように、ラベル付きパケット内のMPLS情報への追加を許可するための多くの提案によって通知されます。これらが2種類のソリューション仕様をもたらすと予想されます。
MNA solution specification:
MNAソリューション仕様：
A specification that describes a common protocol that supports all forms of MNAs.
あらゆる形態のMNAをサポートする一般的なプロトコルを記述する仕様。
Network Action solution specifications:
ネットワークアクションソリューション仕様：
One or more specifications describing the protocol extensions for the MNA solution to address a use case.
MNAソリューションのプロトコル拡張機能を説明する1つ以上の仕様は、ユースケースに対処します。
The term 'solutions', in isolation, refers to both MNA and Network Action solutions. The requirements constrain the MNA solution design to enable interoperability between implementations.
「ソリューション」という用語は、単独で、MNAとネットワークアクションソリューションの両方を指します。要件は、MNAソリューション設計を制約して、実装間の相互運用性を可能にします。
Network Action (NA):
ネットワークアクション（NA）：
An operation to be performed on an MPLS packet or as a consequence of an MPLS packet being processed by a router. An NA may affect router state or MPLS packet forwarding, or it may affect the MPLS packet in some other way.
MPLSパケットで実行される操作、またはMPLSパケットがルーターによって処理される結果として実行される操作。NAは、ルーター状態またはMPLSパケット転送に影響を与える可能性があります。または、MPLSパケットに他の方法で影響を与える可能性があります。
Network Action Indicator (NAI):
ネットワークアクションインジケーター（NAI）：
An indication in the MPLS packet that a certain NA is to be performed.
MPLSパケットの兆候は、特定のNAを実行することを示しています。
Ancillary Data (AD):
補助データ（AD）：
Data in an MPLS packet associated with a given NA that may be used as input to process the NA or may result from processing the NA. Ancillary data may be associated with:
NAを処理するために入力として使用される可能性のある特定のNAに関連付けられたMPLSパケット内のデータ、またはNAの処理から生じる場合があります。補助データは次のことに関連付けられている場合があります。
* Both the control or maintenance information and the data traffic carried by the Label Switched Path (LSP).
* 制御情報またはメンテナンス情報、およびラベルスイッチ付きパス（LSP）によって運ばれるデータトラフィックの両方。
* Only the control or maintenance information.
* 制御またはメンテナンス情報のみ。
* Only the data traffic carried by the LSP.
* LSPによって運ばれるデータトラフィックのみ。
In-Stack Data:
スタック内データ：
Ancillary data carried within the MPLS label stack.
MPLSラベルスタック内に掲載された補助データ。
Post-Stack Data:
ポストスタックデータ：
Ancillary data carried in an MPLS packet between the bottom of the MPLS label stack and the first octet of the user payload. This document does not prescribe whether post-stack data precedes or follows any other post-stack header such as a Control Word or Associated Channel Header (ACH).
MPLSラベルスタックの下部とユーザーペイロードの最初のオクテットの間のMPLSパケットに搭載された補助データ。このドキュメントでは、ポストスタックデータがコントロールワードや関連チャネルヘッダー（ACH）などの他のポストスタックヘッダーに先行するか、従うかを規定していません。
Scope:
範囲：
The set of nodes that should perform a given action.
特定のアクションを実行する必要があるノードのセット。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements.
このドキュメントはプロトコルの仕様ではありませんが、この条約は要件の説明を明確にするために採用されています。
This document specifies requirements on MNAs and the technology to support them in MPLS, such as NAIs, the associated AD, and the alert mechanism to indicate to an LSR that NAIs are present in an MPLS packet.
このドキュメントは、MNAとMPLSでそれらをサポートするためのMNAとテクノロジーに関する要件を指定し、関連するAD、およびNAISがMPLSパケットに存在することをLSRに示すアラートメカニズムを指定します。
The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which indicators for a NA and associated ancillary data are constructed. It does not specify the detailed actions and processing of any NAs or ancillary data by an LSR or LER.
要件は、NAおよび関連する補助データの指標から構成されている構成要素を構成するプロトコルメカニズムと手順の動作に関するものです。LSRまたはLERによるNASまたは補助データの詳細なアクションと処理は指定されていません。
The size of the ancillary data carried post-stack end to end in an MPLS packet is a matter for agreement between the ingress and egress provider edges (PEs), and is not part of these requirements. Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed by transit LSRs along the Label Switched Path (LSP), requirements on the size of such ancillary data are documented in the following sections.
MPLSパケットでポストスタックの端から終了した補助データのサイズは、イングレスプロバイダーと出口プロバイダーのエッジ（PES）の間の一致の問題であり、これらの要件の一部ではありません。ラベルスイッチ付きパス（LSP）に沿ったトランジットLSRによってスタック内の補助データとホップあたりのポストスタックデータを解析および処理する必要があるため、そのような補助データのサイズに関する要件は、次のセクションに文書化されています。
1. Any solutions MUST maintain the properties of extensibility, flexibility, and efficiency inherent in the split between the control plane context and simple data plane used in MPLS and the specification SHOULD describe how this is achieved.
1. すべてのソリューションは、MPLSで使用される制御プレーンコンテキストと単純なデータプレーンに固有の拡張性、柔軟性、および効率の特性を維持する必要があり、仕様はこれがどのように達成されるかを説明する必要があります。
2. Any solutions to these requirements MUST be based on and MUST NOT restrict the generality of the MPLS architecture [RFC3031] [RFC3032] [RFC5331].
2. これらの要件の解決策は、MPLSアーキテクチャの一般性[RFC3031] [RFC3032] [RFC5331]に基づいている必要があります。
3. If extensions to the MPLS data plane are required, they MUST be consistent with the MPLS architecture [RFC3031] [RFC3032] [RFC5331].
3. MPLSデータプレーンへの拡張が必要な場合、それらはMPLSアーキテクチャ[RFC3031] [RFC3032] [RFC5331]と一致する必要があります。
4. Solutions meeting the requirements set out in this document MUST be able to coexist with existing MPLS mechanisms.
4. このドキュメントに記載されている要件を満たすソリューションは、既存のMPLSメカニズムと共存できる必要があります。
5. Subject to the constraints in these requirements, a Network Action solution MAY carry MNA information in-stack, post-stack, or both in-stack and post-stack.
5. これらの要件の制約に従い、ネットワークアクションソリューションは、MNA情報をスタック内、ポストスタック、またはスタック内およびポストスタックの両方で伝達する場合があります。
6. Solution specifications MUST NOT require an implementation to support in-stack ancillary data, unless the implementation chooses to support an NA that uses in-stack ancillary data.
6. ソリューション仕様は、実装がスタック内の補助データを使用するNAをサポートすることを選択しない限り、スタック内の補助データをサポートするための実装を必要としないでください。
7. Solution specifications MUST NOT require an implementation to support post-stack ancillary data, unless the implementation chooses to support an NA that uses post-stack ancillary data.
7. ソリューション仕様は、ポストスタックの補助データを使用するNAをサポートすることを選択しない限り、ポストスタックの補助データをサポートするための実装を必要としないでください。
8. The design of any MNA solution MUST minimize the amount of processing required to parse the label stack at an LSR.
8. 任意のMNAソリューションの設計は、LSRでラベルスタックを解析するために必要な処理量を最小限に抑える必要があります。
9. Solutions MUST minimize any additions to the size of the MPLS label stack.
9. ソリューションは、MPLSラベルスタックのサイズへの追加を最小限に抑える必要があります。
10. Solution specifications that increase the size of the MPLS label stack in a way that is not controlled by the ingress LER MUST discuss the consequences.
10. MPLSラベルスタックのサイズを増加させるソリューション仕様は、イングレスLERによって制御されていない方法で結果を議論する必要があります。
11. Solution specifications MUST discuss the ECMP consequences of the design.
11. ソリューション仕様は、設計のECMPの結果について議論する必要があります。
12. A Network Action solution MUST NOT expose information to the LSRs that is not already exposed to the LER.
12. ネットワークアクションソリューションは、まだLERにさらされていないLSRに情報を公開してはなりません。
13. The design of any NA MUST NOT expose any information that a user of any service using the LSP considers confidential [RFC6973] [RFC3552].
13. NAの設計は、LSPを使用してサービスのユーザーが機密[RFC6973] [RFC3552]を考慮している情報を公開してはなりません。
14. Solution specifications MUST document any new security considerations that they introduce.
14. ソリューション仕様は、紹介する新しいセキュリティ上の考慮事項を文書化する必要があります。
15. An MNA solution MUST allow MPLS packets carrying NAI and ancillary data (where it exists) to coexist with MPLS packets that do not carry this information on the same LSP.
15. MNAソリューションでは、NAIおよび補助データ（存在する場所）を運ぶMPLSパケットを使用して、同じLSPにこの情報を運ばないMPLSパケットと共存する必要があります。
16. An MNA solution specification MUST define how a node determines whether NAIs are present in the MPLS packet.
16. MNAソリューション仕様は、NAIがMPLSパケットに存在するかどうかをノードがどのように決定するかを定義する必要があります。
17. Special Purpose Labels (SPLs) are a mechanism of last resort; therefore, an MNA solution specification that defines their use MUST minimize the number of new SPLs that are allocated.
17. 特別な目的ラベル（SPLS）は、最後の手段のメカニズムです。したがって、それらの使用を定義するMNA溶液仕様は、割り当てられた新しいSPLの数を最小限に抑える必要があります。
18. It is RECOMMENDED that an MNA solution include support for NAs for Private Use (see Section 4.1 of [RFC8126]).
18. MNAソリューションには、私的使用のためのNASのサポートを含めることをお勧めします（[RFC8126]のセクション4.1を参照）。
19. Network Action solution specifications MUST define if the NA needs to be processed as a part of the immediate forwarding operation and whether MPLS packet misordering is allowed to occur as a result of the time taken to process the NA.
19. ネットワークアクションソリューションの仕様は、NAを即時転送操作の一部として処理する必要があるかどうか、およびNAの処理にかかった時間の結果としてMPLSパケットの誤用が発生するかどうかを定義する必要があります。
20. If a Network Action solution specification allows more than one scope for an NA, it MUST define a mechanism to indicate the precedence of the scopes or any combination of the scopes.
20. ネットワークアクションソリューション仕様がNAの複数のスコープを許可する場合、スコープの優先順位またはスコープの任意の組み合わせを示すメカニズムを定義する必要があります。
21. If a network action requires an NAI with in-stack ancillary data that needs to be imposed at an LSR on an LSP, then the Network Action solution MUST specify how this is achieved in all circumstances.
21. ネットワークアクションでLSPのLSRに課す必要があるスタック内の補助データを備えたNAIが必要な場合、ネットワークアクションソリューションは、あらゆる状況でこれがどのように達成されるかを指定する必要があります。
22. If a network action requires an NAI with post-stack ancillary data to be imposed at an LSR on an LSP, then the Network Action solution specification MUST describe how this is achieved in all circumstances.
22. ネットワークアクションでは、LSPのLSRにポストスタックの補助データを備えたNAIを必要とする場合、ネットワークアクションソリューション仕様は、あらゆる状況でこれがどのように達成されるかを説明する必要があります。
23. Insertion, parsing, processing, and disposition of NAIs SHOULD make use of existing MPLS data plane operations.
23. NAISの挿入、解析、処理、および処分は、既存のMPLSデータプレーン操作を利用する必要があります。
24. Without constraining the mechanism, an MNA solution MUST enable a node inserting or modifying NAIs to determine if the target of the NAI, or any other LSR that may expose the NAI, can accept and process an MPLS packet containing the NAI.
24. メカニズムを制約することなく、MNAソリューションは、NAIのターゲット、またはNAIを露出させる可能性のある他のLSRがNAIを含むMPLSパケットを受け入れて処理できるかどうかを判断するためにNAISを挿入または変更するノードを可能にする必要があります。
25. An NAI MUST NOT be imposed for delivery to a node unless it is known that the node supports processing the NAI.
25. NAIは、ノードがNAIの処理をサポートしていることがわかっていない限り、ノードへの配達のために課されてはなりません。
26. The NAI design MUST support setting the scope of network actions.
26. NAIデザインは、ネットワークアクションの範囲の設定をサポートする必要があります。
27. A given Network Action solution specification MUST define which scope or scopes are applicable to the associated NAI.
27. 特定のネットワークアクションソリューション仕様は、関連するNAIに適用できるスコープまたはスコープを定義する必要があります。
28. An MNA solution specification SHOULD define the support of NAIs for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP) paths, but the Network Action solution specification MAY limit a specific NAI to only one of these path types if there is a clear reason to do so.
28. MNAソリューション仕様は、ポイントツーポイント（P2P）とポイントツーマルチポイント（P2MP）パスの両方に対するNAISのサポートを定義する必要がありますが、ネットワークアクションソリューション仕様は、特定のNAIをこれらのパスタイプの1つのみに制限する場合があります。そうする明確な理由があります。
29. An MNA solution specification defining data plane mechanisms for NAIs MUST be consistent across different control plane protocols.
29. NAISのデータプレーンメカニズムを定義するMNAソリューション仕様は、異なるコントロールプレーンプロトコル間で一貫している必要があります。
30. An MNA solution MUST allow the deployed MPLS control and management planes to determine the ability of downstream LSRs to accept and/or process a given NAI.
30. MNAソリューションは、展開されたMPLS制御および管理プレーンを使用して、下流のLSRが特定のNAIを受け入れて処理する能力を決定する必要があります。
31. An MNA solution MUST allow indicators for multiple network actions in the same MPLS packet.
31. MNAソリューションは、同じMPLSパケットで複数のネットワークアクションのインジケーターを許可する必要があります。
32. An MNA solution specification MUST NOT require an implementation to process all NAIs present in an MPLS packet.
32. MNAソリューション仕様は、MPLSパケットに存在するすべてのNAIを処理するための実装を必要としないはずです。
33. NAIs MUST only be inserted at LSRs that push a label onto the stack, but they can be processed by LSRs along the path of the LSP. Two examples of LSRs that push a label onto the stack are head-end LSRs and points of local repair (PLRs).
33. NAISは、ラベルをスタックに押し込むLSRにのみ挿入する必要がありますが、LSPの経路に沿ってLSRによって処理できます。ラベルをスタックに押し込むLSRの2つの例は、ヘッドエンドLSRとローカル修理のポイント（PLR）です。
34. If a network action requires in-stack ancillary data, the NAI that indicates this network action MUST be present in the label stack.
34. ネットワークアクションにスタック内の補助データが必要な場合、このネットワークアクションを示すNAIがラベルスタックに存在する必要があります。
35. All NAIs MUST be encoded in a manner consistent with [RFC3031].
35. すべてのNAIは、[RFC3031]と一致する方法でエンコードする必要があります。
36. If there is post-stack ancillary data for an NAI that is present in the label stack, it MUST be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack.
36. ラベルスタックに存在するNAIのポストスタックの補助データがある場合、ラベルスタックの下部の下を解析することなく、補助データの存在を推測することが可能である必要があります。
37. Any processing that removes an NAI from the label stack MUST also remove all associated ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.
37. ラベルスタックからNAIを削除する処理は、残りのNAIによって補助データが必要でない限り、MPLSパケットから関連するすべての補助データを削除する必要があります。
38. MNA solution specifications MUST request that IANA create registries and make allocations from those registries for NAIs as necessary to ensure unambiguous identification of standardized network actions. An MNA solution specification MAY request that IANA reserve a range of a registry for Private Use.
38. MNAソリューションの仕様は、IANAがレジストリを作成し、標準化されたネットワークアクションの明確な識別を確保するために、必要に応じてNAISのレジストリから割り当てを行うことを要求する必要があります。MNAソリューション仕様は、IANAがプライベート使用のためのレジストリの範囲を予約することを要求する場合があります。
39. A Network Action solution specification MUST state where the NAIs are to be placed in the MPLS packet, that is whether they are placed in-stack or post-stack.
39. ネットワークアクションソリューション仕様は、NAIがMPLSパケットに配置される場所、つまりスタック内に配置されるかポストスタックであるかを述べる必要があります。
40. Network Action solution specifications MUST state whether ancillary data is required to fulfill the action and whether it is in-stack and/or post-stack.
40. ネットワークアクションソリューション仕様は、アクションを満たすために補助データが必要かどうか、およびそれがスタック内および/またはポストスタックであるかどうかを述べる必要があります。
41. Network Action solution specifications MUST state if in-stack or post-stack ancillary data that is already present in the MPLS packet MAY be rewritten by an LSR.
41. ネットワークアクションソリューション仕様は、MPLSパケットに既に存在するスタック内またはポストスタックの補助データがLSRによって書き換えられる可能性があるかどうかを述べる必要があります。
42. Solutions for in-stack ancillary data MUST be able to coexist with and MUST NOT obsolete existing MPLS mechanisms. Such solutions MUST be described in a Standards Track RFC.
42. スタック内の補助データのソリューションは、既存のMPLSメカニズムと廃止されてはならない必要があります。このようなソリューションは、RFCの標準トラックで説明する必要があります。
43. Network Action solutions MUST take care to limit the quantity of in-stack ancillary data to the minimum amount required.
43. ネットワークアクションソリューションは、スタック内の補助データの量を必要な最小額に制限するように注意する必要があります。
44. A Network Action solution SHOULD NOT use post-stack ancillary data unless the size of that ancillary data could prevent the coexistence of the network action with other in-use MPLS network functions if it were inserted into the label stack.
44. ネットワークアクションソリューションは、その補助データのサイズがラベルスタックに挿入された場合、他の使用内MPLSネットワーク関数とネットワークアクションの共存を防ぐことができない限り、ポストスタックの補助データを使用しないでください。
45. The structure of the NAI and any associated ancillary data MUST enable skipping of unknown NAIs and any associated AD.
45. NAIの構造と関連する補助データは、未知のNAIと関連するADのスキップを可能にする必要があります。
46. Any MNA solution specification MUST describe whether the solution can coexist with existing post-stack data mechanisms (e.g., control words and the Generic Associated Channel Header [RFC5586]), and if so how coexistence operates.
46. MNAソリューションの仕様は、ソリューションが既存のポストスタックデータメカニズム（コントロールワードや汎用関連チャネルヘッダー[RFC5586]）と共存できるかどうか、およびその場合、共存がどのように機能するかを記述する必要があります。
47. An MNA solution MUST allow an LER that inserts ancillary data to determine whether each node that needs to process the ancillary data can read the required distance into the MPLS packet at that node (compare with the mechanism in [RFC9088]).
47. MNAソリューションは、補助データを挿入するLERを使用して、補助データを処理する必要がある各ノードが必要な距離をそのノードのMPLSパケットに読み取ることができるかどうかを判断する必要があります（[RFC9088]のメカニズムと比較）。
48. For scoped in-stack or post-stack ancillary data, any MNA solution MUST allow an LER inserting NAIs whose network actions make use of that ancillary data to determine if the NAI and ancillary data will be processed by LSRs within the scope along the path. Such a solution may need to determine if LSRs along the path can process a specific type of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.
48. スコープ中のスタック内またはポストスタックの補助データの場合、MNAソリューションは、パスに沿った範囲内のLSRによってNAIおよび補助データがLSRによって処理されるかどうかを判断するために、ネットワークアクションがその補助データを使用するNAIを挿入することを許可する必要があります。このようなソリューションは、パスに沿ったLSRが、LSRに提示されるスタックの深さでNAIによって暗示される特定のタイプの広告を処理できるかどうかを判断する必要がある場合があります。
49. A mechanism MUST exist to notify an egress LER of the presence of ancillary data so that it can dispose of it appropriately.
49. メカニズムは、補助データの存在を出力に通知して、適切に処分できるようにする必要があります。
50. In-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031].
50. スタック内の補助データは、[RFC3031]に準拠した操作と組み合わせてのみ挿入する必要があります。
51. Post-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031].
51. ポストスタックの補助データは、[RFC3031]に準拠した操作と組み合わせてのみ挿入する必要があります。
52. Processing of ancillary data below a swapped label MAY include rewriting the ancillary data.
52. 交換されたラベルの下の補助データの処理には、補助データの書き換えが含まれる場合があります。
53. If a Network Action solution needs to change the size of the ancillary data, its specification MUST analyze the implications on MPLS packet forwarding and specify how these are addressed.
53. ネットワークアクションソリューションが補助データのサイズを変更する必要がある場合、その仕様はMPLSパケット転送への影響を分析し、これらの対処方法を指定する必要があります。
54. Not more than one Standards Track solution specification SHOULD be defined for encoding in-stack ancillary data.
54. スタック内の補助データをエンコードするために、ソリューション仕様を定義する必要があります。
55. Not more than one Standards Track solution specification SHOULD be defined for encoding post-stack ancillary data.
55. ポストスタックの補助データをエンコードするには、ソリューション仕様を定義する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Solutions designed according to the requirements in this document may introduce new security considerations to MPLS, whose forwarding plane on its own does not provide any built-in security mechanisms [RFC5920].
このドキュメントの要件に従って設計されたソリューションは、MPLSに新しいセキュリティ上の考慮事項を導入する可能性があります。MPLSは、その転送面で組み込みのセキュリティメカニズムを提供していません[RFC5920]。
In particular, such solutions may embed information derived from the MPLS payload in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise assume is opaque to the MPLS network. Furthermore, an LSR may insert information into the labeled packet such that the forwarding behavior is no longer purely a function of the top label or another label with forwarding context. Instead, the forwarding behavior may be the result of a more complex heuristic. This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed and the upstream LSR inserting the data causing that change.
特に、このようなソリューションは、MPLSヘッダーのMPLSペイロードから派生した情報を埋め込む場合があります。これにより、MPLSベースのサービスのユーザーがMPLSネットワークに不透明であると仮定する可能性のあるデータが公開される場合があります。さらに、LSRは、転送動作が純粋にトップレーベルまたは転送コンテキストを持つ別のラベルの関数ではなくなるように、ラベル付きパケットに情報を挿入する場合があります。代わりに、転送動作は、より複雑なヒューリスティックの結果である可能性があります。これにより、転送挙動が変更されているLSRとその変化の原因となるデータを挿入する上流のLSRが暗黙の信頼関係が生まれます。
Several requirements above address some of these considerations. The MNA framework [MNA-FRAMEWORK] also provides security considerations resulting from any extensions to the MPLS architecture, and these SHOULD be taken together with the security considerations herein.
上記のいくつかの要件は、これらの考慮事項のいくつかに対処しています。MNAフレームワーク[MNAフレームワーク]は、MPLSアーキテクチャの拡張から生じるセキュリティ上の考慮事項も提供します。これらは、本書のセキュリティ上の考慮事項と一緒に取得する必要があります。
Individual solution specifications meeting the requirements in this document MUST address any security considerations introduced by the MNA design.
このドキュメントの要件を満たす個々のソリューション仕様は、MNA設計によって導入されたセキュリティ上の考慮事項に対処する必要があります。
The authors gratefully acknowledge the contributions from Joel Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong, Bruno Decraene, and participants in the MPLS Working Group who have provided comments.
著者は、ジョエル・ハルパーン、グレッグ・ミルスキー、Yingzhen QU、Haoyu Song、Tarek Saad、Loa Andersson、Tony Li、Adrian Farrel、Jie Dong、Bruno Decraene、およびコメントを提供したMPLSワーキンググループの参加者からの貢献に感謝します。
The authors also gratefully acknowledge the input of the members of the MPLS Open Design Team.
著者はまた、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>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[MNA-FRAMEWORK]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNA) Framework", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-10>.
[MNA-USECASES]
Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use
Cases for MPLS Network Action Indicators and MPLS
Ancillary Data", Work in Progress, Internet-Draft, draft-
ietf-mpls-mna-usecases-10, 20 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-usecases-10>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[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>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using IS-IS", RFC 9088,
DOI 10.17487/RFC9088, August 2021,
<https://www.rfc-editor.org/info/rfc9088>.
Matthew Bocci (editor)
Nokia
Email: matthew.bocci@nokia.com
Stewart Bryant
University of Surrey ICS
Email: sb@stewartbryant.com
John Drake
Independent
Email: je_drake@yahoo.com