Internet Engineering Task Force (IETF) S. Sidor
Request for Comments: 9933 Z. Rose
Updates: 8664, 9603 Cisco Systems, Inc.
Category: Standards Track S. Peng
ISSN: 2070-1721 ZTE Corporation
S. Peng
Huawei Technologies
A. Stone
Nokia
July 2026
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow such extensions.
この文書では、トラフィック エンジニアリング (TE) におけるセグメント識別子 (SID) と SR アルゴリズムの使用に重点を置き、セグメント ルーティング (SR) のサポートを強化するためのパス計算要素通信プロトコル (PCEP) の拡張機能を指定します。SID に関連付けられた SR アルゴリズムは、インテリア ゲートウェイ プロトコル (IGP) で使用されるパス計算アルゴリズムを定義します。これにより、PCEP ピアが SID に関連付けられた SR アルゴリズムを明示的ルート オブジェクト (ERO) およびレコード ルート オブジェクト (RRO) サブオブジェクトにエンコードすることで通知するメカニズムが導入され、パス計算の SR アルゴリズム制約が有効になり、METRIC オブジェクトの新しいメトリック タイプが定義されます。この文書は、そのような拡張を許可するために RFC 8664 および RFC 9603 を更新します。
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/rfc9933.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9933 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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. Motivation
4. Object Formats
4.1. OPEN Object
4.1.1. SR PCE Capability Sub-TLV
4.1.2. SRv6 PCE Capability Sub-TLV
4.2. SR-ERO Subobject
4.2.1. Subobject Extension Block
4.2.2. Guidance for Future Extensions
4.3. SRv6-ERO Subobject
4.4. SR-Algorithm TLV
4.5. Extensions to METRIC Object
4.5.1. Path Min Delay Metric
4.5.2. Path Bandwidth Metric
4.5.3. User-Defined Metric
5. Operation
5.1. ERO and RRO Subobjects
5.1.1. SR-ERO
5.1.2. SRv6-ERO
5.2. SR-Algorithm Constraint
5.2.1. Path Computation for SR-Algorithms 0-127
5.2.2. Path Computation for Flexible Algorithms
5.3. Metric Types
6. Manageability Considerations
6.1. Control of Function and Policy
6.2. Information and Data Models
6.3. Liveness Detection and Monitoring
6.4. Verify Correct Operations
6.5. Requirements on Other Protocols and Functional Components
6.6. Impact on Network Operations
7. Operational Considerations
8. Security Considerations
9. IANA Considerations
9.1. SR Capability Flag
9.2. SRv6 PCE Capability Flag
9.3. SR-ERO Flag
9.4. SRv6-ERO Flag
9.5. PCEP TLV Types
9.6. Metric Types
9.7. PCEP-Error Object
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. [RFC8664] and [RFC9603] specify PCEP extensions to support Segment Routing (SR) over MPLS and IPv6 data planes, respectively.
[RFC5440] は、パス計算クライアント (PCC) とパス計算要素 (PCE) の間、または 1 対の PCE 間の通信のためのパス計算要素通信プロトコル (PCEP) について説明しています。[RFC8664] と [RFC9603] は、それぞれ MPLS および IPv6 データ プレーン上のセグメント ルーティング (SR) をサポートするための PCEP 拡張を指定しています。
This document specifies extensions to PCEP to enhance support for SR Traffic Engineering (TE). Specifically, it focuses on the use of Segment Identifiers (SIDs) and SR-Algorithms. An SR-Algorithm associated with a SID defines the path computation algorithm used by IGPs.
このドキュメントでは、SR トラフィック エンジニアリング (TE) のサポートを強化するための PCEP の拡張機能を指定します。具体的には、セグメント識別子 (SID) と SR アルゴリズムの使用に焦点を当てています。SID に関連付けられた SR アルゴリズムは、IGP で使用されるパス計算アルゴリズムを定義します。
The PCEP extensions specified in this document are as follows:
この文書で指定されている PCEP 拡張子は次のとおりです。
Signaling SR-Algorithm in ERO and RRO:
ERO および RRO のシグナリング SR アルゴリズム:
Mechanisms are introduced for PCEP peers to exchange information about the SR-Algorithm associated with each SID. This includes extending SR-ERO, SR-RRO, SRv6-ERO, and SRv6-RRO subobjects to carry an Algorithm field. This document updates [RFC8664] and [RFC9603] to enable such encoding.
PCEP ピアが各 SID に関連付けられた SR アルゴリズムに関する情報を交換するためのメカニズムが導入されています。これには、アルゴリズム フィールドを伝送するための SR-ERO、SR-RRO、SRv6-ERO、および SRv6-RRO サブオブジェクトの拡張が含まれます。この文書は、そのようなエンコーディングを可能にするために [RFC8664] と [RFC9603] を更新します。
SR-Algorithm Constraint for Path Computation:
パス計算の SR アルゴリズム制約:
Mechanisms are defined for signaling a specific SR-Algorithm as a constraint to the PCE for path computation. This includes a new SR-Algorithm TLV carried in the Label Switched Path Attributes (LSPA) object.
メカニズムは、パス計算のための PCE への制約として特定の SR アルゴリズムを通知するために定義されています。これには、Label Switched Path Attributes (LSPA) オブジェクトで伝送される新しい SR アルゴリズム TLV が含まれます。
Extensions to METRIC object:
METRIC オブジェクトの拡張:
Several new metric types are introduced for the METRIC object to support optimization metrics derived from Flexible Algorithm Definitions (FADs) during Flexible Algorithm path computation; their application is not restricted to Flexible Algorithms, and they may be used with Label Switched Paths (LSPs) set up using different Path Setup Types (PSTs).
フレキシブル アルゴリズム パスの計算中にフレキシブル アルゴリズム定義 (FAD) から導出される最適化メトリクスをサポートするために、METRIC オブジェクトにいくつかの新しいメトリクス タイプが導入されました。それらのアプリケーションはフレキシブル アルゴリズムに限定されず、さまざまなパス セットアップ タイプ (PST) を使用してセットアップされたラベル スイッチド パス (LSP) とともに使用することもできます。
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]: Explicit Route Object (ERO), Label Switched Path Attributes (LSPA), Path Computation Client (PCC), Path Computation Element (PCE), Path Computation Element Communication Protocol (PCEP), PCEP peer, PCEP speaker, Record Route Object (RRO), and Traffic Engineering Database (TED).
この文書では、[RFC5440] で定義されている次の用語を使用します。明示的ルート オブジェクト (ERO)、ラベル スイッチド パス属性 (LSPA)、パス計算クライアント (PCC)、パス計算要素 (PCE)、パス計算要素通信プロトコル (PCEP)、PCEP ピア、PCEP スピーカー、レコード ルート オブジェクト (RRO)、およびトラフィック エンジニアリング データベース (TED)。
This document uses the following term defined in [RFC3031]: Label Switched Path (LSP).
この文書では、[RFC3031] で定義されているラベル スイッチド パス (LSP) という用語を使用します。
This document uses the following term defined in [RFC9479] and [RFC9492]: Application-Specific Link Attributes (ASLA).
この文書では、[RFC9479] および [RFC9492] で定義されている用語、Application-Specific Link Attributes (ASLA) を使用します。
This document uses the following terms defined in [RFC8664]: Node or Adjacency Identifier (NAI) and Segment Routing Database (SR-DB).
この文書では、[RFC8664] で定義されているノードまたは隣接識別子 (NAI) およびセグメント ルーティング データベース (SR-DB) という用語を使用します。
This document uses the following terms defined in [RFC9350]: Flexible Algorithm Definition (FAD) and winning FAD.
この文書では、[RFC9350] で定義されている次の用語を使用します: 柔軟なアルゴリズム定義 (FAD) および勝利 FAD。
Note that 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 PSTs, 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 などの追加の PST のサポートが導入されました [RFC9603]。「LSP」という用語は PCEP 仕様で広く使用されており、この文書の文脈では SR ポリシー内の候補パスを指します。これは SRv6 パスである可能性があります ([RFC8231] で指定されているように LSP オブジェクトを使用して表現されます)。
The term "extension block" is used in this document to identify the additional bytes appended to a PCEP object, which may exist depending on the inclusion of a flag in that object
このドキュメントでは、「拡張ブロック」という用語は、PCEP オブジェクトに追加される追加バイトを識別するために使用されます。これは、そのオブジェクトに含まれるフラグに応じて存在する可能性があります。
The following terminologies are used in this document:
このドキュメントでは次の用語が使用されます。
P2MP:
P2MP:
Point-to-Multipoint
ポイントツーマルチポイント
Subobject Extension Block:
サブオブジェクト拡張ブロック:
Optional, variable-length extension block for SR-ERO and SR-RRO subobjects defined in Section 4.2.1 of this document.
このドキュメントのセクション 4.2.1 で定義されている SR-ERO および SR-RRO サブオブジェクトのオプションの可変長拡張ブロック。
Subobject Extension Block Flag (SEBF):
サブオブジェクト拡張ブロック フラグ (SEBF):
Any flag in the Flags field of SR-ERO or SR-RRO subobjects that is used to signal that the corresponding field is encoded in the Subobject Extension Block.
SR-ERO または SR-RRO サブオブジェクトの Flags フィールド内のフラグ。対応するフィールドがサブオブジェクト拡張ブロックでエンコードされていることを通知するために使用されます。
Existing PCEP specifications lack mechanisms to explicitly signal and negotiate SR-Algorithm capabilities and constraints. This limits the ability of PCEs to make informed path computation decisions based on the specific SR-Algorithms supported and desired within the network. The absence of an explicit SR-Algorithm specification in PCEP messages implied no specific constraint on the SR-Algorithm to be used for path computation, effectively allowing the use of SIDs with any SR-Algorithm.
既存の PCEP 仕様には、SR アルゴリズムの機能と制約を明示的に通知およびネゴシエートするメカニズムがありません。これにより、ネットワーク内でサポートされ、必要とされる特定の SR アルゴリズムに基づいて、情報に基づいてパス計算を決定する PCE の能力が制限されます。PCEP メッセージに明示的な SR アルゴリズム仕様がないことは、パス計算に使用される SR アルゴリズムに特別な制約がないことを意味し、事実上、任意の SR アルゴリズムで SID を使用できるようになります。
A primary motivation for these extensions is to enable the PCE to leverage the path computation logic and topological information derived from IGPs, including Flexible Algorithms. Aligning PCE path computation with these IGP algorithms enables network operators to obtain paths that are congruent with the underlying routing behavior, which can result in segment lists with a reduced number of SIDs. The support for SR-Algorithm constraints in PCE path computation simplifies the deployment and management of Flexible Algorithm paths in multi-domain network scenarios.
これらの拡張の主な動機は、PCE が柔軟なアルゴリズムを含む IGP から派生したパス計算ロジックとトポロジ情報を活用できるようにすることです。PCE パス計算をこれらの IGP アルゴリズムと調整することで、ネットワーク オペレータは、基礎となるルーティング動作と一致するパスを取得できるようになり、その結果、SID の数が減ったセグメント リストが得られる可能性があります。PCE パス計算における SR アルゴリズム制約のサポートにより、マルチドメイン ネットワーク シナリオでのフレキシブル アルゴリズム パスの展開と管理が簡素化されます。
The PCE and the PCC may independently compute SR-TE paths with different SR-Algorithms. This information needs to be exchanged between PCEP peers for purposes such as network monitoring and troubleshooting. In scenarios involving multiple PCEs, when a PCC receives a path from the primary PCE, it needs to be able to report the complete path information, including the SR-Algorithm, to a backup PCE. This is essential for high availability (HA) scenarios, ensuring that the backup PCE can correctly verify Prefix SIDs.
PCE と PCC は、異なる SR-アルゴリズムを使用して SR-TE パスを独立して計算できます。この情報は、ネットワークの監視やトラブルシューティングなどの目的で、PCEP ピア間で交換する必要があります。複数の PCE が関与するシナリオでは、PCC がプライマリ PCE からパスを受信するときに、SR アルゴリズムを含む完全なパス情報をバックアップ PCE にレポートできる必要があります。これは高可用性 (HA) シナリオに不可欠であり、バックアップ PCE がプレフィックス SID を正しく検証できることを保証します。
The introduction of an SR-Algorithm TLV within the LSPA object allows operators to specify SR-Algorithm constraints directly, thereby refining path computations to meet specific needs, such as low-latency paths.
LSPA オブジェクト内に SR アルゴリズム TLV を導入すると、オペレータは SR アルゴリズム制約を直接指定できるため、低遅延パスなどの特定のニーズを満たすようにパス計算を調整できます。
The ability to specify an SR-Algorithm per SID in ERO and RRO is crucial for multiple reasons, for example:
ERO および RRO で SID ごとに SR アルゴリズムを指定できる機能は、次のような複数の理由から重要です。
* SID types without algorithm specified - Certain SID types, such as Binding SIDs (BSIDs) [RFC8402], may not have an SR-Algorithm specified. It may be inaccurate to state that an entire end-to-end path adheres to a specific algorithm if it includes a BSID from another policy.
* アルゴリズムが指定されていない SID タイプ - バインディング SID (BSID) [RFC8402] などの特定の SID タイプには、SR アルゴリズムが指定されていない場合があります。別のポリシーからの BSID が含まれている場合、エンドツーエンド パス全体が特定のアルゴリズムに準拠していると述べるのは不正確である可能性があります。
Note: In SRv6, the BSID can be allocated from an algorithm-specific SRv6 Locator, which will result in the path to that BSID PCC node following that algorithm-specific path. However, the implicit algorithm of BSID is independent of the SR-Algorithm used for the SR Policy associated with that BSID.
注: SRv6 では、アルゴリズム固有の SRv6 ロケーターから BSID を割り当てることができ、その結果、そのアルゴリズム固有のパスに従うその BSID PCC ノードへのパスが生成されます。ただし、BSID の暗黙的アルゴリズムは、その BSID に関連付けられた SR ポリシーに使用される SR アルゴリズムから独立しています。
* Topologies with two IGP domains, each using the same FAD but with differing algorithm numbers.
* 2 つの IGP ドメインを含むトポロジ。それぞれが同じ FAD を使用しますが、アルゴリズム番号が異なります。
The SR-PCE-CAPABILITY sub-TLV is defined in Section 4.1.2 of [RFC8664] to be included in the PATH-SETUP-TYPE-CAPABILITY TLV.
SR-PCE-CAPABILITY サブ TLV は、[RFC8664] のセクション 4.1.2 で定義され、PATH-SETUP-TYPE-CAPABILITY TLV に含まれます。
This document defines the following flag in the SR-PCE-CAPABILITY Sub-TLV Flags field:
この文書では、SR-PCE-CAPABILITY Sub-TLV Flags フィールドで次のフラグを定義します。
S (SR-Algorithm Capability) - bit 5:
S (SR アルゴリズム機能) - ビット 5:
If the S flag is set to 1, a PCEP speaker indicates support for the Algorithm field and the Subobject Extension Block in the SR-ERO subobject described in Section 4.2 and the SR-Algorithm TLV described in Section 4.4 for LSPs set up using PST 1 (Segment Routing) [RFC8664]. It does not indicate support for these extensions for other PSTs. If the S flag is set to 0, behavior reverts to the procedures defined in existing specifications prior to the introduction of this extension.
S フラグが 1 に設定されている場合、PCEP スピーカーは、セクション 4.2 で説明されている SR-ERO サブオブジェクト内のアルゴリズム フィールドとサブオブジェクト拡張ブロック、および PST 1 (セグメント ルーティング) [RFC8664] を使用して設定された LSP のセクション 4.4 で説明されている SR-アルゴリズム TLV のサポートを示します。他の PST に対するこれらの拡張機能のサポートを示すものではありません。S フラグが 0 に設定されている場合、動作はこの拡張機能の導入前に既存の仕様で定義されているプロシージャに戻ります。
The SRv6-PCE-CAPABILITY sub-TLV is defined in Section 4.1.1 of [RFC9603] to be included in the PATH-SETUP-TYPE-CAPABILITY TLV.
SRv6-PCE-CAPABILITY サブ TLV は、[RFC9603] のセクション 4.1.1 で定義され、PATH-SETUP-TYPE-CAPABILITY TLV に含まれます。
This document defines the following flag in the SRv6-PCE-CAPABILITY Sub-TLV Flags field:
このドキュメントでは、SRv6-PCE-CAPABILITY Sub-TLV Flags フィールドで次のフラグを定義します。
SR-Algorithm Capability (S) - bit 13:
SR アルゴリズム機能 (S) - ビット 13:
If the S flag is set to 1, a PCEP speaker indicates support for the Algorithm field in the SRv6-ERO subobject described in Section 4.3 and the SR-Algorithm TLV described in Section 4.4 for LSPs set up using PST 3 (SRv6) [RFC9603]. It does not indicate support for these extensions for other PSTs. If the S flag is set to 0, behavior reverts to the procedures defined in existing specifications prior to the introduction of this extension.
S フラグが 1 に設定されている場合、PCEP スピーカーは、セクション 4.3 で説明されている SRv6-ERO サブオブジェクトのアルゴリズム フィールドと、PST 3 (SRv6) [RFC9603] を使用して設定された LSP のセクション 4.4 で説明されている SR-アルゴリズム TLV のサポートを示します。他の PST に対するこれらの拡張機能のサポートを示すものではありません。S フラグが 0 に設定されている場合、動作はこの拡張機能の導入前に既存の仕様で定義されているプロシージャに戻ります。
This document updates the SR-ERO subobject format defined in Section 4.3.1 of [RFC8664] with a new optional, variable-length Subobject Extension Block field. The block is used to convey additional information, such as the Algorithm field, and is designed to allow future extensibility. Further, a new A flag in the Flags field is introduced as shown in Figure 1.
この文書は、[RFC8664] のセクション 4.3.1 で定義されている SR-ERO サブオブジェクト形式を、新しいオプションの可変長サブオブジェクト拡張ブロック フィールドで更新します。このブロックは、アルゴリズム フィールドなどの追加情報を伝達するために使用され、将来の拡張性を可能にするように設計されています。さらに、図 1 に示すように、Flags フィールドに新しい A フラグが導入されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT | Flags |A|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Subobject Extension Block (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SR-ERO Subobject Format
図 1: SR-ERO サブオブジェクトの形式
A new flag in the Flags field:
「フラグ」フィールドの新しいフラグ:
A (SR-Algorithm Flag):
A (SR アルゴリズム フラグ):
If set by a PCEP speaker, the Subobject Extension Block MUST be included in the SR-ERO subobject, as shown in Figure 1, along with the specified algorithm. The length of this block is variable and determined by subtracting the size of the fixed fields and any optional SID or NAI fields from the total subobject Length. The length of the Subobject Extension Block MUST always be a multiple of 4 bytes. If this flag is set to 0, then either:
PCEP スピーカーによって設定される場合、サブオブジェクト拡張ブロックは、図 1 に示すように、指定されたアルゴリズムとともに SR-ERO サブオブジェクトに含まれなければなりません (MUST)。このブロックの長さは可変で、サブオブジェクトの合計長から固定フィールドとオプションの SID フィールドまたは NAI フィールドのサイズを減算することによって決定されます。サブオブジェクト拡張ブロックの長さは、常に 4 バイトの倍数でなければなりません。このフラグが 0 に設定されている場合は、次のいずれかになります。
* the Subobject Extension Block is not included and processing described in Section 5.2.1 of [RFC8664] applies or
* サブオブジェクト拡張ブロックは含まれておらず、[RFC8664] のセクション 5.2.1 で説明されている処理が適用されるか、
* the Subobject Extension Block is included (due to an SEBF in a future specifications) and the Algorithm field MUST be ignored.
* サブオブジェクト拡張ブロックが含まれており (将来の仕様の SEBF により)、アルゴリズム フィールドは無視されなければなりません (MUST)。
This document updates the SR-ERO subobject validation defined in Section 5.2.1 of [RFC8664] by extending existing validation to include the Subobject Extension Block and the A flag, as follows.
この文書は、次のように既存の検証を拡張してサブオブジェクト拡張ブロックと A フラグを含めることにより、[RFC8664] のセクション 5.2.1 で定義されている SR-ERO サブオブジェクト検証を更新します。
On receiving an SR-ERO subobject, a PCC MUST validate that the Length field, S bit, F bit, A bit, NT field, and any present SEBFs are consistent, as follows:
SR-ERO サブオブジェクトを受信したとき、PCC は、長さフィールド、S ビット、F ビット、A ビット、NT フィールド、および存在する SEBF が次のように一貫していることを検証しなければなりません。
* If the Subobject Extension Block is included (i.e., if any SEBF, such as A or a future flag, is set to 1), the length of the subobject MUST include the size of the entire Subobject Extension Block as determined by the set of SEBFs.
* サブオブジェクト拡張ブロックが含まれる場合 (つまり、A や将来のフラグなどの SEBF が 1 に設定されている場合)、サブオブジェクトの長さには、SEBF のセットによって決定されるサブオブジェクト拡張ブロック全体のサイズが含まれなければなりません (MUST)。
- The minimum size of the Subobject Extension Block is 4 bytes when only a single SEBF (such as A) is set and may be longer (in multiples of 4 bytes) if additional SEBFs are set and require more space.
- 単一の SEBF (A など) のみが設定されている場合、サブオブジェクト拡張ブロックの最小サイズは 4 バイトですが、追加の SEBF が設定され、より多くのスペースが必要な場合は、より長くなる可能性があります (4 バイトの倍数)。
- The total subobject Length is the sum of the sizes of the fixed and optional fields (SID, NAI, etc.) and the total size of the Subobject Extension Block required by the set of SEBFs.
- サブオブジェクトの合計長は、固定フィールドとオプションのフィールド (SID、NAI など) のサイズと、SEBF のセットに必要なサブオブジェクト拡張ブロックの合計サイズの合計です。
- The exact calculation of Length for each NT, S, F, and set of SEBFs is as follows:
- 各 NT、S、F、および SEBF セットの長さの正確な計算は次のとおりです。
o If NT=0, the F bit MUST be 1, the S bit MUST be 0, and the Length MUST be 8 + the size of the Subobject Extension Block.
o NT=0 の場合、F ビットは 1 でなければならず、S ビットは 0 でなければならず、長さは 8 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=1, the F bit MUST be 0.
o NT=1 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 8 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 8 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 12 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 12 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=2, the F bit MUST be 0.
o NT=2 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 20 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 20 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 24 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 24 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=3, the F bit MUST be 0.
o NT=3 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 12 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 12 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 16 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 16 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=4, the F bit MUST be 0.
o NT=4 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 36 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 36 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 40 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 40 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=5, the F bit MUST be 0.
o NT=5 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 20 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 20 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 24 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 24 + サブオブジェクト拡張ブロックのサイズでなければなりません。
o If NT=6, the F bit MUST be 0.
o NT=6 の場合、F ビットは 0 でなければなりません。
+ If the S bit is 1, the Length MUST be 44 + the size of the Subobject Extension Block.
+ S ビットが 1 の場合、長さは 44 + サブオブジェクト拡張ブロックのサイズでなければなりません。
+ If the S bit is 0, the Length MUST be 48 + the size of the Subobject Extension Block.
+ S ビットが 0 の場合、長さは 48 + サブオブジェクト拡張ブロックのサイズでなければなりません。
* If no SEBF (including the A flag defined in this document) is set, the Length value MUST follow the requirements defined in Section 5.2.1 of [RFC8664].
* SEBF (この文書で定義されている A フラグを含む) が設定されていない場合、長さの値は [RFC8664] のセクション 5.2.1 で定義されている要件に従わなければなりません (MUST)。
The Subobject Extension Block is an optional, extensible field in the SR-ERO subobject. Its presence is indicated by the setting of any SEBF in the subobject's Flags field (e.g., the A flag defined in this document or flags defined by future specifications).
サブオブジェクト拡張ブロックは、SR-ERO サブオブジェクト内のオプションの拡張可能なフィールドです。その存在は、サブオブジェクトの Flags フィールド内の SEBF の設定によって示されます (たとえば、このドキュメントで定義されている A フラグ、または将来の仕様で定義されるフラグ)。
Block length and presence:
ブロックの長さと存在:
* If the A flag is set, and no other SEBF is set, the block length MUST be 4.
* A フラグが設定され、他の SEBF が設定されていない場合、ブロック長は 4 でなければなりません。
* The block length is at least 4 bytes when present.
* ブロック長は存在する場合、少なくとも 4 バイトです。
* The block length MUST always be a multiple of 4 bytes.
* ブロック長は常に 4 バイトの倍数でなければなりません。
* The block MUST be included if any SEBF is set in the Flags field.
* Flags フィールドに SEBF が設定されている場合、ブロックを含める必要があります。
* Future extensions may define additional SEBFs and corresponding fields, allowing the block to be increased in size beyond the initial 4 bytes as needed.
* 将来の拡張では、追加の SEBF と対応するフィールドが定義される可能性があり、必要に応じてブロックのサイズを最初の 4 バイトを超えて増やすことができます。
The first 4 bytes of the Subobject Extension Block are described in Figure 2.
サブオブジェクト拡張ブロックの最初の 4 バイトについては、図 2 で説明されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unassigned | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Subobject Extension Block Format
図 2: サブオブジェクト拡張ブロックの形式
Unassigned (24 bits):
未割り当て (24 ビット):
This field is reserved for future use and MUST be set to zero when sending and ignored when receiving.
このフィールドは将来の使用のために予約されており、送信時にはゼロに設定し、受信時には無視しなければなりません。
Algorithm (8 bits):
アルゴリズム (8 ビット):
The SR-Algorithm value from the "IGP Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" registry group (see [IANA-ALGORITHM-TYPES]).
「Interior Gateway Protocol (IGP) Parameters」レジストリ グループの「IGP Algorithm Types」レジストリからの SR-Algorithm 値 ([IANA-ALGORITHM-TYPES] を参照)。
Future extensions SHOULD first use the Unassigned portion of the initial 4 bytes to carry new information. If additional space is needed, the Subobject Extension Block may be extended in 4-byte increments. Each such extension must be indicated by a dedicated SEBF in the Flags field (similar to the A flag) and must be accompanied by capability signaling in an appropriate capability sub-TLV. The specific sub-TLV to be used is not restricted by this specification and may include, for example, the SR-PCE-CAPABILITY sub-TLV, the SRv6-PCE-CAPABILITY sub-TLV, or other capability TLVs, depending on the context of the extension. Interoperability procedures and the precise signaling mechanisms for each new SEBF and its associated capability will be defined by future specifications or procedures describing those extensions.
将来の拡張では、最初に最初の 4 バイトの未割り当て部分を使用して新しい情報を伝える必要があります (SHOULD)。追加のスペースが必要な場合は、サブオブジェクト拡張ブロックを 4 バイト単位で拡張できます。このような各拡張は、Flags フィールドの専用 SEBF (A フラグと同様) によって示される必要があり、適切な機能サブ TLV 内の機能シグナリングを伴う必要があります。使用される特定のサブ TLV は、この仕様によって制限されず、拡張のコンテキストに応じて、たとえば SR-PCE-CAPABILITY サブ TLV、SRv6-PCE-CAPABILITY サブ TLV、または他の機能 TLV が含まれる場合があります。新しい SEBF とその関連機能の相互運用手順と正確なシグナリング メカニズムは、将来の仕様または拡張機能を記述する手順によって定義されます。
When receiving a Subobject Extension Block longer than 4 bytes, receivers that do not recognize or have not negotiated support for additional flags MUST ignore the unknown additional bytes beyond those defined in this document.
4バイトを超えるサブオブジェクト拡張ブロックを受信する場合、追加フラグのサポートを認識しない、または交渉していない受信者は、この文書で定義されているものを超える未知の追加バイトを無視しなければなりません(MUST)。
Future enhancements extending the Subobject Extension Block must:
サブオブジェクト拡張ブロックを拡張する将来の機能拡張では、次のことが必要になります。
* Define a new SEBF in the Flags field to indicate the presence of a new extension and specify the corresponding capability signaling for that extension.
* Flags フィールドで新しい SEBF を定義して、新しい拡張の存在を示し、その拡張に対応する機能シグナリングを指定します。
* Specify which parts of the reserved/extension block are used and how the block length is calculated when their extension is present.
* 予約/拡張ブロックのどの部分が使用されるか、およびその拡張が存在する場合のブロック長の計算方法を指定します。
* Ensure the reserved bits in the initial 4 bytes are used when possible and the block is extended only when additional space is necessary.
* 可能な場合は最初の 4 バイトの予約ビットが使用され、追加のスペースが必要な場合にのみブロックが拡張されるようにしてください。
* Have future extensions define additional SEBFs and corresponding fields, allowing the block to be increased in size beyond the initial 4 bytes as needed.
* 将来の拡張機能では追加の SEBF と対応するフィールドを定義し、必要に応じてブロックのサイズを最初の 4 バイトを超えて増加できるようにします。
Example: Future extension introducing a Z flag and a new Z field (8 bits):
例: Z フラグと新しい Z フィールド (8 ビット) を導入する将来の拡張:
* If the A flag and/or the Z flag are set, the Subobject Extension Block is included. The Z field may use 8 bits of the reserved portion. A field is only considered valid if its corresponding flag is set. For example, if the Z flag is set to 1 but the A flag is set to 0, the Z field is valid but the Algorithm field is ignored.
* A フラグや Z フラグが設定されている場合、サブオブジェクト拡張ブロックが含まれます。Z フィールドは予約部分の 8 ビットを使用できます。フィールドは、対応するフラグが設定されている場合にのみ有効とみなされます。たとえば、Z フラグが 1 に設定されているが、A フラグが 0 に設定されている場合、Z フィールドは有効ですが、アルゴリズム フィールドは無視されます。
* If space beyond the initial 4 bytes is needed, the extension document specifies the new block layout and total length. To simplify parsing, if a flag for such an extension is set, the full extended block is encoded, including the initial 4 bytes, even if the A flag is set to 0.
* 最初の 4 バイトを超えるスペースが必要な場合は、拡張ドキュメントで新しいブロック レイアウトと全長を指定します。解析を簡略化するために、このような拡張のフラグが設定されている場合、A フラグが 0 に設定されている場合でも、最初の 4 バイトを含む完全な拡張ブロックがエンコードされます。
This document updates the SRv6-ERO subobject format defined in Section 4.3.1 of [RFC9603] with the Algorithm field carved out of the Reserved field. Further, a new A flag is defined in the existing Flags field as shown in Figure 3.
この文書は、予約フィールドから切り出されたアルゴリズムフィールドを使用して、[RFC9603] のセクション 4.3.1 で定義されている SRv6-ERO サブオブジェクト形式を更新します。さらに、図 3 に示すように、新しい A フラグが既存の Flags フィールドに定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=40 | Length | NT | Flags |A|V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Algorithm | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID (optional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6-ERO Subobject Format
図 3: SRv6-ERO サブオブジェクトの形式
Flags field:
フラグフィールド:
A (SR-Algorithm Flag): If set by a PCEP speaker, the Algorithm field is included in the SRv6-ERO subobject as specified in Figure 3. If this flag is set to 0, then the Algorithm field is absent and processing described in Section 5.2.1 of [RFC9603] applies.
A (SR-アルゴリズム フラグ): PCEP スピーカーによって設定された場合、図 3 で指定されているように、アルゴリズム フィールドが SRv6-ERO サブオブジェクトに含まれます。このフラグが 0 に設定されている場合、アルゴリズム フィールドは存在せず、[RFC9603] のセクション 5.2.1 で説明されている処理が適用されます。
Reserved (8 bits):
予約済み (8 ビット):
It MUST be set to 0 while sending and ignored on receipt.
送信時には 0 に設定し、受信時には無視しなければなりません。
Algorithm (8 bits):
アルゴリズム (8 ビット):
The SR-Algorithm value from the "IGP Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" registry group.
「Interior Gateway Protocol (IGP) Parameters」レジストリ グループの「IGP Algorithm Types」レジストリの SR-Algorithm 値。
Note: The Subobject Extension Block is applicable to the SRv6-ERO subobject but is not required by this specific specification as existing reserved space is used. When additional space is needed in the SRv6-ERO subobject, the future extensions SHOULD specify the usage of the Subobject Extension Block for the SRv6-ERO subobject.
注: サブオブジェクト拡張ブロックは SRv6-ERO サブオブジェクトに適用できますが、既存の予約スペースが使用されるため、この特定の仕様では必須ではありません。SRv6-ERO サブオブジェクトに追加のスペースが必要な場合、将来の拡張では、SRv6-ERO サブオブジェクトのサブオブジェクト拡張ブロックの使用を指定する必要があります (SHOULD)。
A new TLV for the LSPA object is introduced to carry the SR-Algorithm constraint (Section 5.2). This TLV MUST only be used when PST = 1 or 3 for SR-MPLS and SRv6, respectively. Only the first instance of this TLV MUST be processed; subsequent instances MUST be ignored.
LSPA オブジェクトの新しい TLV は、SR アルゴリズム制約を運ぶために導入されました (セクション 5.2)。この TLV は、SR-MPLS と SRv6 でそれぞれ PST = 1 または 3 の場合にのみ使用しなければなりません (MUST)。この TLV の最初のインスタンスのみを処理しなければなりません (MUST)。後続のインスタンスは無視しなければなりません (MUST)。
The format of the SR-Algorithm TLV is as follows:
SR アルゴリズム 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=66 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SR-Algorithm TLV Format
図 4: SR アルゴリズム TLV フォーマット
Type (16 bits):
タイプ (16 ビット):
66
66
Length (16 bits):
長さ (16 ビット):
4
4
The 32-bit value is formatted as follows.
32 ビット値は次のようにフォーマットされます。
Reserved (16 bits):
予約済み (16 ビット):
MUST be set to 0 by the sender and MUST be ignored by the receiver.
送信者は 0 に設定しなければならず、受信者は無視しなければなりません。
Flags (8 bits):
フラグ (8 ビット):
This document defines the following flag. The other flags MUST be set to 0 by the sender and MUST be ignored by the receiver.
このドキュメントでは次のフラグを定義します。他のフラグは送信者によって 0 に設定されなければならず、受信者によって無視されなければなりません。
S (Strict):
S (厳密):
If set, the path computation at the PCE MUST fail if the specified SR-Algorithm constraint cannot be satisfied. If the S (Strict) bit is unset and the PCE is unable to compute a path that satisfies the specified SR-Algorithm constraint, the PCE MUST attempt to compute a path as if no SR-Algorithm constraint had been requested. This means the PCE may use any available SR-Algorithm for the computation, consistent with the default behavior in the absence of SR-Algorithm constraint.
設定されている場合、指定された SR アルゴリズム制約を満たすことができない場合、PCE でのパス計算は失敗しなければなりません (MUST)。S (厳密) ビットが設定されておらず、PCE が指定された SR アルゴリズム制約を満たすパスを計算できない場合、PCE は SR アルゴリズム制約が要求されていないかのようにパスの計算を試行しなければなりません (MUST)。これは、PCE が、SR アルゴリズム制約がない場合のデフォルトの動作と一致して、計算に利用可能な SR アルゴリズムを使用できることを意味します。
Algorithm (8 bits):
アルゴリズム (8 ビット):
The SR-Algorithm to be used during path computation (see Section 5.2).
パス計算中に使用される SR アルゴリズム (セクション 5.2 を参照)。
The METRIC object is defined in Section 7.8 of [RFC5440]. This document specifies additional types for the METRIC object to enable the encoding of optimization metric types derived from the FAD during Flexible Algorithm path computation (see Section 5.2.2). While these new metric types are defined to support this specific use case, their use is not restricted to Flexible Algorithm path computation or to any specific PST.
METRIC オブジェクトは [RFC5440] のセクション 7.8 で定義されています。この文書は、柔軟なアルゴリズムのパス計算中に FAD から派生した最適化メトリック タイプのエンコードを有効にするために、METRIC オブジェクトの追加のタイプを指定します (セクション 5.2.2 を参照)。これらの新しいメトリック タイプは、この特定の使用例をサポートするために定義されていますが、その使用は柔軟なアルゴリズム パスの計算や特定の PST に限定されません。
* T=22: Path Min Delay metric (Section 4.5.1.1)
* T=22: パス最小遅延メトリック (セクション 4.5.1.1)
* T=23: P2MP Path Min Delay metric (Section 4.5.1.2)
* T=23: P2MP パス最小遅延メトリック (セクション 4.5.1.2)
* T=24: Path Bandwidth metric (Section 4.5.2.1)
* T=24: パス帯域幅メトリック (セクション 4.5.2.1)
* T=25: P2MP Path Bandwidth metric (Section 4.5.2.2)
* T=25: P2MP パス帯域幅メトリック (セクション 4.5.2.2)
* T=128-255: User-defined metric (Section 4.5.3)
* T=128-255: ユーザー定義のメトリック (セクション 4.5.3)
The following terminology is used and expanded along the way.
次の用語が使用され、途中で拡張されます。
* A network comprises a set of N links {Li, (i=1...N)}.
* ネットワークは、N 個のリンクのセット {Li,(i=1...N)} で構成されます。
* A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.
* ポイントツーポイント (P2P) LSP のパス P は、K 個のリンク {Lpi,(i=1...K)} のリストです。
* A P2MP tree T comprises a set of M destinations {Dest_j,(j=1...M)}.
* P2MP ツリー T は、M 個の宛先のセット {Dest_j,(j=1...M)} で構成されます。
[RFC7471] and [RFC8570] define the "Min/Max Unidirectional Link Delay" sub-TLV to advertise the link minimum and maximum delay in microseconds in a 24-bit field.
[RFC7471] および [RFC8570] は、リンクの最小および最大遅延を 24 ビット フィールドでマイクロ秒単位でアドバタイズする「最小/最大単方向リンク遅延」サブ TLV を定義しています。
[RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.2019]).
[RFC5440] は、IEEE 浮動小数点形式でエンコードされた 32 ビットのメトリック値を持つ METRIC オブジェクトを定義しています ([IEEE.754.2019] を参照)。
The encoding for the Path Min Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format.
Path Min Delay メトリック値のエンコードはマイクロ秒単位で定量化され、IEEE 浮動小数点形式でエンコードされます。
For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].
PCEP METRIC オブジェクトで使用するために、24 ビット符号なし整数遅延値は 32 ビット IEEE 浮動小数点値に変換されます。この変換は、[IEEE.754.2019] で指定された手順に従います。
The minimum Link Delay metric is defined in [RFC7471] and [RFC8570] as "Min Unidirectional Link Delay". The Path Min Link Delay metric represents the measured minimum link delay value over a configurable interval.
最小リンク遅延メトリックは、[RFC7471] および [RFC8570] で「最小単方向リンク遅延」として定義されています。パス最小リンク遅延メトリックは、設定可能な間隔で測定された最小リンク遅延値を表します。
The Path Min Delay metric type of the METRIC object in PCEP represents the sum of the Min Link Delay metric of all links along a P2P path.
PCEP の METRIC オブジェクトの Path Min Delay メトリック タイプは、P2P パスに沿ったすべてのリンクの Min Link Delay メトリックの合計を表します。
* A Min Link Delay metric of link L is denoted by D(L).
* リンクＬの最小リンク遅延メトリックは、Ｄ（Ｌ）によって示される。
* A Path Min Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.
* P2P パスのパス最小遅延メトリック P = Sum {D(Lpi), (i=1...K)}。
The P2MP Path Min Delay metric type of the METRIC object in PCEP encodes the Path Min Delay metric for the destination that observes the worst (i.e., highest value) delay metric among all destinations of the P2MP tree.
PCEP の METRIC オブジェクトの P2MP パス最小遅延メトリック タイプは、P2MP ツリーのすべての宛先の中で最悪の (つまり、最高値の) 遅延メトリックを観察する宛先のパス最小遅延メトリックをエンコードします。
* The P2P Path Min Delay metric of the path to destination Dest_j is denoted by PMDM(Dest_j).
* 宛先 Dest_j へのパスの P2P パス最小遅延メトリックは、PMDM(Dest_j) で示されます。
* The P2MP Path Min Delay metric for the P2MP tree T = Maximum{PMDM(Dest_j), (j=1...M)}.
* P2MP ツリーの P2MP パス最小遅延メトリック T = Maximum{PMDM(Dest_j), (j=1...M)}。
Section 4 of [RFC9843] defines a new metric type, "Bandwidth metric", which may be advertised in their link metric advertisements.
[RFC9843] のセクション 4 では、リンク メトリック アドバタイズメントでアドバタイズできる新しいメトリック タイプ「帯域幅メトリック」を定義しています。
When performing Flexible Algorithm path computation as described in Section 5.2.2, procedures described in Sections 4.1 and 5 from [RFC9843] MUST be followed with automatic metric calculation.
セクション 5.2.2 で説明されている柔軟なアルゴリズムのパス計算を実行する場合、[RFC9843] のセクション 4.1 および 5 で説明されている手順に自動メトリック計算を従わなければなりません (MUST)。
For path computations in contexts other than Flexible Algorithm (including PSTs other than 1 or 3 for SR-MPLS and SRv6, respectively), if the Generic Metric sub-TLV with the Bandwidth metric type is not advertised for a link, the PCE implementation MAY apply a local policy to derive a metric value (similar to the procedures in Sections 4.1.3 and 4.1.4 of [RFC9843]) or the link MAY be treated as if the metric value is unavailable (e.g., by using a default value). If the Bandwidth metric value is advertised for a link, the PCE MUST use the advertised value to compute the path metric in accordance with Sections 4.5.2.1 and 4.5.2.2.
フレキシブル アルゴリズム以外のコンテキスト (SR-MPLS および SRv6 のそれぞれ 1 または 3 以外の PST を含む) でのパス計算の場合、帯域幅メトリック タイプを持つ汎用メトリック サブ TLV がリンクに対してアドバタイズされていない場合、PCE 実装は、メトリック値を導出するローカル ポリシーを適用してもよい(MAY) (セクション 4.1.3 および 4.1.4 の手順と同様)。[RFC9843])、またはリンクは、メトリック値が利用できないかのように扱われてもよい(たとえば、デフォルト値を使用することによって)。帯域幅メトリック値がリンクに対してアドバタイズされる場合、PCE は、セクション 4.5.2.1 および 4.5.2.2 に従って、アドバタイズされた値を使用してパス メトリックを計算しなければなりません (MUST)。
The Path Bandwidth metric value is encoded in IEEE floating point format (see [IEEE.754.2019]).
パス帯域幅メトリック値は、IEEE 浮動小数点形式でエンコードされます ([IEEE.754.2019] を参照)。
For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].
PCEP METRIC オブジェクトで使用するために、24 ビット符号なし整数遅延値は 32 ビット IEEE 浮動小数点値に変換されます。この変換は、[IEEE.754.2019] で指定された手順に従います。
The Path Bandwidth metric type of the METRIC object in PCEP represents the sum of the Bandwidth metric of all links along a P2P path.
PCEP の METRIC オブジェクトのパス帯域幅メトリック タイプは、P2P パスに沿ったすべてのリンクの帯域幅メトリックの合計を表します。
Note: The link Bandwidth metric utilized in the formula may be the original metric advertised on the link, which may have a value inversely proportional to the link capacity.
注: 式で使用されるリンク帯域幅メトリックは、リンク上でアドバタイズされる元のメトリックである可能性があり、リンク容量に反比例する値を持つ可能性があります。
* A Bandwidth metric of link L is denoted by B(L).
* リンクＬの帯域幅メトリックはＢ（Ｌ）で表される。
* A Path Bandwidth metric for the P2P path P = Sum {B(Lpi), (i=1...K)}.
* P2P パスのパス帯域幅メトリック P = Sum {B(Lpi), (i=1...K)}。
The Bandwidth metric type of the METRIC object in PCEP encodes the Path Bandwidth metric for the destination that observes the worst Bandwidth metric among all destinations of the P2MP tree.
PCEP の METRIC オブジェクトの帯域幅メトリック タイプは、P2MP ツリーのすべての宛先の中で最も悪い帯域幅メトリックを観察する宛先のパス帯域幅メトリックをエンコードします。
* The P2P Bandwidth metric of the path to destination Dest_j is denoted by BM(Dest_j).
* 宛先 Dest_j へのパスの P2P 帯域幅メトリックは、BM(Dest_j) で示されます。
* The P2MP Path Bandwidth metric for the P2MP tree T = Maximum{BM(Dest_j), (j=1...M)}.
* P2MP ツリーの P2MP パス帯域幅メトリック T = Maximum{BM(Dest_j), (j=1...M)}。
Section 2 of [RFC9843] defined a new metric type range for "User-defined metric", which may be advertised in their link metric advertisements. These are user defined and can be assigned by an operator for local use.
[RFC9843] のセクション 2 は、リンク メトリック アドバタイズメントでアドバタイズできる「ユーザー定義メトリック」の新しいメトリック タイプ範囲を定義しました。これらはユーザー定義であり、オペレーターがローカルで使用するために割り当てることができます。
User-defined metric values are encoded using the IEEE floating point format (see [IEEE.754.2019]).
ユーザー定義のメトリック値は、IEEE 浮動小数点形式を使用してエンコードされます ([IEEE.754.2019] を参照)。
For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].
PCEP METRIC オブジェクトで使用するために、24 ビット符号なし整数遅延値は 32 ビット IEEE 浮動小数点値に変換されます。この変換は、[IEEE.754.2019] で指定された手順に従います。
The metric type range was chosen to allow mapping with values assigned in the "IGP Metric-Type" registry. For example, the User-defined metric type 130 of the METRIC object in PCEP can represent the sum of the User-defined metric 130 of all links along a P2P path.
メトリック タイプの範囲は、「IGP Metric-Type」レジストリで割り当てられた値とのマッピングを可能にするために選択されました。例えば、ＰＣＥＰ内のＭＥＴＲＩＣオブジェクトのユーザ定義メトリックタイプ１３０は、Ｐ２Ｐパスに沿ったすべてのリンクのユーザ定義メトリック１３０の合計を表すことができる。
User-defined metrics are equally applicable to P2P and P2MP paths.
ユーザー定義のメトリックは、P2P パスと P2MP パスに同様に適用できます。
The PCEP extensions defined in Sections 5.1 and 5.2 of this document MUST NOT be used unless both PCEP speakers have indicated support by setting the S flag in the Path Setup Type sub-TLV corresponding to the PST of the LSP. If this condition is not met, the receiving PCEP speaker MUST respond with a PCErr message with Error-Type 19 (Invalid Operation) and Error-value 33 (Attempted use of SR-Algorithm without advertised capability).
この文書のセクション 5.1 および 5.2 で定義されている PCEP 拡張は、両方の PCEP スピーカーが LSP の PST に対応するパス セットアップ タイプ サブ TLV に S フラグを設定してサポートを示していない限り、使用してはなりません (MUST NOT)。この条件が満たされない場合、受信側 PCEP スピーカーは、エラー タイプ 19 (無効な操作) およびエラー値 33 (アドバタイズされた機能なしの SR アルゴリズムの使用の試み) を含む PCErr メッセージで応答しなければなりません (MUST)。
The SR-Algorithm used in this document refers to a complete range of SR-Algorithm values (0-255) if a specific section does not specify otherwise. Valid SR-Algorithm values are defined in the "IGP Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" registry group. Refer to Section 3.1.1 of [RFC8402] and [RFC9256] for the definition of SR-Algorithm in SR. [RFC8665] and [RFC8667] describe the use of the SR-Algorithm in IGP. Note that some RFCs refer to SR-Algorithm with different names, for example, "Prefix-SID Algorithm" and "SR Algorithm".
このドキュメントで使用される SR アルゴリズムは、特定のセクションで特に指定がない限り、SR アルゴリズム値の完全な範囲 (0 ～ 255) を指します。有効な SR アルゴリズム値は、「Interior Gateway Protocol (IGP) Parameters」レジストリ グループの「IGP Algorithm Types」レジストリで定義されています。SR における SR アルゴリズムの定義については、[RFC8402] および [RFC9256] のセクション 3.1.1 を参照してください。[RFC8665] および [RFC8667] では、IGP での SR アルゴリズムの使用について説明しています。一部の RFC では、「プレフィックス SID アルゴリズム」や「SR アルゴリズム」など、異なる名前で SR アルゴリズムを参照していることに注意してください。
If a PCC receives the Algorithm field in the ERO subobject within PCInitiate, PCUpd, or PCRep messages and the path received from those messages is being included in the ERO of PCRpt message, then the PCC MUST include the Algorithm field in the encoded subobjects with the received SR-Algorithm value.
PCC が PCInitiate、PCUpd、または PCRep メッセージ内の ERO サブオブジェクトの Algorithm フィールドを受信し、それらのメッセージから受信したパスが PCRpt メッセージの ERO に含まれている場合、PCC は、受信した SR-Algorithm 値を持つ符号化されたサブオブジェクトに Algorithm フィールドを含めなければなりません。
As per [RFC8664], the format of the SR-RRO subobject is the same as that of the SR-ERO subobject but without the L flag; therefore, the SR-RRO subobject may also carry the A flag and Algorithm field in the Subobject Extension Block. Similarly, as per [RFC9603], the format of the SRv6-RRO subobject is the same as that of the SRv6-ERO subobject but without the L flag; therefore, the SRv6-RRO subobject may also carry the A flag and Algorithm field.
[RFC8664] に従って、SR-RRO サブオブジェクトの形式は SR-ERO サブオブジェクトの形式と同じですが、L フラグがありません。したがって、SR-RRO サブオブジェクトは、サブオブジェクト拡張ブロック内の A フラグとアルゴリズム フィールドも保持する可能性があります。同様に、[RFC9603] に従って、SRv6-RRO サブオブジェクトの形式は SRv6-ERO サブオブジェクトの形式と同じですが、L フラグがありません。したがって、SRv6-RRO サブオブジェクトには、A フラグとアルゴリズム フィールドも含まれる場合があります。
A PCEP speaker MAY set the A flag and include the Algorithm field as part of the Subobject Extension Block in an SR-ERO subobject if the S flag has been advertised in the SR-PCE-CAPABILITY sub-TLV by both PCEP speakers.
両方の PCEP スピーカーによって SR-PCE-CAPABILITY サブ TLV で S フラグがアドバタイズされている場合、PCEP スピーカーは A フラグを設定し、SR-ERO サブオブジェクトのサブオブジェクト拡張ブロックの一部としてアルゴリズム フィールドを含めてもよい(MAY)。
If the PCEP peer receives an SR-ERO subobject with the A flag set but the S flag was not advertised in SR-PCE-CAPABILITY sub-TLV, then it MUST consider the entire ERO as invalid, as described in Section 5.2.1 of [RFC8664].
PCEP ピアが A フラグが設定された SR-ERO サブオブジェクトを受信したが、S フラグが SR-PCE-CAPABILITY サブ TLV でアドバタイズされなかった場合、[RFC8664] のセクション 5.2.1 で説明されているように、ERO 全体を無効と見なされなければなりません (MUST)。
The Subobject Extension Block field in the SR-ERO subobject MUST be included after the optional SID, NAI, or SID structure, and the length of the SR-ERO subobject MUST be increased by the size of the Subobject Extension Block, as determined by the set of SEBFs.
SR-ERO サブオブジェクトのサブオブジェクト拡張ブロック フィールドは、オプションの SID、NAI、または SID 構造の後に含まれなければなりません (MUST)。また、SR-ERO サブオブジェクトの長さは、SEBF のセットによって決定されるサブオブジェクト拡張ブロックのサイズだけ増加しなければなりません (MUST)。
If the length and the A flag are not consistent, as specified in Section 4.2, the PCEP peer MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
セクション 4.2 で規定されているように、長さと A フラグが一致しない場合、PCEP ピアは ERO 全体を無効とみなしなければならず、Error-Type = 10 (「無効なオブジェクトの受信」) および Error-value = 11 (「不正なオブジェクト」) の PCErr メッセージを送信しなければなりません。
If the SID value is absent (S flag is set to 1), the NAI value is present (F flag is set to 0), and the Algorithm field is set (the A flag is set to 1), the PCC is responsible for choosing the SRv6-SID value based on values specified in the NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID").
SID 値が存在せず (S フラグが 1 に設定されている)、NAI 値が存在し (F フラグが 0 に設定されている)、アルゴリズム フィールドが設定されている (A フラグが 1 に設定されている) 場合、PCC は NAI フィールドとアルゴリズム フィールドで指定された値に基づいて SRv6-SID 値を選択する責任があります。PCC が SR-DB で SID インデックスを見つけられない場合、Error-Type = 10 (「無効なオブジェクトの受信」) および Error-value = 14 (「不明な SID」) の PCErr メッセージを送信しなければなりません。
A PCEP speaker MAY set the A flag and include the Algorithm field in an SRv6-ERO subobject if the S flag has been advertised in SRv6-PCE-CAPABILITY sub-TLV by both PCEP speakers.
両方の PCEP スピーカーによって SRv6-PCE-CAPABILITY サブ TLV で S フラグがアドバタイズされている場合、PCEP スピーカーは A フラグを設定し、SRv6-ERO サブオブジェクトに Algorithm フィールドを含めてもよい(MAY)。
If the PCEP peer receives an SRv6-ERO subobject with the A flag set or with the SR-Algorithm included, but the S flag was not advertised in SRv6-PCE-CAPABILITY sub-TLV, then it MUST consider the entire ERO as invalid, as described in Section 5.2.1 of [RFC8664].
PCEP ピアが、A フラグが設定されている、または SR アルゴリズムが含まれている SRv6-ERO サブオブジェクトを受信したが、S フラグが SRv6-PCE-CAPABILITY サブ TLV でアドバタイズされていない場合、[RFC8664] のセクション 5.2.1 で説明されているように、ERO 全体を無効と見なされなければなりません (MUST)。
The Algorithm field in the SRv6-ERO subobject MUST be included in the position specified in Section 4.3; the length of the SRv6-ERO subobject is not impacted by the inclusion of the Algorithm field.
SRv6-ERO サブオブジェクトの Algorithm フィールドは、セクション 4.3 で指定された位置に含めなければなりません (MUST)。SRv6-ERO サブオブジェクトの長さは、Algorithm フィールドを含めても影響を受けません。
If the SRv6-SID value is absent (S flag is set to 1), the NAI value is present (F flag is n), and the Algorithm field is set (the A flag is set to 1), the PCC is responsible for choosing the SRv6-SID value based on values specified in the NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID").
SRv6-SID 値が存在せず (S フラグが 1 に設定されている)、NAI 値が存在し (F フラグが n)、アルゴリズム フィールドが設定されている (A フラグが 1 に設定されている) 場合、PCC は NAI フィールドとアルゴリズム フィールドで指定された値に基づいて SRv6-SID 値を選択する責任があります。PCC が SR-DB で SID インデックスを見つけられない場合、Error-Type = 10 (「無効なオブジェクトの受信」) および Error-value = 14 (「不明な SID」) の PCErr メッセージを送信しなければなりません。
To signal a specific SR-Algorithm constraint to the PCE, the headend MUST encode the SR-Algorithm TLV inside the LSPA object.
特定の SR アルゴリズム制約を PCE に通知するには、ヘッドエンドは LSPA オブジェクト内で SR アルゴリズム TLV をエンコードしなければなりません (MUST)。
If a PCC receives an LSPA object with the SR-Algorithm TLV as part of PCInitiate or PCUpd messages, then it MUST include an LSPA object with the SR-Algorithm TLV in a PCRpt message as part of intended-attribute-list.
PCC が PCInitiate または PCUpd メッセージの一部として SR アルゴリズム TLV を持つ LSPA オブジェクトを受信した場合、PCC は SR アルゴリズム TLV を持つ LSPA オブジェクトを意図された属性リストの一部として PCRpt メッセージに含めなければなりません (MUST)。
If a PCE receives an LSPA object with the SR-Algorithm TLV in PCRpt or PCReq, then it MUST include the LSPA object with the SR-Algorithm TLV in a PCUpd message, or a PCRep message in case of an unsuccessful path computation based on rules described in Section 7.11 of [RFC5440].
PCE が PCRpt または PCReq で SR アルゴリズム TLV を持つ LSPA オブジェクトを受信した場合、PCUpd メッセージ、または [RFC5440] のセクション 7.11 に記載されている規則に基づくパス計算が失敗した場合の PCRep メッセージに SR アルゴリズム TLV を持つ LSPA オブジェクトを含めなければなりません (MUST)。
A PCEP peer that did not advertise the S flag in the Path Setup Type sub-TLV corresponding to the LSP's PST MUST ignore the SR-Algorithm TLV on receipt.
LSP の PST に対応するパス セットアップ タイプのサブ TLV で S フラグをアドバタイズしなかった PCEP ピアは、受信時に SR アルゴリズム TLV を無視しなければなりません (MUST)。
The PCE MUST NOT use Prefix SIDs associated with an SR-Algorithm other than the one specified in the SR-Algorithm constraint. If a protected Adjacency SID is used without an associated SR-Algorithm, there is a risk that the backup path may fail to forward traffic over parts of the topology that are not included in the specified SR-Algorithm. Consequently, it is NOT RECOMMENDED to use protected Adjacency SIDs without an explicitly specified SR-Algorithm. If an Adjacency SID has an associated SR-Algorithm, the PCE MUST ensure that the SR-Algorithm matches the one specified in the SR-Algorithm constraint.
PCE は、SR アルゴリズム制約で指定されたもの以外の SR アルゴリズムに関連付けられたプレフィックス SID を使用してはなりません (MUST NOT)。保護された隣接 SID が SR アルゴリズムに関連付けられずに使用される場合、バックアップ パスが、指定された SR アルゴリズムに含まれていないトポロジの部分を介してトラフィックを転送できない可能性があります。したがって、明示的に指定された SR アルゴリズムなしで保護された隣接 SID を使用することは推奨されません。隣接 SID に SR アルゴリズムが関連付けられている場合、PCE は SR アルゴリズムが SR アルゴリズム制約で指定されたものと一致することを確認しなければなりません (MUST)。
Other SID types, such as BSIDs, are allowed. Furthermore, the inclusion of a path BSID from another policy is permitted only if the path associated with that policy fully satisfies all the constraints of the current path computation.
BSID などの他の SID タイプも許可されます。さらに、別のポリシーからのパス BSID を含めることは、そのポリシーに関連付けられたパスが現在のパス計算の制約をすべて完全に満たす場合にのみ許可されます。
The specified SR-Algorithm constraint is applied to the end-to-end SR Policy path. Using different SR-Algorithm constraints or using winning FAD with different optimization metrics or constraints for the same SR-Algorithm in each domain or part of the topology in single path computation is out of the scope of this document.
指定された SR アルゴリズム制約は、エンドツーエンドの SR ポリシー パスに適用されます。シングル パス計算における各ドメインまたはトポロジの一部で、異なる SR アルゴリズム制約を使用したり、同じ SR アルゴリズムに対して異なる最適化メトリクスや制約を備えた最適な FAD を使用したりすることは、このドキュメントの範囲外です。
If the PCE is unable to find a path with the given SR-Algorithm constraint, it does not support a combination of specified constraints, or if the FAD contains constraints, optimization metrics, or other attributes, which the PCE does not support or recognize, it MUST use an empty ERO in PCInitiate for LSP instantiation, a PCUpd message if an update is required, or a NO-PATH object in PCRep to indicate that it was not able to find the valid path.
PCE が指定された SR アルゴリズム制約を持つパスを見つけることができない場合、指定された制約の組み合わせをサポートしていない場合、あるいは PCE がサポートまたは認識していない制約、最適化メトリック、またはその他の属性が FAD に含まれている場合、PCE は、LSP インスタンス化には PCInitiate の空の ERO、更新が必要な場合は PCUpd メッセージ、または有効なパスを見つけられなかったことを示すために PCRep の NO-PATH オブジェクトを使用しなければなりません (MUST)。
If the Algorithm field value is in the range 128-255, the PCE MUST perform path computation according to the Flexible Algorithm procedures outlined in Section 5.2.2. Otherwise, the PCE MUST adhere to the path computation procedures with SID filtering as defined in Section 5.2.1.
Algorithm フィールドの値が 128 ～ 255 の範囲にある場合、PCE はセクション 5.2.2 で概説されている柔軟なアルゴリズム手順に従ってパス計算を実行しなければなりません (MUST)。それ以外の場合、PCE はセクション 5.2.1 で定義されている SID フィルタリングを使用したパス計算手順に従わなければなりません (MUST)。
If the NO-PATH object is included in PCRep, then the PCE MAY include the SR-Algorithm TLV to indicate constraint, which cannot be satisfied as described in Section 7.5 of [RFC5440].
NO-PATH オブジェクトが PCRep に含まれる場合、PCE には、[RFC5440] のセクション 7.5 に記載されているように満たせない制約を示すための SR-Algorithm TLV を含めてもよい[MAY]。
SR-Algorithm does not replace the objective function defined in [RFC5541].
SR アルゴリズムは、[RFC5541] で定義されている目的関数を置き換えるものではありません。
The SR-Algorithm constraint acts as a filter, restricting which SIDs may be used as a result of the path computation function. Path computation is done based on optimization metric type and constraints specified in the PCEP message received from the PCC.
SR アルゴリズム制約はフィルターとして機能し、パス計算関数の結果として使用できる SID を制限します。パスの計算は、PCC から受信した PCEP メッセージで指定された最適化メトリック タイプと制約に基づいて行われます。
The mechanism described in this section is applicable only to SR-Algorithm values in the range 0-127. It is not applicable to Flexible Algorithms (range 128-255), which are handled as described in Section 5.2.2. Within the 0-127 range, currently defined algorithms are 0 (Shortest Path First (SPF)) and 1 (Strict-SPF), as introduced in Section 3.1.1 of [RFC8402]. Future algorithms defined within this range that do not require explicit PCEP extensions beyond the SR-Algorithm TLV may also utilize this SID filtering approach. If a PCE implementation receives a request with an SR-Algorithm value in the 0-127 range that it does not support for path computation, it MUST reject the PCEP message and send a PCErr message with Error-Type 19 (Invalid Operation) and Error-value 34 (Unsupported combination of constraints).
このセクションで説明するメカニズムは、0 ～ 127 の範囲の SR アルゴリズム値にのみ適用されます。これは、セクション 5.2.2 で説明されているように処理される柔軟なアルゴリズム (範囲 128 ～ 255) には適用されません。[RFC8402] のセクション 3.1.1 で導入されているように、0 ～ 127 の範囲内で、現在定義されているアルゴリズムは 0 (Shortest Path First (SPF)) と 1 (Strict-SPF) です。SR アルゴリズム TLV を超える明示的な PCEP 拡張を必要としない、この範囲内で定義される将来のアルゴリズムも、この SID フィルタリング アプローチを利用する可能性があります。PCE 実装が、パス計算でサポートしていない 0 ～ 127 の範囲の SR アルゴリズム値を持つリクエストを受信した場合、PCEP メッセージを拒否し、エラー タイプ 19 (無効な操作) およびエラー値 34 (サポートされていない制約の組み合わせ) を含む PCErr メッセージを送信しなければなりません (MUST)。
This section is applicable only to the Flexible Algorithms range of SR-Algorithm values. The PCE performs Flexible Algorithm path computation based on topology information stored in its TED [RFC5440]. The TED is expected to be populated with necessary information, including Flexible Algorithm Definitions (FADs), node participation, and ASLA-specific link attributes, through standard mechanisms, such as IGPs with Traffic Engineering extensions or BGP - Link State (BGP-LS) [RFC9552].
このセクションは、SR アルゴリズム値のフレキシブル アルゴリズム範囲にのみ適用されます。PCE は、TED [RFC5440] に格納されているトポロジー情報に基づいて、柔軟なアルゴリズムのパス計算を実行します。TED には、トラフィック エンジニアリング拡張機能を備えた IGP や BGP - リンク ステート (BGP-LS) [RFC9552] などの標準メカニズムを通じて、柔軟なアルゴリズム定義 (FAD)、ノード参加、ASLA 固有のリンク属性などの必要な情報が入力されることが期待されています。
The PCE must follow the IGP Flexible Algorithm path computation logic as described in [RFC9350]. This includes performing the FAD selection as described in Section 5.3 of [RFC9350] and other sections, determining the topology associated with specific a Flexible Algorithm based on the FAD, the node participation (Section 11 of [RFC9350]), using ASLA-specific link attributes (Section 12 of [RFC9350]), and applying other rules for Flexible Algorithm path calculation (Section 13 of [RFC9350]). While [RFC9350] defines the base procedures for IGP Flexible Algorithms, these procedures are further extended by other documents, such as [RFC9843]; a PCE implementation may need to support these IGP extensions to allow use of specific constraints in FAD. [RFC9917] created an IANA registry called "IGP Flex-Algorithm Path Computation Rules" <https://www.iana.org/assignments/igp-parameters> within the "Interior Gateway Protocol (IGP) Parameters" registry group with the ordered set of rules that MUST be used to prune links from the topology during the Flexible Algorithm path computation.
PCE は、[RFC9350] で説明されている IGP フレキシブル アルゴリズム パス計算ロジックに従わなければなりません。これには、[RFC9350] のセクション 5.3 および他のセクションで説明されている FAD 選択の実行、FAD に基づく特定のフレキシブル アルゴリズムに関連付けられたトポロジーの決定、ノード参加 ([RFC9350] のセクション 11)、ASLA 固有のリンク属性の使用 ([RFC9350] のセクション 12)、およびフレキシブル アルゴリズム パス計算のための他のルールの適用 (RFC9350 のセクション 13) が含まれます。[RFC9350])。[RFC9350] は IGP フレキシブル アルゴリズムの基本手順を定義していますが、これらの手順は [RFC9843] などの他の文書によってさらに拡張されています。FAD で特定の制約を使用できるようにするには、PCE 実装でこれらの IGP 拡張機能をサポートする必要がある場合があります。[RFC9917] は、「Interior Gateway Protocol (IGP) Parameters」レジストリ グループ内に「IGP Flex-Algorithm Path Computation Rules」<https://www.iana.org/assignments/igp-parameters> と呼ばれる IANA レジストリを作成し、フレキシブル アルゴリズム パスの計算中にトポロジからリンクをプルーニングするために使用しなければならない順序付けられたルールのセットを設定しました。
The PCE MUST optimize the computed path based on the metric type specified in the FAD. The optimization metric type included in PCEP messages from the PCC MUST be ignored. The PCE MUST use the metric type from the FAD in messages sent to the PCC unless that metric type is not defined in PCEP or not supported by the PCEP peer. It is allowed to use SID types other than Prefix SID (e.g., Adjacency or BSID) but only from nodes participating in the specified SR-Algorithm.
PCE は、FAD で指定されたメトリック タイプに基づいて計算されたパスを最適化する必要があります。PCC からの PCEP メッセージに含まれる最適化メトリック タイプは無視しなければなりません (MUST)。PCE は、そのメトリック タイプが PCEP で定義されていない場合、または PCEP ピアでサポートされていない場合を除き、PCC に送信されるメッセージで FAD からのメトリック タイプを使用しなければなりません (MUST)。プレフィックス SID 以外の SID タイプ (隣接関係や BSID など) の使用は許可されますが、指定された SR アルゴリズムに参加しているノードからのみ使用できます。
There are corresponding metric types in PCEP for IGP and TE metrics from FAD introduced in [RFC9350], but there were no corresponding metric types defined for "Min Unidirectional Link Delay" from [RFC9350] and "Bandwidth metric" and "User-defined metric" from [RFC9843]. Section 4.5 of this document introduces them. Note that the defined "Path Bandwidth metric" is accumulative and is different from the BANDWIDTH object defined in [RFC5440].
PCEP には、[RFC9350] で導入された FAD の IGP および TE メトリックに対応するメトリック タイプがありますが、[RFC9350] の「最小単方向リンク遅延」と、[RFC9843] の「帯域幅メトリック」および「ユーザー定義メトリック」には、対応するメトリック タイプが定義されていませんでした。このドキュメントのセクション 4.5 でそれらを紹介します。定義された「パス帯域幅メトリック」は累積的であり、[RFC5440] で定義されている BANDWIDTH オブジェクトとは異なることに注意してください。
The PCE MUST use the constraints specified in the FAD and also constraints (except optimization metric type) directly included in PCEP messages from the PCC. The PCE implementation MAY decide to ignore specific constraints received from the PCC based on existing processing rules for PCEP objects and TLVs, e.g., the P flag described in Section 7.2 of [RFC5440] and processing rules described in [RFC9753]. If the PCE does not support a specified combination of constraints, it MUST fail path computation and respond with a PCEP message with a PCInitiate or PCUpd message with an empty ERO or PCRep with NO-PATH object. The PCC MUST NOT include constraints from the FAD in the PCEP message sent to the PCE, as it can result in undesired behavior in various cases. The PCE SHOULD NOT include constraints from the FAD in PCEP messages sent to the PCC.
PCE は、FAD で指定された制約と、PCC からの PCEP メッセージに直接含まれる制約 (最適化メトリック タイプを除く) を使用しなければなりません (MUST)。PCE 実装は、PCEP オブジェクトと TLV の既存の処理規則 ([RFC5440] のセクション 7.2 に記述されている P フラグや [RFC9753] に記述されている処理規則など) に基づいて、PCC から受け取った特定の制約を無視することを決定してもよい(MAY)。PCE が指定された制約の組み合わせをサポートしない場合、PCE はパス計算に失敗し、空の ERO または NO-PATH オブジェクトを含む PCRep を含む PCInitiate または PCUpd メッセージを含む PCEP メッセージで応答しなければなりません (MUST)。PCC は、さまざまな場合に望ましくない動作を引き起こす可能性があるため、PCE に送信される PCEP メッセージに FAD からの制約を含めてはなりません (MUST NOT)。PCE は、PCC に送信される PCEP メッセージに FAD からの制約を含めるべきではありません (SHOULD NOT)。
The combinations of the constraints specified in the FAD and constraints directly included in PCEP messages from the PCC may decrease the chance that Flexible-Algorithm-specific Prefix SIDs represent an optimal path while satisfying all specified constraints; as a result, a longer SID list may be required for the computed path. Adding more constraints on top of the FAD requires complex path computation and may reduce the benefit of this scheme.
FAD で指定された制約と、PCC からの PCEP メッセージに直接含まれる制約の組み合わせにより、フレキシブル アルゴリズム固有のプレフィックス SID が、指定された制約をすべて満たしながら最適なパスを表す可能性が減少する可能性があります。その結果、計算されたパスにはより長い SID リストが必要になる場合があります。FAD の上にさらに制約を追加すると、複雑なパス計算が必要となり、このスキームの利点が減少する可能性があります。
All the rules of processing the METRIC object as explained in [RFC5440] and [RFC8233] are applicable to the metric types defined in this document.
[RFC5440] および [RFC8233] で説明されている METRIC オブジェクトの処理規則はすべて、この文書で定義されているメトリック タイプに適用されます。
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], and [RFC9603] apply to the PCEP extensions defined in this document. In addition, the requirements and considerations listed in this section apply.
[RFC5440]、[RFC8231]、[RFC8664]、および [RFC9603] にリストされているすべての管理要件と考慮事項は、この文書で定義されている PCEP 拡張に適用されます。さらに、このセクションに記載されている要件と考慮事項が適用されます。
A PCE or PCC implementation MAY allow the capability of supporting the PCEP extensions introduced in this document to be enabled or disabled as part of the global configuration. By default, this capability SHOULD be enabled.
PCE または PCC 実装では、この文書で紹介されている PCEP 拡張機能をサポートする機能をグローバル設定の一部として有効または無効にすることができます (MAY)。デフォルトでは、この機能は有効になっている必要があります(SHOULD)。
An implementation SHOULD allow the operator to view the capability defined in this document. Sections 4.1 and 4.1.1 of [RFC9826] should be extended to include the capabilities introduced in Sections 4.1.1 and 4.1.2 for the PCEP peer.
実装では、オペレータがこの文書で定義された機能を表示できるようにする必要があります (SHOULD)。[RFC9826] のセクション 4.1 および 4.1.1 は、セクション 4.1.1 および 4.1.2 で導入された PCEP ピアの機能を含むように拡張される必要があります。
This document does not define any new mechanism that impacts the liveness detection and monitoring of PCEP.
この文書は、PCEP の活性検出と監視に影響を与える新しいメカニズムを定義するものではありません。
An implementation SHOULD also allow the operator to view FADs, which may be used in Flexible Algorithm path computation as defined in Section 5.2.2.
実装では、オペレータがセクション 5.2.2 で定義されている柔軟なアルゴリズムのパス計算で使用できる FAD を表示できるようにする必要があります (SHOULD)。
An implementation SHOULD allow the operator to view nodes participating in the specified SR-Algorithm.
実装では、オペレータが指定された SR アルゴリズムに参加しているノードを表示できるようにする必要があります (SHOULD)。
This document does not put new requirements but relies on the necessary IGP extensions.
この文書は新しい要件を規定するものではなく、必要な IGP 拡張機能に依存します。
This document inherits considerations from documents describing IGP Flexible Algorithm -- for example, [RFC9350] and [RFC9843].
この文書は、IGP フレキシブル アルゴリズムを説明する文書 ([RFC9350] や [RFC9843] など) からの考慮事項を継承しています。
This document inherits operational considerations from documents describing IGP Flexible Algorithm -- for example, [RFC9350] and [RFC9843].
この文書は、IGP フレキシブル アルゴリズムを説明する文書 ([RFC9350] や [RFC9843] など) から運用上の考慮事項を継承しています。
The security considerations described in [RFC5440], [RFC8231], [RFC8253], [RFC8281], [RFC8664], [RFC9603], and [RFC9350] apply to the extensions described in this document as well.
[RFC5440]、[RFC8231]、[RFC8253]、[RFC8281]、[RFC8664]、[RFC9603]、および [RFC9350] で説明されているセキュリティ上の考慮事項は、この文書で説明されている拡張機能にも適用されます。
Note that this specification introduces the possibility of computing paths by the PCE based on Flexible-Algorithm-related topology attributes and based on the metric type and constraints from the FAD. This creates additional vulnerabilities, which are already described for the path computation done by IGP, like those described in the Security Considerations section of [RFC9350] but which are also applicable to path computation done by the PCE. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] [RFC9916] is RECOMMENDED as per the recommendations and best current practices described in [RFC9325].
この仕様では、フレキシブル アルゴリズム関連のトポロジ属性と、FAD からのメトリック タイプおよび制約に基づいて、PCE によってパスを計算する可能性が導入されていることに注意してください。これにより、追加の脆弱性が生じます。これらの脆弱性は、[RFC9350] のセキュリティに関する考慮事項セクションで説明されているものと同様、IGP によって実行されるパス計算についてすでに説明されていますが、PCE によって実行されるパス計算にも当てはまります。したがって、[RFC9325] で説明されている推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ (TLS) [RFC8253] [RFC9916] を使用して PCEP セッションを保護することが推奨されます。
IANA maintains a registry named "SR Capability Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABILITY sub-TLV. IANA has registered the following:
IANA は、SR-PCE-CAPABILITY サブ TLV の Flags フィールドを管理するために、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「SR Capability Flag Field」という名前のレジストリを維持します。IANA は以下を登録しました。
+=====+=========================+===========+
| Bit | Description | Reference |
+=====+=========================+===========+
| 5 | SR-Algorithm Capability | RFC 9933 |
+-----+-------------------------+-----------+
Table 1
IANA maintains a registry named "SRv6 Capability Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILITY sub-TLV. IANA has registered the following:
IANA は、SRv6-PCE-CAPABILITY サブ TLV の Flags フィールドを管理するために、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「SRv6 Capability Flag Field」という名前のレジストリを維持します。IANA は以下を登録しました。
+=====+=========================+===========+
| Bit | Description | Reference |
+=====+=========================+===========+
| 13 | SR-Algorithm Capability | RFC 9933 |
+-----+-------------------------+-----------+
Table 2
IANA maintains a registry named "SR-ERO Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobject. IANA has registered the following:
IANA は、SR-ERO サブオブジェクトの Flags フィールドを管理するために、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「SR-ERO Flag Field」という名前のレジストリを維持します。IANA は以下を登録しました。
+=====+=======================+===========+
| Bit | Description | Reference |
+=====+=======================+===========+
| 7 | SR-Algorithm Flag (A) | RFC 9933 |
+-----+-----------------------+-----------+
Table 3
IANA maintains a registry named "SRv6-ERO Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SRv6-ERO subobject. IANA has registered the following:
IANA は、SRv6-ERO サブオブジェクトの Flags フィールドを管理するために、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「SRv6-ERO Flag Field」という名前のレジストリを管理します。IANA は以下を登録しました。
+=====+=======================+===========+
| Bit | Description | Reference |
+=====+=======================+===========+
| 7 | SR-Algorithm Flag (A) | RFC 9933 |
+-----+-----------------------+-----------+
Table 4
IANA maintains a registry named "PCEP TLV Type Indicators" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has registered the following TLV type for the new LSPA TLV specified in this document.
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「PCEP TLV Type Indicators」という名前のレジストリを管理しています。IANA は、この文書で指定されている新しい LSPA TLV として次の TLV タイプを登録しました。
+=======+==============+===========+
| Value | Description | Reference |
+=======+==============+===========+
| 66 | SR-Algorithm | RFC 9933 |
+-------+--------------+-----------+
Table 5
IANA maintains a registry named "METRIC Object T Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has registered these codepoints as follows:
IANA は、「Path Computation Element Protocol (PCEP) Numbers」レジストリ グループ内に「METRIC Object T Field」という名前のレジストリを管理しています。IANA はこれらのコードポイントを次のように登録しています。
+=========+============================+===========+
| Value | Description | Reference |
+=========+============================+===========+
| 22 | Path Min Delay metric | RFC 9933 |
+---------+----------------------------+-----------+
| 23 | P2MP Path Min Delay metric | RFC 9933 |
+---------+----------------------------+-----------+
| 24 | Path Bandwidth metric | RFC 9933 |
+---------+----------------------------+-----------+
| 25 | P2MP Path Bandwidth metric | RFC 9933 |
+---------+----------------------------+-----------+
| 128-255 | User-defined metric | RFC 9933 |
+---------+----------------------------+-----------+
Table 6
IANA has registered the following Error-Types and Error-values within 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 |
+============+===========+=======================+===========+
| 19 | Invalid | 33: Attempted use of | RFC 9933 |
| | Operation | SR-Algorithm without | |
| | | advertised capability | |
+------------+-----------+-----------------------+-----------+
| | | 34: Unsupported | RFC 9933 |
| | | combination of | |
| | | constraints | |
+------------+-----------+-----------------------+-----------+
Table 7
[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>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[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>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
[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>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[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>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[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>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[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>.
[RFC9753] Li, C., Zheng, H., and S. Litkowski, "Extension for
Stateful PCE to Allow Optional Processing of Path
Computation Element Communication Protocol (PCEP)
Objects", RFC 9753, DOI 10.17487/RFC9753, April 2025,
<https://www.rfc-editor.org/info/rfc9753>.
[RFC9843] Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak,
P., and T. Li, "IGP Flexible Algorithms: Bandwidth, Delay,
Metrics, and Constraints", RFC 9843, DOI 10.17487/RFC9843,
September 2025, <https://www.rfc-editor.org/info/rfc9843>.
[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>.
[RFC9917] Psenak, P., Horn, J., and A. Dhamija, "IGP Flexible
Algorithms Reverse Affinity Constraint", RFC 9917,
DOI 10.17487/RFC9917, January 2026,
<https://www.rfc-editor.org/info/rfc9917>.
[IANA-ALGORITHM-TYPES]
IANA, "IGP Algorithm Types",
<https://www.iana.org/assignments/igp-parameters>.
[IEEE.754.2019]
IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
<https://doi.org/10.1109/IEEESTD.2019.8766229>.
[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>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[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>.
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 9479, DOI 10.17487/RFC9479, October 2023,
<https://www.rfc-editor.org/info/rfc9479>.
[RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023,
<https://www.rfc-editor.org/info/rfc9492>.
[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>.
[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>.
Thanks to Dhruv Dhody for shepherding the document and for their contributions and suggestions.
この文書を管理し、貢献と提案をしてくれた Dhruv Dhody に感謝します。
The authors would like to thank Adrian Farrel, Aijun Wang, Alexey Melnikov, Boris Khasanov, Deb Cooley, Éric Vyncke, Gunter Van de Velde, Jie Dong, Ketan Talaulikar, Mahesh Jethanandani, Marina Fizgeer, Mike Bishop, Mohamed Boucadair, Nagendra Nainar, Rakesh Gandhi, Russ White, and Shraddha Hegde for review and suggestions.
著者らは、Adrian Farrel、Aijun Wang、Alexey Melnikov、Boris Khasanov、Deb Cooley、Éric Vyncke、Gunter Van de Velde、Jie Dong、Ketan Talaulikar、Mahesh Jethanandani、Marina Fizgeer、Mike Bishop、Mohamed Boucadair、Nagendra Nainar、Rakesh Gandhi、Russ White、Shraddha Hegde に感謝します。レビューと提案のために。
Mike Koldychev
Ciena Corporation
Email: mkoldych@proton.me
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Stephane Litkowski
Cisco Systems, Inc.
Email: slitkows.ietf@gmail.com
Siva Sivabalan
Ciena
Email: msiva282@gmail.com
Tarek Saad
Cisco Systems, Inc.
Email: tsaad.net@gmail.com
Mahendra Singh Negi
RtBrick Inc
Email: mahend.ietf@gmail.com
Tom Petch
Email: ietfc@btconnect.com
Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3.
Pribinova 10
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com
Zoey Rose
Cisco Systems, Inc.
2300 East President George
Richardson, TX 75082
United States of America
Email: atokar@cisco.com
Shaofu Peng
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: peng.shaofu@zte.com.cn
Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: pengshuping@huawei.com
Andrew Stone
Nokia
Email: andrew.stone@nokia.com