Internet Engineering Task Force (IETF) C. Li
Request for Comments: 9753 H. Zheng
Updates: 8231 Huawei Technologies
Category: Standards Track S. Litkowski
ISSN: 2070-1721 Cisco
April 2025
This document introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element (PCE) model can relax some constraints during path computation and setup. This document introduces this relaxation to stateful PCE, and it updates RFC 8231.
このドキュメントでは、PCEPメッセージ交換中にパス計算要素通信プロトコル（PCEP）オブジェクトをオプションとしてマークするメカニズムを導入するため、Stateful Path Computation Element（PCE）モデルは、パス計算とセットアップ中にいくつかの制約を緩和できます。このドキュメントでは、このリラクゼーションをStateful PCEに紹介し、RFC 8231を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9753.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9753で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Overview
2.1. Usage Example
3. PCEP Extension
3.1. STATEFUL-PCE-CAPABILITY TLV
3.2. Handling of the P Flag
3.2.1. The PCRpt Message
3.2.1.1. Delegation
3.2.2. The PCUpd Message and the PCInitiate Message
3.3. Handling of the I Flag
3.3.1. The PCUpd Message
3.3.2. The PCRpt Message
3.3.3. The PCInitiate Message
3.4. Unknown Object Handling
4. Security Considerations
5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV
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
6.6. Impact on Network Operations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP), which enables communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture [RFC4655].
[RFC5440]は、パス計算クライアント（PCC）とパス制御要素（PCE）間、またはPCEアーキテクチャに基づく2つのPCE [RFC4655]の間の通信を可能にするパス計算要素通信プロトコル（PCEP）を説明します。
PCEP extensions for the stateful PCE model [RFC8231] describes a set of extensions to PCEP to enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for dynamic control.
Stateful PCEモデル[RFC8231]のPCEP拡張は、PCEPの一連の拡張機能を説明し、マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）および一般化されたMPL（GMPLS）トンネルの積極的な制御を可能にします。[RFC8281]は、PCCのローカル構成を必要とせずに、アクティブなステートフルPCEモデルの下でのPCE開始LSPのセットアップと分解について説明しているため、動的制御が可能になります。
[RFC5440] defined the P flag (Processing-Rule) in the Common Object Header to allow a PCC to specify in a Path Computation Request (PCReq) message (sent to a PCE) whether the object must be taken into account by the PCE during path computation or is optional. The I flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) message to indicate to a PCC whether or not an optional object was considered by the PCE during path computation. Stateful PCE [RFC8231] specifies that the P and I flags of the PCEP objects are to be set to zero on transmission and ignored on receipt, since they are exclusively related to the path computation requests. This document defines a new flag, the R (RELAX) flag in STATEFUL-PCE-CAPABILITY TLV, in the PCEP common object header to indicate a PCE speaker supporting P and I flags processing, and it also specifies how the P and I flags could be used in the stateful PCE model to identify optional objects in the Path Computation State Report (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] messages.
[RFC5440]は、共通オブジェクトヘッダーのPフラグ（処理ルール）を定義して、PCCがPATH計算要求（PCREQ）メッセージ（PCEに送信）で指定できるようにしました。iフラグ（無視）は、PATH計算応答（PCREP）メッセージでPCEによって使用され、PCCにPCCがPCCの計算中にPCEによって考慮されたかどうかを示します。Stateful PCE [RFC8231]は、PCEPオブジェクトのPとIフラグが送信時にゼロに設定され、領収書で無視されることを指定します。このドキュメントでは、PCEP共通オブジェクトヘッダーの新しいフラグ、PCEP共通オブジェクトヘッダーのR（リラックス）フラグを定義して、PおよびIフラグの処理をサポートするPCEスピーカーを示します。また、PAST Computation State Reptumation（PCC8231] [RFC8231] [RFC8231] [RFC8231] [RFC8231]のPATY Computation状態レポート（PCRPT）を特定するために、PとIフラグをPAST Computation State Repates（PCRPT）に識別する方法も指定します。[RFC8231]、およびLSP開始要求（PCInitiate）[RFC8281]メッセージ。
This document updates [RFC8231] concerning usage of the P and I flags as well as the handling of unknown objects in stateful PCEP message exchange.
このドキュメントは、PとIフラグの使用法と、ステートフルPCEPメッセージ交換における未知のオブジェクトの処理に関する[RFC8231]を更新します。
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] で説明されているように解釈されます。
Setting the P flag in the PCReq message to handle unknown objects is as described in Section 7.2 of [RFC5440]. Further, [RFC8231] defined the usage of the LSP Error Code TLV in the PCRpt message in response to a failed LSP Update Request via the PCUpd message (for example, due to an unsupported object or TLV).
PCREQメッセージにPフラグを設定して、未知のオブジェクトを処理するように、[RFC5440]のセクション7.2で説明されています。さらに、[RFC8231]は、PCUPDメッセージを介したLSP更新リクエストの失敗に応じて、PCRPTメッセージでLSPエラーコードTLVの使用を定義しました（たとえば、サポートされていないオブジェクトまたはTLVのため）。
This document specifies the procedure of marking some objects as 'optional to be processed' by the PCEP peer in the stateful PCEP messages. Furthermore, this document updates the procedure for handling unknown objects in stateful PCEP messages based on the P flag.
このドキュメントは、Stateful PCEPメッセージのPCEPピアによって「処理されるオプション」として一部のオブジェクトをマークする手順を指定します。さらに、このドキュメントでは、Pフラグに基づいて、ステートフルなPCEPメッセージで不明なオブジェクトを処理する手順を更新します。
The PCRpt message is used to report the current state of an LSP. As part of the message, both the <intended-attribute-list> and <actual-attribute-list> are encoded (see [RFC8231]). For example, the <intended-attribute-list> could include the METRIC object to indicate a limiting constraint (Bound 'B' flag set) for the Path Delay Variation metric [RFC8233]. In some scenarios, it would be useful to indicate that this constraint can be relaxed by the PCE in case it cannot find a path. In these cases, it would be useful to mark the objects as 'optional' so they could be ignored by the PCEP peer. Also, it would be useful for the PCEP speaker to learn if the PCEP peer has relaxed the constraint and ignored the processing of the PCEP object.
PCRPTメッセージは、LSPの現在の状態を報告するために使用されます。メッセージの一部として、<意図しのアトリブリスト>と<実際のアトリブリスト>の両方がエンコードされています（[rfc8231]を参照）。たとえば、<目的のアトリブリスト>には、経路遅延変動メトリック[RFC8233]の制限制約（「B」フラグセット）を示すメトリックオブジェクトを含めることができます。一部のシナリオでは、パスを見つけることができない場合に備えて、PCEによってこの制約が緩和される可能性があることを示すことが有用です。これらの場合、オブジェクトを「オプション」としてマークすると、PCEPピアによって無視される可能性があります。また、PCEPスピーカーがPCEPピアが制約を緩和し、PCEPオブジェクトの処理を無視したかどうかを学習することは役立ちます。
Thus, this document specifies how the already existing P and I flags in the PCEP common object header could be used during the stateful PCEP message exchange. The scope of how P and I flags are applied is defined in [RFC5440] and is unchanged by this document. Therefore, these flags can only be applied to an entire PCEP object; they cannot be applied at the granularity of optional TLVs encoded in the PCEP object.
したがって、このドキュメントは、PCEP共通オブジェクトヘッダーの既存のPとIフラグが、ステートフルなPCEPメッセージ交換中にどのように使用できるかを指定します。PとIフラグの適用方法の範囲は[RFC5440]で定義されており、このドキュメントで変更されていません。したがって、これらのフラグは、PCEPオブジェクト全体にのみ適用できます。これらは、PCEPオブジェクトにエンコードされたオプションのTLVの粒度に適用することはできません。
A PCEP speaker indicates its ability to support the handling of the P and I flags in the stateful PCEP message exchange during the PCEP initialization phase, as follows. During the PCEP initialization phase, a PCC sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, the R (RELAX) flag, is added to this TLV to indicate support for relaxing the processing of some objects via the use of the P and I flags in the PCEP common object header.
PCEPスピーカーは、次のように、PCEP初期化フェーズ中のステートフルPCEPメッセージ交換でPとIフラグの処理をサポートする能力を示します。PCEP初期化フェーズでは、[RFC8231]で定義されているように、PCCは、ステートフルPCE能力TLVを含むオープンオブジェクトを使用して開いたメッセージを送信します。新しいフラグであるR（リラックス）フラグがこのTLVに追加され、PCEP共通オブジェクトヘッダーのPおよびIフラグを使用して、一部のオブジェクトの処理をリラックスするためのサポートを示します。
R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to handle the P and I flags in the PCEP common object header for the PCEP objects in the stateful PCEP messages. If the bit is unset, it indicates that the PCEP Speaker will not handle the P and I flags in the PCEP common object header for stateful PCE messages.
R（リラックスビット-17）：PCEPスピーカーによって1に設定された場合、Rフラグは、PCEPスピーカーがPCEP共通オブジェクトヘッダーのPCEPオブジェクトのPCEPオブジェクトのPCEPオブジェクトヘッダーのPCEPオブジェクトのフラグを処理する意思があることを示します。BITが設定されていない場合、PCEPスピーカーがPCEP共通オブジェクトヘッダーのPCEPとIフラグをステートフルPCEメッセージに処理しないことを示します。
The R flag MUST be set by both the PCC and PCE to indicate support for handling the P and I flags in the PCEP common object header to allow relaxing some constraints by marking objects as 'optional to process'. If the PCEP speaker does not set the R flag but receives PCEP objects with the P or I bits set, it MUST ignore the flags. [RFC8231] states that P and I flags of the PCEP objects are set to 0 on transmission and ignored on receipt. It fails to mention the behaviour of objects defined outside of [RFC8231], leading to ambiguity.
Rフラグは、PCCとPCEの両方で設定して、PCEP共通オブジェクトヘッダーのPおよびIフラグの処理のサポートを示して、オブジェクトを「プロセスにオプション」とマークすることにより、いくつかの制約をリラックスできるようにする必要があります。PCEPスピーカーがRフラグを設定せず、PまたはIビットを設定してPCEPオブジェクトを受信する場合、フラグを無視する必要があります。[RFC8231] PCEPオブジェクトのPとIフラグは、送信時に0に設定され、受領時に無視されると述べています。[RFC8231]の外部で定義されたオブジェクトの動作について言及しておらず、曖昧さにつながります。
The P flag in the PCRpt message [RFC8231] allows a PCC to specify to a PCE whether the object must be taken into account by the PCE (during state maintenance, path computation, or re-optimisation) or is optional to process. When the P flag is set in the PCRpt message received on a PCEP session on which the R bit is set by both peers, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE can ignore it. The P flag for the mandatory objects, such as the LSP and the ERO (Explicit Route Object) object (intended path), MUST be set in the PCRpt message. If a mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (Reception of an object with P flag not set). On a PCEP session on which the R bit was set by both peers, the PCC SHOULD set the P flag by default, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCE or the object itself conveys informational parameters that can be safely ignored.
PCRPTメッセージ[RFC8231]のPフラグにより、PCCはPCEをPCE（状態メンテナンス、パス計算中、または再最適化中）で考慮する必要があるかどうかをPCEに指定できます。PCRPTメッセージが両方のピアによってRビットが設定されているPCEPセッションで受信されたPCRPTメッセージに設定されている場合、オブジェクトはPCEによって考慮される必要があります。逆に、Pフラグがクリアされると、オブジェクトはオプションであり、PCEはそれを無視できます。LSPやERO（明示的ルートオブジェクト）オブジェクト（意図されたパス）などの必須オブジェクトのPフラグは、PCRPTメッセージに設定する必要があります。上記のルールに従ってPフラグセットで必須オブジェクトが誤って受信された場合、受信ピアはエラータイプ= 10（無効なオブジェクトの受信）およびエラー値= 1（Pフラグが設定されていないオブジェクトの受信）でPCERRメッセージを送信する必要があります。Rビットが両方のピアによって設定されたPCEPセッションでは、ローカル構成またはローカルポリシーがいくつかの制約（対応するPCEPオブジェクト）がオプションとしてマークされ、PCEによって無視できるか、オブジェクト自体が安全に無視できる情報パラメーターを伝えることができることを示していない限り、PCCはデフォルトでPフラグを設定する必要があります。
Delegation is an operation to grant a PCE temporary rights to modify a subset of parameters on one or more LSPs by a PCC as described in [RFC8051]. Note that for the delegated LSPs, the PCE can update and mark some objects as ignored even when the PCC has set the P flag during the delegation. Similarly, the PCE can update and mark some objects as a 'must to process' even when the PCC has not set the P flag during delegation.
委任は、[RFC8051]で説明されているように、PCCによって1つ以上のLSPのパラメーターのサブセットを変更するPCE一時的な権利を付与する操作です。委任されたLSPの場合、PCCが代表団中にPフラグを設定した場合でも、PCEは無視されているようにいくつかのオブジェクトを更新およびマークできることに注意してください。同様に、PCCは、PCCが委任中にPフラグを設定していない場合でも、一部のオブジェクトを「処理する必要がある」として更新およびマークすることができます。
The PCC MUST acknowledge this by sending the PCRpt message with the P flag set as per the PCE expectation for the corresponding object. If the PCC cannot accept the update message, it MUST react as per the processing rules of unacceptable update in Section 5.8.3 of [RFC8231].
PCCは、対応するオブジェクトに対するPCEの期待に従ってPCRPTメッセージをPフラグセットで送信することにより、これを認める必要があります。PCCが更新メッセージを受け入れられない場合、[RFC8231]のセクション5.8.3の容認できない更新の処理ルールに従って反応する必要があります。
The P flag in the PCUpd message [RFC8231] and the PCInitiate message [RFC8281] allows a PCE to specify to a PCC whether the object must be taken into account by the PCC (during path setup) or is optional to process. When the P flag is set in the PCUpd/PCInitiate message received on a PCEP session on which the R bit was set by both peers, the object MUST be taken into account by the PCC. Conversely, when the P flag is cleared, the object is optional and the PCC can ignore it. The P flag for the mandatory objects -- such as the SRP (Stateful PCE Request Parameters), the LSP, and the ERO -- MUST be set in the PCUpd/PCInitiate message. If a mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (Reception of an object with P flag not set). On a PCEP session in which both peers set the R bit, the PCE SHOULD set the P flag by default unless a local configuration/policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and can be ignored by the PCC or the object itself conveys informational parameters that can be safely ignored.
PCUPDメッセージ[RFC8231]およびPCINITIATEメッセージ[RFC8281]のPフラグにより、PCCがPCCが考慮する必要があるか（パスのセットアップ中）、または処理するオプションであるかどうかをPCCに指定できます。Pフラグが両方のピアによってRビットが設定されたPCEPセッションで受信されたPCUPD/PCInitiateメッセージに設定されている場合、オブジェクトはPCCによって考慮される必要があります。逆に、Pフラグがクリアされると、オブジェクトはオプションであり、PCCはそれを無視できます。SRP（Stateful PCE Requestパラメーター）、LSP、EROなどの必須オブジェクトのPフラグは、PCUPD/PCInitiateメッセージに設定する必要があります。上記のルールに従ってPフラグセットで必須オブジェクトが誤って受信された場合、受信ピアはエラータイプ= 10（無効なオブジェクトの受信）およびエラー値= 1（Pフラグが設定されていないオブジェクトの受信）でPCERRメッセージを送信する必要があります。両方のピアがRビットを設定するPCEPセッションでは、ローカル構成/ポリシーがいくつかの制約（対応するPCEPオブジェクト）がオプションとしてマークされ、PCCによって無視できることを示さない限り、PCEはデフォルトでPフラグを設定する必要があります。
The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its update request and set the I flag to indicate that the optional object was ignored. When the I flag is cleared, the PCE indicates that the optional object was processed.
PCUPDメッセージ[RFC8231]のIフラグにより、PCEはオプションのオブジェクトが処理されたかどうかをPCCに示すことができます。PCEには、更新リクエストに無視されたオプションオブジェクトを含めることができ、Iフラグを設定して、オプションのオブジェクトが無視されたことを示します。Iフラグがクリアされると、PCEはオプションのオブジェクトが処理されたことを示します。
Note that when a PCE is unable to find the path that meets all the constraints as per the PCEP object that cannot be ignored (i.e. the P flag is set), the PCUpd message MAY optionally include the PCEP objects that caused the path computation to fail along with the empty ERO.
PCEが無視できないPCEPオブジェクトに従ってすべての制約を満たすパスを見つけることができない場合（つまり、Pフラグが設定されています）、PCUPDメッセージには、空のEROとともにパス計算が故障したPCEPオブジェクトをオプションに含める場合があることに注意してください。
The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to a PCE whether or not an optional object was processed in response to a PCUpd or PCInitiate message. The PCC MAY include the ignored optional object in its report and set the I flag to indicate that the optional object was ignored at PCC. When the I flag is cleared, the PCC indicates that the optional object was processed. The I flag has no meaning if the PCRpt message is not in response to a PCUpd or PCInitiate message (i.e., without the SRP object in the PCRpt message).
PCRPTメッセージ[RFC8231]のIフラグにより、PCCはPCUPDまたはPCInitiateメッセージに応じてオプションのオブジェクトが処理されたかどうかをPCCに示すことができます。PCCには、そのレポートに無視されたオプションオブジェクトを含めることができ、Iフラグを設定して、PCCでオプションのオブジェクトが無視されたことを示すことができます。Iフラグがクリアされると、PCCはオプションのオブジェクトが処理されたことを示します。Iフラグには、PCRPTメッセージがPCUPDまたはPCInitiateメッセージに応答していない場合（つまり、PCRPTメッセージにSRPオブジェクトがない場合）、意味がありません。
Note that when a PCC is unable to set up a path that meets all the parameters as per the PCEP object that cannot be ignored (i.e., the P flag is set), the PCRpt message MAY optionally include the PCEP objects that caused the path setup to fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the failure.
PCCが無視できないPCEPオブジェクト（つまり、Pフラグが設定されている）に従ってすべてのパラメーターを満たすパスを設定できない場合、PCRPTメッセージには、lsp-error-code tlv [rfc8231]とともにパスセットアップを失敗させたPCEPオブジェクトをオプションに含めることができることに注意してください。
The I flag has no meaning in the PCInitiate message [RFC8281], so the I flag MUST set to 0 on transmission and ignored on receipt.
Iフラグには、PCInitiateメッセージ[RFC8281]には意味がないため、Iフラグは送信時に0に設定し、受信時に無視する必要があります。
This document updates the handling of unknown objects in the stateful PCEP messages by setting the P flag in the common object header in a similar way as described in [RFC5440]. That is, if a PCEP speaker does not understand an object with the P flag set, or if the PCEP speaker understands the object but decides to ignore the object, the entire stateful PCEP message MUST be rejected, and the PCE MUST send a PCErr message with Error- Type="Unknown Object" or "Not supported object" [RFC5440]. If the P flag is not set, the PCEP speaker can ignore the object and continue with the message processing as defined.
このドキュメントでは、[RFC5440]で説明されているように、共通オブジェクトヘッダーにPフラグを同様の方法で設定することにより、ステートフルPCEPメッセージの不明なオブジェクトの処理を更新します。つまり、PCEPスピーカーがPフラグセットを持つオブジェクトを理解していない場合、またはPCEPスピーカーがオブジェクトを理解しているがオブジェクトを無視することを決定した場合、ステートフルなPCEPメッセージ全体を拒否する必要があり、PCEはエラー-Type = "不明なオブジェクト"または「サポートされていないオブジェクト」[RFC5440]でPCERRメッセージを送信する必要があります。Pフラグが設定されていない場合、PCEPスピーカーはオブジェクトを無視し、定義されたメッセージ処理を続行できます。
[RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt message in the LSP object to convey error information. This document does not change that procedure.
[RFC8231]は、LSPオブジェクトのPCRPTメッセージに掲載されるLSPエラーコードTLVを定義して、エラー情報を伝達しました。このドキュメントは、その手順を変更しません。
This document specifies how the already existing P and I flags in the PCEP common object header could be used during stateful PCEP exchanges. It updates the unknown object error handling in stateful PCEP message exchange. On their own, these changes do not add any new security concerns. The security considerations identified in [RFC5440], [RFC8231], and [RFC8281] continue to apply.
このドキュメントは、PCEP共通オブジェクトヘッダーの既存のPとIフラグを、ステートフルなPCEP交換中にどのように使用できるかを指定します。Stateful PCEPメッセージ交換で不明なオブジェクトエラー処理を更新します。単独では、これらの変更は新しいセキュリティの懸念を追加しません。[RFC5440]、[RFC8231]、および[RFC8281]で特定されたセキュリティ上の考慮事項は、引き続き適用されます。
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 described in [RFC9325].
[RFC8231]によると、これらのPCEP拡張は、[RFC9325]に記載されている推奨事項と最良の慣行に従って、輸送層のセキュリティ（TLS）[RFC8253]を使用して、同じ行政当局に属するPCESおよびPCC全体で認証され、暗号化されたセッションでのみアクティブ化できることをお勧めします。
[RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has allocated a new bit in the registry, as follows:
[RFC8231]は、ステートフルPCEのキャピリティTLVとIANAを定義し、「ステートフルPCEキャピールTLVフラグフィールド」レジストリを作成して、ステートフルPCE能力TLVのフラグフィールドの価値を管理しました。IANAは、次のように、レジストリに新しいビットを割り当てました。
+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 17 | RELAX | RFC 9753 |
+-----+-------------+-----------+
Table 1
An implementation supporting this document SHOULD allow configuration of the capability to support relaxation of constraints in the stateful PCEP message exchange. They SHOULD also allow configuration of related LSP constraints (or parameters) that are optional to process.
このドキュメントをサポートする実装により、ステートフルなPCEPメッセージ交換における制約の緩和をサポートする機能の構成が可能になるはずです。また、処理するのにオプションの関連するLSP制約（またはパラメーター）の構成を許可する必要があります。
An implementation supporting this document SHOULD allow the operator to view the capability defined in this document. To serve this purpose, the PCEP YANG module [PCEP-YANG] could be extended in the future.
このドキュメントをサポートする実装により、オペレーターはこのドキュメントで定義されている機能を表示できるようにする必要があります。この目的を果たすために、PCEP Yangモジュール[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].
このドキュメントで定義されているメカニズムは、[RFC5440]に既にリストされているものに加えて、新しい活性検出および監視要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい操作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルの新しい要件を意味するものではありません。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、ネットワーク操作に影響を与えません。
[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>.
[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>.
[PCEP-YANG]
Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-30>.
[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>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[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>.
[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>.
Thanks to Jonathan Hardwick for the discussion and suggestions around this document.
この文書に関する議論と提案をしてくれたJonathan Hardwickに感謝します。
Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and Peng Shaofu for their review comments.
オスカー・ゴンザレス・デ・ディオス、マイク・コルディチェフ、サミュエル・サイドール、ペン・ショーフのレビューのコメントに感謝します。
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com
Stephane Litkowski
Cisco
Email: slitkows.ietf@gmail.com