Internet Engineering Task Force (IETF) M. Koldychev
Request for Comments: 9862 S. Sivabalan
Updates: 8231 Ciena Corporation
Category: Standards Track S. Sidor
ISSN: 2070-1721 Cisco Systems, Inc.
C. Barth
Juniper Networks, Inc.
S. Peng
Huawei Technologies
H. Bidgoli
Nokia
October 2025
A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths.
セグメント ルーティング (SR) ポリシーは、ソース ルーティング ポリシーを表す「セグメント」と呼ばれる命令の順序付きリストです。パケット フローは、インスタンス化されるノード上の SR ポリシーに誘導されます。SR ポリシーは 1 つ以上の候補パスで構成されます。
This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal Candidate Paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP) without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6).
この文書では、SR ポリシーの候補パスを通知するためのパス計算要素通信プロトコル (PCEP) 拡張を指定します。さらに、この文書は RFC 8231 を更新し、パス計算要求および応答メッセージを使用せずに SR ラベル スイッチド パス (LSP) の委任とセットアップを可能にします。このドキュメントは、セグメント ルーティング オーバー MPLS (SR-MPLS) とセグメント ルーティング オーバー IPv6 (SRv6) の両方に適用されます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9862.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9862 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Terminology
3. Overview
4. SR Policy Association (SRPA)
4.1. SR Policy Identifier
4.2. SR Policy Candidate Path Identifier
4.3. SR Policy Candidate Path Attributes
4.4. Association Parameters
4.5. Association Information
4.5.1. SRPOLICY-POL-NAME TLV
4.5.2. SRPOLICY-CPATH-ID TLV
4.5.3. SRPOLICY-CPATH-NAME TLV
4.5.4. SRPOLICY-CPATH-PREFERENCE TLV
5. SR Policy Signaling Extensions
5.1. SRPOLICY-CAPABILITY TLV
5.2. LSP Object TLVs
5.2.1. COMPUTATION-PRIORITY TLV
5.2.2. EXPLICIT-NULL-LABEL-POLICY TLV
5.2.3. INVALIDATION TLV
5.2.3.1. Drop-Upon-Invalid Applies to SR Policy
5.3. Updates to RFC 8231
6. IANA Considerations
6.1. Association Type
6.2. PCEP TLV Type Indicators
6.3. PCEP Errors
6.4. TE-PATH-BINDING TLV Flag Field
6.5. SR Policy Invalidation Operational State
6.6. SR Policy Invalidation Configuration State
6.7. SR Policy Capability TLV Flag Field
7. Security Considerations
8. Manageability 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
Acknowledgements
Contributors
Authors' Addresses
"Segment Routing Policy Architecture" [RFC9256] details the concepts of Segment Routing (SR) Policy [RFC8402] and approaches to steering traffic into an SR Policy.
「セグメント ルーティング ポリシー アーキテクチャ」[RFC9256] では、セグメント ルーティング (SR) ポリシー [RFC8402] の概念と、トラフィックを SR ポリシーに誘導するアプローチについて詳しく説明しています。
"Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing" [RFC8664] specifies extensions to the PCEP that allow a stateful Path Computation Element (PCE) to compute and initiate Traffic Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in an SR domain. Although PCEP extensions introduced in [RFC8664] enable the creation of SR-TE paths, these do not constitute SR Policies as defined in [RFC9256]. Therefore, they lack support for:
「セグメントルーティングのためのパス計算要素通信プロトコル (PCEP) 拡張機能」[RFC8664] は、ステートフル パス計算要素 (PCE) がトラフィック エンジニアリング (TE) パスを計算および開始できるようにするだけでなく、パス計算クライアント (PCC) が SR ドメイン内の特定の制約と最適化基準に従ってパスを要求できるようにする PCEP の拡張機能を指定しています。[RFC8664] で導入された PCEP 拡張により SR-TE パスの作成が可能になりますが、これらは [RFC9256] で定義されている SR ポリシーを構成しません。したがって、以下のサポートが不足しています。
* Association of SR Policy Candidate Paths signaled via PCEP with Candidate Paths of the same SR Policy signaled via other sources (e.g., local configuration or BGP).
* PCEP 経由でシグナリングされた SR ポリシー候補パスと、他のソース (ローカル構成や BGP など) 経由でシグナリングされた同じ SR ポリシーの候補パスとの関連付け。
* Association of an SR Policy with an intent via color, enabling headend-based steering of BGP service routes over SR Policies provisioned via PCEP.
* SR ポリシーとカラーによるインテントの関連付けにより、PCEP 経由でプロビジョニングされた SR ポリシーを介した BGP サービス ルートのヘッドエンド ベースのステアリングが可能になります。
"Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)" [RFC8697] introduces a generic mechanism to create a grouping of LSPs that is called an "Association".
「ラベル スイッチド パス (LSP) のセット間の関係を確立するためのパス計算要素通信プロトコル (PCEP) 拡張機能」[RFC8697] では、「アソシエーション」と呼ばれる LSP のグループを作成するための汎用メカニズムが導入されています。
An SR Policy is associated with one or more Candidate Paths. A Candidate Path is the unit for signaling an SR Policy to a headend as described in Section 2.2 of [RFC9256]. This document extends [RFC8664] to support signaling SR Policy Candidate Paths as LSPs and to signal Candidate Path membership in an SR Policy by means of the Association mechanism. A PCEP Association corresponds to an SR Policy and an LSP corresponds to a Candidate Path. The unit of signaling in PCEP is the LSP, thus, all the information related to an SR Policy is carried at the Candidate Path level.
SR ポリシーは 1 つ以上の候補パスに関連付けられます。候補パスは、[RFC9256] のセクション 2.2 で説明されているように、ヘッドエンドに SR ポリシーをシグナリングするための単位です。この文書は、SR ポリシー候補パスの LSP としてのシグナリングをサポートし、アソシエーション メカニズムによって SR ポリシー内の候補パス メンバーシップをシグナリングできるように [RFC8664] を拡張します。PCEP アソシエーションは SR ポリシーに対応し、LSP は候補パスに対応します。PCEP におけるシグナリングの単位は LSP であるため、SR ポリシーに関連するすべての情報は候補パス レベルで伝送されます。
Also, this document updates Section 5.8.2 of [RFC8231], making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs that are set up using Path Setup Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 (for SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges and simplifying implementation.
また、この文書は、[RFC8231] のセクション 5.8.2 を更新し、PCEP メッセージ交換を削減することを目的として、パス セットアップ タイプ 1 (セグメント ルーティング用) [RFC8664] およびパス セットアップ タイプ 3 (SRv6 用) [RFC9603] を使用してセットアップされた LSP に対して、パス計算要求 (PCReq) およびパス計算応答 (PCRep) メッセージの使用をオプションにします。実装の簡素化。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the following terms defined in [RFC5440]:
この文書では、[RFC5440] で定義されている次の用語を使用します。
* Explicit Route Object (ERO)
* 明示的ルート オブジェクト (ERO)
* Path Computation Client (PCC)
* パス計算クライアント (PCC)
* Path Computation Element (PCE)
* パス計算要素 (PCE)
* PCEP Peer
* PCEP ピア
* PCEP speaker
* PCEPスピーカー
This document uses the following term defined in [RFC3031]:
この文書では、[RFC3031] で定義されている次の用語を使用します。
* Label Switched Path (LSP)
* ラベル スイッチド パス (LSP)
This document uses the following term defined in [RFC9552]:
この文書では、[RFC9552] で定義されている次の用語を使用します。
* Border Gateway Protocol - Link State (BGP-LS)
* ボーダー ゲートウェイ プロトコル - リンク ステート (BGP-LS)
The following other terms are used in this document:
このドキュメントでは、次のその他の用語が使用されます。
Endpoint:
終点：
The IPv4 or IPv6 endpoint address of an SR Policy, as described in Section 2.1 of [RFC9256].
[RFC9256] のセクション 2.1 で説明されている SR ポリシーの IPv4 または IPv6 エンドポイント アドレス。
Color:
色：
The 32-bit color of an SR Policy, as described in Section 2.1 of [RFC9256].
[RFC9256] のセクション 2.1 で説明されている SR ポリシーの 32 ビット カラー。
Protocol-Origin:
プロトコルの発信元:
The protocol that was used to create a Candidate Path, as described in Section 2.3 of [RFC9256].
[RFC9256] のセクション 2.3 で説明されている、候補パスの作成に使用されたプロトコル。
Originator:
発信者:
A device that created a Candidate Path, as described in Section 2.4 of [RFC9256].
[RFC9256] のセクション 2.4 で説明されているように、候補パスを作成したデバイス。
Discriminator:
識別子:
Distinguishes Candidate Paths created by the same device, as described in Section 2.5 of [RFC9256].
[RFC9256] のセクション 2.5 で説明されているように、同じデバイスによって作成された候補パスを区別します。
Association parameters:
関連付けパラメータ:
Refers to the key data that uniquely identifies an Association, as described in [RFC8697].
[RFC8697] で説明されているように、アソシエーションを一意に識別するキー データを指します。
Association information:
協会情報:
Refers to information related to Association Type, as described in Section 6.1.4 of [RFC8697].
[RFC8697] のセクション 6.1.4 で説明されている、関連付けタイプに関連する情報を指します。
SR Policy LSP:
SR ポリシー LSP:
An LSP setup using Path Setup Type [RFC8408] 1 (for Segment Routing) or 3 (for SRv6).
パス セットアップ タイプ [RFC8408] 1 (セグメント ルーティングの場合) または 3 (SRv6 の場合) を使用した LSP セットアップ。
SR Policy Association (SRPA):
SR ポリシー アソシエーション (SRPA):
A new Association Type used to group Candidate Paths belonging to the same SR Policy. Depending on the discussion context, it can refer to the PCEP ASSOCIATION object of an SR Policy type or to a group of LSPs that belong to the association.
同じ SR ポリシーに属する候補パスをグループ化するために使用される新しい関連付けタイプ。議論のコンテキストに応じて、SR ポリシー タイプの PCEP ASSOCIATION オブジェクト、またはアソシエーションに属する LSP のグループを参照できます。
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. 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 in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP object as specified in [RFC8231]).
基本 PCEP 仕様 [RFC4655] は当初、RSVP-TE シグナリング プロトコルを使用してインスタンス化された LSP を備えた MPLS および GMPLS ネットワークに対する PCE アーキテクチャの使用を定義しました。時間の経過とともに、SRv6 などの追加のパス設定タイプのサポートが導入されました [RFC9603]。「LSP」という用語は PCEP 仕様で広く使用されており、この文書の文脈では、SR ポリシー内の候補パスを指します。これは SRv6 パスである可能性があります ([RFC8231] で指定されているように LSP オブジェクトを使用して表現されます)。
The SR Policy is represented by a new type of PCEP Association, called the SR Policy Association (SRPA) (see Section 4). The SR Policy Candidate Paths of a specific SR Policy are the LSPs within the same SRPA. The extensions in this document specify the encoding of a single segment list within an SR Policy Candidate Path. Encoding of multiple segment lists is outside the scope of this document and is specified in [PCEP-MULTIPATH].
SR ポリシーは、SR ポリシー アソシエーション (SRPA) と呼ばれる新しいタイプの PCEP アソシエーションによって表されます (セクション 4 を参照)。特定の SR ポリシーの SR ポリシー候補パスは、同じ SRPA 内の LSP です。このドキュメントの拡張機能は、SR ポリシー候補パス内の単一セグメント リストのエンコーディングを指定します。複数のセグメントリストのエンコーディングはこの文書の範囲外であり、[PCEP-MULTIPATH] で指定されています。
An SRPA carries three pieces of information: SR Policy Identifier, SR Policy Candidate Path Identifier, and SR Policy Candidate Path Attribute(s).
SRPA は、SR ポリシー識別子、SR ポリシー候補パス識別子、および SR ポリシー候補パス属性の 3 つの情報を伝送します。
This document also specifies some additional information that is not encoded as part of an SRPA: computation priority of the LSP, Explicit NULL Label Policy for the unlabeled IP packets and Drop-Upon-Invalid behavior for traffic steering when the LSP is operationally down (see Section 5).
この文書では、SRPA の一部としてエンコードされていないいくつかの追加情報も指定します。LSP の計算優先順位、ラベルのない IP パケットの明示的 NULL ラベル ポリシー、および LSP が動作的にダウンしているときのトラフィック ステアリングの Drop-Upon-Invalid 動作 (セクション 5 を参照)。
Per [RFC8697], LSPs are associated with other LSPs with which they interact by adding them to a common association group. An association group is uniquely identified by the combination of the following fields in the ASSOCIATION object (Section 6.1 of [RFC8697]): Association Type, Association ID, Association Source, and (if present) Global Association Source, or Extended Association ID. These fields are referred to as "association parameters" (Section 4.4).
[RFC8697] に従って、LSP は、共通の関連付けグループに追加することによって、相互作用する他の LSP に関連付けられます。アソシエーション グループは、ASSOCIATION オブジェクト ([RFC8697] のセクション 6.1) の次のフィールドの組み合わせによって一意に識別されます: アソシエーション タイプ、アソシエーション ID、アソシエーション ソース、および (存在する場合) グローバル アソシエーション ソース、または拡張アソシエーション ID。これらのフィールドは「関連付けパラメータ」と呼ばれます (セクション 4.4)。
[RFC8697] specifies the ASSOCIATION object with two Object-Types for IPv4 and IPv6 that includes the field Association Type. This document defines a new Association Type (6) "SR Policy Association" for an SRPA.
[RFC8697] は、フィールド Association Type を含む IPv4 および IPv6 の 2 つの Object-Type を持つ ASSOCIATION オブジェクトを指定します。この文書は、SRPA の新しい関連付けタイプ (6)「SR ポリシー関連付け」を定義します。
[RFC8697] specifies the mechanism for the capability advertisement of the Association Types supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the SRPA Type MUST be done before using the SRPA. To that aim, a PCEP speaker MUST include the SRPA Type (6) in the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer before using the SRPA (Section 6.1).
[RFC8697] は、OPEN オブジェクト内で伝送される ASSOC-Type-List TLV を定義することにより、PCEP スピーカーによってサポートされるアソシエーション タイプの機能通知のメカニズムを指定します。SRPA タイプのこの機能交換は、SRPA を使用する前に行う必要があります。そのために、PCEP スピーカーは ASSOC-Type-List TLV に SRPA タイプ (6) を含めなければならず、SRPA を使用する前に PCEP ピアからそれを受信しなければなりません (セクション 6.1)。
An SRPA MUST be assigned for all SR Policy LSPs by the PCEP speaker originating the LSP if the capability was advertised by both PCEP speakers. If the above condition is not satisfied, then the receiving PCEP speaker MUST send a PCErr message with:
機能が両方の PCEP スピーカーによってアドバタイズされた場合、LSP を発信する PCEP スピーカーによってすべての SR ポリシー LSP に SRPA を割り当てなければなりません (MUST)。上記の条件が満たされない場合、受信側 PCEP スピーカーは以下の PCErr メッセージを送信しなければなりません。
* Error-Type = 6 "Mandatory Object Missing"
* エラータイプ = 6 「必須オブジェクトがありません」
* Error-value = 22 "Missing SR Policy Association"
* エラー値 = 22 「SR ポリシーの関連付けがありません」
A given LSP MUST belong to one SRPA at most, since an SR Policy Candidate Path cannot belong to multiple SR Policies. If a PCEP speaker receives a PCEP message requesting to join more than one SRPA for the same LSP, then the PCEP speaker MUST send a PCErr message with:
SR ポリシー候補パスは複数の SR ポリシーに属することができないため、特定の LSP は最大でも 1 つの SRPA に属さなければなりません (MUST)。PCEP スピーカーが同じ LSP の複数の SRPA への参加を要求する PCEP メッセージを受信した場合、PCEP スピーカーは次の内容の PCErr メッセージを送信しなければなりません (MUST)。
* Error-Type = 26 "Association Error"
* エラータイプ = 26 「関連付けエラー」
* Error-value = 7 "Cannot join the association group"
* エラー値 = 7 「関連グループに参加できません」
The existing behavior for the use of Binding SID (BSID) with an SR Policy is already documented in [RFC9604]. If BSID value allocation failed because of conflict with the BSID used by another policy, then the PCEP peer MUST send a PCErr message with:
SR ポリシーでバインディング SID (BSID) を使用する場合の既存の動作は、すでに [RFC9604] に文書化されています。別のポリシーで使用されている BSID との競合により BSID 値の割り当てが失敗した場合、PCEP ピアは以下を含む PCErr メッセージを送信しなければなりません (MUST)。
* Error-Type = 32 "Binding label/SID failure"
* エラータイプ = 32 「ラベル/SID のバインドエラー」
* Error-value = 2 "Unable to allocate the specified binding value"
* エラー値 = 2 「指定されたバインディング値を割り当てることができません」
The SR Policy Identifier uniquely identifies an SR Policy [RFC9256] within the SR domain. The SR Policy Identifier is assigned by the PCEP peer originating the LSP and MUST be uniform across all the PCEP sessions. Candidate Paths within an SR Policy MUST carry the same SR Policy Identifiers in their SRPAs. Candidate Paths within an SR Policy MUST NOT change their SR Policy Identifiers for the lifetime of the PCEP session. If the above conditions are not satisfied, the receiving PCEP speaker MUST send a PCEP Error (PCErr) message with:
SR ポリシー識別子は、SR ドメイン内の SR ポリシー [RFC9256] を一意に識別します。SR ポリシー識別子は、LSP を発信する PCEP ピアによって割り当てられ、すべての PCEP セッションにわたって均一でなければなりません。SR ポリシー内の候補パスは、SRPA 内で同じ SR ポリシー識別子を持たなければなりません (MUST)。SR ポリシー内の候補パスは、PCEP セッションの存続期間中、SR ポリシー識別子を変更してはなりません (MUST NOT)。上記の条件が満たされない場合、受信側の PCEP スピーカーは次のような PCEP エラー (PCErr) メッセージを送信しなければなりません。
* Error-Type = 26 "Association Error"
* エラータイプ = 26 「関連付けエラー」
* Error-value = 20 "SR Policy Identifier Mismatch"
* エラー値 = 20 「SR ポリシー識別子が一致しません」
The SR Policy Identifier consists of:
SR ポリシー識別子は次のもので構成されます。
* Headend router where the SR Policy originates.
* SR ポリシーの発信元となるヘッドエンド ルーター。
* Color of the SR Policy ([RFC9256], Section 2.1).
* SR ポリシーの色 ([RFC9256]、セクション 2.1)。
* Endpoint of the SR Policy ([RFC9256], Section 2.1).
* SR ポリシーのエンドポイント ([RFC9256]、セクション 2.1)。
The SR Policy Candidate Path Identifier uniquely identifies the SR Policy Candidate Path within the context of an SR Policy. The SR Policy Candidate Path Identifier is assigned by the PCEP peer originating the LSP. Candidate Paths within an SR Policy MUST NOT change their SR Policy Candidate Path Identifiers for the lifetime of the PCEP session. Two or more Candidate Paths within an SR Policy MUST NOT carry the same SR Policy Candidate Path Identifiers in their SRPAs. If the above conditions are not satisfied, the PCEP speaker MUST send a PCErr message with:
SR ポリシー候補パス識別子は、SR ポリシーのコンテキスト内で SR ポリシー候補パスを一意に識別します。SR ポリシー候補パス識別子は、LSP を発信する PCEP ピアによって割り当てられます。SR ポリシー内の候補パスは、PCEP セッションの存続期間中、SR ポリシー候補パス識別子を変更してはなりません (MUST NOT)。SR ポリシー内の 2 つ以上の候補パスは、SRPA 内で同じ SR ポリシー候補パス識別子を保持してはなりません (MUST NOT)。上記の条件が満たされない場合、PCEP スピーカーは以下の PCErr メッセージを送信しなければなりません。
* Error-Type = 26 "Association Error"
* エラータイプ = 26 「関連付けエラー」
* Error-value = 21 "SR Policy Candidate Path Identifier Mismatch"
* エラー値 = 21 「SR ポリシー候補パス識別子が一致しません」
The SR Policy Candidate Path Identifier consists of:
SR ポリシー候補パス識別子は次のもので構成されます。
* Protocol-Origin ([RFC9256], Section 2.3)
* プロトコルオリジン ([RFC9256]、セクション 2.3)
* Originator ([RFC9256], Section 2.4)
* 発信者 ([RFC9256]、セクション 2.4)
* Discriminator ([RFC9256], Section 2.5)
* 識別子 ([RFC9256]、セクション 2.5)
SR Policy Candidate Path Attributes carry optional, non-key information about a Candidate Path and MAY change during the lifetime of an LSP. SR Policy Candidate Path Attributes consist of:
SR ポリシー候補パス属性は、候補パスに関するオプションの非キー情報を運び、LSP の存続期間中に変更される場合があります (MAY)。SR ポリシー候補パス属性は次のもので構成されます。
* Candidate Path Preference ([RFC9256], Section 2.7)
* 候補パスの優先順位 ([RFC9256]、セクション 2.7)
* Candidate Path name ([RFC9256], Section 2.6)
* 候補パス名 ([RFC9256]、セクション 2.6)
* SR Policy name ([RFC9256], Section 2.1)
* SR ポリシー名 ([RFC9256]、セクション 2.1)
Per Section 2.1 of [RFC9256], an SR Policy is identified through the <Headend, Color, Endpoint> tuple.
[RFC9256] のセクション 2.1 に従って、SR ポリシーは <Headend, Color, Endpoint> タプルを通じて識別されます。
The association parameters consist of:
関連付けパラメータは次のもので構成されます。
Association Type:
関連付けの種類:
Set to 6 "SR Policy Association".
6「SRポリシーアソシエーション」に設定します。
Association Source (IPv4/IPv6):
アソシエーションソース (IPv4/IPv6):
Set to the headend value of the SR Policy, as defined in [RFC9256], Section 2.1.
[RFC9256] セクション 2.1 で定義されている SR ポリシーのヘッドエンド値に設定します。
Association ID (16 bit):
アソシエーション ID (16 ビット):
Always set to the numeric value 1.
常に数値 1 に設定します。
Extended Association ID TLV:
拡張アソシエーション ID TLV:
Mandatory TLV for an SRPA. Encodes the Color and Endpoint of the SR Policy (Figure 1).
SRPA の必須 TLV。SR ポリシーのカラーとエンドポイントをエンコードします (図 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Endpoint ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Association ID TLV Format
図 1: 拡張アソシエーション ID TLV フォーマット
Type:
タイプ：
31 for the Extended Association ID TLV [RFC8697].
拡張アソシエーション ID TLV [RFC8697] の場合は 31。
Length:
長さ：
8 octets if IPv4 address or 20 octets if IPv6 address is encoded in the Endpoint field.
IPv4 アドレスの場合は 8 オクテット、IPv6 アドレスが [エンドポイント] フィールドでエンコードされている場合は 20 オクテット。
Color:
色：
Unsigned non-zero 32-bit integer value, SR Policy color per Section 2.1 of [RFC9256].
符号なし非ゼロの 32 ビット整数値、[RFC9256] のセクション 2.1 に基づく SR ポリシーの色。
Endpoint:
終点：
Can be either IPv4 (4 octets) or IPv6 address (16 octets). This value MAY be different from the one contained in the destination address field in the END-POINTS object, or in the Tunnel Endpoint Address field in the LSP-IDENTIFIERS TLV (Section 2.1 of [RFC9256]).
IPv4 (4 オクテット) または IPv6 アドレス (16 オクテット) のいずれかを使用できます。この値は、END-POINTS オブジェクトの宛先アドレス フィールド、または LSP-IDENTIFIERS TLV ([RFC9256] のセクション 2.1) のトンネル エンドポイント アドレス フィールドに含まれる値と異なっていてもよい(MAY)。
If a PCEP speaker receives an SRPA object whose association parameters do not follow the above specification, then the PCEP speaker MUST send a PCErr message with:
PCEP スピーカーがアソシエーション パラメータが上記の仕様に従っていない SRPA オブジェクトを受信した場合、PCEP スピーカーは次のような PCErr メッセージを送信しなければなりません。
* Error-Type = 26 "Association Error"
* エラータイプ = 26 「関連付けエラー」
* Error-value = 20 "SR Policy Identifier Mismatch"
* エラー値 = 20 「SR ポリシー識別子が一致しません」
The encoding choice of the association parameters in this way is meant to guarantee that there is no possibility of a race condition when multiple PCEP speakers want to associate the same SR Policy at the same time. By adhering to this format, all PCEP speakers come up with the same association parameters independently of each other based on the SR Policy parameters [RFC9256].
この方法での関連付けパラメータのエンコーディングの選択は、複数の PCEP スピーカーが同時に同じ SR ポリシーを関連付けたい場合に、競合状態が発生する可能性がないことを保証することを目的としています。この形式に従うことにより、すべての PCEP スピーカーは、SR ポリシー パラメーター [RFC9256] に基づいて、互いに独立して同じ関連付けパラメーターを作成します。
The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <Headend, Color, Endpoint> tuple. An example use case is to terminate the SR Policy before reaching the Endpoint and have decapsulated traffic be forwarded the rest of the path to the Endpoint node using the Interior Gateway Protocol (IGP) shortest path(s). In this example, the destination of the SR Policy Candidate Paths will be some node before the Endpoint, but the Endpoint value is still used at the headend to steer traffic with that Endpoint IP address into the SR Policy. The destination of the SR Policy Candidate Path is signaled using the END-POINTS object and/ or the LSP-IDENTIFIERS TLV, per the usual PCEP procedure. When neither the END-POINTS object nor the LSP-IDENTIFIERS TLV is present, the PCEP speaker MUST extract the destination from the Endpoint field in the SRPA Extended Association ID TLV.
計算された SR ポリシー候補パスの最後のホップは、<Headend, Color, Endpoint> タプルに含まれるエンドポイントと異なる場合があります (MAY)。使用例の例としては、エンドポイントに到達する前に SR ポリシーを終了し、カプセル化解除されたトラフィックをインテリア ゲートウェイ プロトコル (IGP) の最短パスを使用して残りのパスでエンドポイント ノードに転送することが挙げられます。この例では、SR ポリシー候補パスの宛先はエンドポイントの前のノードになりますが、エンドポイントの値は依然としてヘッドエンドで使用され、そのエンドポイント IP アドレスを持つトラフィックを SR ポリシーに誘導します。SR ポリシー候補パスの宛先は、通常の PCEP プロシージャに従って、END-POINTS オブジェクトおよび/または LSP-IDENTIFIERS TLV を使用して通知されます。END-POINTS オブジェクトも LSP-IDENTIFIERS TLV も存在しない場合、PCEP スピーカーは SRPA 拡張アソシエーション ID TLV のエンドポイント フィールドから宛先を抽出しなければなりません (MUST)。
SR Policy with Color-Only steering is signaled with the Endpoint value set to unspecified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per Section 8.8 of [RFC9256].
Color-Only ステアリングを備えた SR ポリシーは、[RFC9256] のセクション 8.8 に従って、エンドポイント値が未指定、つまり IPv4 の場合は 0.0.0.0、IPv6 の場合は :: に設定されてシグナリングされます。
The SRPA object may carry the following TLVs:
SRPA オブジェクトには次の TLV が含まれる場合があります。
SRPOLICY-POL-NAME TLV (Section 4.5.1):
SRPOLICY-POL-NAME TLV (セクション 4.5.1):
(optional) encodes the SR Policy Name string.
(オプション) SR ポリシー名の文字列をエンコードします。
SRPOLICY-CPATH-ID TLV (Section 4.5.2):
SRPOLICY-CPATH-ID TLV (セクション 4.5.2):
(mandatory) encodes the SR Policy Candidate Path Identifier.
(必須) SR ポリシー候補パス識別子をエンコードします。
SRPOLICY-CPATH-NAME TLV (Section 4.5.3):
SRPOLICY-CPATH-NAME TLV (セクション 4.5.3):
(optional) encodes the SR Policy Candidate Path string name.
(オプション) SR ポリシー候補パス文字列名をエンコードします。
SRPOLICY-CPATH-PREFERENCE TLV (Section 4.5.4):
SRPOLICY-CPATH-PREFERENCE TLV (セクション 4.5.4):
(optional) encodes the SR Policy Candidate Path Preference value.
(オプション) SR ポリシー候補パス設定値をエンコードします。
When a mandatory TLV is missing from an SRPA object, the PCEP speaker MUST send a PCErr message with:
SRPA オブジェクトに必須の TLV が欠落している場合、PCEP スピーカーは以下を含む PCErr メッセージを送信しなければなりません (MUST)。
* Error-Type = 6 "Mandatory Object Missing"
* エラータイプ = 6 「必須オブジェクトがありません」
* Error-value = 21 "Missing SR Policy Mandatory TLV"
* エラー値 = 21 「SR ポリシーの必須 TLV がありません」
Only one TLV instance of each TLV type can be carried in an SRPA object, and only the first occurrence is processed. Any others MUST be silently ignored.
各 TLV タイプの TLV インスタンスは 1 つだけ SRPA オブジェクトに含めることができ、最初に出現したものだけが処理されます。その他のものは黙って無視しなければなりません。
The SRPOLICY-POL-NAME TLV (Figure 2) is an optional TLV for the SRPA object. It is RECOMMENDED that the size of the name for the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes to simplify interoperability with other protocols.
SRPOLICY-POL-NAME TLV (図 2) は、SRPA オブジェクトのオプションの TLV です。SR ポリシーの名前のサイズは 255 バイトに制限されることが推奨されます。実装では、他のプロトコルとの相互運用性を簡素化するために、長い名前を 255 バイトに切り詰めることを選択してもよい(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SR Policy Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRPOLICY-POL-NAME TLV Format
図 2: SRPOLICY-POL-NAME TLV フォーマット
Type:
タイプ：
56 for the SRPOLICY-POL-NAME TLV.
SRPOLICY-POL-NAME TLV の場合は 56。
Length:
長さ：
Indicates the length of the value portion of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned. Padding is not included in the Length field.
TLV の値部分の長さをオクテット単位で示し、0 より大きくなければなりません。TLV が 4 オクテットでアライメントされるように、TLV はゼロ埋めされなければなりません。パディングは長さフィールドには含まれません。
SR Policy Name:
SR ポリシー名:
SR Policy name, as defined in Section 2.1 of [RFC9256]. It MUST be a string of printable ASCII [RFC0020] characters, without a NULL terminator.
[RFC9256] のセクション 2.1 で定義されている SR ポリシー名。これは、NULL 終端文字を含まない、印刷可能な ASCII [RFC0020] 文字の文字列でなければなりません。
The SRPOLICY-CPATH-ID TLV (Figure 3) is a mandatory TLV for the SRPA object.
SRPOLICY-CPATH-ID TLV (図 3) は、SRPA オブジェクトの必須 TLV です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto-Origin | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originator Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRPOLICY-CPATH-ID TLV Format
図 3: SRPOLICY-CPATH-ID TLV フォーマット
Type:
タイプ：
57 for the SRPOLICY-CPATH-ID TLV.
SRPOLICY-CPATH-ID TLV の場合は 57。
Length:
長さ：
28.
28.
Protocol-Origin:
プロトコルの発信元:
8-bit unsigned integer value that encodes the Protocol-Origin. The values of this field are specified in the IANA registry "SR Policy Protocol Origin" under the "Segment Routing" registry group, which is introduced in Section 8.4 of [RFC9857]. Note that in the PCInitiate message [RFC8281], the Protocol-Origin is always set to 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)". The "SR Policy Protocol Origin" IANA registry includes a combination of values intended for use in PCEP and BGP-LS. When the registry contains two variants of values associated with the mechanism or protocol used for provisioning of the Candidate Path, for example 1 - "PCEP" and 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)", the "(In PCEP or when BGP-LS Producer is PCE)", then variants MUST be used in PCEP.
Protocol-Origin をエンコードする 8 ビットの符号なし整数値。このフィールドの値は、[RFC9857] のセクション 8.4 で導入されている、「Segment Routing」レジストリ グループの下の IANA レジストリ「SR Policy Protocol Origin」で指定されています。PCInitiate メッセージ [RFC8281] では、Protocol-Origin が常に 10 - 「PCEP (PCEP または BGP-LS プロデューサーが PCE の場合)」に設定されることに注意してください。「SR Policy Protocol Origin」IANA レジストリには、PCEP と BGP-LS での使用を目的とした値の組み合わせが含まれています。レジストリに、候補パスのプロビジョニングに使用されるメカニズムまたはプロトコルに関連付けられた 2 つの値のバリアントが含まれている場合、たとえば、1 - 「PCEP」と 10 - 「PCEP (PCEP または BGP-LS プロデューサが PCE の場合)」、「(PCEP または BGP-LS プロデューサが PCE の場合)」の場合、PCEP ではバリアントを使用しなければなりません。
Reserved:
予約済み：
This field MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
Originator Autonomous System Number (ASN):
発信者自律システム番号 (ASN):
Represented as a 32-bit unsigned integer value, part of the originator identifier, as specified in Section 2.4 of [RFC9256]. When sending a PCInitiate message [RFC8281], the PCE is the originator of the Candidate Path. If the PCE is configured with an ASN, then it MUST set it; otherwise, the ASN is set to 0.
[RFC9256] のセクション 2.4 で規定されているように、発信者識別子の一部である 32 ビットの符号なし整数値として表されます。PCInitiate メッセージ [RFC8281] を送信する場合、PCE は候補パスの発信者になります。PCE が ASN で構成されている場合は、それを設定する必要があります。それ以外の場合、ASN は 0 に設定されます。
Originator Address:
発信者の住所:
Represented as a 128-bit value as specified in Section 2.4 of [RFC9256]. When sending a PCInitiate message, the PCE is acting as the originator and therefore MAY set this to an address that it owns.
[RFC9256] のセクション 2.4 で規定されている 128 ビット値として表されます。PCInitiate メッセージを送信するとき、PCE は発信者として機能するため、これを自身が所有するアドレスに設定してもよい(MAY)。
Discriminator:
識別子:
32-bit unsigned integer value that encodes the Discriminator of the Candidate Path, as specified in Section 2.5 of [RFC9256]. This is the field that mainly distinguishes different SR Policy Candidate Paths, coming from the same originator. It is allowed to be any number in the 32-bit range.
[RFC9256] のセクション 2.5 で規定されているように、候補パスの識別子をエンコードする 32 ビットの符号なし整数値。これは、主に、同じ作成者からの異なる SR ポリシー候補パスを区別するフィールドです。32 ビット範囲内の任意の数値を使用できます。
The SRPOLICY-CPATH-NAME TLV (Figure 4) is an optional TLV for the SRPA object. It is RECOMMENDED that the size of the name for the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes to simplify interoperability with other protocols.
SRPOLICY-CPATH-NAME TLV (図 4) は、SRPA オブジェクトのオプションの TLV です。SR ポリシーの名前のサイズは 255 バイトに制限されることが推奨されます。実装では、他のプロトコルとの相互運用性を簡素化するために、長い名前を 255 バイトに切り詰めることを選択してもよい(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SR Policy Candidate Path Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRPOLICY-CPATH-NAME TLV Format
図 4: SRPOLICY-CPATH-NAME TLV フォーマット
Type:
タイプ：
58 for the SRPOLICY-CPATH-NAME TLV.
SRPOLICY-CPATH-NAME TLV の場合は 58。
Length:
長さ：
Indicates the length of the value portion of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned. Padding is not included in the Length field.
TLV の値部分の長さをオクテット単位で示し、0 より大きくなければなりません。TLV が 4 オクテットでアライメントされるように、TLV はゼロ埋めされなければなりません。パディングは長さフィールドには含まれません。
SR Policy Candidate Path Name:
SR ポリシー候補のパス名:
SR Policy Candidate Path Name, as defined in Section 2.6 of [RFC9256]. It MUST be a string of printable ASCII characters, without a NULL terminator.
[RFC9256] のセクション 2.6 で定義されている SR ポリシー候補パス名。これは、NULL 終端文字を含まない、印刷可能な ASCII 文字の文字列でなければなりません。
The SRPOLICY-CPATH-PREFERENCE TLV (Figure 5) is an optional TLV for the SRPA object. If the TLV is absent, then the default Preference value is 100, per Section 2.7 of [RFC9256].
SRPOLICY-CPATH-PREFERENCE TLV (図 5) は、SRPA オブジェクトのオプションの TLV です。TLV が存在しない場合、[RFC9256] のセクション 2.7 に従って、デフォルトの設定値は 100 になります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SRPOLICY-CPATH-PREFERENCE TLV Format
図 5: SRPOLICY-CPATH-PREFERENCE TLV フォーマット
Type:
タイプ：
59 for the SRPOLICY-CPATH-PREFERENCE TLV.
SRPOLICY-CPATH-PREFERENCE TLV の場合は 59。
Length:
長さ：
4.
4.
Preference:
好み：
32-bit unsigned integer value that encodes the Preference of the Candidate Path as defined in Section 2.7 of [RFC9256].
[RFC9256] のセクション 2.7 で定義されている候補パスの設定をエンコードする 32 ビットの符号なし整数値。
This section introduces mechanisms described for SR Policies in [RFC9256] to PCEP. These extensions do not make use of the SRPA for signaling in PCEP; therefore, they cannot rely on the Association capability negotiation in the ASSOC-Type-List TLV. Instead, separate capability negotiation is required.
このセクションでは、PCEP に対する [RFC9256] の SR ポリシーについて説明されているメカニズムを紹介します。これらの拡張機能は、PCEP でのシグナリングに SRPA を使用しません。したがって、ASSOC-Type-List TLV のアソシエーション機能ネゴシエーションに依存することはできません。代わりに、個別の機能ネゴシエーションが必要です。
This document specifies four new TLVs to be carried in the OPEN or LSP object. Only one TLV instance of each type can be carried, and only the first occurrence is processed. Any others MUST be ignored.
この文書では、OPEN または LSP オブジェクトで伝送される 4 つの新しい TLV を指定します。各タイプの TLV インスタンスは 1 つだけ伝送でき、最初に出現したものだけが処理されます。それ以外のものは無視しなければなりません。
The SRPOLICY-CAPABILITY TLV (Figure 6) is a TLV for the OPEN object. It is used at session establishment to learn the peer's capabilities with respect to SR Policy. Implementations that support SR Policy MUST include the SRPOLICY-CAPABILITY TLV in the OPEN object if the extension is enabled. In addition, the ASSOC-Type-List TLV containing SRPA Type (6) MUST be present in the OPEN object, as specified in Section 4.
SRPOLICY-CAPABILITY TLV (図 6) は、OPEN オブジェクトの TLV です。これは、セッションの確立時に、SR ポリシーに関するピアの機能を学習するために使用されます。SR ポリシーをサポートする実装では、拡張機能が有効になっている場合、OPEN オブジェクトに SRPOLICY-CAPABILITY TLV を含める必要があります。さらに、セクション 4 で指定されているように、SRPA タイプ (6) を含む ASSOC-Type-List TLV が OPEN オブジェクト内に存在しなければなりません (MUST)。
If a PCEP speaker receives an SRPA but the SRPOLICY-CAPABILITY TLV is not exchanged, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 "Reception of an invalid object" and Error-value = 44 "Missing SRPOLICY-CAPABILITY TLV" and MUST then close the PCEP session.
PCEP スピーカーが SRPA を受信したが、SRPOLICY-CAPABILITY TLV が交換されていない場合、PCEP スピーカーは、Error-Type = 10「無効なオブジェクトの受信」および Error-value = 44「SRPOLICY-CAPABILITY TLV の欠落」を含む PCErr メッセージを送信し、PCEP セッションを閉じなければなりません(MUST)。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |L| |I|E|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SRPOLICY-CAPABILITY TLV Format
図 6: SRPOLICY 機能 TLV フォーマット
Type:
タイプ：
71 for the SRPOLICY-CAPABILITY TLV.
SRPOLICY-CAPABILITY TLV の場合は 71。
Length:
長さ：
4.
4.
Flags:
フラグ:
32 bits. The following flags are currently defined:
32ビット。現在、次のフラグが定義されています。
P-flag (Computation Priority):
P フラグ (演算優先度):
If set to 1 by a PCEP speaker, the P-flag indicates that the PCEP speaker supports the handling of the COMPUTATION-PRIORITY TLV for the SR Policy (Section 5.2.1). If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the COMPUTATION-PRIORITY TLV and MUST ignore it on receipt.
PCEP スピーカーによって P フラグが 1 に設定された場合、P フラグは、PCEP スピーカーが SR ポリシー (セクション 5.2.1) の COMPUTATION-PRIORITY TLV の処理をサポートしていることを示します。このフラグが 0 に設定されている場合、受信側 PCEP スピーカーは COMPUTATION-PRIORITY TLV を送信してはならず、受信時に無視しなければなりません (MUST)。
E-flag (Explicit NULL Label Policy):
E フラグ (明示的な NULL ラベル ポリシー):
If set to 1 by a PCEP speaker, the E-flag indicates that the PCEP speaker supports the handling of the EXPLICIT-NULL-LABEL-POLICY TLV for the SR Policy (Section 5.2.2). If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the EXPLICIT-NULL-LABEL-POLICY TLV and MUST ignore it on receipt.
PCEP スピーカーによって E フラグが 1 に設定された場合、E フラグは、PCEP スピーカーが SR ポリシーの EXPLICIT-NULL-LABEL-POLICY TLV の処理をサポートしていることを示します (セクション 5.2.2)。このフラグが 0 に設定されている場合、受信側 PCEP スピーカーは EXPLICIT-NULL-LABEL-POLICY TLV を送信してはならず、受信時にそれを無視しなければなりません (MUST)。
I-flag (Invalidation):
I フラグ (無効化):
If set to 1 by a PCEP speaker, the I-flag indicates that the PCEP speaker supports the handling of the INVALIDATION TLV for the SR Policy (Section 5.2.3). If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the INVALIDATION TLV and MUST ignore it on receipt.
PCEP スピーカーによって I フラグが 1 に設定された場合、I フラグは、PCEP スピーカーが SR ポリシーの INVALIDATION TLV の処理をサポートしていることを示します (セクション 5.2.3)。このフラグが 0 に設定されている場合、受信側 PCEP スピーカーは INVALIDATION TLV を送信してはならず、受信時にそれを無視しなければなりません (MUST)。
L-flag (Stateless Operation):
L フラグ (ステートレス操作):
If set to 1 by a PCEP speaker, the L-flag indicates that the PCEP speaker supports the stateless (PCReq/PCRep) operations for the SR Policy (Section 5.3). If the PCE set this flag to 0, then the PCC MUST NOT send PCReq messages to this PCE for the SR Policy.
PCEP スピーカーによって 1 に設定された場合、L フラグは、PCEP スピーカーが SR ポリシー (セクション 5.3) のステートレス (PCReq/PCRep) 操作をサポートしていることを示します。PCE がこのフラグを 0 に設定した場合、PCC は SR ポリシーのために PCReq メッセージをこの PCE に送信してはなりません。
Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt. More flags can be assigned in the future per (Section 6.7).
未割り当てのビットは送信時に 0 に設定されなければならず、受信時には無視されなければなりません。(セクション 6.7) に従って、将来さらに多くのフラグを割り当てることができます。
This section is introducing three new TLVs to be carried in the LSP object introduced in Section 7.3 of [RFC8231].
このセクションでは、[RFC8231] のセクション 7.3 で導入された LSP オブジェクトで伝送される 3 つの新しい TLV を紹介します。
The COMPUTATION-PRIORITY TLV (Figure 7) is an optional TLV. It is used to signal the numerical computation priority, as specified in Section 2.12 of [RFC9256]. If the TLV is absent from the LSP object, and the P-flag in the SRPOLICY-CAPABILITY TLV is set to 1, a default Priority value of 128 is used.
COMPUTATION-PRIORITY TLV (図 7) はオプションの TLV です。[RFC9256] のセクション 2.12 で規定されているように、数値計算の優先順位を通知するために使用されます。TLV が LSP オブジェクトに存在せず、SRPOLICY-CAPABILITY TLV の P フラグが 1 に設定されている場合、デフォルトの優先度値 128 が使用されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: COMPUTATION-PRIORITY TLV Format
図 7: 計算優先 TLV フォーマット
Type:
タイプ：
68 for the COMPUTATION-PRIORITY TLV.
COMPUTATION-PRIORITY TLV の場合は 68。
Length:
長さ：
4.
4.
Priority:
優先度：
8-bit unsigned integer value that encodes numerical priority with which this LSP is to be recomputed by the PCE upon topology change. The lowest value is the highest priority.
トポロジー変更時に PCE によってこの LSP が再計算される優先順位の数値をエンコードする 8 ビットの符号なし整数値。最も低い値が最も高い優先度になります。
Reserved:
予約済み：
This field MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
To steer an unlabeled IP packet into an SR Policy for the MPLS data plane, it is necessary to push a label stack of one or more labels on that packet. The EXPLICIT-NULL-LABEL-POLICY TLV is an optional TLV for the LSP object used to indicate whether an Explicit NULL label [RFC3032] must be pushed on an unlabeled IP packet before any other labels. The contents of this TLV are used by the SR Policy manager as described in Section 4.1 of [RFC9256]. If an EXPLICIT-NULL-LABEL-POLICY TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration. Note that Explicit NULL is currently only defined for SR-MPLS and not for SRv6. Therefore, the receiving PCEP speaker MUST ignore the presence of this TLV for SRv6 Policies.
ラベルのない IP パケットを MPLS データ プレーンの SR ポリシーに誘導するには、そのパケットに 1 つ以上のラベルのラベル スタックをプッシュする必要があります。EXPLICIT-NULL-LABEL-POLICY TLV は、明示的 NULL ラベル [RFC3032] を他のラベルの前にラベルのない IP パケットにプッシュする必要があるかどうかを示すために使用される LSP オブジェクトのオプションの TLV です。この TLV の内容は、[RFC9256] のセクション 4.1 で説明されているように、SR ポリシー マネージャーによって使用されます。EXPLICIT-NULL-LABEL-POLICY TLV が存在しない場合、特定のパケットに明示的 NULL ラベルをプッシュするかどうかの決定は、ローカル構成の問題になります。現在、明示的 NULL は SR-MPLS に対してのみ定義されており、SRv6 に対しては定義されていないことに注意してください。したがって、受信側の PCEP スピーカーは、SRv6 ポリシーのこの TLV の存在を無視しなければなりません (MUST)。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENLP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EXPLICIT-NULL-LABEL-POLICY TLV Format
図 8: EXPLICIT-NULL-LABEL-POLICY TLV フォーマット
Type:
タイプ：
69 for the EXPLICIT-NULL-LABEL-POLICY TLV.
EXPLICIT-NULL-LABEL-POLICY TLV の場合は 69。
Length:
長さ：
4.
4.
ENLP:
英語:
Explicit NULL Label Policy. 8-bit unsigned integer value that indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SR Policy. The values of this field are specified in the IANA registry "SR Policy ENLP Values" under the "Segment Routing" registry group, which was introduced in Section 6.10 of [RFC9830].
明示的な NULL ラベル ポリシー。特定の SR ポリシーに誘導されるラベルのない IP パケットに明示的 NULL ラベルをプッシュするかどうかを示す 8 ビットの符号なし整数値。このフィールドの値は、[RFC9830] のセクション 6.10 で導入された、「セグメント ルーティング」レジストリ グループの下の IANA レジストリ「SR ポリシー ENLP 値」で指定されます。
Reserved:
予約済み：
This field MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
The ENLP unassigned values may be used for future extensions, and implementations MUST ignore the EXPLICIT-NULL-LABEL-POLICY TLV with unrecognized values. The behavior signaled in this TLV MAY be overridden by local configuration by the network operator based on their deployment requirements. Section 4.1 of [RFC9256] describes the behavior on the headend for the handling of the Explicit NULL label.
ENLP の未割り当て値は将来の拡張に使用される可能性があり、実装は認識できない値を含む EXPLICIT-NULL-LABEL-POLICY TLV を無視しなければなりません (MUST)。この TLV で通知される動作は、展開要件に基づいて、ネットワーク オペレータによるローカル構成によってオーバーライドされる場合があります。[RFC9256] のセクション 4.1 では、明示的 NULL ラベルを処理するためのヘッドエンドでの動作について説明しています。
The INVALIDATION TLV (Figure 9) is an optional TLV. This TLV is used to control traffic steering into an LSP when the LSP is operationally down/invalid. In the context of SR Policy, this TLV facilitates the Drop-Upon-Invalid behavior, specified in Section 8.2 of [RFC9256]. Normally, if the LSP is down/invalid then it stops attracting traffic; traffic that would have been destined for that LSP is redirected somewhere else, such as via IGP or another LSP. The Drop-Upon-Invalid behavior specifies that the LSP keeps attracting traffic and the traffic has to be dropped at the headend. Such an LSP is said to be "in drop state". While in the drop state, the LSP operational state is "UP", as indicated by the O-flag in the LSP object. However, the ERO object MAY be empty if no valid path has been computed.
INVALIDATION TLV (図 9) はオプションの TLV です。この TLV は、LSP が動作上ダウンしているか無効である場合に、LSP へのトラフィック ステアリングを制御するために使用されます。SR ポリシーのコンテキストでは、この TLV は、[RFC9256] のセクション 8.2 で規定されている Drop-Upon-Invalid 動作を容易にします。通常、LSP がダウンまたは無効な場合、トラフィックの引き付けが停止されます。その LSP 宛てであるはずのトラフィックは、IGP や別の LSP 経由など、別の場所にリダイレクトされます。Drop-Upon-Invalid 動作は、LSP がトラフィックを引き付け続け、トラフィックをヘッドエンドでドロップする必要があることを指定します。このような LSP は「ドロップ状態」であると言われます。ドロップ状態にある間、LSP オブジェクトの O フラグで示されるように、LSP の動作状態は「UP」です。ただし、有効なパスが計算されていない場合、ERO オブジェクトは空であってもよい(MAY)。
The INVALIDATION TLV is used in both directions between PCEP peers:
INVALIDATION TLV は、PCEP ピア間で両方向に使用されます。
* PCE -> PCC: The PCE specifies to the PCC whether to enable or disable Drop-Upon-Invalid (Config).
* PCE -> PCC: PCE は、Drop-Upon-Invalid (Config) を有効にするか無効にするかを PCC に指定します。
* PCC -> PCE: The PCC reports the current setting of the Drop-Upon-Invalid (Config) and also whether the LSP is currently in the drop state (Oper).
* PCC -> PCE: PCC は、Drop-Upon-Invalid の現在の設定 (Config) と、LSP が現在ドロップ状態にあるかどうか (Oper) を報告します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | Config | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: INVALIDATION TLV Format
図 9: 無効化 TLV フォーマット
Type:
タイプ：
70 for the INVALIDATION TLV.
INVALIDATION TLV の場合は 70。
Length:
長さ：
4.
4.
Oper:
オペラ:
An 8-bit flag field that encodes the operational state of the LSP. It MUST be set to 0 by the PCE when sending and MUST be ignored by the PCC upon receipt. See Section 6.5 for IANA information.
LSP の動作状態をエンコードする 8 ビットのフラグ フィールド。送信時には PCE によって 0 に設定されなければならず、受信時には PCC によって無視されなければなりません。IANA の情報については、セクション 6.5 を参照してください。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
Figure 10: Oper State of Drop-Upon-Invalid Feature
図 10: ドロップアポン無効機能の動作状態
* D: Dropping - the LSP is actively dropping traffic as a result of Drop-Upon-Invalid behavior being activated.
* D: ドロップ - Drop-Upon-Invalid 動作がアクティブ化された結果、LSP はトラフィックをアクティブにドロップしています。
* The unassigned bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.
* Flag オクテットの未割り当てビットは送信時にゼロに設定されなければならず (MUST)、受信時には無視されなければなりません (MUST)。
Config:
構成:
An 8-bit flag field that encodes the configuration of the LSP. See Section 6.6 for IANA information.
LSP の設定をエンコードする 8 ビットのフラグ フィールド。IANA の情報については、セクション 6.6 を参照してください。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
Figure 11: Config State of Drop-Upon-Invalid Feature
図 11: Drop-Upon-Invalid 機能の構成状態
* D: Drop enabled - the Candidate Path has Drop-Upon-Invalid feature enabled.
* D: ドロップが有効 - 候補パスでは Drop-Upon-Invalid 機能が有効になっています。
* The unassigned bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.
* Flag オクテットの未割り当てビットは送信時にゼロに設定されなければならず (MUST)、受信時には無視されなければなりません (MUST)。
Reserved:
予約済み：
This field MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
The Drop-Upon-Invalid feature is somewhat special among the other SR Policy features in the way that it is enabled/disabled. This feature is enabled only on the whole SR Policy, not on a particular Candidate Path of that SR Policy, i.e., when any Candidate Path has Drop-Upon-Invalid enabled, it means that the whole SR Policy has the feature enabled. As stated in Section 8.1 of [RFC9256], an SR Policy is invalid when all its Candidate Paths are invalid.
Drop-Upon-Invalid 機能は、有効/無効にする方法が他の SR ポリシー機能の中でもやや特殊です。この機能は、SR ポリシー全体でのみ有効になり、その SR ポリシーの特定の候補パスでは有効になりません。つまり、いずれかの候補パスで Drop-Upon-Invalid が有効になっている場合、SR ポリシー全体でこの機能が有効になったことを意味します。[RFC9256] のセクション 8.1 に記載されているように、すべての候補パスが無効な場合、SR ポリシーは無効です。
Once all the Candidate Paths of an SR Policy have become invalid, then the SR Policy checks whether any of the Candidate Paths have Drop-Upon-Invalid enabled. If so, the SR Policy enters the drop state and "activates" the highest preference Candidate Path that has the Drop-Upon-Invalid enabled. Note that only one Candidate Path needs to be reported to the PCE with the Dropping (D) flag set.
SR ポリシーのすべての候補パスが無効になると、SR ポリシーは、いずれかの候補パスで Drop-Upon-Invalid が有効になっているかどうかを確認します。そうである場合、SR ポリシーはドロップ状態に入り、Drop-Upon-Invalid が有効になっている最も優先度の高い候補パスを「アクティブ化」します。ドロップ (D) フラグを設定して PCE に報告する必要がある候補パスは 1 つだけであることに注意してください。
Section 5.8.2 of [RFC8231] allows delegation of an LSP in operationally down state, but at the same time mandates the use of PCReq before sending PCRpt. This document updates Section 5.8.2 of [RFC8231], by making that section of [RFC8231] not applicable to SR Policy LSPs. Thus, when a PCC wants to delegate an SR Policy LSP, it MAY proceed directly to sending PCRpt, without first sending PCReq and waiting for PCRep. This has the advantage of reducing the number of PCEP messages and simplifying the implementation.
[RFC8231] のセクション 5.8.2 では、動作的にダウン状態の LSP の委任が許可されていますが、同時に PCRpt を送信する前に PCReq の使用が義務付けられています。この文書は、[RFC8231] のセクション 5.8.2 を更新し、[RFC8231] のセクションを SR ポリシー LSP に適用しないようにします。したがって、PCC が SR ポリシー LSP を委任したい場合、最初に PCReq を送信して PCRep を待つことなく、直接 PCRpt の送信に進んでもよい(MAY)。これには、PCEP メッセージの数が減り、実装が簡素化されるという利点があります。
Furthermore, a PCEP speaker is not required to support PCReq/PCRep at all for SR Policies. The PCEP speaker can indicate support for PCReq/PCRep via the L-flag in the SRPOLICY-CAPABILITY TLV (see Section 5.1). When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peer MUST NOT be sent PCReq/PCRep messages for SR Policy LSPs. Conversely, when this flag is set, the peer can receive and process PCReq/PCRep messages for SR Policy LSPs.
さらに、PCEP スピーカーは、SR ポリシーに関して PCReq/PCRep をサポートする必要はまったくありません。PCEP スピーカーは、SRPOLICY-CAPABILITY TLV の L フラグを介して PCReq/PCRep のサポートを示すことができます (セクション 5.1 を参照)。このフラグがクリアされている場合、または SRPOLICY-CAPABILITY TLV が存在しない場合、指定されたピアに SR ポリシー LSP の PCReq/PCRep メッセージを送信してはなりません (MUST NOT)。逆に、このフラグが設定されている場合、ピアは SR ポリシー LSP の PCReq/PCRep メッセージを受信して処理できます。
The above applies only to SR Policy LSPs and does not affect other LSP types, such as RSVP-TE LSPs. For other LSP types, Section 5.8.2 of [RFC8231] continues to apply.
上記は SR ポリシー LSP にのみ適用され、RSVP-TE LSP などの他の LSP タイプには影響しません。他の LSP タイプについては、[RFC8231] のセクション 5.8.2 が引き続き適用されます。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <https://www.iana.org/assignments/pcep>.
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリを <https://www.iana.org/assignments/pcep> で管理しています。
This document defines a new Association Type: SR Policy Association. IANA has made the following assignment in the "ASSOCIATION Type Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group:
このドキュメントでは、新しい関連付けタイプである SR ポリシー関連付けを定義します。IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内の「ASSOCIATION Type Field」レジストリに次の割り当てを行いました。
+======+=======================+===========+
| Type | Name | Reference |
+======+=======================+===========+
| 6 | SR Policy Association | RFC 9862 |
+------+-----------------------+-----------+
Table 1
This document defines eight new TLVs for carrying additional information about SR Policy and SR Policy Candidate Paths. IANA has made the following assignments in the existing "PCEP TLV Type Indicators" registry:
この文書では、SR ポリシーおよび SR ポリシー候補パスに関する追加情報を伝送するための 8 つの新しい TLV を定義します。IANA は、既存の「PCEP TLV Type Indicators」レジストリに次の割り当てを行っています。
+=======+============================+===========+
| Value | Description | Reference |
+=======+============================+===========+
| 56 | SRPOLICY-POL-NAME | RFC 9862 |
+-------+----------------------------+-----------+
| 57 | SRPOLICY-CPATH-ID | RFC 9862 |
+-------+----------------------------+-----------+
| 58 | SRPOLICY-CPATH-NAME | RFC 9862 |
+-------+----------------------------+-----------+
| 59 | SRPOLICY-CPATH-PREFERENCE | RFC 9862 |
+-------+----------------------------+-----------+
| 68 | COMPUTATION-PRIORITY | RFC 9862 |
+-------+----------------------------+-----------+
| 69 | EXPLICIT-NULL-LABEL-POLICY | RFC 9862 |
+-------+----------------------------+-----------+
| 70 | INVALIDATION | RFC 9862 |
+-------+----------------------------+-----------+
| 71 | SRPOLICY-CAPABILITY | RFC 9862 |
+-------+----------------------------+-----------+
Table 2
This document defines the following:
この文書では次のことを定義します。
* one new Error-value within the "Mandatory Object Missing" Error-Type,
* 「必須オブジェクトが見つかりません」エラー タイプ内の 1 つの新しいエラー値、
* one new Error-value within the "Reception of an invalid object", and
* 「無効なオブジェクトの受信」内の 1 つの新しいエラー値、および
* two new Error-values within the "Association Error" Error-Type.
* 「関連付けエラー」エラー タイプ内の 2 つの新しいエラー値。
IANA has made the following assignments in the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group.
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「PCEP-ERROR Object Error Types and Values」レジストリに次の割り当てを行っています。
+============+=================+=======================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+=================+=======================+===========+
| 6 | Mandatory | | [RFC5440] |
| | Object Missing | | |
| +-----------------+-----------------------+-----------+
| | | 21: Missing SR Policy | RFC 9862 |
| | | Mandatory TLV | |
| +-----------------+-----------------------+-----------+
| | | 22: Missing SR Policy | RFC 9862 |
| | | Association | |
+------------+-----------------+-----------------------+-----------+
| 10 | Reception of an | | [RFC5440] |
| | invalid object | | |
| +-----------------+-----------------------+-----------+
| | | 44: Missing SRPOLICY- | RFC 9862 |
| | | CAPABILITY TLV | |
+------------+-----------------+-----------------------+-----------+
| 26 | Association | | [RFC8697] |
| | Error | | |
| +-----------------+-----------------------+-----------+
| | | 20: SR Policy | RFC 9862 |
| | | Identifiers Mismatch | |
| +-----------------+-----------------------+-----------+
| | | 21: SR Policy | RFC 9862 |
| | | Candidate Path | |
| | | Identifier Mismatch | |
+------------+-----------------+-----------------------+-----------+
Table 3
A draft version of this document added a new bit in the "TE-PATH-BINDING TLV Flag Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group, which was early allocated by IANA.
この文書のドラフト版では、IANA によって早期に割り当てられた「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの「TE-PATH-BINDING TLV Flag Field」レジストリに新しいビットが追加されました。
IANA has marked the bit position as deprecated.
IANA は、ビット位置を非推奨としてマークしました。
+=====+==================================+===========+
| Bit | Description | Reference |
+=====+==================================+===========+
| 1 | Deprecated (Specified-BSID-only) | RFC 9862 |
+-----+----------------------------------+-----------+
Table 4
IANA has created and now maintains a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Invalidation Operational Flags". New values are to be assigned by "IETF Review" [RFC8126]. Each bit will be tracked with the following qualities:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの下に新しいレジストリを作成し、管理しています。新しいレジストリは「SR ポリシー無効化操作フラグ」と呼ばれます。新しい値は、「IETF Review」[RFC8126] によって割り当てられます。各ビットは次の品質で追跡されます。
* Bit (counting from bit 0 as the most significant bit)
* ビット（ビット0から最上位ビットとして数えます）
* Description
* 説明
* Reference
* 参照
+=====+========================================+===========+
| Bit | Description | Reference |
+=====+========================================+===========+
| 0 - | Unassigned | |
| 6 | | |
+-----+----------------------------------------+-----------+
| 7 | D: Dropping - the LSP is actively | RFC 9862 |
| | dropping traffic as a result of Drop- | |
| | Upon-Invalid behavior being activated. | |
+-----+----------------------------------------+-----------+
Table 5
IANA has created and now maintains a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Invalidation Configuration Flags". New values are to be assigned by "IETF Review" [RFC8126]. Each bit will be tracked with the following qualities:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの下に新しいレジストリを作成し、管理しています。新しいレジストリは「SR ポリシー無効化構成フラグ」と呼ばれます。新しい値は、「IETF Review」[RFC8126] によって割り当てられます。各ビットは次の品質で追跡されます。
* Bit (counting from bit 0 as the most significant bit)
* ビット（ビット0から最上位ビットとして数えます）
* Description
* 説明
* Reference
* 参照
+=======+========================================+===========+
| Bit | Description | Reference |
+=======+========================================+===========+
| 0 - 6 | Unassigned | |
+-------+----------------------------------------+-----------+
| 7 | D: Drop enabled - the Candidate Path | RFC 9862 |
| | has Drop-Upon-Invalid feature enabled. | |
+-------+----------------------------------------+-----------+
Table 6
IANA has created and now maintains a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Capability TLV Flag Field". New values are to be assigned by "IETF Review" [RFC8126]. Each bit will be tracked with the following qualities:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループの下に新しいレジストリを作成し、管理しています。新しいレジストリは「SR Policy Capability TLV Flag Field」と呼ばれます。新しい値は、「IETF Review」[RFC8126] によって割り当てられます。各ビットは次の品質で追跡されます。
* Bit (counting from bit 0 as the most significant bit)
* ビット（ビット0から最上位ビットとして数えます）
* Description
* 説明
* Reference
* 参照
+========+=====================================+===========+
| Bit | Description | Reference |
+========+=====================================+===========+
| 0 - 26 | Unassigned | RFC 9862 |
+--------+-------------------------------------+-----------+
| 27 | Stateless Operation (L-flag) | RFC 9862 |
+--------+-------------------------------------+-----------+
| 28 | Unassigned | RFC 9862 |
+--------+-------------------------------------+-----------+
| 29 | Invalidation (I-flag) | RFC 9862 |
+--------+-------------------------------------+-----------+
| 30 | Explicit NULL Label Policy (E-flag) | RFC 9862 |
+--------+-------------------------------------+-----------+
| 31 | Computation Priority (P-flag) | RFC 9862 |
+--------+-------------------------------------+-----------+
Table 7
The information carried in the newly defined SRPA object and TLVs could provide an eavesdropper with additional information about the SR Policy.
新しく定義された SRPA オブジェクトおよび TLV で伝送される情報は、SR ポリシーに関する追加情報を盗聴者に提供する可能性があります。
The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], [RFC8697], [RFC9256], and [RFC9603] are applicable to this specification.
[RFC5440]、[RFC8231]、[RFC8281]、[RFC8664]、[RFC8697]、[RFC9256]、および [RFC9603] で説明されているセキュリティに関する考慮事項は、この仕様に適用されます。
As per [RFC8231], it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC9325].
[RFC8231] に従って、これらの PCEP 拡張機能は、[RFC9325] の推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ (TLS) [RFC8253] を使用して、同じ管理権限に属する PCE および PCC にわたる認証および暗号化されたセッションでのみアクティブ化できることが推奨されます。
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], [RFC9256], and [RFC9603] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]、[RFC8231]、[RFC8664]、[RFC9256]、および [RFC9603] にリストされているすべての管理要件と考慮事項は、この文書で定義されている PCEP プロトコル拡張に適用されます。さらに、このセクションに記載されている要件と考慮事項が適用されます。
A PCE or PCC implementation MAY allow the capabilities specified in Section 5.1 and the capability for support of an SRPA advertised in the ASSOC-Type-List TLV to be enabled and disabled.
PCE または PCC 実装では、セクション 5.1 で指定された機能と、ASSOC-Type-List TLV でアドバタイズされる SRPA のサポートの機能を有効または無効にすることができます (MAY)。
[PCEP-SRv6-YANG] defines a YANG module with common building blocks for PCEP extensions described in Section 4 of this document.
[PCEP-SRv6-YANG] は、この文書のセクション 4 で説明されている PCEP 拡張の共通構成要素を持つ YANG モジュールを定義します。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440], [RFC8664], and [RFC9256].
この文書で定義されるメカニズムは、[RFC5440]、[RFC8664]、および [RFC9256] にすでにリストされているものに加えて、新たな活性検出および監視要件を示唆するものではありません。
Operation verification requirements already listed in [RFC5440], [RFC8231], [RFC8664], [RFC9256], and [RFC9603] are applicable to mechanisms defined in this document.
[RFC5440]、[RFC8231]、[RFC8664]、[RFC9256]、および [RFC9603] に既にリストされている動作検証要件は、この文書で定義されるメカニズムに適用されます。
An implementation MUST allow the operator to view SR Policy Identifier and SR Policy Candidate Path Identifier advertised in an SRPA object.
実装では、オペレータが SRPA オブジェクトでアドバタイズされる SR ポリシー識別子と SR ポリシー候補パス識別子を表示できるようにしなければなりません (MUST)。
An implementation SHOULD allow the operator to view the capabilities defined in this document advertised by each PCEP peer.
実装では、各 PCEP ピアによってアドバタイズされる、この文書で定義されている機能をオペレーターが表示できるようにする必要があります (SHOULD)。
An implementation SHOULD allow the operator to view LSPs associated with a specific SR Policy Identifier.
実装では、オペレータが特定の SR ポリシー識別子に関連付けられた LSP を表示できるようにする必要があります (SHOULD)。
The PCEP extensions defined in this document do not imply any new requirements on other protocols.
この文書で定義されている PCEP 拡張は、他のプロトコルに対する新しい要件を示唆するものではありません。
The mechanisms defined in [RFC5440], [RFC8231], [RFC9256], and [RFC9603] also apply to the PCEP extensions defined in this document.
[RFC5440]、[RFC8231]、[RFC9256]、および [RFC9603] で定義されているメカニズムは、この文書で定義されている PCEP 拡張にも適用されます。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[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>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
[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>.
[PCEP-MULTIPATH]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Yadav, B., Peng, S., Mishra, G. S., and S.
Sidor, "Path Computation Element Communication Protocol
(PCEP) Extensions for Signaling Multipath Information",
Work in Progress, Internet-Draft, draft-ietf-pce-
multipath-16, 17 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
multipath-16>.
[PCEP-SRv6-YANG]
Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.
Ndifor, "A YANG Data Model for Segment Routing (SR) Policy
and SR in IPv6 (SRv6) support in Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-srv6-yang-08, 14
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pcep-srv6-yang-08>.
[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>.
[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>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/info/rfc9830>.
[RFC9857] Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H.,
and J. Tantsura, "Advertisement of Segment Routing
Policies Using BGP - Link State", RFC 9857, October 2025,
<https://www.rfc-editor.org/info/rfc9857>.
We would like to thank Abdul Rehman, Andrew Stone, Boris Khasanov, Cheng Li, Dhruv Dhody, Gorry Fairhurst, Gyan Mishra, Huaimo Chen, Ines Robles, Joseph Salowey, Ketan Talaulikar, Marina Fizgeer, Mike Bishopm, Praveen Kumar, Robert Sparks, Roman Danyliw, Stephane Litkowski, Tom Petch, Zoey Rose, Xiao Min, and Xiong Quan for their reviews and suggestions.
Abdul Rehman、Andrew Stone、Boris Khasanov、Cheng Li、Dhruv Dhody、Gorry Fairhurst、Gyan Mishra、Huaimo Chen、Ines Robles、Joseph Salowey、Ketan Talaulikar、Marina Fizgeer、Mike Bishopm、Praveen Kumar、Robert Sparks、Roman Danyliw、Stephane Litkowski、Tom Petch、Zoey に感謝します。Rose、Xiao Min、Xiong Quan にレビューと提案をいただきました。
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
10095
China
Email: chengli13@huawei.com
Zafar Ali
Cisco Systems, Inc
Email: zali@cisco.com
Rajesh Melarcode
Cisco Systems, Inc.
2000 Innovation Dr.
Kanata Ontario
Canada
Email: rmelarco@cisco.com
Mike Koldychev
Ciena Corporation
385 Terry Fox Dr.
Kanata Ontario K2K 0L1
Canada
Email: mkoldych@proton.me
Siva Sivabalan
Ciena Corporation
385 Terry Fox Dr.
Kanata Ontario K2K 0L1
Canada
Email: ssivabal@ciena.com
Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3.
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com
Colby Barth
Juniper Networks, Inc.
Email: cbarth@juniper.net
Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: pengshuping@huawei.com
Hooman Bidgoli
Nokia
Email: hooman.bidgoli@nokia.com