[要約] RFC 10066は、1つのPCEP LSPに複数の転送パスを対応付け、負荷分散や冗長化を可能にするためのパス計算要素通信プロトコル（PCEP）の拡張を定義する標準化過程の文書です。パスごとの情報を運ぶPATH-ATTRIB オブジェクトと、重み、逆方向パス、フォワーディングクラスなどを表すTLVを追加し、MULTIPATH-CAP TLVでケイパビリティをネゴシエーションします。ステートレス・ステートフルのどちらのPCEPにも適用でき、主な用途はSRポリシーの候補パス内の複数のセグメントリストのシグナリングで、RFC 9862では対象外だった部分を補います。
Internet Engineering Task Force (IETF) M. Koldychev, Ed.
Request for Comments: 10066 Ciena Corporation
Category: Standards Track S. Sidor, Ed.
ISSN: 2070-1721 Cisco Systems.
October 2026
This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP and are designed to be reusable for future path types. Their primary application is Segment Routing Policy (SR Policy), where a Candidate Path can contain multiple segment lists: current PCEP extensions for SR Policy only allow signaling of a single segment list per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load balancing across paths.
この文書は、マルチパス情報をシグナリングするためのパス計算要素通信プロトコル (Path Computation Element Communication Protocol, PCEP) の拡張を定義します。この拡張は、複数の転送パスを1つのPCEP Label Switched Path (LSP) に関連付け、多様なパスにわたる負荷分散と冗長性を可能にします。この拡張は汎用的であり、ステートレスPCEPとステートフルPCEPの両方に適用できます。また、将来のパスタイプでも再利用できるように設計されています。主な適用先はセグメントルーティングポリシー (Segment Routing Policy, SR Policy) です。SRポリシーでは、候補パス (Candidate Path) が複数のセグメントリストを含むことができますが、SRポリシー向けの現行のPCEP拡張では、候補パスごとに1つのセグメントリストしかシグナリングできません。この拡張により、パス間の重み付きまたは等コストの負荷分散といったマルチパス機能が可能になります。
This is an Internet Standards Track document.
これはInternet Standards Trackの文書です。
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.
この文書は Internet Engineering Task Force (IETF) の成果物です。IETFコミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) により発行が承認されています。Internet Standards の詳細については、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/rfc10066.
この文書の現在の状況、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10066 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書著者として特定された人々。All rights reserved.（著作権はすべて留保されています。）
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 Trust の IETF文書に関する法的規定 (https://trustee.ietf.org/license-info) の適用を受けます。これらの文書は、本文書に関する権利と制限を記述しているため、注意深く確認してください。この文書から抽出されるコード部品には、Trust Legal Provisions のセクション4.eに記載されているとおり Revised BSD License のテキストを含めなければならず、Revised BSD License に記載されているとおり無保証で提供されます。
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Motivation
2.1. Signaling Multiple Segment Lists of an SR Candidate Path
2.2. Splitting of Requested Bandwidth
2.3. Reverse Path Information
3. Protocol Extensions
3.1. PATH-ATTRIB Object
3.2. METRIC Object
3.3. MULTIPATH-WEIGHT TLV
3.4. MULTIPATH-OPPDIR-PATH TLV
3.5. Composite Candidate Path
3.5.1. Per-Flow Candidate Path
4. Operation
4.1. Capability Negotiation
4.1.1. Multipath Capability TLV
4.2. Path ID
4.3. Signaling Multiple Paths for Load Balancing
4.4. Signaling Opposite-Direction Path Information
5. PCEP Message Extensions
6. IANA Considerations
6.1. PCEP Object
6.2. PCEP TLV
6.3. PCEP-Error Object
6.4. Flags in the MULTIPATH-CAP TLV
6.5. Flags in the PATH-ATTRIB Object
6.6. Flags in the MULTIPATH-OPPDIR-PATH TLV
6.7. Flags in the MULTIPATH-FORWARD-CLASS TLV
7. Security Considerations
8. Operational Considerations
8.1. Control of Function and Policy
8.2. Information and Data Models
8.3. Liveness Detection and Monitoring
8.4. Verify Correct Operations
8.5. Requirements on Other Protocols
8.6. Impact on Network Operations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Examples
A.1. SR Policy Candidate Path with Multiple Segment Lists
A.2. Composite Candidate Path
A.3. Opposite-Direction Tunnels
Acknowledgements
Contributors
Authors' Addresses
1. Introduction
1. はじめに
1.1. Requirements Language
1.1. 要求事項の表記
1.2. Terminology
1.2. 用語
2. Motivation
2. 動機
2.1. Signaling Multiple Segment Lists of an SR Candidate Path
2.1. SR候補パスの複数のセグメントリストのシグナリング
2.2. Splitting of Requested Bandwidth
2.2. 要求された帯域幅の分割
2.3. Reverse Path Information
2.3. 逆方向パス情報
3. Protocol Extensions
3. プロトコル拡張
3.1. PATH-ATTRIB Object
3.1. PATH-ATTRIB オブジェクト
3.2. METRIC Object
3.2. METRIC オブジェクト
3.3. MULTIPATH-WEIGHT TLV
3.3. MULTIPATH-WEIGHT TLV
3.4. MULTIPATH-OPPDIR-PATH TLV
3.4. MULTIPATH-OPPDIR-PATH TLV
3.5. Composite Candidate Path
3.5. 合成候補パス
3.5.1. Per-Flow Candidate Path
3.5.1. フロー単位の候補パス
4. Operation
4. 運用
4.1. Capability Negotiation
4.1. ケーパビリティのネゴシエーション
4.1.1. Multipath Capability TLV
4.1.1. Multipath Capability TLV
4.2. Path ID
4.2. Path ID
4.3. Signaling Multiple Paths for Load Balancing
4.3. 負荷分散のための複数パスのシグナリング
4.4. Signaling Opposite-Direction Path Information
4.4. 逆方向パス情報のシグナリング
5. PCEP Message Extensions
5. PCEPメッセージの拡張
6. IANA Considerations
6. IANAに関する考慮事項
6.1. PCEP Object
6.1. PCEP Object
6.2. PCEP TLV
6.2. PCEP TLV
6.3. PCEP-Error Object
6.3. PCEP-Error Object
6.4. Flags in the MULTIPATH-CAP TLV
6.4. MULTIPATH-CAP TLVのフラグ
6.5. Flags in the PATH-ATTRIB Object
6.5. PATH-ATTRIB Objectのフラグ
6.6. Flags in the MULTIPATH-OPPDIR-PATH TLV
6.6. MULTIPATH-OPPDIR-PATH TLVのフラグ
6.7. Flags in the MULTIPATH-FORWARD-CLASS TLV
6.7. MULTIPATH-FORWARD-CLASS TLVのフラグ
7. Security Considerations
7. セキュリティに関する考慮事項
8. Operational Considerations
8. 運用上の考慮事項
8.1. Control of Function and Policy
8.1. 機能とポリシーの制御
8.2. Information and Data Models
8.2. 情報モデルとデータモデル
8.3. Liveness Detection and Monitoring
8.3. 生存性の検出とモニタリング
8.4. Verify Correct Operations
8.4. 正しい動作の検証
8.5. Requirements on Other Protocols
8.5. 他のプロトコルへの要件
8.6. Impact on Network Operations
8.6. ネットワーク運用への影響
9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献
9.2. Informative References
9.2. 参考情報の文献
Appendix A. Examples
Appendix A. 例
A.1. SR Policy Candidate Path with Multiple Segment Lists
A.1. 複数のセグメントリストを持つSRポリシー候補パス
A.2. Composite Candidate Path
A.2. 合成候補パス
A.3. Opposite-Direction Tunnels
A.3. 逆方向トンネル
Acknowledgements
謝辞
Contributors
貢献者
Authors' Addresses
著者の住所
Segment Routing Policy (SR Policy) for Traffic Engineering [RFC9256] details the concepts of Segment Routing Policy and approaches to steering traffic into an SR Policy. In particular, it describes the SR Candidate Path as a collection of one or more segment lists. The current PCEP specifications only allow for signaling of one segment list per Candidate Path. The PCEP extension to support Segment Routing Policy Candidate Paths [RFC9862] specifically kept the signaling of multiple segment lists outside its scope.
Segment Routing Policy (SR Policy) for Traffic Engineering [RFC9256] は、セグメントルーティングポリシーの概念と、トラフィックをSRポリシーにステアリングする方法を詳述しています。特に、SR候補パス (Candidate Path) を1つ以上のセグメントリストの集合として記述しています。現行のPCEP仕様では、候補パスごとに1つのセグメントリストしかシグナリングできません。セグメントルーティングポリシーの候補パスをサポートするPCEP拡張 [RFC9862] は、複数のセグメントリストのシグナリングを、その範囲外として意図的に除外していました。
This document defines the required extensions that allow the signaling of multipath information via PCEP. Although these extensions are motivated by the SR Policy use case, they are also applicable to other technologies. For SR Policy, support for [RFC9862] is a prerequisite for using the multipath extensions defined in this document with SR Policy Candidate Paths.
この文書は、PCEPによるマルチパス情報のシグナリングを可能にするために必要な拡張を定義します。これらの拡張はSRポリシーのユースケースを動機としていますが、他の技術にも適用できます。SRポリシーについては、この文書で定義するマルチパス拡張をSRポリシーの候補パスで使用するための前提条件として、[RFC9862] のサポートが必要です。
The following terms are used in this document:
この文書では次の用語を使用します。
ECMP:
ECMP:
Equal-Cost Multipath, equally distributing traffic among multiple paths/links, where each path/link gets the same share of traffic as others.
等コストマルチパス (Equal-Cost Multipath)。複数のパス/リンクの間でトラフィックを均等に分散し、各パス/リンクが他と同じ割合のトラフィックを受け持ちます。
W-ECMP:
W-ECMP:
Weighted Equal-Cost Multipath, unequally distributing traffic among multiple paths/links, where some paths/links get more traffic than others.
重み付き等コストマルチパス (Weighted Equal-Cost Multipath)。複数のパス/リンクの間でトラフィックを不均等に分散し、一部のパス/リンクが他よりも多くのトラフィックを受け持ちます。
PLSP:
PLSP:
PCE Label Switched Path, a path or set of paths computed or controlled by the PCE. In the context of SR Policy, a PLSP corresponds to a Candidate Path.
PCE Label Switched Path。PCEによって計算または制御される、パスまたはパスの集合です。SRポリシーの文脈では、PLSPは候補パス (Candidate Path) に対応します。
Segment List:
セグメントリスト (Segment List):
An ordered list of segments that defines a forwarding path in Segment Routing, as defined in [RFC9256]. In PCEP for SR Policy, each segment list is encoded as an ERO or RRO.
[RFC9256] で定義されている、セグメントルーティングにおける転送パスを定義するセグメントの順序付きリストです。SRポリシー向けのPCEPでは、各セグメントリストはEROまたはRROとしてエンコードされます。
ERO:
ERO:
Explicit Route Object, defined in [RFC5440], encodes an explicit path. In the context of SR Policy, an ERO encodes a segment list.
Explicit Route Object。[RFC5440] で定義され、明示的パスをエンコードします。SRポリシーの文脈では、EROはセグメントリストをエンコードします。
RRO:
RRO:
Record Route Object, defined in [RFC5440], encodes the actual signaled path. In the context of SR Policy, an RRO reports a segment list.
Record Route Object。[RFC5440] で定義され、実際にシグナリングされたパスをエンコードします。SRポリシーの文脈では、RROはセグメントリストを報告します。
Path:
パス (Path):
In the context of this document, a path refers to a single forwarding path encoded in an ERO or RRO. For SR Policy, a path corresponds to a segment list. The mechanisms defined in this document use the generic term "path" to allow applicability beyond SR Policy.
この文書の文脈では、パスとは、EROまたはRROでエンコードされる単一の転送パスを指します。SRポリシーでは、パスはセグメントリストに対応します。この文書で定義するメカニズムは、SRポリシー以外にも適用できるよう、汎用的な用語として "path" を使用します。
LSP:
LSP:
Label Switched Path. The base PCEP specification [RFC4655] originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol [RFC3209]. Over time, support for additional path setup types such as SRv6 has been introduced [RFC9603]. The term "LSP" is used extensively in PCEP specifications and, while the multipath extensions defined in this document are applicable beyond SR Policy, in the context of PCEP for SR Policy [RFC9862], an LSP object represents an SR Policy Candidate Path, which may be an SRv6 path (still represented using the LSP object as specified in [RFC8231]). A single LSP may contain multiple paths (segment lists).
Label Switched Path。基本のPCEP仕様 [RFC4655] は、当初、RSVP-TEシグナリングプロトコル [RFC3209] でインスタンス化されるLSPを持つMPLSおよびGMPLSネットワークに対するPCEアーキテクチャの使用を定義していました。その後、SRv6などの追加のパスセットアップタイプへのサポートが導入されています [RFC9603]。"LSP" という用語はPCEPの仕様で広く使用されています。この文書で定義するマルチパス拡張はSRポリシー以外にも適用できますが、SRポリシー向けのPCEP [RFC9862] の文脈では、LSPオブジェクトはSRポリシーの候補パスを表します。この候補パスはSRv6パスの場合もあり、その場合も [RFC8231] で規定されているとおりLSPオブジェクトを使用して表現されます。1つのLSPは、複数のパス (セグメントリスト) を含むことができます。
SR Policy:
SRポリシー (SR Policy):
A Segment Routing Policy as defined in [RFC9256], identified by the tuple (headend, color, endpoint).
[RFC9256] で定義されるセグメントルーティングポリシーで、タプル (headend, color, endpoint) によって識別されます。
This extension is motivated by the use cases described below.
この拡張は、以下に述べるユースケースを動機としています。
The Candidate Path of an SR Policy is the unit of signaling in PCEP [RFC9862]. A single Candidate Path can consist of multiple segment lists. Each segment list is represented by an ERO. In existing PCEP specifications, a PCEP LSP object is associated with exactly one ERO. This restriction prevents the encoding of multiple segment lists (i.e., multiple EROs) within the single LSP.
SRポリシーの候補パス (Candidate Path) は、PCEPにおけるシグナリングの単位です [RFC9862]。1つの候補パスは、複数のセグメントリストで構成できます。各セグメントリストはEROで表現されます。既存のPCEP仕様では、PCEPのLSPオブジェクトは厳密に1つのEROに関連付けられます。この制約により、1つのLSP内に複数のセグメントリスト (すなわち複数のERO) をエンコードすることができません。
For example, a Path Computation Client (PCC) may request a path whose bandwidth demand cannot be accommodated on any single link along an available path in the network. The PCE can return multiple paths that together can carry the requested bandwidth. The PCC can then equally or unequally split the incoming traffic among these paths.
例えば、Path Computation Client (PCC) が、ネットワーク内の利用可能なパス上のどの単一リンクでも帯域幅の要求を収容できないパスを要求することがあります。PCEは、合わせて要求された帯域幅を運ぶことができる複数のパスを返すことができます。その後、PCCは、着信トラフィックをこれらのパス間で均等または不均等に分割できます。
PCEP extensions for Associated Bidirectional LSPs [RFC9059] defines a mechanism in PCEP to associate two opposite-direction SR Policy Candidate Paths. However, within each Candidate Path there can be multiple segment lists, and [RFC9059] does not define a mechanism to specify mapping between segment lists of the forward and reverse Candidate Paths.
Certain applications, such as Circuit Style SR Policy [CS-SR-POLICY], require the knowledge of reverse paths per segment list, not just per Candidate Path. For example, when the headend knows the reverse segment list for each forward segment list, then Performance Measurement (PM) / Bidirectional Forwarding Detection (BFD) can run a separate session on every segment list, by imposing a double stack (forward stack followed by a reverse stack) onto the packet. If the reverse segment list is co-routed with the forward segment list, then the PM/BFD session would traverse the same links in the forward and reverse directions, thus allowing detection of link/node failures in both directions.
Circuit Style SRポリシー [CS-SR-POLICY] などの一部のアプリケーションは、Candidate Path ごとだけでなく、セグメントリストごとの逆方向パスに関する情報を必要とします。例えば、ヘッドエンドが各順方向セグメントリストに対応する逆方向セグメントリストを把握している場合、Performance Measurement (PM) や Bidirectional Forwarding Detection (BFD) は、パケットに二重スタック (順方向スタックに逆方向スタックが続くもの) を付与することで、各セグメントリスト上で個別のセッションを実行できます。逆方向セグメントリストが順方向セグメントリストと同一経路 (co-routed) である場合、PM/BFD セッションは順方向と逆方向で同じリンクを通過するため、両方向のリンク障害やノード障害を検出できます。
This document defines the PATH-ATTRIB object that is used to carry per-path information and to act as a separator between EROs/RROs in the <intended-path>/<actual-path> Routing Backus-Naur Form (RBNF) [RFC5511] element. The PATH-ATTRIB object always precedes the ERO or RRO that it applies to. If multiple EROs or RROs are present, then each ERO or RRO MUST be preceded by a PATH-ATTRIB object that describes it.
本文書は、パスごとの情報を運び、<intended-path>/<actual-path> の Routing Backus-Naur Form (RBNF) [RFC5511] 要素内で ERO/RRO 間の区切りとして機能する PATH-ATTRIB オブジェクトを定義します。PATH-ATTRIB オブジェクトは、適用対象の ERO または RRO の直前に必ず置かれます。複数の ERO または RRO が存在する場合、各 ERO または RRO の直前には、それを記述する PATH-ATTRIB オブジェクトを置かなければなりません (MUST)。
The PATH-ATTRIB Object-Class value is 45.
PATH-ATTRIB の Object-Class 値は 45 です。
The PATH-ATTRIB Object-Type value is 1.
PATH-ATTRIB の Object-Type 値は 1 です。
The format of the PATH-ATTRIB object is shown in Figure 1.
PATH-ATTRIB オブジェクトの形式を図1に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R| O |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-ATTRIB Object Format
図1: PATH-ATTRIB オブジェクトの形式
Flags (32 bits):
Flags (32ビット):
O (Operational - 3 bits):
O (Operational - 3ビット):
Operational state of the path, same values as the identically named field in the LSP object [RFC8231]. The relationship between the per-path Operational state and the LSP-level Operational state in the LSP object is outside the scope of this document; for SR Policy, the Candidate Path validity criterion is defined in Section 2.8 of [RFC9256].
R (Reverse - 1 bit):
R (Reverse - 1ビット):
Indicates the path flows in the reverse direction, i.e., it originates on the LSP destination and terminates on the LSP source (usually the PCC headend itself). Paths with this flag set are not installed in the forwarding plane for load-balancing purposes, but MAY be used by the PCC for operations such as Performance Measurement (PM) or Bidirectional Forwarding Detection (BFD).
パスが逆方向に流れること、すなわち LSP の宛先を始点とし、LSP の送信元 (通常は PCC ヘッドエンド自身) を終点とすることを示します。このフラグが設定されたパスは、負荷分散の目的では転送プレーンにインストールされませんが、PCC が Performance Measurement (PM) や Bidirectional Forwarding Detection (BFD) などの動作に使用してもよい (MAY)。
Unassigned bits
未割り当てビット
MUST be set to 0 on transmission and MUST be ignored on receipt.
送信時には 0 に設定しなければならず (MUST)、受信時には無視しなければなりません (MUST)。
Path ID (32 bits):
Path ID (32ビット):
4-octet identifier that identifies a path (encoded in the ERO/RRO) within the set of multiple paths under the PCEP LSP. See Section 4.2 for details.
PCEP LSP 配下の複数パスの集合の中で、(ERO/RRO にエンコードされた) 1つのパスを識別する 4オクテットの識別子です。詳細はセクション 4.2 を参照してください。
Optional TLVs:
Optional TLVs:
Variable length field that can contain zero or more Type-Length-Value (TLV) elements that carry additional per-path information. The specific TLVs that can be included are defined in subsequent sections of this document.
パスごとの追加情報を運ぶ Type-Length-Value (TLV) 要素を0個以上含むことができる可変長フィールドです。含めることのできる具体的な TLV は、本文書の後続のセクションで定義されます。
The PCEP METRIC object can continue to be used at the LSP level to describe properties of the overall LSP. Mechanisms for encoding per-path metrics (e.g., a separate METRIC for each path) are outside the scope of this document and would require further extensions.
PCEP の METRIC オブジェクトは、LSP 全体の特性を記述するために、引き続き LSP レベルで使用できます。パスごとのメトリックをエンコードするメカニズム (例えば、各パスに個別の METRIC を設ける方法) は、本文書の対象範囲外であり、さらなる拡張が必要となります。
A new MULTIPATH-WEIGHT TLV is optional in the PATH-ATTRIB object.
新しい MULTIPATH-WEIGHT TLV は、PATH-ATTRIB オブジェクト内で任意です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MULTIPATH-WEIGHT TLV Format
図2: MULTIPATH-WEIGHT TLV の形式
Type (16 bits):
Type (16ビット):
61 for "MULTIPATH-WEIGHT" TLV.
"MULTIPATH-WEIGHT" TLV では 61。
Length (16 bits):
Length (16ビット):
MUST be set to 4.
4 に設定しなければなりません (MUST)。
Weight (32 bits):
Weight (32ビット):
unsigned integer weight of the path described by the enclosing PATH-ATTRIB object, if W-ECMP is desired. The fraction of flows that a specific ERO/RRO carries is derived from the ratio of its weight to the sum of the weights of all paths in the multipath (including that path): see Section 4.3 for details. For SR Policy, if the Weight value is 0, the corresponding segment list is declared invalid per Section 5.1 of [RFC9256] and carries no traffic. If all paths within an LSP have Weight 0, the sum of weights is zero, making the candidate path invalid per Section 2.11 of [RFC9256]. Signaling a zero-weight path alongside paths with non-zero weights can be used to drain traffic from a path while retaining its forwarding instructions.
W-ECMP が望まれる場合の、囲んでいる PATH-ATTRIB オブジェクトが記述するパスの、符号なし整数の重みです。特定の ERO/RRO が運ぶフローの割合は、その重みと、(当該パスを含む) マルチパス内の全パスの重みの合計との比から導出されます。詳細はセクション 4.3 を参照してください。SRポリシーでは、Weight 値が 0 の場合、対応するセグメントリストは [RFC9256] のセクション 5.1 に従って無効と宣言され、トラフィックを運びません。LSP 内の全パスの Weight が 0 の場合、重みの合計はゼロとなり、[RFC9256] のセクション 2.11 に従って Candidate Path は無効になります。ゼロ以外の重みを持つパスと並べて、重みゼロのパスをシグナリングすることで、転送命令を保持したまま、そのパスからトラフィックを排出 (drain) できます。
When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, or the PATH-ATTRIB object is absent from the <intended-path>/<actual-path>, then the Weight of the corresponding path is assumed to be 1.
MULTIPATH-WEIGHT TLV が PATH-ATTRIB オブジェクトに存在しない場合、または PATH-ATTRIB オブジェクトが <intended-path>/<actual-path> に存在しない場合、対応するパスの Weight は 1 であると見なされます。
A new MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB object. Multiple instances of the TLV are allowed in the same PATH-ATTRIB object. Each TLV instance identifies one opposite-direction path for the path described by this PATH-ATTRIB object. This provides per-path-level opposite-direction mapping within an LSP. In the context of SR Policy, this corresponds to per-Segment-List mapping within a Candidate Path, complementing the Candidate Path level bidirectional association defined in [RFC10067], which also describes the usage of this TLV in the context of associated bidirectional SR Paths. See Section 4.4 for operational details.
新しい MULTIPATH-OPPDIR-PATH TLV は、PATH-ATTRIB オブジェクト内で任意です。同じ PATH-ATTRIB オブジェクト内に、この TLV の複数のインスタンスを含めることができます。各 TLV インスタンスは、この PATH-ATTRIB オブジェクトが記述するパスに対する、逆方向のパスを1つ識別します。これにより、LSP 内でパスごとのレベルの逆方向対応付けが提供されます。SRポリシーの文脈では、これは Candidate Path 内のセグメントリストごとの対応付けに相当し、[RFC10067] で定義されている Candidate Path レベルの双方向関連付けを補完します。[RFC10067] は、関連付けられた双方向 SR パスの文脈におけるこの TLV の使用についても記述しています。運用上の詳細はセクション 4.4 を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |L|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opposite-Direction Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MULTIPATH-OPPDIR-PATH TLV Format
図3: MULTIPATH-OPPDIR-PATH TLV の形式
Type (16 bits):
Type (16ビット):
63 for "MULTIPATH-OPPDIR-PATH" TLV
"MULTIPATH-OPPDIR-PATH" TLV では 63
Length (16 bits):
Length (16ビット):
MUST be set to 8.
8 に設定しなければなりません (MUST)。
Reserved:
Reserved:
This field MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは、送信時にはゼロに設定しなければならず (MUST)、受信時には無視しなければなりません (MUST)。
Flags (16 bits):
Flags (16ビット):
N (Node co-routed):
N (Node co-routed):
If set, indicates this path is node co-routed with its opposite-direction path specified in this TLV. Two opposite-direction paths are node co-routed if they traverse the same nodes, but MAY traverse different links. If not set, the paths are not guaranteed to be node co-routed (they may or may not traverse the same set of nodes).
設定されている場合、このパスが、この TLV で指定された逆方向のパスとノードに関して同一経路 (node co-routed) であることを示します。逆方向の2つのパスは、同じノードを通過する場合、node co-routed です。ただし、異なるリンクを通過してもよい (MAY)。設定されていない場合、これらのパスが node co-routed であることは保証されません (同じノードの集合を通過することもあれば、通過しないこともあります)。
L (Link co-routed):
L (Link co-routed):
If set, indicates this path is link co-routed with its opposite-direction path, specified in this TLV. Two opposite-direction paths are link co-routed if they traverse the same links (but in opposite directions). Link co-routing implies node co-routing; therefore, it is not necessary to set the N-flag when the L-flag is set.
設定されている場合、このパスが、この TLV で指定された逆方向のパスとリンクに関して同一経路 (link co-routed) であることを示します。逆方向の2つのパスは、同じリンクを (逆向きに) 通過する場合、link co-routed です。link co-routing は node co-routing を含意します。したがって、L-flag を設定する場合に N-flag を設定する必要はありません。
The terms "link" and "node" used by the N-flag and L-flag
N-flag と L-flag で用いられる「リンク」と「ノード」という用語は、
refer to the links and nodes as represented in the topology that the PCE uses for path computation. The exact nature of a link is determined by the PCE's topology view and is out of scope of this document. The same notion of "link" and "node" MUST be used consistently for both the forward and the opposite-direction path when evaluating co-routing; a path and its opposite-direction path are represented in the same topology view.
PCE がパス計算に用いるトポロジーで表現されるリンクとノードを指します。リンクの正確な性質は PCE のトポロジービューによって決まり、本書の範囲外です。同一経路性を評価する際には、順方向のパスと逆方向のパスの両方に対して、「リンク」と「ノード」について同じ概念を一貫して使用しなければなりません (MUST)。パスとその逆方向のパスは、同じトポロジービューで表現されるためです。
Unassigned bits
Unassigned bits
MUST be set to 0 on transmission and MUST be ignored on receipt.
送信時には 0 に設定しなければならず (MUST)、受信時には無視しなければなりません (MUST)。
Opposite-Direction Path ID (32 bits):
Opposite-Direction Path ID (32ビット):
References the Path ID field (see Section 4.2) of a PATH-ATTRIB object that identifies a path going in the opposite direction to this path. The value 0 is reserved and MUST NOT be used in this field. If no opposite-direction path exists, the MULTIPATH-OPPDIR-PATH TLV MUST NOT be included in the PATH-ATTRIB object (see Section 4.4). If a PCEP speaker receives a MULTIPATH-OPPDIR-PATH TLV with Opposite-Direction Path ID set to 0, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 37 ("Invalid opposite-direction path mapping").
このパスと逆方向に向かうパスを識別する PATH-ATTRIB オブジェクトの Path ID フィールド (4.2節を参照) を参照します。値 0 は予約されており、このフィールドで使用してはなりません (MUST NOT)。逆方向のパスが存在しない場合、MULTIPATH-OPPDIR-PATH TLV を PATH-ATTRIB オブジェクトに含めてはなりません (MUST NOT) (4.4節を参照)。PCEP スピーカーが、Opposite-Direction Path ID が 0 に設定された MULTIPATH-OPPDIR-PATH TLV を受信した場合、Error-Type = 19 ("Invalid Operation")、Error-Value = 37 ("Invalid opposite-direction path mapping") の PCErr メッセージを送信しなければなりません (MUST)。
SR Policy Architecture [RFC9256] defines the concept of a composite candidate path. A regular SR Policy candidate path outputs traffic to a set of segment lists, while an SR Policy composite candidate path outputs traffic recursively to a set of SR Policies on the same headend. In PCEP, the composite candidate path still consists of PATH-ATTRIB objects, but ERO is replaced by color of the recursively used SR Policy.
SRポリシーアーキテクチャ [RFC9256] は、合成候補パス (composite candidate path) の概念を定義しています。通常の SRポリシーの候補パスは、トラフィックをセグメントリストの集合に出力しますが、SRポリシーの合成候補パスは、同じヘッドエンド上の SRポリシーの集合に対して再帰的にトラフィックを出力します。PCEP では、合成候補パスは引き続き PATH-ATTRIB オブジェクトで構成されますが、ERO は、再帰的に使用される SRポリシーの color に置き換えられます。
To signal the composite candidate path, this document makes use of the COLOR TLV, defined in [RFC9863]. For a composite candidate path, the COLOR TLV is included in the PATH-ATTRIB object, thus allowing each composite candidate path to do ECMP/W-ECMP among SR Policies identified by its constituent colors. To achieve W-ECMP, the MULTIPATH-WEIGHT TLV (Section 3.3) is included alongside the COLOR TLV in each PATH-ATTRIB object. Each PATH-ATTRIB object identifies one constituent color of the composite candidate path. If multiple COLOR TLVs are contained in the PATH-ATTRIB object, the first one is processed and the others MUST be ignored.
合成候補パスをシグナリングするために、本書は [RFC9863] で定義された COLOR TLV を利用します。合成候補パスでは、COLOR TLV が PATH-ATTRIB オブジェクトに含まれます。これにより、各合成候補パスは、それを構成する color で識別される SRポリシー間で ECMP/W-ECMP を行うことができます。W-ECMP を実現するには、各 PATH-ATTRIB オブジェクトで、MULTIPATH-WEIGHT TLV (3.3節) を COLOR TLV と併せて含めます。各 PATH-ATTRIB オブジェクトは、合成候補パスを構成する color を1つ識別します。PATH-ATTRIB オブジェクトに複数の COLOR TLV が含まれる場合、最初のものが処理され、それ以外は無視しなければなりません (MUST)。
An ERO MUST be included as per the existing RBNF; this ERO MUST contain no subobjects. This empty ERO serves as a placeholder to maintain compatibility with existing implementations based on the RBNF defined in [RFC8231]. If the headend receives a non-empty ERO for a composite candidate path, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 21 ("Non-empty path").
既存の RBNF に従って ERO を含めなければなりません (MUST) が、この ERO にはサブオブジェクトを含めてはなりません (MUST)。この空の ERO は、[RFC8231] で定義された RBNF に基づく既存の実装との互換性を維持するためのプレースホルダーとして機能します。ヘッドエンドが合成候補パスに対して空でない ERO を受信した場合、Error-Type = 19 ("Invalid Operation")、Error-Value = 21 ("Non-empty path") の PCErr メッセージを送信しなければなりません (MUST)。
See Appendix A.2 for an example of the encoding.
エンコーディングの例については、付録 A.2 を参照してください。
Per-Flow Candidate Path builds on the concept of the composite candidate path. Each Path in a Per-Flow Candidate Path is assigned a 3-bit forwarding class value, which allows Quality-of-Service (QoS) classified traffic to be steered depending on the forwarding class.
フロー単位の候補パス (Per-Flow Candidate Path) は、合成候補パスの概念を基盤としています。フロー単位の候補パス内の各 Path には、3ビットのフォワーディングクラス値が割り当てられます。これにより、Quality-of-Service (QoS) で分類されたトラフィックを、フォワーディングクラスに応じてステアリングできます。
A new MULTIPATH-FORWARD-CLASS TLV is optional in the PATH-ATTRIB object.
新しい MULTIPATH-FORWARD-CLASS TLV は、PATH-ATTRIB オブジェクトでは任意です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Flags | FC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MULTIPATH-FORWARD-CLASS TLV Format
図4: MULTIPATH-FORWARD-CLASS TLV の形式
Type (16 bits):
Type (16ビット):
76 for "MULTIPATH-FORWARD-CLASS" TLV.
"MULTIPATH-FORWARD-CLASS" TLV では 76。
Length (16 bits):
Length (16ビット):
MUST be set to 4.
4 に設定しなければなりません (MUST)。
Flags (32 bits):
Flags (32ビット):
T (1 bit):
T (1ビット):
MPLS Traffic Class (TC) type. This is the most significant bit of the Flags field. When set, indicates that the FC value is derived from the MPLS TC bits as described in Section 8.6 of [RFC9256]. When not set, the interpretation of the FC value is reserved for future use; a future specification MAY define a wider, right-aligned classifier value occupying additional low-order bits of the Flags field (e.g., for a non-MPLS data plane).
MPLS Traffic Class (TC) タイプ。これは Flags フィールドの最上位ビットです。設定されている場合、FC 値が [RFC9256] の8.6節で説明されているとおり MPLS TC ビットから導出されることを示します。設定されていない場合、FC 値の解釈は将来の使用のために予約されています。将来の仕様が、Flags フィールドの追加の下位ビットを占める、より幅の広い右詰めの分類子の値を定義してもよい (MAY) (たとえば、MPLS 以外のデータプレーン向け)。
FC (3 bits):
FC (3ビット):
Forwarding class value. When the T-flag is set, this carries the MPLS TC-based forwarding class value as defined in Section 8.6 of [RFC9256]. This value is given by the QoS classifier to traffic entering the given Candidate Path. Different classes of traffic that enter the given Candidate Path can be differentially steered into different colors. The FC field allows up to 8 different forwarding classes (values 0-7). The semantics of specific FC values are significant at the headend node (PCC) that implements the SR Policy and are determined by that node's local QoS policy or configuration. Coordination of FC value meanings between PCEP peers (e.g., through out-of-band configuration management or operational procedures) is outside the scope of this document.
フォワーディングクラス値。T-flag が設定されている場合、このフィールドは [RFC9256] の8.6節で定義された、MPLS TC に基づくフォワーディングクラス値を保持します。この値は、QoS 分類子によって、当該候補パスに入るトラフィックに与えられます。当該候補パスに入るトラフィックの異なるクラスは、異なる color に差別的にステアリングできます。FC フィールドでは、最大8つの異なるフォワーディングクラス (値 0-7) を扱えます。個々の FC 値の意味は、SRポリシーを実装するヘッドエンドノード (PCC) において有意であり、そのノードのローカルな QoS ポリシーまたは設定によって決まります。PCEP ピア間での FC 値の意味の調整 (たとえば、帯域外の設定管理や運用手順を通じたもの) は、本書の範囲外です。
Unassigned bits
Unassigned bits
MUST be set to 0 on transmission and MUST be ignored on receipt.
送信時には 0 に設定しなければならず (MUST)、受信時には無視しなければなりません (MUST)。
A new MULTIPATH-CAP TLV is defined. This TLV MAY be present in the OPEN object during PCEP session establishment. It MAY also be present in the LSP object for each individual LSP from the PCC.
新しい MULTIPATH-CAP TLV が定義されます。この TLV は、PCEP セッション確立時に OPEN オブジェクトに含まれてもよい (MAY)。また、PCC からの個々の LSP ごとに LSP オブジェクトに含まれてもよい (MAY)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Multipaths | Flags |C|F|O| |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MULTIPATH-CAP TLV Format
図5: MULTIPATH-CAP TLV の形式
Type (16 bits):
Type (16ビット):
60 for "MULTIPATH-CAP" TLV.
"MULTIPATH-CAP" TLV では 60。
Length (16 bits):
Length (16ビット):
MUST be set to 4.
4に設定しなければなりません (MUST)。
Number of Multipaths (16 bits):
Number of Multipaths (16ビット):
When sent from a PCC, it indicates how many forward primary multipaths the PCC can install in the forwarding plane. From a PCE, it indicates how many forward primary multipaths the PCE can compute. This value is per-LSP when carried in the LSP object; the effective value governing a given LSP is the LSP object value if present; otherwise, it is the OPEN object value (see below). This count does not include reverse paths (R-flag=1, where the R-flag is defined in Section 3.1), which are not installed in forwarding for load-balancing purposes. Therefore, the total number of PATH-ATTRIB objects in an LSP may exceed this value when reverse paths are also signaled. The value 0 indicates an unlimited number.
PCCから送信される場合、PCCが転送プレーンにインストールできる順方向プライマリマルチパスの数を示します。PCEから送信される場合は、PCEが計算できる順方向プライマリマルチパスの数を示します。この値は、LSP objectに含まれる場合はLSPごとの値となります。特定のLSPに適用される有効な値は、LSP objectの値が存在する場合はその値であり、存在しない場合はOPEN objectの値です（後述）。この数には、負荷分散を目的とした転送にはインストールされない逆方向パス (R-flag=1。R-flagはセクション3.1で定義されています) は含まれません。したがって、逆方向パスもシグナリングされる場合、LSP内のPATH-ATTRIB objectの総数がこの値を超えることがあります。値0は無制限を示します。
Flags (16 bits):
Flags (16ビット):
W-flag:
W-flag:
Indicates whether MULTIPATH-WEIGHT TLV is supported. This flag covers the use of MULTIPATH-WEIGHT for both regular and composite candidate paths.
MULTIPATH-WEIGHT TLVがサポートされているかどうかを示します。このフラグは、通常の候補パスと複合候補パスの両方におけるMULTIPATH-WEIGHTの使用を対象とします。
O-flag:
O-flag:
In the OPEN object, this flag indicates whether the MULTIPATH-OPPDIR-PATH TLV is supported. In the LSP object, this flag indicates that opposite-direction path information is requested or provided for that specific LSP. When set by the PCC (in PCRpt/PCReq), it requests that the PCE provide reverse path information. When set by the PCE (in PCInitiate/PCUpd/ PCRep), it indicates the PCE is providing or will provide reverse path information. In both cases, the PCE SHOULD provide the reverse path information if it is able to. For PCC-Initiated LSPs, if the PCC has not set the O-flag in the MULTIPATH-CAP TLV of the LSP object, the PCE SHOULD NOT include reverse path information in the corresponding response. If the PCC receives unsolicited reverse path information, it MAY ignore it.
OPEN objectでは、このフラグはMULTIPATH-OPPDIR-PATH TLVがサポートされているかどうかを示します。LSP objectでは、このフラグは、その特定のLSPについて逆方向のパス情報が要求または提供されることを示します。PCCが (PCRpt/PCReqで) 設定した場合は、PCEに逆方向パス情報の提供を要求します。PCEが (PCInitiate/PCUpd/PCRepで) 設定した場合は、PCEが逆方向パス情報を提供している、または提供する予定であることを示します。どちらの場合も、PCEは可能であれば逆方向パス情報を提供すべきです (SHOULD)。PCC起動のLSPについて、PCCがLSP object内のMULTIPATH-CAP TLVでO-flagを設定していない場合、PCEは対応する応答に逆方向パス情報を含めるべきではありません (SHOULD NOT)。PCCが要求していない逆方向パス情報を受信した場合、PCCはそれを無視してもよい (MAY)。
F-flag:
F-flag:
Indicates whether the MULTIPATH-FORWARD-CLASS TLV is supported.
MULTIPATH-FORWARD-CLASS TLVがサポートされているかどうかを示します。
C-flag:
C-flag:
Indicates whether the composite candidate path (Section 3.5) is supported, including the use of the COLOR TLV in the PATH-ATTRIB object.
PATH-ATTRIB objectでのCOLOR TLVの使用を含め、複合候補パス（セクション3.5）がサポートされているかどうかを示します。
Unassigned bits
未割り当てビット
MUST be set to 0 on transmission and MUST be ignored on receipt.
送信時には0に設定しなければならず (MUST)、受信時には無視しなければなりません (MUST)。
Note that F-flag and C-flag can be set independently for capability negotiation purposes. While Per-Flow Candidate Path (Section 3.5.1) builds on top of composite candidate path, the F-flag reflects whether the MULTIPATH-FORWARD-CLASS TLV is supported, and the C-flag reflects whether composite candidate path signaling is supported. A peer that supports Per-Flow Candidate Path MUST set both the C-flag and F-flag. Note that the F-flag is defined independently of the C-flag to allow for future use cases that may use the MULTIPATH-FORWARD-CLASS TLV for purposes other than Per-Flow Candidate Path; in such cases, the F-flag MAY be set without the C-flag.
ケイパビリティのネゴシエーションにおいて、F-flagとC-flagは独立に設定できることに注意してください。Per-Flow候補パス（セクション3.5.1）は複合候補パスを土台としていますが、F-flagはMULTIPATH-FORWARD-CLASS TLVがサポートされているかどうかを表し、C-flagは複合候補パスのシグナリングがサポートされているかどうかを表します。Per-Flow候補パスをサポートするピアは、C-flagとF-flagの両方を設定しなければなりません (MUST)。F-flagがC-flagとは独立に定義されているのは、Per-Flow候補パス以外の目的でMULTIPATH-FORWARD-CLASS TLVを使用する将来のユースケースを可能にするためです。そのような場合には、C-flagを設定せずにF-flagを設定してもよい (MAY)。
When a PCE computes an LSP path, it MUST NOT return more forward multipaths than the minimum of the effective "Number of Multipaths" values of both the PCE and PCC. The effective value for a given LSP is determined by the per-LSP MULTIPATH-CAP TLV in the LSP object if present; otherwise, it defaults to the value from the MULTIPATH-CAP TLV in the OPEN object. This ensures the PCE does not exceed either its own computation capability or the PCC's installation capability. If this TLV is absent from both OPEN and LSP objects, the PCEP speaker does not support multipath and the behavior is consistent with existing PCEP specifications, where a single path is associated with each LSP.
PCEがLSPパスを計算するとき、PCEとPCCの双方の有効な "Number of Multipaths" の値のうち小さい方を超える数の順方向マルチパスを返してはなりません (MUST NOT)。特定のLSPの有効な値は、LSP object内のLSPごとのMULTIPATH-CAP TLVが存在する場合はその値で決まり、存在しない場合はOPEN object内のMULTIPATH-CAP TLVの値がデフォルトとなります。これにより、PCEが自身の計算能力もPCCのインストール能力も超えないことが保証されます。このTLVがOPEN objectにもLSP objectにも存在しない場合、そのPCEPスピーカーはマルチパスをサポートしておらず、動作は、各LSPに単一のパスが関連付けられる既存のPCEP仕様と一貫したものになります。
If a PCC receives more paths than it advertised support for, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 36 ("Unsupported multipath capability"). When a PCE receives a PCRpt message containing more paths than its own computation capability, it MUST NOT treat this as an error condition; PCRpt conveys PCC-reported Operational state and is not subject to the PCE's computation limits.
PCCが、自身がサポートを通知した数を超えるパスを受信した場合、Error-Type = 19 ("Invalid Operation") かつ Error-Value = 36 ("Unsupported multipath capability") のPCErrメッセージを送信しなければなりません (MUST)。PCEが、自身の計算能力を超える数のパスを含むPCRptメッセージを受信した場合、これをエラー状態として扱ってはなりません (MUST NOT)。PCRptはPCCが報告するOperational状態を伝えるものであり、PCEの計算上の制限の対象ではありません。
The PCC MAY also include the MULTIPATH-CAP TLV in the LSP object for each individual LSP, to specify per-LSP values. The PCC MUST NOT include this TLV in the LSP object if the TLV was not present in the OPEN objects of both PCEP peers. TLV values in the LSP object override the session default values in the OPEN object. If a PCEP speaker receives a PATH-ATTRIB object but the multipath capability was not successfully negotiated during session establishment, it MUST treat this as an error. The PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 45 ("Unexpected PATH-ATTRIB object").
PCCは、LSPごとの値を指定するために、個々のLSPのLSP objectにMULTIPATH-CAP TLVを含めてもよい (MAY)。両方のPCEPピアのOPEN objectにこのTLVが存在していなかった場合、PCCはLSP objectにこのTLVを含めてはなりません (MUST NOT)。LSP object内のTLV値は、OPEN object内のセッションのデフォルト値を上書きします。PCEPスピーカーがPATH-ATTRIB objectを受信したものの、セッション確立時にマルチパスケイパビリティのネゴシエーションが成功していなかった場合、これをエラーとして扱わなければなりません (MUST)。PCEPスピーカーは、Error-Type = 10 ("Reception of an invalid object") かつ Error-Value = 45 ("Unexpected PATH-ATTRIB object") のPCErrメッセージを送信しなければなりません (MUST)。
For example, the PCC includes this TLV in the OPEN object at session establishment, setting "Number of Multipaths" to 4 and "O-flag" to 0. The PCC also includes this TLV in the LSP object for a particular LSP, setting "Number of Multipaths" to 16 and "O-flag" to 1. This indicates that the PCC only wants to receive the reverse path information for that particular LSP and that this LSP can have up to 16 multipaths, while other LSPs can only have up to 4 multipaths.
例えば、PCCがセッション確立時にOPEN objectにこのTLVを含め、"Number of Multipaths" を4、"O-flag" を0に設定します。PCCはさらに、特定のLSPのLSP objectにもこのTLVを含め、"Number of Multipaths" を16、"O-flag" を1に設定します。これは、PCCがその特定のLSPについてのみ逆方向パス情報を受信したいこと、およびそのLSPは最大16個のマルチパスを持てるのに対し、他のLSPは最大4個のマルチパスしか持てないことを示します。
Additionally, if a PCEP speaker receives a TLV within the PATH-ATTRIB object (such as MULTIPATH-WEIGHT, MULTIPATH-OPPDIR-PATH, or MULTIPATH-FORWARD-CLASS) but the corresponding capability flag was not set in the negotiated MULTIPATH-CAP TLV, it MUST treat this as an error. The PCEP speaker MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 36 ("Unsupported multipath capability").
さらに、PCEPスピーカーがPATH-ATTRIB object内のTLV (MULTIPATH-WEIGHT、MULTIPATH-OPPDIR-PATH、MULTIPATH-FORWARD-CLASSなど) を受信したものの、ネゴシエートされたMULTIPATH-CAP TLVで対応するケイパビリティフラグが設定されていなかった場合、これをエラーとして扱わなければなりません (MUST)。PCEPスピーカーは、Error-Type = 19 ("Invalid Operation") かつ Error-Value = 36 ("Unsupported multipath capability") のPCErrメッセージを送信しなければなりません (MUST)。
The Path ID uniquely identifies a Path within the context of an LSP. A single Path ID space is shared among all paths within the LSP, including forward paths and reverse paths (R-flag=1). Path IDs MUST be unique across forward and reverse paths within the same LSP. The meaning of "Path" depends on the type of LSP:
Path IDは、LSPのコンテキスト内でパスを一意に識別します。LSP内のすべてのパス（順方向パスと逆方向パス (R-flag=1) を含む）で、単一のPath ID空間を共有します。Path IDは、同一LSP内の順方向パスと逆方向パスにまたがって一意でなければなりません (MUST)。"パス" の意味は、LSPの種類によって異なります。
* For a regular SR Policy Candidate Path, the Paths within that LSP are the segment lists.
* 通常のSRポリシー候補パスでは、そのLSP内のパスはセグメントリストです。
* For a composite candidate path (Section 3.5), the Paths within that LSP are the constituent SR Policies, each of which is identified by its color (carried in the COLOR TLV within the corresponding PATH-ATTRIB object).
* 複合候補パス（セクション3.5）では、そのLSP内のパスは構成要素となるSRポリシーであり、それぞれが (対応するPATH-ATTRIB object内のCOLOR TLVで運ばれる) カラーによって識別されます。
Value 0 indicates an unallocated Path ID. The value of 0 MAY be used when this Path is not referenced and the allocation of a Path ID is not necessary.
値0は、未割り当てのPath IDを示します。このパスが参照されず、Path IDの割り当てが不要な場合には、値0を使用してもよい (MAY)。
Path IDs are allocated by the PCEP peer that owns the LSP. If the LSP is delegated to the PCE, then the PCE allocates the Path IDs and sends them in the PCRep/PCUpd/PCInitiate messages. If the LSP is locally computed on the PCC, then the PCC allocates the Path IDs and sends them in the PCReq/PCRpt messages. When LSP delegation changes (e.g., the PCC revokes delegation from the PCE), the new path owner SHOULD retain the existing Path IDs to simplify path correlation in the event of redelegation. If the new owner cannot retain them, it MAY allocate new Path IDs.
Path IDは、そのLSPを所有するPCEPピアが割り当てます。LSPがPCEに委任されている場合は、PCEがPath IDを割り当て、PCRep/PCUpd/PCInitiateメッセージで送信します。LSPがPCC上でローカルに計算される場合は、PCCがPath IDを割り当て、PCReq/PCRptメッセージで送信します。LSPの委任が変更される場合（例：PCCがPCEからの委任を取り消す場合）、再委任に備えてパスの対応付けを容易にするため、新しいパスの所有者は既存のPath IDを保持すべきです (SHOULD)。新しい所有者が保持できない場合は、新しいPath IDを割り当ててもよい (MAY)。
If a PCEP speaker detects that there are two Paths with the same non-zero Path ID, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 38 ("Conflicting Path ID"). Multiple paths MAY have Path ID set to 0, as this value indicates those paths are not referenced and do not require unique identification.
PCEPスピーカーが、ゼロ以外の同じPath IDを持つパスが2つあることを検出した場合、Error-Type = 10 ("Reception of an invalid object") かつ Error-Value = 38 ("Conflicting Path ID") のPCErrメッセージを送信しなければなりません (MUST)。複数のパスのPath IDを0に設定してもよい (MAY)。この値は、それらのパスが参照されず、一意な識別を必要としないことを示すためです。
The PATH-ATTRIB object can be used to signal multiple paths and indicate equal or unequal load balancing among the set of multipaths. In this case, the PATH-ATTRIB is populated for each ERO as follows:
PATH-ATTRIB objectを使用して、複数のパスをシグナリングし、マルチパスの集合における均等または不均等な負荷分散を示すことができます。この場合、PATH-ATTRIBは各EROについて次のように設定されます。
1. The PCE MAY assign a unique Path ID to each ERO path and populate it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (when non-zero).
1. PCEは、各EROパスに一意のPath IDを割り当て、PATH-ATTRIB object内に設定してもよい (MAY)。Path IDは、PLSPのコンテキスト内で (ゼロ以外の場合に) 一意です。
2. The PCE MAY include the MULTIPATH-WEIGHT TLV inside the PATH-ATTRIB object, populating a weight value to reflect the relative share of traffic to be carried by the path. If the MULTIPATH-WEIGHT is not carried inside a PATH-ATTRIB object, the PCC MUST assume the default weight of 1 when computing the traffic share.
2. PCEは、PATH-ATTRIB object内にMULTIPATH-WEIGHT TLVを含め、そのパスが運ぶトラフィックの相対的な割合を反映する重み値を設定してもよい (MAY)。MULTIPATH-WEIGHTがPATH-ATTRIB objectに含まれていない場合、PCCはトラフィックの割合を計算する際にデフォルトの重み1を仮定しなければなりません (MUST)。
3. The PCC derives the fraction of flows carried by a specific primary path from the ratio of its weight to the sum of the weights of all paths in the multipath. For SR Policy, the use of weights for load balancing between segment lists of a Candidate Path is described in Section 2.11 of [RFC9256].
3. PCCは、特定のプライマリパスが運ぶフローの割合を、そのパスの重みとマルチパス内のすべてのパスの重みの合計との比から導出します。SRポリシーにおいて、候補パスのセグメントリスト間の負荷分散に重みを使用する方法は、[RFC9256]のセクション2.11に記述されています。
The PATH-ATTRIB object can be used to signal opposite-direction path associations within a PCEP LSP. This capability is used to establish bidirectional path relationships where forward and reverse paths can be explicitly mapped to each other. In this case, the PATH-ATTRIB is populated for each ERO as follows:
PATH-ATTRIB objectを使用して、PCEP LSP内の逆方向パスの関連付けをシグナリングできます。この機能は、順方向パスと逆方向パスを明示的に相互にマッピングできる双方向のパス関係を確立するために使用されます。この場合、PATH-ATTRIBは各EROについて次のように設定されます。
1. The PCEP peer (PCC or PCE) allocates a unique Path ID to each path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (PCE Label Switched Path).
1. PCEPピア (PCCまたはPCE) は、各パスに一意のPath IDを割り当て、PATH-ATTRIB object内に設定します。Path IDは、PLSP (PCE Label Switched Path) のコンテキスト内で一意です。
2. For paths that have opposite-direction counterparts, the MULTIPATH-OPPDIR-PATH TLV is added to the PATH-ATTRIB object. The Opposite-Direction Path ID field is set to reference the Path ID of the corresponding opposite-direction path.
2. 逆方向の対応パスを持つパスには、MULTIPATH-OPPDIR-PATH TLVがPATH-ATTRIB objectに追加されます。Opposite-Direction Path IDフィールドには、対応する逆方向パスのPath IDを参照するように設定されます。
3. Multiple instances of the MULTIPATH-OPPDIR-PATH TLV MAY be present in the same PATH-ATTRIB object to support many-to-many mappings between forward and reverse paths. This allows a single forward path to map to multiple reverse paths and vice versa. A many-to-many mapping can occur when a segment list contains Node Segment(s) that traverse parallel links at a midpoint. The reverse of this segment list may require multiple reverse segment lists to cover all the parallel links at the midpoint.
3. 順方向パスと逆方向パスの多対多のマッピングをサポートするため、MULTIPATH-OPPDIR-PATH TLVの複数のインスタンスを同じPATH-ATTRIB object内に含めてもよい (MAY)。これにより、1つの順方向パスを複数の逆方向パスにマッピングでき、その逆も可能です。多対多のマッピングは、セグメントリストが中間地点で並列リンクを通過するNode Segmentを含む場合に発生することがあります。このセグメントリストの逆方向には、中間地点のすべての並列リンクを網羅するために、複数の逆方向セグメントリストが必要になることがあります。
4. The N-flag and L-flag in the MULTIPATH-OPPDIR-PATH TLV MAY be set to indicate node co-routing or link co-routing respectively. These flags inform the receiver about the relationship between the forward and reverse paths.
4. MULTIPATH-OPPDIR-PATH TLVのN-flagとL-flagは、それぞれノードのコルーティングまたはリンクのコルーティングを示すために設定してもよい (MAY)。これらのフラグは、順方向パスと逆方向パスの関係を受信側に知らせます。
The N-flag and L-flag describe the relationship between the signaled paths as known to the PCEP speaker at the time the message is sent. They do not guarantee that transient local protection, local repair, or local policy actions in the network will preserve node or link co-routing for all forwarded traffic.
N-flagとL-flagは、メッセージ送信時点でPCEPスピーカーが把握している、シグナリングされたパス間の関係を表します。これらは、ネットワーク内の一時的なローカル保護、ローカル修復、またはローカルポリシーの動作が、転送されるすべてのトラフィックについてノードまたはリンクのコルーティングを維持することを保証するものではありません。
5. For paths that have no opposite-direction counterpart, the MULTIPATH-OPPDIR-PATH TLV is omitted from the PATH-ATTRIB object.
5. 逆方向の対応パスを持たないパスでは、MULTIPATH-OPPDIR-PATH TLVはPATH-ATTRIB objectから省略されます。
Forward paths (R-flag=0) and reverse paths (R-flag=1) are included in the same PCEP LSP, allowing bidirectional relationships to be established in a single message exchange. The opposite-direction path associations MUST be symmetric within the same LSP: for each (A -> B) reference expressed via a MULTIPATH-OPPDIR-PATH TLV instance in path A's PATH-ATTRIB object, the corresponding (B -> A) reference MUST also be present as a MULTIPATH-OPPDIR-PATH TLV instance in path B's PATH-ATTRIB object. Multiple MULTIPATH-OPPDIR-PATH TLV instances per PATH-ATTRIB object are permitted, supporting many-to-many mappings. Additionally, the R-flags of opposite-direction paths MUST have opposite values (one set to 0, the other to 1).
順方向パス (R-flag=0) と逆方向パス (R-flag=1) は同じPCEP LSPに含まれるため、1回のメッセージ交換で双方向の関係を確立できます。逆方向パスの関連付けは、同じLSP内で対称でなければなりません (MUST)。すなわち、パスAのPATH-ATTRIB objectにあるMULTIPATH-OPPDIR-PATH TLVインスタンスで表現された(A -> B)の参照ごとに、対応する(B -> A)の参照も、パスBのPATH-ATTRIB objectにMULTIPATH-OPPDIR-PATH TLVインスタンスとして存在しなければなりません (MUST)。1つのPATH-ATTRIB objectに複数のMULTIPATH-OPPDIR-PATH TLVインスタンスを含めることが認められており、多対多のマッピングをサポートします。さらに、逆方向パス同士のR-flagは、互いに逆の値でなければなりません (MUST)（一方を0、他方を1に設定します）。
If a PCEP speaker receives an opposite-direction path mapping that is asymmetric or where the R-flags are inconsistent, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 37 ("Invalid opposite-direction path mapping").
PCEPスピーカーが、非対称な逆方向パスのマッピング、またはR-flagが矛盾しているマッピングを受信した場合、Error-Type = 19 ("Invalid Operation")、Error-Value = 37 ("Invalid opposite-direction path mapping") のPCErrメッセージを送信しなければなりません (MUST)。
See Appendix A.3 for an example of usage.
使用例については、付録A.3を参照してください。
The RBNF of PCRpt and PCUpd messages, as defined in [RFC8231], uses a combination of <intended-path> and/or <actual-path>. PCReq and PCRep messages, as defined in [RFC5440] and extended by [RFC8231], directly include ERO and RRO within their respective message structures rather than encapsulating them within <intended-path> or <actual-path> constructs.
As specified in Section 6.1 of [RFC8231], within the context of messages that use these constructs, <intended-path> is represented by the ERO and <actual-path> is represented by the RRO:
[RFC8231]のセクション6.1に規定されているとおり、これらの構成要素を使用するメッセージでは、<intended-path>はEROで、<actual-path>はRROで表されます。
<intended-path> ::= <ERO>
<actual-path> ::= <RRO>
This document extends [RFC8231] by allowing multiple EROs/RROs to be present in the <intended-path>/<actual-path>:
本文書は、<intended-path>/<actual-path>に複数のERO/RROを含めることを認めることで、[RFC8231]を拡張します。
<intended-path> ::= <ERO> |
<PATH-ATTRIB><ERO>[<intended-path-multipath>]
<intended-path-multipath> ::= <PATH-ATTRIB><ERO>
[<intended-path-multipath>]
<actual-path> ::= <RRO> |
<PATH-ATTRIB><RRO>[<actual-path-multipath>]
<actual-path-multipath> ::= <PATH-ATTRIB><RRO>
[<actual-path-multipath>]
Similarly, this document extends [RFC8281] by allowing multiple paths in the PCInitiate message by allowing multiple EROs with their associated path attributes. The PCE-initiated LSP instantiation format is updated to:
同様に、本文書は、関連するパス属性を持つ複数のEROを認めることでPCInitiateメッセージに複数のパスを含められるようにし、[RFC8281]を拡張します。PCE-initiated LSPのインスタンス化の形式は、次のように更新されます。
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<intended-path>
[<attribute-list>]
where <intended-path> follows the recursive definition above, allowing multiple paths to be signaled in a single PCInitiate message. When multiple paths are present, each ERO MUST be preceded by a PATH-ATTRIB object that describes it. A single path MAY be sent as a bare ERO without PATH-ATTRIB for backward compatibility.
ここで、<intended-path>は上記の再帰的な定義に従い、1つのPCInitiateメッセージで複数のパスをシグナリングできます。複数のパスが存在する場合、各EROの前に、そのEROを記述するPATH-ATTRIB objectを置かなければなりません (MUST)。後方互換性のために、単一のパスはPATH-ATTRIBなしの単独のEROとして送信してもよい (MAY)。
This document also extends the PCRep and PCReq messages, defined in [RFC5440], to carry multipath information. Because these messages include the ERO and RRO directly rather than within the <intended-path>/<actual-path> constructs, the extension allows a PATH-ATTRIB object to precede each ERO or RRO that it describes.
本文書は、[RFC5440]で定義されているPCRepおよびPCReqメッセージも拡張し、マルチパス情報を運べるようにします。これらのメッセージは、EROとRROを<intended-path>/<actual-path>の構成要素の中ではなく直接含むため、この拡張では、PATH-ATTRIB objectが、それが記述する各EROまたはRROの前に置けるようにします。
In the PCRep message, the <path> element is updated to allow a PATH-ATTRIB object to precede the ERO, with multiple <path> elements in the existing <path-list> used to signal multiple paths:
PCRepメッセージでは、<path>要素を更新して、PATH-ATTRIB objectをEROの前に置けるようにします。複数のパスのシグナリングには、既存の<path-list>内の複数の<path>要素を使用します。
<path> ::= <ERO><attribute-list> |
<PATH-ATTRIB><ERO><attribute-list>
When multiple paths are returned for load balancing, each <path> in the <path-list> MUST include a PATH-ATTRIB object preceding its ERO. A single <path> MAY be sent as a bare ERO without PATH-ATTRIB for backward compatibility.
負荷分散のために複数のパスを返す場合、<path-list>内の各<path>は、そのEROの前にPATH-ATTRIB objectを含めなければなりません (MUST)。後方互換性のために、単一の<path>はPATH-ATTRIBなしの単独のEROとして送信してもよい (MAY)。
In the PCReq message, the existing path reported for reoptimization is updated to allow multiple RROs, each preceded by a PATH-ATTRIB object:
PCReqメッセージでは、再最適化のために報告される既存のパスを更新して、複数のRROを認めます。各RROの前にはPATH-ATTRIB objectを置きます。
<request> ::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<reported-path>]
[<IRO>]
[<LOAD-BALANCING>]
<reported-path> ::= <RRO>[<BANDWIDTH>] |
<PATH-ATTRIB><RRO>[<BANDWIDTH>]
[<reported-path-multipath>]
<reported-path-multipath> ::= <PATH-ATTRIB><RRO>[<BANDWIDTH>]
[<reported-path-multipath>]
When multiple existing paths are reported, each RRO MUST be preceded by a PATH-ATTRIB object. A single reported path MAY be sent as a bare RRO without PATH-ATTRIB for backward compatibility.
複数の既存パスを報告する場合、各RROの前にPATH-ATTRIB objectを置かなければなりません (MUST)。後方互換性のために、単一の報告パスはPATH-ATTRIBなしの単独のRROとして送信してもよい (MAY)。
The LOAD-BALANCING object [RFC5440] and the multipath extensions defined in this document are two different mechanisms for requesting multiple paths and MUST NOT be combined. The LOAD-BALANCING object requests a set of independent TE LSPs, each with its own bandwidth, whereas these extensions return multiple paths within a single LSP. Accordingly, a PCReq message MUST NOT contain both a LOAD-BALANCING object and a MULTIPATH-CAP TLV (in the LSP object) for the same request. A PCEP speaker that receives such a request MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 38 ("LOAD-BALANCING and MULTIPATH-CAP TLV in the same request").
LOAD-BALANCING object [RFC5440]と本文書で定義するマルチパス拡張は、複数のパスを要求するための2つの異なるメカニズムであり、組み合わせてはなりません (MUST NOT)。LOAD-BALANCING objectは、それぞれ独自の帯域幅を持つ独立したTE LSPの集合を要求するのに対し、これらの拡張は単一のLSP内で複数のパスを返します。したがって、PCReqメッセージは、同じ要求に対して、LOAD-BALANCING objectと（LSP object内の）MULTIPATH-CAP TLVの両方を含んではなりません (MUST NOT)。このような要求を受信したPCEPスピーカーは、Error-Type = 19 ("Invalid Operation")、Error-Value = 38 ("LOAD-BALANCING and MULTIPATH-CAP TLV in the same request") のPCErrメッセージを送信しなければなりません (MUST)。
The capability negotiation and error handling defined in Section 4 apply equally to the PCReq and PCRep messages. In particular, a PCEP speaker that receives a PATH-ATTRIB object, or a TLV within it, in a PCReq or PCRep message without having negotiated the corresponding capability in the MULTIPATH-CAP TLV MUST treat it as an error as specified in Section 4.
セクション4で定義されたケイパビリティのネゴシエーションとエラー処理は、PCReqおよびPCRepメッセージにも同様に適用されます。特に、MULTIPATH-CAP TLVで対応するケイパビリティをネゴシエーションしないまま、PCReqまたはPCRepメッセージでPATH-ATTRIB object、またはその中のTLVを受信したPCEPスピーカーは、セクション4に規定されているとおり、それをエラーとして扱わなければなりません (MUST)。
The RBNF extensions defined in this section are additive and apply only to sessions where the capabilities from the MULTIPATH-CAP TLV have been successfully negotiated (Section 4). Legacy PCEP peers that do not advertise the MULTIPATH-CAP TLV will not receive PATH-ATTRIB objects introduced by the updated RBNF.
本セクションで定義するRBNFの拡張は追加的なものであり、MULTIPATH-CAP TLVのケイパビリティのネゴシエーションが正常に完了したセッション (セクション4) にのみ適用されます。MULTIPATH-CAP TLVをアドバタイズしない従来のPCEPピアは、更新されたRBNFで導入されたPATH-ATTRIB objectを受信しません。
All IANA actions in this section pertain to the "Path Computation Element Protocol (PCEP) Numbers" registry group, available at <https://www.iana.org/assignments/pcep/>.
本セクションのIANAによるすべての処理は、<https://www.iana.org/assignments/pcep/>で公開されている "Path Computation Element Protocol (PCEP) Numbers" レジストリグループに関するものです。
IANA has allocated the following in the "PCEP Objects" registry (<https://www.iana.org/assignments/pcep>):
IANAは、"PCEP Objects" レジストリ (<https://www.iana.org/assignments/pcep>) に次を割り当てました。
+====================+=============+===================+===========+
| Object-Class Value | Name | Object-Type Value | Reference |
+====================+=============+===================+===========+
| 45 | PATH-ATTRIB | 0: Reserved | RFC 10066 |
| | +-------------------+-----------+
| | | 1: PATH-ATTRIB | RFC 10066 |
| | +-------------------+-----------+
| | | 2-15: Unassigned | |
+--------------------+-------------+-------------------+-----------+
Table 1
Object-Type values are managed via the IETF Review policy per [RFC8126].
Object-Typeの値は、[RFC8126]に従い、IETF Reviewポリシーで管理されます。
IANA has allocated the following in the "PCEP TLV Type Indicators" registry (<https://www.iana.org/assignments/pcep>):
IANAは、"PCEP TLV Type Indicators" レジストリ (<https://www.iana.org/assignments/pcep>) に次を割り当てました。
+================+=======================+===========+
| TLV Type Value | TLV Name | Reference |
+================+=======================+===========+
| 60 | MULTIPATH-CAP | RFC 10066 |
+----------------+-----------------------+-----------+
| 61 | MULTIPATH-WEIGHT | RFC 10066 |
+----------------+-----------------------+-----------+
| 63 | MULTIPATH-OPPDIR-PATH | RFC 10066 |
+----------------+-----------------------+-----------+
Table 2
IANA has allocated the following in the "PCEP TLV Type Indicators" registry:
IANAは、"PCEP TLV Type Indicators" レジストリに次を割り当てました。
+================+=========================+===========+
| TLV Type Value | TLV Name | Reference |
+================+=========================+===========+
| 76 | MULTIPATH-FORWARD-CLASS | RFC 10066 |
+----------------+-------------------------+-----------+
Table 3
IANA has allocated the following in the "PCEP-ERROR Object Error Types and Values" registry (<https://www.iana.org/assignments/pcep>):
IANAは、"PCEP-ERROR Object Error Types and Values" レジストリ (<https://www.iana.org/assignments/pcep>) に次を割り当てました。
+============+==========================+===========+
| Error-Type | Error-Value | Reference |
+============+==========================+===========+
| 10 | 38 - Conflicting Path ID | RFC 10066 |
+------------+--------------------------+-----------+
| 19 | 21 - Non-empty path | RFC 10066 |
+------------+--------------------------+-----------+
Table 4
IANA has allocated the following in the "PCEP-ERROR Object Error Types and Values" registry:
IANAは、"PCEP-ERROR Object Error Types and Values" レジストリに次を割り当てました。
+============+=======================================+===========+
| Error-Type | Error-Value | Reference |
+============+=======================================+===========+
| 10 | 45 - Unexpected PATH-ATTRIB object | RFC 10066 |
+------------+---------------------------------------+-----------+
| 19 | 36 - Unsupported multipath capability | RFC 10066 |
+------------+---------------------------------------+-----------+
| 19 | 37 - Invalid opposite-direction path | RFC 10066 |
| | mapping | |
+------------+---------------------------------------+-----------+
| 19 | 38 - LOAD-BALANCING and MULTIPATH-CAP | RFC 10066 |
| | TLV in the same request | |
+------------+---------------------------------------+-----------+
Table 5
IANA created the "Flags in MULTIPATH-CAP TLV" registry to manage the Flag field of the MULTIPATH-CAP TLV. New values are to be assigned by IETF Review [RFC8126].
IANAは、MULTIPATH-CAP TLVのFlagフィールドを管理するために、"Flags in MULTIPATH-CAP TLV" レジストリを作成しました。新しい値は、IETF Review [RFC8126]により割り当てられます。
+======+=============================================+===========+
| Bit | Description | Reference |
+======+=============================================+===========+
| 0-10 | Unassigned | |
+------+---------------------------------------------+-----------+
| 11 | C-flag: Composite Candidate Path support | RFC 10066 |
+------+---------------------------------------------+-----------+
| 12 | F-flag: MULTIPATH-FORWARD-CLASS TLV support | RFC 10066 |
+------+---------------------------------------------+-----------+
| 13 | O-flag: MULTIPATH-OPPDIR-PATH TLV support | RFC 10066 |
+------+---------------------------------------------+-----------+
| 14 | Unassigned | |
+------+---------------------------------------------+-----------+
| 15 | W-flag: MULTIPATH-WEIGHT TLV support | RFC 10066 |
+------+---------------------------------------------+-----------+
Table 6
IANA has created the "Flags in PATH-ATTRIB Object" registry to manage the Flag field of the PATH-ATTRIB object. New values are to be assigned by IETF Review [RFC8126].
IANAは、PATH-ATTRIB objectのFlagフィールドを管理するために、"Flags in PATH-ATTRIB Object" レジストリを作成しました。新しい値は、IETF Review [RFC8126]により割り当てられます。
+=======+===========================+===========+
| Bit | Description | Reference |
+=======+===========================+===========+
| 0-27 | Unassigned | |
+-------+---------------------------+-----------+
| 28 | R-flag: Reverse path | RFC 10066 |
+-------+---------------------------+-----------+
| 29-31 | O-flag: Operational state | RFC 10066 |
+-------+---------------------------+-----------+
Table 7
IANA has created the "Flags in MULTIPATH-OPPDIR-PATH TLV" registry to manage the Flag field of the MULTIPATH-OPPDIR-PATH TLV. New values are to be assigned by IETF Review [RFC8126].
IANAは、MULTIPATH-OPPDIR-PATH TLVのFlagフィールドを管理するために、"Flags in MULTIPATH-OPPDIR-PATH TLV" レジストリを作成しました。新しい値は、IETF Review [RFC8126]により割り当てられます。
+======+========================+===========+
| Bit | Description | Reference |
+======+========================+===========+
| 0-13 | Unassigned | |
+------+------------------------+-----------+
| 14 | L-flag: Link co-routed | RFC 10066 |
+------+------------------------+-----------+
| 15 | N-flag: Node co-routed | RFC 10066 |
+------+------------------------+-----------+
Table 8
IANA has created the "Flags in MULTIPATH-FORWARD-CLASS TLV" registry to manage the Flag field of the MULTIPATH-FORWARD-CLASS TLV. New values are to be assigned by IETF Review [RFC8126].
IANAは、MULTIPATH-FORWARD-CLASS TLVのFlagフィールドを管理するために、"Flags in MULTIPATH-FORWARD-CLASS TLV" レジストリを作成しました。新しい値は、IETF Review [RFC8126]により割り当てられます。
+=======+======================+===========+
| Bit | Description | Reference |
+=======+======================+===========+
| 0 | T-flag: MPLS TC type | RFC 10066 |
+-------+----------------------+-----------+
| 1-28 | Unassigned | |
+-------+----------------------+-----------+
| 29-31 | FC: Forwarding class | RFC 10066 |
+-------+----------------------+-----------+
Table 9
As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] [RFC9916] as per the recommendations and best current practices in [RFC9325].
The multipath extensions defined in this document allow a PCE to signal multiple paths per LSP, which increases the per-LSP state maintained by the PCC. A misbehaving or compromised PCE could exploit this to amplify state at the PCC by maximizing multipath fan out. The "Number of Multipaths" field in the MULTIPATH-CAP TLV provides an upper bound on the number of paths a PCC will accept per LSP, and operators SHOULD configure a non-zero value to limit exposure. The existing PCEP authentication and encryption recommendations (TLS per [RFC8253]) mitigate the risk of unauthorized PCE access.
本文書で定義するマルチパス拡張により、PCEはLSPごとに複数のパスをシグナリングできますが、これによりPCCが保持するLSPごとの状態が増加します。不正な動作をするPCE、または侵害されたPCEは、マルチパスのファンアウトを最大化することで、これを悪用してPCCの状態を増幅させる可能性があります。MULTIPATH-CAP TLVの "Number of Multipaths" フィールドは、PCCがLSPごとに受け入れるパス数の上限を定めるものであり、オペレーターは、リスクにさらされる範囲を限定するために、ゼロ以外の値を設定すべきです (SHOULD)。既存のPCEPの認証および暗号化に関する推奨事項 ([RFC8253]に従ったTLS) は、PCEへの不正アクセスのリスクを軽減します。
A PCEP speaker (PCC or PCE) implementation should allow an operator to enable or disable the multipath capabilities advertised in the MULTIPATH-CAP TLV (see Section 4).
PCEPスピーカー (PCCまたはPCE) の実装は、MULTIPATH-CAP TLVでアドバタイズされるマルチパス機能を、オペレータが有効化または無効化できるようにすべきです (「4節」参照)。
It is expected that a future version of the PCEP YANG module [RFC9826] will be extended to include the PCEP extensions defined in this document.
将来のバージョンのPCEP YANGモジュール [RFC9826] が、本文書で定義するPCEP拡張を含むように拡張されることが期待されます。
* An implementation should allow an operator to view the capabilities advertised in the MULTIPATH-CAP TLV by each PCEP peer for a session and for individual LSPs.
* 実装は、セッションごと、および個々のLSPごとに、各PCEPピアがMULTIPATH-CAP TLVでアドバタイズした機能をオペレータが参照できるようにすべきです。
* An implementation should allow an operator to view the PATH-ATTRIB object and all its associated TLVs for each path within an LSP. This includes the Path ID, weight, and opposite-direction path associations.
* 実装は、LSP内の各パスについて、PATH-ATTRIBオブジェクトとそれに関連付けられたすべてのTLVをオペレータが参照できるようにすべきです。これには、Path ID、重み、および逆方向パスの関連付けが含まれます。
* An implementation should provide a mechanism to log and display the new PCEP errors defined in this document.
* 実装は、本文書で定義する新しいPCEPエラーを記録および表示するメカニズムを提供すべきです。
The PCEP extensions defined in this document do not impose any new requirements on other protocols.
本文書で定義するPCEP拡張は、他のプロトコルに対して新たな要件を課しません。
The mechanisms in this document allow for more complex LSP structures with multiple paths. Network operators should be aware of the potential increase in PCEP message sizes and the additional state that must be maintained by PCEP speakers. The "Number of Multipaths" field in the MULTIPATH-CAP TLV can be used to control the scale of multipath computations and state.
本文書のメカニズムにより、複数のパスを持つより複雑なLSP構造が可能になります。ネットワークオペレータは、PCEPメッセージサイズが増大する可能性があることと、PCEPスピーカーが維持しなければならない状態が増えることに留意すべきです。MULTIPATH-CAP TLVの "Number of Multipaths" フィールドは、マルチパス計算と状態の規模を制御するために使用できます。
Paths within a single LSP may have significantly different properties, such as MTU, latency, and available bandwidth. When flow-based load balancing is used across such paths, individual flows are hashed to a single path, so per-path MTU or latency divergence is a per-flow concern rather than a per-packet one. However, operators should be aware that advertising weighted load balancing across paths with very different latencies can degrade application performance. Similarly, if paths have different MTUs, the effective MTU for flows on each path will differ; operators should ensure that PMTUD or consistent MTU configuration is in place. For bidirectional applications relying on Performance Measurement (PM) or BFD, note that forward and reverse paths may have asymmetric properties, and implementations should account for this.
単一のLSP内のパスは、MTU、遅延、利用可能な帯域幅など、大きく異なる特性を持つ場合があります。このようなパスにわたってフローベースの負荷分散を使用する場合、個々のフローは単一のパスにハッシュされるため、パスごとのMTUや遅延の相違は、パケット単位ではなくフロー単位の問題となります。ただし、遅延が大きく異なるパスにわたって重み付き負荷分散をアドバタイズすると、アプリケーションの性能が低下する可能性があることに、オペレータは留意すべきです。同様に、パスごとにMTUが異なる場合、各パス上のフローの実効MTUも異なります。オペレータは、PMTUDまたは一貫したMTU設定が整っていることを確認すべきです。パフォーマンス測定 (PM) やBFDに依存する双方向アプリケーションについては、順方向パスと逆方向パスが非対称な特性を持つ場合があることに注意し、実装はこれを考慮に入れるべきです。
PCE implementations should minimize unnecessary churn in multipath state. With multiple paths per LSP, frequent recomputation or weight changes cause flow redistribution across segment lists, which may perturb congestion control state and trigger PMTUD rediscovery on a broader scale than with single-path LSPs.
PCEの実装は、マルチパス状態の不要な変動を最小限に抑えるべきです。LSPごとに複数のパスがある場合、頻繁な再計算や重みの変更によってセグメントリスト間でフローの再分配が発生し、輻輳制御の状態を乱したり、単一パスのLSPよりも広範囲でPMTUDの再探索を引き起こしたりする可能性があります。
For composite candidate paths, recursive policy resolution is therefore bounded, as Section 2.2 of [RFC9256] prohibits constituent SR Policies of a composite candidate path from themselves using composite candidate paths.
合成候補パスについては、[RFC9256] の2.2節が、合成候補パスの構成要素であるSRポリシー自身が合成候補パスを使用することを禁止しているため、再帰的なポリシー解決には上限があります。
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[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>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, <https://www.rfc-editor.org/info/rfc9603>.
[RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, <https://www.rfc-editor.org/info/rfc9862>.
[RFC9863] Rajagopalan, B., Beeram, V., Peng, S., Koldychev, M., and G. Mishra, "Path Computation Element Protocol (PCEP) Extension for Color", RFC 9863, DOI 10.17487/RFC9863, October 2025, <https://www.rfc-editor.org/info/rfc9863>.
[RFC9916] Dhody, D., Turner, S., and R. Housley, "Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 9916, DOI 10.17487/RFC9916, July 2026, <https://www.rfc-editor.org/info/rfc9916>.
[CS-SR-POLICY]
Schmutzer, C., Ed., Ali, Z., Ed., Maheshwari, P., Rokui,
R., and A. Stone, "Circuit Style Segment Routing Policy",
Work in Progress, Internet-Draft, draft-ietf-spring-cs-sr-
policy-17, 12 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
cs-sr-policy-17>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[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>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 9059, DOI 10.17487/RFC9059, June 2021, <https://www.rfc-editor.org/info/rfc9059>.
[RFC9826] Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura, "A YANG Data Model for the Path Computation Element Communication Protocol (PCEP)", RFC 9826, DOI 10.17487/RFC9826, September 2025, <https://www.rfc-editor.org/info/rfc9826>.
[RFC10067] Li, C., Ed., Chen, M., Cheng, W., Gandhi, R., Ed., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs", RFC 10067, DOI 10.17487/RFC10067, October 2026, <https://www.rfc-editor.org/info/rfc10067>.
Consider the following sample SR Policy.
次のSRポリシーの例を考えます。
SR policy POL1 <headend, color, endpoint>
Candidate Path CP1 <protocol-origin = 20, originator-asn = 100,
originator-address = 192.0.2.1,
discriminator = 1>
Preference 200
Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j>
Candidate Path CP2 <protocol-origin = 20, originator-asn = 100,
originator-address = 198.51.100.1,
discriminator = 2>
Preference 100
Weight W3, SID-List3 <SID31...SID3i>
Weight W4, SID-List4 <SID41...SID4j>
As specified in [RFC9862], CP1 and CP2 are signaled as separate state-report elements and each has a unique PLSP-ID, assigned by the PCC. For this example, PLSP-ID 100 is assigned to CP1 and PLSP-ID 200 to CP2.
[RFC9862] で規定されているとおり、CP1とCP2は別個のstate-report要素としてシグナリングされ、それぞれにPCCが割り当てる一意のPLSP-IDを持ちます。この例では、CP1にPLSP-ID 100、CP2にPLSP-ID 200が割り当てられます。
The state-report (as defined in [RFC8231]) for CP1 can be encoded as:
CP1のstate-report ([RFC8231] で定義) は、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=100>
<ASSOCIATION>
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W1>>
<ERO SID-List1>
<PATH-ATTRIB Path ID=2 <WEIGHT-TLV Weight=W2>>
<ERO SID-List2>
The state-report for CP2 can be encoded as:
CP2のstate-reportは、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=200>
<ASSOCIATION>
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W3>>
<ERO SID-List3>
<PATH-ATTRIB Path ID=2 <WEIGHT-TLV Weight=W4>>
<ERO SID-List4>
The above sample state-report elements only specify the minimum mandatory objects; of course, other objects like SRP, LSPA, METRIC, etc., are allowed to be inserted.
上記のstate-report要素の例は、最小限の必須オブジェクトのみを示しています。もちろん、SRP、LSPA、METRICなどの他のオブジェクトを挿入してもかまいません。
Note that the syntax
次の構文に注意してください。
<PATH-ATTRIB Path ID=1 <WEIGHT-TLV Weight=W1>>
means that this is a PATH-ATTRIB object with the Path ID field set to 1 and with a MULTIPATH-WEIGHT TLV carrying the weight of "W1".
これは、Path IDフィールドが1に設定され、重み "W1" を伝えるMULTIPATH-WEIGHT TLVを持つPATH-ATTRIBオブジェクトであることを意味します。
Consider the following composite candidate path.
次の合成候補パスを考えます。
SR policy POL100 <headend = H1, color = 100, endpoint = E1>
Candidate Path CP1 <protocol-origin = 20, originator-asn = 100,
originator-address = 192.0.2.1,
discriminator = 1>
Preference 200
Weight W1, SR policy <color = 1>
Weight W2, SR policy <color = 2>
This is signaled in PCEP as:
これは、PCEPでは次のようにシグナリングされます。
<LSP PLSP-ID=100>
<ASSOCIATION>
<PATH-ATTRIB Path ID=1
<WEIGHT-TLV Weight=W1>
<COLOR-TLV Color=1>>
<ERO (empty)>
<PATH-ATTRIB Path ID=2
<WEIGHT-TLV Weight=W2>
<COLOR-TLV Color=2>>
<ERO (empty)>
Consider the two opposite-direction SR Policies between endpoints H1 and E1.
エンドポイントH1とE1の間にある、2つの逆方向のSRポリシーを考えます。
SR policy POL1 <headend = H1, color, endpoint = E1>
Candidate Path CP1
Preference 200
Bidirectional Association = A1
SID-List = <H1,M1,M2,E1>
SID-List = <H1,M3,M4,E1>
Candidate Path CP2
Preference 100
Bidirectional Association = A2
SID-List = <H1,M5,M6,E1>
SID-List = <H1,M7,M8,E1>
SR policy POL2 <headend = E1, color, endpoint = H1>
Candidate Path CP1
Preference 200
Bidirectional Association = A1
SID-List = <E1,M2,M1,H1>
SID-List = <E1,M4,M3,H1>
Candidate Path CP2
Preference 100
Bidirectional Association = A2
SID-List = <E1,M6,M5,H1>
The state-report for POL1, CP1 can be encoded as:
POL1, CP1のstate-reportは、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB Path ID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=4>>
<ERO <H1,M3,M4,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB Path ID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=2>>
<ERO <E1,M4,M3,H1>>
The state-report for POL1, CP2 can be encoded as:
POL1, CP2のstate-reportは、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <H1,M5,M6,E1>>
<PATH-ATTRIB Path ID=2 R-flag=0>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <E1,M6,M5,H1>>
The state-report for POL2, CP1 can be encoded as:
POL2, CP1のstate-reportは、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB Path ID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=4>>
<ERO <E1,M4,M3,H1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB Path ID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=2>>
<ERO <H1,M3,M4,E1>>
The state-report for POL2, CP2 can be encoded as:
POL2、CP2 のstate-reportは、次のようにエンコードできます。
<state-report> =
<LSP PLSP-ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB Path ID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePath ID=3>>
<ERO <E1,M6,M5,H1>>
<PATH-ATTRIB Path ID=2 R-flag=1>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB Path ID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePath ID=1>>
<ERO <H1,M5,M6,E1>>
Thanks to Adrian Farrel for shepherding this document, Ketan Talaulikar for his thorough AD review, Dhruv Dhody for ideas and discussion, and Diego Achaval, Quan Xiong, Giuseppe Fioccola, Italo Busi, Yuan Yaping, Cheng Li, Éric Vyncke, Mohamed Boucadair, Gunter Van de Velde, Christopher Inacio, Mike Bishop, Mahesh Jethanandani, Vidhi Goel, Gorry Fairhurst, and David Mandelberg for their reviews.
本文書のシェパーディングを務めてくださった Adrian Farrel 氏、綿密なADレビューを行ってくださった Ketan Talaulikar 氏、アイデアと議論を提供してくださった Dhruv Dhody 氏、そしてレビューを行ってくださった Diego Achaval、Quan Xiong、Giuseppe Fioccola、Italo Busi、Yuan Yaping、Cheng Li、Éric Vyncke、Mohamed Boucadair、Gunter Van de Velde、Christopher Inacio、Mike Bishop、Mahesh Jethanandani、Vidhi Goel、Gorry Fairhurst、David Mandelberg の各氏に感謝します。
The following individuals initiated and developed the core work of this document. Mike Koldychev is also listed as editor in the Authors' Addresses section. The other individuals appear here rather than in the Authors' Addresses section due to the IETF guidelines on the maximum number of listed authors, but they should be considered co-authors of this document. Samuel Sidor joined the effort at a later stage as an additional editor.
次の人々が本文書の中核となる作業を開始し、発展させました。Mike Koldychev は「Authors' Addresses」セクションにも編集者として記載されています。それ以外の人々は、記載できる著者数の上限に関するIETFのガイドラインのため、「Authors' Addresses」セクションではなくここに記載していますが、本文書の共著者とみなされるべきです。Samuel Sidor は後の段階で、追加の編集者として作業に加わりました。
Mike Koldychev Ed.
Ciena Corporation
Email: mkoldych@ciena.com
Siva Sivabalan
Ciena Corporation
Email: ssivabal@ciena.com
Tarek Saad
Cisco Systems
Email: tsaad@cisco.com
Vishnu Pavan Beeram
Juniper Networks, Inc.
Email: vbeeram@juniper.net
Hooman Bidgoli
Nokia
Email: hooman.bidgoli@nokia.com
Shuping Peng
Huawei Technologies
Email: pengshuping@huawei.com
Bhupendra Yadav
Ciena
Email: byadav@ciena.com
Gyan Mishra
Verizon Inc.
Email: hayabusagsm@gmail.com
The following individuals made contributions to this document:
次の人々が本文書に貢献しました。
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Andrew Stone
Nokia
Email: andrew.stone@nokia.com
Chen Ran
ZTE
Email: chen.ran@zte.com.cn
Mike Koldychev (editor)
Ciena Corporation
Email: mkoldych@ciena.com
Samuel Sidor (editor)
Cisco Systems.
Email: ssidor@cisco.com