[要約] PCEPは、ネットワーク内の経路とリソース使用状況に関する情報を維持するstateful PCE機能をサポートするように拡張されました。ただし、これらの拡張機能はGMPLSネットワークのすべての要件をカバーしていません。この文書は、PCEPに必要な拡張機能を提供し、GMPLS制御ネットワークでstateful PCE機能を使用できるようにします。
Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 9504 Samsung
Category: Standards Track H. Zheng
ISSN: 2070-1721 Huawei Technologies
O. Gonzalez de Dios
Telefonica
V. Lopez
Nokia
Z. Ali
Cisco
December 2023
The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements for GMPLS networks.
PATH計算要素通信プロトコル（PCEP）は、ステートフルPCEがネットワーク内のパスとリソースの使用に関する情報を維持するステートフルPCE関数をサポートするために拡張されています。ただし、これらの拡張機能は、GMPLSネットワークのすべての要件をカバーするわけではありません。
This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks.
このドキュメントは、GMPLS制御ネットワークでのステートフルPCE機能の使用を可能にするために、PCEPに必要な拡張機能を提供します。
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/rfc9504.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9504で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Conventions Used in This Document
2. Terminology
3. General Context of Stateful PCE and PCEP for GMPLS
4. Main Requirements
5. Overview of Stateful PCEP Extensions for GMPLS Networks
5.1. Capability Advertisement for Stateful PCEP in GMPLS
5.2. LSP Synchronization
5.3. LSP Delegation and Cleanup
5.4. LSP Operations
6. PCEP Object Extensions
6.1. Existing Extensions Used for Stateful GMPLS
6.2. New Extensions
6.2.1. GMPLS-CAPABILITY TLV in OPEN Object
6.2.2. New LSP Exclusion Subobject in the XRO
6.2.3. New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object
7. Update to Error Handling
7.1. Error Handling in PCEP Capabilities Advertisement
7.2. Error Handling in LSP Reoptimization
7.3. Error Handling in Route Exclusion
7.4. Error Handling for the Generalized END-POINTS Object
8. IANA Considerations
8.1. New Flags in the GMPLS-CAPABILITY TLV
8.2. New Subobject for the Exclude Route Object
8.3. Flags Field for the LSP Exclusion Subobject
8.4. New Flags in the LSP-EXTENDED-FLAGS TLV
8.5. New PCEP Error Codes
9. Manageability Considerations
9.1. Control of Function through Configuration and Policy
9.2. Information and Data Models
9.3. Liveness Detection and Monitoring
9.4. Verifying Correct Operation
9.5. Requirements on Other Protocols and Functional Components
9.6. Impact on Network Operation
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. PCEP Messages
A.1. The PCRpt Message
A.2. The PCUpd Message
A.3. The PCInitiate Message
Acknowledgements
Contributors
Authors' Addresses
[RFC4655] presents the architecture of a PCE-based model for computing Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). A PCE that only maintains a TED is referred to as a "stateless PCE". [RFC5440] describes the Path Computation Element Communication Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE or between two PCEs, enabling computation of TE LSPs. PCEP is further extended to support GMPLS-controlled networks as per [RFC8779].
[RFC4655]は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）トラフィックエンジニアリングラベルの切り替えパス（TE LSP）のためのPCEベースのモデルのアーキテクチャを提示します。このような制約された計算を実行するために、PCEはTEデータベース（TED）にネットワークトポロジ（つまり、TEリンクとノード）とリソース情報（つまり、TE属性）を保存します。TEDのみを維持するPCEは、「ステートレスPCE」と呼ばれます。[RFC5440]は、パス計算クライアント（PCC）とPCEまたは2つのPCE間の相互作用のパス計算要素通信プロトコル（PCEP）を説明し、TE LSPの計算を可能にします。PCEPは、[RFC8779]に従ってGMPLS制御ネットワークをサポートするためにさらに拡張されます。
Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [RFC8051]. Further discussion of the concept of a stateful PCE can be found in [RFC7399]. In order for these applications to be able to exploit the capability of stateful PCEs, extensions to stateful PCEP for GMPLS are required.
[RFC8051]に示されているように、ステートフルPCESは、MPLSネットワークとGMPLSネットワークの両方で多くのアプリケーションシナリオで役立つことが示されています。ステートフルPCEの概念のさらなる議論は、[RFC7399]に記載されています。これらのアプリケーションがステートフルPCESの能力を活用できるためには、GMPLのステートフルPCEPへの拡張が必要です。
[RFC8051] describes how a stateful PCE can be applied to solve various problems for MPLS-TE and GMPLS networks and the benefits it brings to such deployments.
[RFC8051]は、MPLS-TEおよびGMPLSネットワークのさまざまな問題を解決するために、ステートフルPCEを適用する方法と、それがそのような展開にもたらす利点を説明しています。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs where they are configured on the PCC and control over them could be delegated to the PCE. Furthermore, [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. However, both documents omit the specification for technology-specific objects and TLVs, and they do not cover GMPLS-controlled networks (e.g., Wavelength Switched Optical Network (WSON), Optical Transport Network (OTN), Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)).
[RFC8231]は、PCCで構成され、それらを制御することがPCEに委任される可能性があるTE LSPのステートフルな制御を可能にするために、PCEPの拡張セットを指定します。さらに、[RFC8281]は、PCCのローカル構成を必要とせずに、アクティブなステートフルPCEモデルでのPCE開始LSPのセットアップと分解について説明します。ただし、両方のドキュメントは、テクノロジー固有のオブジェクトとTLVの仕様を省略しており、GMPLS制御ネットワーク（例：波長スイッチネットワーク（WSON）、光学輸送ネットワーク（OTN）、同期光ネットワーク（SONET） /同期をカバーしていませんデジタル階層（SDH））。
This document focuses on the extensions that are necessary in order for the deployment of stateful PCEs and the requirements for PCE-initiated LSPs in GMPLS-controlled networks. Section 3 provides a general context of the usage of stateful PCEs and PCEP for GMPLS. The various requirements for stateful GMPLS, including PCE initiation for GMPLS LSPs, are provided in Section 4. An overview of the PCEP extensions is specified in Section 5. A solution to address such requirements with PCEP object extensions is specified in Section 6.
このドキュメントは、ステートフルPCESの展開とGMPLS制御ネットワークにおけるPCE開始LSPの要件に必要な拡張機能に焦点を当てています。セクション3では、GMPLSのStateful PCESとPCEPの使用に関する一般的なコンテキストを提供します。GMPLS LSPのPCE開始を含むステートフルGMPLSのさまざまな要件は、セクション4に記載されています。PCEP拡張機能の概要は、セクション5で指定されています。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Terminology used in this document is the same as terminology used in [RFC5440], [RFC8231], [RFC8281], and [RFC8779].
このドキュメントで使用される用語は、[RFC5440]、[RFC8231]、[RFC8281]、および[RFC8779]で使用される用語と同じです。
This section is built on the basis of stateful PCEs specified in [RFC8231] and PCEP for GMPLS specified in [RFC8779].
このセクションは、[RFC8231]で指定されたステートフルPCESおよび[RFC8779]で指定されたGMPLSのPCEPに基づいて構築されています。
The operation of a stateful PCE on LSPs can be divided into two types: active stateful PCE and passive stateful PCE (as described in [RFC8051]).
LSPでのステートフルPCEの動作は、アクティブなステートフルPCEとパッシブステートフルPCE（[RFC8051]で説明されている）の2つのタイプに分けることができます。
* For active stateful PCEs, a Path Computation Update Request (PCUpd) message is sent from the PCE to the PCC to update the LSP state for the LSPs delegated to the PCE. Any changes to the delegated LSPs generate a Path Computation State Report (PCRpt) message from the PCC to the PCE to convey the changes of the LSPs. Any modifications to the objects and TLVs that are identified in this document to support GMPLS-specific attributes will be carried in the PCRpt and PCUpd messages.
* Active Stateful PCESの場合、PATH計算更新リクエスト（PCUPD）メッセージがPCCからPCCに送信され、PCEに委任されたLSPのLSP状態を更新します。委任されたLSPの変更は、LSPの変更を伝えるために、PCCからPCCへのPATH計算状態レポート（PCRPT）メッセージを生成します。GMPLS固有の属性をサポートするためにこのドキュメントで識別されたオブジェクトとTLVの変更は、PCRPTおよびPCUPDメッセージに掲載されます。
* For passive stateful PCEs, Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages are used to request path computation. GMPLS-specific objects and TLVs are defined in [RFC8779], which this document builds on and adds the stateful PCE aspects where applicable. A passive stateful PCE makes use of PCRpt messages when reporting LSP state changes sent by PCCs to PCEs. Any modifications to the objects and TLVs that are identified in this document to support GMPLS-specific attributes will be carried in the PCRpt message.
* 受動的なステートフルなPCESの場合、PATH計算要求（PCREQ）およびPATH計算応答（PCREP）メッセージを使用して、パス計算を要求します。GMPLS固有のオブジェクトとTLVは[RFC8779]で定義されています。このドキュメントは、該当する場合はステートフルPCEの側面に基づいて追加されています。PCCSがPCSに送信したLSP状態の変更を報告する際に、受動的なステートフルPCEはPCRPTメッセージを使用します。GMPLS固有の属性をサポートするためにこのドキュメントで特定されたオブジェクトとTLVの変更は、PCRPTメッセージに掲載されます。
Furthermore, the LSP Initiation function of PCEP is defined in [RFC8281] to allow the PCE to initiate LSP establishment after the path is computed. An LSP Initiate Request (PCInitiate) message is used to trigger the end node to set up the LSP. Any modifications to the objects and TLVs that are identified in this document to support GMPLS-specific attributes will be carried in the PCInitiate messages.
さらに、PCEPのLSP開始関数は[RFC8281]で定義されており、PCEがパスを計算した後にLSP確立を開始できるようにします。LSP開始要求（PCINITIATE）メッセージを使用して、ENDノードをトリガーしてLSPをセットアップします。GMPLS固有の属性をサポートするためにこのドキュメントで識別されたオブジェクトとTLVの変更は、PCINITIATEメッセージに掲載されます。
[RFC8779] defines GMPLS-specific objects and TLVs in stateless PCEP; this document makes use of these objects and TLVs without modifications where applicable. Where these objects and TLVs require modifications to incorporate stateful PCEs, they are described in this document. PCE-initiated LSPs follow the principle specified in [RFC8281], and the GMPLS-specific extensions are also included in this document.
[RFC8779]は、ステートレスPCEPでGMPLS固有のオブジェクトとTLVを定義します。このドキュメントでは、該当する場合は変更なしでこれらのオブジェクトとTLVを使用します。これらのオブジェクトとTLVがステートフルなPCEを組み込むために変更を必要とする場合、このドキュメントに記載されています。PCEによって開始されたLSPは、[RFC8281]で指定された原理に従い、GMPLS固有の拡張機能もこのドキュメントに含まれています。
This section notes the main functional requirements for PCEP extensions to support stateful PCEs for use in GMPLS-controlled networks, based on the description in [RFC8051]. Many requirements are common across a variety of network types (e.g., MPLS-TE networks and GMPLS networks) and the protocol extensions to meet the requirements are already described in [RFC8231] (such as LSP update, delegation, and state synchronization/report). Protection context information that describes the GMPLS requirement can also follow the description in [RFC8745]. This document does not repeat the description of those protocol extensions. This document presents protocol extensions for a set of requirements that are specific to the use of a stateful PCE in a GMPLS-controlled network.
このセクションは、[RFC8051]の説明に基づいて、GMPLS制御ネットワークで使用するためのステートフルPCESをサポートするPCEP拡張の主な機能要件を示しています。多くの要件は、さまざまなネットワークタイプ（MPLS-TEネットワークやGMPLSネットワークなど）で一般的であり、要件を満たすプロトコル拡張は[RFC8231]（LSPアップデート、委任、および州同期/レポートなど）ですでに説明されています。。GMPLS要件を記述する保護コンテキスト情報[RFC8745]の説明にも従うことができます。このドキュメントでは、これらのプロトコル拡張の説明を繰り返しません。このドキュメントでは、GMPLS制御ネットワークでのステートフルPCEの使用に固有の一連の要件のプロトコル拡張を提示します。
The requirements for GMPLS-specific stateful PCEs are as follows:
GMPLS固有のステートフルPCESの要件は次のとおりです。
* Advertisement of the stateful PCE capability. This generic requirement is covered in Section 5.4 of [RFC8231]. The GMPLS-CAPABILITY TLV specified in Section 2.1 of [RFC8779] and its extension in this document need to be advertised as well.
* ステートフルPCE機能の広告。この一般的な要件は、[RFC8231]のセクション5.4で説明されています。[RFC8779]のセクション2.1で指定されたGMPLSキャピールTLVと、このドキュメントでのその拡張も宣伝する必要があります。
* All the PCEP messages need to be capable of indicating GMPLS-specific switching capabilities. GMPLS LSP creation, modification, and deletion require knowledge of LSP switching capabilities (e.g., Time-Division Multiplex Capable (TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.) and the Generalized Payload Identifier (G-PID) to be used according to [RFC3471] and [RFC3473]. It also requires that traffic parameters that are both data flow and technology specific be defined. These traffic parameters are also known as "Traffic Specification" or "Tspec". Such information would need to be included in various PCEP messages.
* すべてのPCEPメッセージは、GMPLS固有のスイッチング機能を示すことができる必要があります。GMPLS LSPの作成、変更、および削除には、LSPスイッチング機能（例：時間分割マルチプレックス対応（TDM）、レイヤー2スイッチ対応（L2SC）、OTN-TDM、Lambdaスイッチ対応など）の知識が必要です。[RFC3471]および[RFC3473]に従って使用する一般化ペイロード識別子（G-PID）。また、データフローとテクノロジー固有のトラフィックパラメーターを定義する必要があります。これらのトラフィックパラメーターは、「トラフィック仕様」または「TSPEC」とも呼ばれます。このような情報は、さまざまなPCEPメッセージに含める必要があります。
* In some technologies, path calculation is tightly coupled with label selection along the route. For example, path calculation in a Wavelength Division Multiplexing (WDM) network may include lambda continuity and/or lambda feasibility constraints; hence, a path computed by the PCE is associated with a specific lambda (label). Thus, in such networks, the label information needs to be provided to a PCC in order for a PCE to initiate GMPLS LSPs under the active stateful PCE model, i.e., Explicit Label Control (ELC) may be required.
* 一部のテクノロジーでは、パスの計算は、ルートに沿ったラベル選択と密接に結びついています。たとえば、波長分割多重化（WDM）ネットワークのパス計算には、Lambdaの連続性および/またはLambdaの実現可能性の制約が含まれる場合があります。したがって、PCEによって計算されたパスは、特定のラムダ（ラベル）に関連付けられています。したがって、そのようなネットワークでは、PCEがアクティブなステートフルPCEモデルでGMPLS LSPを開始するために、つまり明示的なラベルコントロール（ELC）を開始するためには、PCCにラベル情報を提供する必要があります。
* Stateful PCEP messages also need to indicate the protection context information for the LSP specified by GMPLS, as defined in [RFC4872] and [RFC4873].
* ステートフルPCEPメッセージは、[RFC4872]および[RFC4873]で定義されているように、GMPLSで指定されたLSPの保護コンテキスト情報を示す必要もあります。
Capability advertisement is specified in [RFC8231]; it can be achieved by using the STATEFUL-PCE-CAPABILITY TLV in the Open message. Another GMPLS-CAPABILITY TLV is defined in [RFC8779]. A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV has been created by IANA as requested by [RFC8779]. The following bits are introduced by this document in the GMPLS-CAPABILITY TLV as flags to indicate the capability for LSP report, update, and initiation in GMPLS networks: LSP-REPORT-CAPABILITY (31), LSP-UPDATE-CAPABILITY (30), and LSP-INSTANTIATION-CAPABILITY (29).
機能広告は[RFC8231]で指定されています。開いたメッセージでStateful-PCEキャピールTLVを使用することで実現できます。別のGMPLSキャピールTLVは[RFC8779]で定義されています。[RFC8779]が要求したように、GMPLSキャピールTLVのフラグフィールドを管理するためのサブレジストリがIANAによって作成されました。次のBITは、GMPLSキャピールTLVでこのドキュメントでフラグとして導入され、GMPLSネットワークのLSPレポート、更新、および開始の機能を示すフラグとして紹介されます。およびLSP-inStantiation-Capability（29）。
After the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a PCC's LSPs (including its attributes) before it can perform path computations or update LSP attributes in a PCC. This process is known as "LSP state synchronization". The LSP attributes, including bandwidth, associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB). Note that, as described in [RFC8231], the LSP state synchronization covers both the bulk reporting of LSPs at initialization as well as the reporting of new or modified LSPs during normal operation. Incremental LSP-DB synchronization may be desired in a GMPLS-controlled network; it is specified in [RFC8232].
PCCとステートフルPCEの間のセッションが初期化された後、PCCはPCCの計算を実行したり、PCCでLSP属性を更新する前に、PCCのLSP（属性を含む）の状態を学習する必要があります。このプロセスは、「LSP状態同期」として知られています。帯域幅、関連するルート、保護情報などを含むLSP属性は、LSPデータベース（LSP-DB）のPCEによって保存されます。[RFC8231]で説明されているように、LSP状態の同期は、初期化時のLSPのバルク報告と、通常の動作中の新規または変更されたLSPの報告の両方をカバーしていることに注意してください。GMPLS制御ネットワークでは、増分LSP-DB同期が必要になる場合があります。[RFC8232]で指定されています。
The format of the PCRpt message is specified in [RFC8231] and extended in [RFC8623] to include the END-POINTS object. The END-POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS object can be carried in the PCRpt message as specified in [RFC8623]. The END-POINTS object type for GMPLS is included in the PCRpt message as per the same.
PCRPTメッセージの形式は[RFC8231]で指定され、[RFC8623]で拡張され、エンドポイントオブジェクトが含まれます。エンドポイントオブジェクトは、[RFC8779]のGMPLに対して拡張されています。エンドポイントオブジェクトは、[RFC8623]で指定されているように、PCRPTメッセージに携帯できます。GMPLSのエンドポイントオブジェクトタイプは、同じようにPCRPTメッセージに含まれています。
The following objects are extended for GMPLS in [RFC8779] and are also used in the PCRpt in the same manner: BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO). These objects are carried in the PCRpt message as specified in [RFC8231] (as the attribute-list defined in Section 6.5 of [RFC5440] and extended by many other documents that define PCEP extensions for specific scenarios).
次のオブジェクトは[RFC8779]のGMPLに対して拡張され、同じ方法でPCRPTで使用されます：帯域幅、LSP属性（LSPA）、ルートオブジェクト（IRO）を含む、およびルートオブジェクト（XRO）を除外します。これらのオブジェクトは、[RFC8231]で指定されているPCRPTメッセージ（[RFC5440]のセクション6.5で定義されており、特定のシナリオのPCEP拡張を定義する他の多くのドキュメントによって拡張された属性リストとして掲載されています。
The SWITCH-LAYER object is defined in [RFC8282]. This object is carried in the PCRpt message as specified in Section 3.2 of [RFC8282].
スイッチ層オブジェクトは[RFC8282]で定義されています。このオブジェクトは、[RFC8282]のセクション3.2で指定されているように、PCRPTメッセージに掲載されています。
The LSP delegation and cleanup procedure specified in [RFC8281] are equally applicable to GMPLS LSPs and this document does not modify the associated usage.
[RFC8281]で指定されたLSP委任およびクリーンアップ手順は、GMPLS LSPに等しく適用でき、このドキュメントは関連する使用法を変更しません。
Both passive and active stateful PCE mechanisms in [RFC8231] are applicable in GMPLS-controlled networks. Remote LSP Initiation in [RFC8281] is also applicable in GMPLS-controlled networks.
[RFC8231]の受動的およびアクティブなステートフルPCEメカニズムの両方が、GMPLS制御ネットワークに適用されます。[RFC8281]のリモートLSP開始は、GMPLS制御ネットワークにも適用できます。
Existing extensions defined in [RFC8779] can be used in stateful PCEP with no or slight changes for GMPLS network control, including the following:
[RFC8779]で定義されている既存の拡張機能は、GMPLSネットワークコントロールの変更なしまたはわずかな変更で、以下を含む、またはわずかな変更を加えることができます。
END-POINTS:
エンドポイント：
The END-POINTS object was specified in [RFC8779] to include GMPLS capabilities. All stateful PCEP messages MUST include the END-POINTS object with Generalized Endpoint object type, containing the LABEL-REQUEST TLV. Further note that: * As per [RFC8779], for stateless GMPLS path computation, the Generalized END-POINTS object may contain a LABEL-REQUEST and/ or LABEL-SET TLV. In this document, only the LABEL-REQUEST TLV is used to specify the switching type, encoding type, and G-PID of the LSP. * If unnumbered endpoint addresses are used for the LSP, the UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be used to specify the unnumbered endpoint addresses. * The Generalized END-POINTS object MAY contain other TLVs defined in [RFC8779].
end-pointsオブジェクトは[RFC8779]で指定され、GMPLS機能を含めました。すべてのStateful PCEPメッセージには、Label-Request TLVを含む一般化エンドポイントオブジェクトタイプのエンドポイントオブジェクトを含める必要があります。さらに次のことに注意してください。 * [RFC8779]によると、ステートレスGMPLSパス計算の場合、一般化されたエンドポイントオブジェクトには、ラベルリクエストおよび/またはラベルセットTLVが含まれる場合があります。このドキュメントでは、LSPのスイッチングタイプ、エンコーディングタイプ、およびG-PIDを指定するために、ラベルレクエストTLVのみが使用されます。* LSPには、非数のエンドポイントアドレスが使用されている場合は、非仮数のエンドポイントアドレスを指定するために、非仮定エンドポイントTLV [RFC8779]を使用する必要があります。*一般化されたエンドポイントオブジェクトには、[RFC8779]で定義されている他のTLVを含む場合があります。
RP:
RP：
The Request Parameter (RP) object extension (together with the Routing Granularity (RG) flag defined in [RFC8779]) is applicable in stateful PCEP for GMPLS networks.
要求パラメーター（RP）オブジェクト拡張（[RFC8779]で定義されているルーティング粒度（RG）フラグと一緒に）は、GMPLSネットワークのステートフルPCEPに適用されます。
BANDWIDTH:
帯域幅：
Generalized BANDWIDTH is specified in [RFC8779] to represent GMPLS features, including asymmetric bandwidth and G-PID information.
一般化された帯域幅は、非対称帯域幅やG-PID情報を含むGMPLS機能を表すために[RFC8779]で指定されています。
LSPA:
LSPA：
LSPA Extensions in Section 2.8 of [RFC8779] are applicable in stateful PCEP for GMPLS networks.
[RFC8779]のセクション2.8のLSPA拡張機能は、GMPLSネットワークのステートフルPCEPに適用されます。
IRO:
IRO：
IRO Extensions in Section 2.6 of [RFC8779] are applicable in stateful PCEP for GMPLS networks.
[RFC8779]のセクション2.6のIRO拡張機能は、GMPLSネットワークのStateful PCEPに適用されます。
XRO:
XRO：
XRO Extensions in Section 2.7 of [RFC8779] are applicable in stateful PCEP for GMPLS networks. A new flag is defined in Section 6.2.3 of this document.
[RFC8779]のセクション2.7のXRO拡張機能は、GMPLSネットワークのステートフルPCEPに適用されます。新しいフラグは、このドキュメントのセクション6.2.3で定義されています。
ERO:
エロ：
The Explicit Route Object (ERO) is not extended in [RFC8779], nor is it in this document.
明示的なルートオブジェクト（ERO）は[RFC8779]に拡張されておらず、このドキュメントにも拡張されていません。
SWITCH-LAYER:
スイッチレイヤー：
The SWITCH-LAYER definition in Section 3.2 of [RFC8282] is applicable in stateful PCEP messages for GMPLS networks.
[RFC8282]のセクション3.2のスイッチ層定義は、GMPLSネットワークのステートフルPCEPメッセージに適用できます。
In [RFC8779], IANA allocates value 45 (GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" subregistry. This specification adds three flags to the Flag field of this TLV to indicate the Report, Update, and Initiation capabilities.
[RFC8779]では、IANAは「PCEP TLVタイプインジケーター」から値45（GMPLSキャピール）を割り当てます。この仕様は、このTLVのフラグフィールドに3つのフラグを追加して、レポート、更新、および開始機能を示します。
R (LSP-REPORT-CAPABILITY (31) -- 1 bit):
R（LSP-Report-capability（31）-1ビット）：
If set to 1 by a PCC, the R flag indicates that the PCC is capable of reporting the current state of a GMPLS LSP whenever there's a change to the parameters or operational status of the GMPLS LSP. If set to 1 by a PCE, the R flag indicates that the PCE is interested in receiving GMPLS LSP State Reports whenever there is a parameter or operational status change to the LSP. The LSP-REPORT-CAPABILITY flag must be advertised by both a PCC and a PCE for PCRpt messages to be allowed on a PCEP session for GMPLS LSP.
PCCによって1に設定されている場合、Rフラグは、PCCがGMPLS LSPのパラメーターまたは動作ステータスに変更があるたびにGMPLS LSPの現在の状態を報告できることを示します。PCEによって1に設定されている場合、Rフラグは、PCEがLSPにパラメーターまたは運用ステータスの変更があるたびにGMPLS LSP状態レポートを受信することに関心があることを示します。LSP-Report-Capabilityフラグは、GMPLS LSPのPCEPセッションで許可されるPCCとPCRPTメッセージのPCEの両方によって宣伝する必要があります。
U (LSP-UPDATE-CAPABILITY (30) -- 1 bit):
u（lsp-update-capability（30） - 1ビット）：
If set to 1 by a PCC, the U flag indicates that the PCC allows modification of GMPLS LSP parameters. If set to 1 by a PCE, the U flag indicates that the PCE is capable of updating GMPLS LSP parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd messages to be allowed on a PCEP session for GMPLS LSP.
PCCによって1に設定されている場合、Uフラグは、PCCがGMPLS LSPパラメーターの変更を許可することを示します。PCEで1に設定されている場合、Uフラグは、PCEがGMPLS LSPパラメーターを更新できることを示します。LSP-Update-Capabilityフラグは、GMPLS LSPのPCEPセッションでPCUPDメッセージのPCCとPCEの両方によって宣伝する必要があります。
I (LSP-INSTANTIATION-CAPABILITY (29) -- 1 bit):
I（lsp-instantiation-capability（29） - 1ビット）：
If set to 1 by a PCC, the I flag indicates that the PCC allows instantiation of a GMPLS LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the PCE supports instantiating GMPLS LSPs. The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC and PCE in order to enable PCE-initiated LSP instantiation.
PCCによって1に設定されている場合、Iフラグは、PCCがPCEによってGMPLS LSPのインスタンス化を許可することを示します。PCEによって1に設定されている場合、Iフラグは、PCEがインスタンス化GMPLS LSPをサポートしていることを示します。PCE開始LSPインスタンス化を有効にするために、LSP-inStantiation-CapabilityフラグをPCCとPCEの両方によって設定する必要があります。
[RFC5521] defines a mechanism for a PCC to request or demand that specific nodes, links, or other network resources be excluded from paths computed by a PCE. A PCC may wish to request the computation of a path that avoids all links and nodes traversed by some other LSP.
[RFC5521]は、PCCがPCEによって計算されたパスから特定のノード、リンク、またはその他のネットワークリソースを要求または要求または要求または要求するメカニズムを定義します。PCCは、他のLSPによって移動されたすべてのリンクとノードを回避するパスの計算を要求する場合があります。
To this end, this document defines a new subobject for use with route exclusion defined in [RFC5521]. The LSP Exclusion subobject is as follows:
この目的のために、このドキュメントは、[RFC5521]で定義されたルート除外で使用する新しいサブオブジェクトを定義します。LSP除外サブオブジェクトは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Type (11) | Length | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New LSP Exclusion Subobject Format
図1：新しいLSP除外サブオブジェクト形式
X:
バツ：
This field is the same as the X-bit defined in the XRO subobjects in Section 2.1.1 of [RFC5521] where it says: The X-bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the resource.
このフィールドは、[RFC5521]のセクション2.1.1のXROサブオブジェクトで定義されているXビットと同じです。0は、指定されたリソースがPCEによって計算されたパスから除外する必要があることを示します。1は、指定されたリソースをPCEによって計算されたパスから除外する必要があることを示しますが、PCEポリシーと、他の制約を満たし、リソースを除外する実行可能なパスの欠如の対象となる場合があります。
Type:
タイプ：
The subobject type for an LSP Exclusion subobject. Value of 11.
LSP除外サブオブジェクトのサブオブジェクトタイプ。11の値。
Length:
長さ：
The Length contains the total length of the subobject in bytes, including the Type and Length fields.
長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。
Reserved:
予約済み：
Reserved MUST be set to zero on transmission and ignored on receipt.
予約済みは、送信時にゼロに設定し、受領時に無視する必要があります。
Flags:
フラグ：
This field may be used to further specify the exclusion constraint with regard to the LSP. Currently, no flags are defined.
このフィールドは、LSPに関する除外制約をさらに指定するために使用できます。現在、フラグは定義されていません。
Symbolic Path Name:
シンボリックパス名：
This is the identifier given to an LSP. Its syntax and semantics are identical to those of the Symbolic Path Name field defined in Section 7.3.2 of [RFC8231] where it says: "symbolic name for the LSP, unique in the PCC. It SHOULD be a string of printable ASCII characters, without a NULL terminator." The symbolic path name in the LSP Exclusion subobject MUST only vary from being a string of printable ASCII characters without a NULL terminator when it is matching the value contained in another subobject. It is worth noting that given that the symbolic path name is unique in the context of the headnode, only LSPs that share the same headnode or PCC could be excluded. This subobject MAY be present multiple times in the XRO to exclude resources from multiple LSPs. When a stateful PCE receives a PCReq message carrying this subobject, it MUST search for the identified LSP in its LSP-DB and then exclude from the new path computation all resources used by the identified LSP. Note that this XRO subobject could also be used by non-GMPLS LSPs. The usage of the XRO subobject for any non-GMPLS LSPs is not in the scope of this document.
これは、LSPに与えられた識別子です。その構文とセマンティクスは、[RFC8231]のセクション7.3.2で定義されているシンボリックパス名フィールドのフィールドと同一です。ヌルターミネーターなし。」LSP除外サブオブジェクトのシンボリックパス名は、別のサブオブジェクトに含まれる値と一致している場合、ヌルターミネーターのない一連の印刷可能なASCII文字であることによってのみ異なる必要があります。シンボリックパス名がヘッドノードのコンテキストで一意であることを考えると、同じヘッドノードまたはPCCを共有するLSPのみを除外できることは注目に値します。このサブオブジェクトは、複数のLSPからリソースを除外するためにXROに複数回存在する場合があります。ステートフルなPCEがこのサブオブジェクトを運ぶPCREQメッセージを受信すると、識別されたLSPをLSP-DBで検索し、新しいパスから除外する必要があります。このXROサブオブジェクトは、非GMPLS LSPでも使用できることに注意してください。非GMPLS LSPSのXroサブオブジェクトの使用は、このドキュメントの範囲内ではありません。
The LSP object is defined in Section 7.3 of [RFC8231], and the new extended flags TLV is defined in [RFC9357]. This TLV is used in PCUpd, PCRpt and PCInitiate messages for GMPLS, with the following flags defined in this document:
LSPオブジェクトは[RFC8231]のセクション7.3で定義されており、新しい拡張フラグTLVは[RFC9357]で定義されています。このTLVは、GMPLSのPCUPD、PCRPT、PCINITIATEメッセージで使用され、次のフラグがこのドキュメントで定義されています。
G (GMPLS LSP (0) -- 1 bit):
g（gmpls lsp（0）-1ビット）：
If set to 1, it indicates the LSP is a GMPLS LSP.
1に設定すると、LSPがGMPLS LSPであることを示します。
B (Bidirectional LSP (1) -- 1 bit):
B（双方向LSP（1）-1ビット）：
If set to 0, it indicates a request to create a unidirectional LSP. If set to 1, it indicates a request to create a bidirectional co-routed LSP.
0に設定すると、単方向LSPを作成するリクエストが示されます。1に設定されている場合、双方向の共同ルートLSPを作成するリクエストを示します。
RG (Routing Granularity (2-3) -- 2 bits):
RG（ルーティング粒度（2-3） - 2ビット）：
00:
00：
reserved
予約済み備蓄控え目貸し切り貸切り借り切り寡黙いじいじ予約した
01:
01：
node
ノード節点節
10:
10：
link
リンク接続繋がり結ぶつなぎ目連ねる合わせる合わす環併設伝送路連結する関係つける
11:
11：
label
ラベル付箋荷札票付け紙下げ札付け札はり紙をする
The RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG TLV. The values are defined as per [RFC8779]: 00: reserved 01: node 10: link 11: label
GMPLSのRGフラグは、LSP拡張フラグTLVでも定義されています。値は[RFC8779]：00：予約された01：ノード10：リンク11：ラベル
A PCEP-ERROR object is used to report a PCEP error and is characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error. This section adds additional error handling procedures to those specified in Section 3 of [RFC8779]. Please note that all error handling specified in Section 3 of [RFC8779] is applicable and MUST be supported for a stateful PCE in GMPLS networks.
PCEP-ERRORオブジェクトは、PCEPエラーを報告するために使用され、エラーのタイプとエラーに関する追加情報を提供するエラー値を指定するエラータイプによって特徴付けられます。このセクションでは、[RFC8779]のセクション3で指定されているものに追加のエラー処理手順を追加します。[RFC8779]のセクション3で指定されたすべてのエラー処理が適用され、GMPLSネットワークのステートフルPCEでサポートする必要があることに注意してください。
The PCEP extensions described in this document for stateful PCEs with GMPLS capabilities MUST NOT be used if the PCE has not advertised its capabilities with GMPLS as per Section 6.2.1.
このドキュメントで説明されているPCEP拡張機能は、GMPLS機能を備えたStateful PCESについては、PCEがセクション6.2.1に従ってGMPLSでその機能を宣伝していない場合は、使用しないでください。
If the PCC understands the U flag that indicates the stateful LSP-UPDATE-CAPABILITY, but did not advertise this capability, then upon receipt of a PCUpd message for GMPLS LSP from the PCE, it SHOULD generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value 25 ("Attempted LSP update request for GMPLS if stateful PCE capability not advertised") and terminate the PCEP session. Such a PCC MAY decide to utilize the capability even though it did not advertise support for it.
PCCが、ステートフルなLSP-Updateの能力を示すが、この機能を宣伝しなかったUフラグを理解している場合、PCEからGMPLS LSPのPCUPDメッセージを受信すると、エラータイプ19（」でPCERRを生成するはずです。無効な操作 "）エラー値25（「ステートフルPCE機能が宣伝されていない場合のGMPLSのLSP更新リクエストの試み」）およびPCEPセッションを終了します。このようなPCCは、サポートを宣伝していなくても、機能を利用することを決定する場合があります。
If the PCE understands the R flag that indicates the stateful LSP-REPORT-CAPABILITY, but did not advertise this capability, then upon receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value 26 ("Attempted LSP State Report for GMPLS if stateful PCE capability not advertised") and terminate the PCEP session. Such a PCE MAY decide to utilize the capability even though it did not advertise support for it.
PCEが、ステートフルLSPレポートの能力を示すが、この機能を宣伝しなかったRフラグを理解している場合、PCCからGMPLS LSPのPCRPTメッセージを受信すると、エラータイプ19（」でPCERRを生成するはずです。無効な操作 "）エラー値26（「ステートフルPCE機能が宣伝されていない場合のGMPLSのLSP状態レポートの試み」）およびPCEPセッションを終了します。このようなPCEは、サポートを宣伝していなくても、機能を利用することを決定する場合があります。
If the PCC understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY, but did not advertise this capability, then upon receipt of a PCInitiate message for GMPLS LSP from the PCE, it SHOULD generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value 27 ("Attempted LSP instantiation request for GMPLS if stateful PCE instantiation capability for not advertised") and terminate the PCEP session. Such a PCC MAY decide to utilize the capability even though it did not advertise support for it.
PCCがLSP-inStantiationの能力を示しているがこの機能を宣伝しなかったIフラグを理解している場合、PCEからGMPLS LSPのPCINITIATEメッセージを受信すると、エラータイプ19でPCERRを生成するはずです（ "無効操作"）エラー値27（「宣伝されていない場合のステートフルPCEインスタンス化機能の場合、GMPLSのLSPインスタンス化リクエストの試み」とPCEPセッションを終了します。このようなPCCは、サポートを宣伝していなくても、機能を利用することを決定する場合があります。
A stateful PCE is expected to perform an LSP reoptimization when receiving a message with the R bit set in the RP object. If no LSP state information is available to carry out reoptimization, the stateful PCE SHOULD report Error-Type 19 ("Invalid Operation") Error-value 23 ("LSP state info unavailable for reoptimization"), although such a PCE MAY consider the reoptimization to have successfully completed. Note that this error message could also be used by non-GMPLS LSPs.
Stateful PCEは、RPオブジェクトにR BITセットを使用してメッセージを受信するときにLSPの再最適化を実行することが期待されています。LSPの状態情報が再最適化を実行できる場合、ステートフルPCEはエラータイプ19（「無効操作」）エラー値23（「LSP状態情報が再現できない」）を報告する必要がありますが、そのようなPCEは再最適化を検討するかもしれませんが正常に完了しました。このエラーメッセージは、非GMPLS LSPでも使用できることに注意してください。
The LSP Exclusion subobject in XRO, as defined in Section 6.2.2 of this document, MAY be present multiple times. When a stateful PCE receives a PCEP message carrying this subobject, it searches for the identified LSP in its LSP-DB. It then excludes from the new path computation all the resources used by the identified LSP. If the stateful PCE cannot recognize the symbolic path name of the identified LSP, it SHOULD send an error message PCErr reporting Error-Type 19 ("Invalid Operation") Error-value 24 ("LSP state info for route exclusion not found"). Along with the unrecognized symbolic path name, it MAY also provide information to the requesting PCC using the error-reporting techniques described in [RFC5440]. An implementation MAY choose to ignore the requested exclusion when the LSP cannot be found because it could claim that it has avoided using all resources associated with an LSP that doesn't exist.
このドキュメントのセクション6.2.2で定義されているように、XroのLSP除外サブオブジェクトは、複数回存在する場合があります。ステートフルなPCEがこのサブオブジェクトを運ぶPCEPメッセージを受信すると、LSP-DBで特定されたLSPを検索します。次に、識別されたLSPで使用されるすべてのリソースを新しいパス計算から除外します。ステートフルPCEが識別されたLSPのシンボリックパス名を認識できない場合、エラーメッセージPCERRレポートエラータイプ19（「無効な操作」）エラー値24（「ルート除外のLSP状態情報」）を送信する必要があります。認識されていないシンボリックパス名に加えて、[RFC5440]で説明されているエラー報告手法を使用して、要求PCCに情報を提供する場合があります。実装は、存在しないLSPに関連付けられたすべてのリソースを使用して回避したと主張できるため、LSPが見つからない場合、要求された除外を無視することを選択する場合があります。
Note that the END-POINTS object in stateful PCEP messages was introduced for Point-to-Multipoint (P2MP) [RFC8623]. Similarly, the END-POINTS object MUST be carried for the GMPLS LSP. If the END-POINTS object is missing and the GMPLS flag in LSP-EXTENDED-FLAG is set, the receiving PCE or PCC MUST send a PCErr message with Error-Type 6 ("Mandatory Object missing") and Error-value 3 ("END-POINTS object missing") (defined in [RFC5440]). Similarly, if the END-POINTS object with the Generalized Endpoint object type is received but the LSP-EXTENDED-FLAG TLV is missing in the LSP object or the G flag in the LSP-EXTENDED-FLAG TLV is not set, the receiving PCE or PCC MUST send a PCErr message with Error-Type 19 ("Invalid Operation") Error-value 28 ("Use of the Generalized Endpoint object type for non-GMPLS LSPs").
Stateful PCEPメッセージのエンドポイントオブジェクトは、ポイントツーマルチポイント（P2MP）[RFC8623]に導入されたことに注意してください。同様に、GMPLS LSPに対してエンドポイントオブジェクトを運ぶ必要があります。エンドポイントオブジェクトが欠落し、LSP拡張型フラグのGMPLSフラグが設定されている場合、受信PCCまたはPCCは、エラータイプ6（「必須オブジェクトの欠落」）およびエラー値3（ "エンドポイントオブジェクトの欠落 "）（[RFC5440]で定義）。同様に、一般化されたエンドポイントオブジェクトタイプを持つエンドポイントオブジェクトが受信されたが、LSPオブジェクトまたはLSPエクステンデッドフラグTLVのGフラグにLSP拡張フラグTLVが欠落している場合、受信PCEまたは受信PCEまたはPCCは、エラータイプ19（「無効操作」）エラー値28（「非GMPLS LSPSの一般化エンドポイントオブジェクトタイプの使用」）を使用してPCERRメッセージを送信する必要があります。
If the END-POINTS object with Generalized Endpoint object type is missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a PCErr message with Error-Type 6 ("Mandatory Object missing") Error-value 20 ("LABEL-REQUEST TLV missing").
一般化されたエンドポイントオブジェクトタイプを持つエンドポイントオブジェクトがラベルリケストTLVを欠いている場合、受信PCCまたはPCCはエラータイプ6（ "必須オブジェクトの欠落"）エラー値20（ "label-requestを使用してPCERRメッセージを送信する必要があります。TLV欠落 "）。
[RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA created the "GMPLS-CAPABILITY TLV Flag Field" registry to manage the values of the GMPLS-CAPABILITY TLV's Flag field. This document registers new bits in this registry as follows:
[RFC8779]は、GMPLSキャピールTLVを定義します。そのRFCに従って、IANAは「GMPLSキャピールTLVフラグフィールド」レジストリを作成して、GMPLSキャピールTLVのフラグフィールドの値を管理しました。このドキュメントは、次のようにこのレジストリの新しいビットを登録します。
+=====+==================================+===========+
| Bit | Capability Description | Reference |
+=====+==================================+===========+
| 31 | LSP-REPORT-CAPABILITY (R) | RFC 9504 |
+-----+----------------------------------+-----------+
| 30 | LSP-UPDATE-CAPABILITY (U) | RFC 9504 |
+-----+----------------------------------+-----------+
| 29 | LSP-INSTANTIATION-CAPABILITY (I) | RFC 9504 |
+-----+----------------------------------+-----------+
Table 1
IANA maintains the various XRO subobject types within the "XRO Subobjects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated a codepoint for another XRO subobject as follows:
IANAは、「Xroサブオブジェクト」の「パス計算要素プロトコル（PCEP）番号」レジストリの「XRO Subobjects」サブレジストリ内のさまざまなXroサブオブジェクトタイプを維持しています。IANAは、次のように別のXROサブオブジェクトにコードポイントを割り当てました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 11 | LSP | RFC 9504 |
+-------+-------------+-----------+
Table 2
IANA has created a registry named "LSP Exclusion Subobject Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" group, to manage the Flag field of the LSP Exclusion subobject in the XRO. No flag is currently defined for this Flag field in this document.
IANAは、XROのLSP排除サブオブジェクトのフラグフィールドを管理するために、「PATH計算要素プロトコル（PCEP）番号」グループ内に「LSP Exclusion Subobject Flagフィールド」という名前のレジストリを作成しました。このドキュメントでは、このフラグフィールドのフラグは現在定義されていません。
Codespace of the Flag field (LSP Exclusion Subobject)
フラグフィールドのコードスペース（LSP除外サブオブジェクト）
+=====+========================+===========+
| Bit | Capability Description | Reference |
+=====+========================+===========+
| 0-7 | Unassigned | RFC 9504 |
+-----+------------------------+-----------+
Table 3
New values are to be assigned by Standards Action [RFC8126]. Each bit should be registered with the following entries:
新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次のエントリに登録する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（最も重要なビットとしてビット0からカウント）
* Capability description
* 機能の説明
* Reference to defining RFC
* RFCの定義への参照
[RFC9357] requested IANA to create a subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the LSP-EXTENDED-FLAG TLV.
[RFC9357]は、「PATH計算要素プロトコル（PCEP）数字」レジストリ内で、「LSP拡張FLAG TLV Flagフィールド」という名前のサブレジストリを作成するようにIANAに要求し、LSP-Extended-Flag TLVのフラグフィールドを管理します。。
IANA has made assignments from this registry as follows:
IANAは次のようにこのレジストリから割り当てを行いました。
+=====+=================================+===========+
| Bit | Capability Description | Reference |
+=====+=================================+===========+
| 0 | GMPLS LSP (G) | RFC 9504 |
+-----+---------------------------------+-----------+
| 1 | Bidirectional Co-routed LSP (B) | RFC 9504 |
+-----+---------------------------------+-----------+
| 2-3 | Routing Granularity (RG) | RFC 9504 |
+-----+---------------------------------+-----------+
Table 4
IANA has made the following allocations in the "PCEP-ERROR Object Error Types and Values" registry.
IANAは、「PCEP-Errorオブジェクトエラータイプと値」レジストリで次の割り当てを行いました。
+============+===========+===========================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+===========+===========================+===========+
| 6 | Mandatory | 20: LABEL-REQUEST TLV | RFC 9504 |
| | Object | missing | |
| | missing | | |
+------------+-----------+---------------------------+-----------+
| 19 | Invalid | 23: LSP state info | RFC 9504 |
| | Operation | unavailable for | |
| | | reoptimization | |
| | +---------------------------+-----------+
| | | 24: LSP state info for | RFC 9504 |
| | | route exclusion not found | |
| | +---------------------------+-----------+
| | | 25: Attempted LSP update | RFC 9504 |
| | | request for GMPLS if | |
| | | stateful PCE capability | |
| | | not advertised | |
| | +---------------------------+-----------+
| | | 26: Attempted LSP State | RFC 9504 |
| | | Report for GMPLS if | |
| | | stateful PCE capability | |
| | | not advertised | |
| | +---------------------------+-----------+
| | | 27: Attempted LSP | RFC 9504 |
| | | instantiation request for | |
| | | GMPLS if stateful PCE | |
| | | instantiation capability | |
| | | not advertised | |
| | +---------------------------+-----------+
| | | 28: Use of the | RFC 9504 |
| | | Generalized Endpoint | |
| | | object type for non-GMPLS | |
| | | LSPs | |
+------------+-----------+---------------------------+-----------+
Table 5
General PCE management considerations are discussed in [RFC4655] and [RFC5440], and GMPLS-specific PCEP management considerations are described in [RFC8779]. In this document, the management considerations for stateful PCEP extension in GMPLS are described.
一般的なPCE管理の考慮事項は[RFC4655]および[RFC5440]で議論されており、GMPLS固有のPCEP管理に関する考慮事項は[RFC8779]で説明されています。このドキュメントでは、GMPLSのステートフルなPCEP拡張に関する管理上の考慮事項について説明します。
This section follows the guidance of [RFC6123].
このセクションは、[RFC6123]のガイダンスに従います。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCC. However, an implementation MAY choose to make these features available on all PCEP sessions:
[RFC5440]のセクション8.1に既にリストされているパラメーターに加えて、PCCPの実装により、PCCの次のPCEPセッションパラメーターの構成が可能になります。ただし、実装により、これらの機能をすべてのPCEPセッションで利用できるようにすることができます。
* The ability to send stateful PCEP messages for GMPLS LSPs.
* GMPLS LSPのステートフルPCEPメッセージを送信する機能。
* The ability to use path computation constraints (e.g., XRO).
* パス計算制約（XROなど）を使用する機能。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCE:
[RFC5440]のセクション8.1に既にリストされているパラメーターに加えて、PCEP実装は、PCEで次のPCEPセッションパラメーターを構成できるようにする必要があります。
* The ability to compute paths in a stateful manner in GMPLS networks.
* GMPLSネットワークでステートフルな方法でパスを計算する機能。
* A set of GMPLS-specific constraints.
* GMPLS固有の制約のセット。
These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in or they may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers.
これらのパラメーターは、PCEPスピーカーが参加する任意のPCEPセッションのデフォルトパラメーターとして構成されるか、特定のPCEPピアとの特定のセッションまたは特定のPCEPピアグループとの特定のセッショングループのグループに適用される場合があります。
The YANG module in [PCE-PCEP-YANG] can be used to configure and monitor PCEP states and messages. To make sure that the YANG module is useful for the extensions as described in this document, it would need to include advertised GMPLS stateful capabilities etc. A future version of [PCE-PCEP-YANG] will include this.
[PCE-PCEP-Yang]のYangモジュールを使用して、PCEPの状態とメッセージを構成および監視できます。このドキュメントで説明されているように、Yangモジュールが拡張機能に役立つことを確認するには、広告のGMPLSステートフルな機能などを含める必要があります。
As described in [YANG-PATH-COMPUTATION], a YANG-based interface can be used in some cases to request GMPLS path computations, instead of PCEP. Refer to [YANG-PATH-COMPUTATION] for details.
[Yang-Path-Computation]で説明されているように、Yangベースのインターフェイスを使用して、PCEPの代わりにGMPLSパス計算を要求するために使用できます。詳細については、[Yang-Path-Computation]を参照してください。
This document makes no change to the basic operation of PCEP, so there are no changes to the requirements for liveness detection and monitoring in [RFC4657] and Section 8.3 of [RFC5440].
このドキュメントは、PCEPの基本的な動作に変更を加えないため、[RFC4657]および[RFC5440]のセクション8.3の責任検出と監視の要件に変更はありません。
This document makes no change to the basic operations of PCEP and the considerations described in Section 8.4 of [RFC5440]. New errors defined by this document should satisfy the requirement to log error events.
このドキュメントは、PCEPの基本操作と[RFC5440]のセクション8.4で説明されている考慮事項に変更を加えません。このドキュメントで定義された新しいエラーは、エラーイベントを記録するための要件を満たす必要があります。
When the detailed route information is included for LSP state synchronization (either at the initial stage or during the LSP State Report process), this requires the ingress node of an LSP to carry the Record Route Object (RRO) object in order to enable the collection of such information.
LSP状態の同期に詳細なルート情報が含まれている場合（初期段階またはLSP状態レポートプロセス中）、これには、レコードルートオブジェクト（RRO）オブジェクトを運ぶためにLSPの侵入ノードがコレクションを有効にする必要があります。そのような情報の。
The management considerations concerning the impact on network operations described in Section 4.6 of [RFC8779] apply here.
[RFC8779]のセクション4.6で説明されているネットワーク操作への影響に関する管理上の考慮事項は、ここに適用されます。
The security considerations elaborated in [RFC5440] apply to this document. The PCEP extensions to support GMPLS-controlled networks should be considered under the same security as for MPLS networks, as noted in [RFC7025]. Therefore, the PCEP extension to support GMPLS specified in [RFC8779] is used as the foundation of this document; the security considerations in [RFC8779] should also be applicable to this document. The secure transport of PCEP specified in [RFC8253] allows the usage of Transport Layer Security (TLS). The same can also be used by the PCEP extension defined in this document.
[RFC5440]で詳しく説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。[RFC7025]に記載されているように、GMPLS制御ネットワークをサポートするPCEP拡張機能は、MPLSネットワークと同じセキュリティの下で考慮する必要があります。したがって、[RFC8779]で指定されたGMPLSをサポートするPCEP拡張は、このドキュメントの基礎として使用されます。[RFC8779]のセキュリティ上の考慮事項もこのドキュメントに適用できる必要があります。[RFC8253]で指定されたPCEPの安全な輸送により、輸送層セキュリティ（TLS）の使用が可能になります。このドキュメントで定義されているPCEP拡張でも同じことが使用できます。
This document provides additional extensions to PCEP so as to facilitate stateful PCE usage in GMPLS-controlled networks, on top of [RFC8231] and [RFC8281]. Security issues caused by the extension in [RFC8231] and [RFC8281] are not altered by the additions in this document. The security considerations in [RFC8231] and [RFC8281], including both issues and solutions, apply to this document as well.
このドキュメントは、[RFC8231]および[RFC8281]の上にあるGMPLS制御ネットワークでのステートフルPCE使用を促進するために、PCEPへの追加の拡張を提供します。[RFC8231]および[RFC8281]の拡張によって引き起こされるセキュリティの問題は、このドキュメントの追加によって変更されません。[RFC8231]および[RFC8281]のセキュリティ上の考慮事項は、問題とソリューションの両方を含め、このドキュメントにも適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <https://www.rfc-editor.org/info/rfc5521>.
[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>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>.
[RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", RFC 9357,
DOI 10.17487/RFC9357, February 2023,
<https://www.rfc-editor.org/info/rfc9357>.
[PCE-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-22, 11 September
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-22>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[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>.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, DOI 10.17487/RFC7025, September 2013,
<https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
to the Path Computation Element Communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", RFC 8282, DOI 10.17487/RFC8282, December
2017, <https://www.rfc-editor.org/info/rfc8282>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[YANG-PATH-COMPUTATION]
Busi, I., Ed., Belotti, S., Ed., de Dios, O. G., Sharma,
A., and Y. Shi, "A YANG Data Model for requesting path
computation", Work in Progress, Internet-Draft, draft-
ietf-teas-yang-path-computation-21, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-path-computation-21>.
This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to illustrate the PCEP messages. The RBNF in this section is reproduced for informative purposes. It is also expanded to show the GMPLS-specific objects.
このセクションでは、ルーティングBackus-Naurフォーム（RBNF）[RFC5511]を使用して、PCEPメッセージを説明します。このセクションのRBNFは、有益な目的で再現されています。また、GMPLS固有のオブジェクトを表示するために拡張されます。
According to [RFC8231], the PCRpt message is used to report the current state of an LSP. This document extends the message in reporting the status of LSPs with GMPLS characteristics.
[RFC8231]によると、PCRPTメッセージは、LSPの現在の状態を報告するために使用されます。このドキュメントは、GMPLS特性を持つLSPのステータスを報告する際のメッセージを拡張します。
The format of the PCRpt message is as follows:
PCRPTメッセージの形式は次のとおりです。
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
ただし：
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<END-POINTS>]
<path>
Where:
ただし：
<path> ::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list> ::=[<BANDWIDTH>]
[<metric-list>]
Where:
ただし：
* The END-POINTS object MUST be carried in a PCRpt message when the G flag is set in the LSP-EXTENDED-FLAG TLV in the LSP object for a GMPLS LSP.
* GMPLS LSPのLSPオブジェクトのLSPエクステンデッドフラグTLVにGフラグが設定されている場合、エンドポイントオブジェクトをPCRPTメッセージに携帯する必要があります。
* <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440] and augmented in [RFC8779] with ELC.
* <Ented-Path>は、[RFC5440]のセクション7.9で定義されたEROオブジェクトで表され、[RFC8779]でELCと拡張されています。
* <actual-attribute-list> consists of the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
* <実際のアトリブリスト>は、[RFC5440]で定義されている<BandWidth>および<メトリックリスト>オブジェクトの実際の計算値と信号値で構成されています。
* <actual-path> is represented by the RRO object defined in Section 7.10 of [RFC5440].
* <実際のパス>は、[RFC5440]のセクション7.10で定義されているRROオブジェクトで表されます。
* <intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended by many other documents that define PCEP extensions for specific scenarios as shown below:
* <目的aTtribute-list>は、[RFC5440]のセクション6.5で定義されている属性リストであり、以下に示すように特定のシナリオのPCEP拡張機能を定義する他の多くのドキュメントによって拡張されました。
<attribute-list> ::= [<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>][<XRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
The format of a PCUpd message is as follows:
PCUPDメッセージの形式は次のとおりです。
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
ただし：
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
[<END-POINTS>]
<path>
Where:
ただし：
<path> ::= <intended-path><intended-attribute-list>
Where:
ただし：
* The END-POINTS object MUST be carried in a PCUpd message for the GMPLS LSP.
* end-pointsオブジェクトは、GMPLS LSPのPCUPDメッセージに携帯する必要があります。
* <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440], augmented in [RFC8779] with ELC.
* <Ented-Path>は、[RFC5440]のセクション7.9で定義されたEROオブジェクトで表され、[RFC8779]でELCで増強されています。
* <intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by many other documents that define PCEP extensions for specific scenarios and as shown for PCRpt above.
* <目的aTtribute-list>は、[RFC5440]で定義されており、特定のシナリオのPCEP拡張機能を定義する他の多くのドキュメントによって拡張され、上記のPCRPTに示されている属性リストです。
According to [RFC8281], the PCInitiate message is used allow LSP Initiation. This document extends the message in initiating LSPs with GMPLS characteristics. The format of a PCInitiate message is as follows:
[RFC8281]によると、PCINITIATEメッセージが使用されています。LSPの開始が許可されています。このドキュメントは、GMPLS特性を使用してLSPを開始する際にメッセージを拡張します。pcinitiateメッセージの形式は次のとおりです。
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
ただし：
<Common Header> is defined in <xref target="RFC5440" />.
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
The format of the PCInitiate message is unchanged from Section 5.1 of [RFC8281]. All fields are similar to the PCRpt and the PCUpd messages.
PCInitiateメッセージの形式は、[RFC8281]のセクション5.1から変化していません。すべてのフィールドは、PCRPTおよびPCUPDメッセージに似ています。
We would like to thank Adrian Farrel, Cyril Margaria, George Swallow, Jan Medved, Sue Hares, and John Scudder for the useful comments and discussions.
エイドリアン・ファレル、シリル・マーガリア、ジョージ・スワロー、ヤン・メドベッド、スー・ハーズ、ジョン・スカダーに有用なコメントとディスカッションに感謝します。
Thanks to Dhruv Dhody for Shepherding this document and providing useful comments.
この文書を羊飼いし、有用なコメントを提供してくれたDhruv Dhodyに感謝します。
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technology
India
Email: dhruv.ietf@gmail.com
Yi Lin
Huawei Technologies
Email: yi.lin@huawei.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
08860 Barcelona Castelldefels
Spain
Email: ramon.casellas@cttc.es
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Robert Varga
Pantheon Technologies
Email: nite@hq.sk
Young Lee
Samsung
Email: younglee.tx@gmail.com
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Victor Lopez
Nokia
Email: victor.lopez@nokia.com
Zafar Ali
Cisco
Email: zali@cisco.com