[要約] RFC 8779は、GMPLSのためのPCEP拡張に関する規格であり、PCEとPCC間の通信プロトコルを定義しています。目的は、GMPLSネットワークでの経路計算と制御を効率化し、ネットワークの性能と信頼性を向上させることです。
Internet Engineering Task Force (IETF) C. Margaria, Ed.
Request for Comments: 8779 Juniper
Category: Standards Track O. Gonzalez de Dios, Ed.
ISSN: 2070-1721 Telefonica Investigacion y Desarrollo
F. Zhang, Ed.
Huawei Technologies
July 2020
Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS
GMPLSのパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025.
パス計算エレメント（PCE）は、マルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークにパス計算機能を提供します。 GMPLSの追加要件は、RFC 7025で規定されています。
This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.
このメモは、GMPLSコントロールプレーンがこれらの要件に対処するためのサポートのために、パス計算要素通信プロトコル（PCEP）への拡張を提供します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8779.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8779で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 1.1. Terminology 1.2. PCEP Requirements for GMPLS 1.3. Requirements Applicability 1.3.1. Requirements on the Path Computation Request 1.3.2. Requirements on the Path Computation Response 1.4. Existing Support and Limitations for GMPLS in Base PCEP Objects 2. PCEP Objects and Extensions 2.1. GMPLS Capability Advertisement 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery Protocol 2.1.2. OPEN Object Extension GMPLS-CAPABILITY TLV 2.2. RP Object Extension 2.3. BANDWIDTH Object Extensions 2.4. LOAD-BALANCING Object Extensions 2.5. END-POINTS Object Extensions 2.5.1. Generalized Endpoint Object Type 2.5.2. END-POINTS TLV Extensions 2.6. IRO Extension 2.7. XRO Extension 2.8. LSPA Extensions 2.9. NO-PATH Object Extension 2.9.1. Extensions to NO-PATH-VECTOR TLV 3. Additional Error-Types and Error-Values Defined 4. Manageability Considerations 4.1. Control of Function through Configuration and Policy 4.2. Information and Data Models 4.3. Liveness Detection and Monitoring 4.4. Verifying Correct Operation 4.5. Requirements on Other Protocols and Functional Components 4.6. Impact on Network Operation 5. IANA Considerations 5.1. PCEP Objects 5.2. Endpoint Type Field in the Generalized END-POINTS Object 5.3. New PCEP TLVs 5.4. RP Object Flag Field 5.5. New PCEP Error Codes 5.6. New Bits in NO-PATH-VECTOR TLV 5.7. New Subobject for the Include Route Object 5.8. New Subobject for the Exclude Route Object 5.9. New GMPLS-CAPABILITY TLV Flag Field 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Appendix A. LOAD-BALANCING Usage for SDH Virtual Concatenation Acknowledgments Contributors Authors' Addresses
1. はじめに1.1。用語1.2。 GMPLS 1.3のPCEP要件。要件の適用性1.3.1。パス計算リクエストの要件1.3.2。パス計算応答の要件1.4。ベースPCEPオブジェクトにおけるGMPLSの既存のサポートと制限2. PCEPオブジェクトと拡張2.1。 GMPLS機能のアドバタイズメント2.1.1。既存のPCE検出プロトコルのGMPLS計算TLV 2.1.2。 OPEN Object Extension GMPLS-CAPABILITY TLV 2.2。 RPオブジェクト拡張2.3。 BANDWIDTHオブジェクト拡張2.4。 LOAD-BALANCINGオブジェクト拡張2.5。 END-POINTSオブジェクト拡張2.5.1。一般化されたエンドポイントオブジェクトタイプ2.5.2。エンドポイントTLV拡張2.6。 IRO Extension 2.7。 XRO Extension 2.8。 LSPA拡張2.9。 NO-PATHオブジェクト拡張2.9.1。 NO-PATH-VECTOR TLVの拡張3.定義された追加のエラータイプとエラー値4.管理性の考慮事項4.1。設定とポリシーによる機能の制御4.2。情報およびデータモデル4.3。活性検出とモニタリング4.4。正しい動作の確認4.5。他のプロトコルと機能コンポーネントの要件4.6。ネットワーク運用への影響5. IANAの考慮事項5.1。 PCEPオブジェクト5.2。一般化されたEND-POINTSオブジェクトのエンドポイントタイプフィールド5.3。新しいPCEP TLV 5.4。 RPオブジェクトフラグフィールド5.5。新しいPCEPエラーコード5.6。 NO-PATH-VECTOR TLV 5.7の新しいビット。 Include Route Object 5.8の新しいサブオブジェクト。除外ルートオブジェクトの新しいサブオブジェクト5.9。新しいGMPLS-CAPABILITY TLVフラグフィールド6.セキュリティに関する考慮事項7.参考資料7.1。規範的な参考文献7.2。参考情報参考資料付録A. SDH仮想連結確認応答のLOAD-BALANCINGの使用法寄稿者著者のアドレス
Although the PCE architecture and framework for both MPLS and GMPLS networks are defined in [RFC4655], most pre-existing PCEP RFCs, such as [RFC5440], [RFC5521], [RFC5541], and [RFC5520], are focused on MPLS networks and do not cover the wide range of GMPLS networks. This document complements these RFCs by addressing the extensions required for GMPLS applications and routing requests, for example, for Optical Transport Networks (OTNs) and Wavelength Switched Optical Networks (WSONs).
MPLSおよびGMPLSネットワークのPCEアーキテクチャとフレームワークは[RFC4655]で定義されていますが、[RFC5440]、[RFC5521]、[RFC5541]、[RFC5520]など、既存のPCEP RFCのほとんどはMPLSネットワークに焦点を当てていますまた、広範囲のGMPLSネットワークは対象外です。このドキュメントは、GMPLSアプリケーションとルーティング要求に必要な拡張機能、たとえば、光トランスポートネットワーク（OTN）と波長スイッチ光ネットワーク（WSON）に対処することにより、これらのRFCを補足します。
The functional requirements to be addressed by the PCEP extensions to support these applications are fully described in [RFC7025] and [RFC7449].
これらのアプリケーションをサポートするためにPCEP拡張機能によって対処される機能要件は、[RFC7025]および[RFC7449]で完全に説明されています。
This document uses terminologies from the PCE architecture document [RFC4655]; the PCEP documents including [RFC5440], [RFC5521], [RFC5541], [RFC5520], [RFC7025], and [RFC7449]; and the GMPLS documents such as [RFC3471], [RFC3473], and so on. Note that the reader is expected to be familiar with these documents. The following abbreviations are used in this document:
このドキュメントでは、PCEアーキテクチャドキュメント[RFC4655]の用語を使用しています。 [RFC5440]、[RFC5521]、[RFC5541]、[RFC5520]、[RFC7025]、および[RFC7449]を含むPCEPドキュメント。 [RFC3471]、[RFC3473]などのGMPLSドキュメント。読者はこれらのドキュメントに精通している必要があることに注意してください。このドキュメントでは、次の略語を使用しています。
ERO: Explicit Route Object
ERO：明示的なルートオブジェクト
IRO: Include Route Object
IRO：ルートオブジェクトを含める
L2SC: Layer 2 Switch Capable [RFC3471]
L2SC：レイヤー2スイッチ対応[RFC3471]
LSC: Lambda Switch Capable [RFC3471]
LSC：Lambda Switch Capable [RFC3471]
LSP: Label Switched Path
LSP：ラベルスイッチドパス
LSPA: LSP Attribute
LSPA：LSP属性
MEF: Metro Ethernet Forum
MEF：メトロイーサネットフォーラム
MT: Multiplier [RFC4328] [RFC4606]
MT：乗数[RFC4328] [RFC4606]
NCC: Number of Contiguous Components [RFC4606]
NCC：隣接するコンポーネントの数[RFC4606]
NVC: Number of Virtual Components [RFC4328] [RFC4606]
NVC：仮想コンポーネントの数[RFC4328] [RFC4606]
ODU: Optical Data Unit [G.709-v3]
ODE：光学日付ユニットYG.709-v3sh
OTN: Optical Transport Network [G.709-v3]
OTN：光転送ネットワークSHG.709-vzshch
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
PCC: Path Computation Client
PCC：パス計算クライアント
PCRep: Path Computation Reply [RFC5440]
PCRep：パス計算応答[RFC5440]
PCReq: Path Computation Request [RFC5440]
PCReq：パス計算リクエスト[RFC5440]
RCC: Requested Contiguous Concatenation [RFC4606]
RCC：要求された連続した連結[RFC4606]
RRO: Record Route Object
RRO：ルートオブジェクトの記録
RSVP-TE: Resource Reservation Protocol - Traffic Engineering
RSVP-TE：リソース予約プロトコル-トラフィックエンジニアリング
SDH: Synchronous Digital Hierarchy
SDH：同期デジタル階層
SONET: Synchronous Optical Network
SONET：同期光ネットワーク
SRLG: Shared Risk Link Group
SRLG：共有リスクリンクグループ
SSON: Spectrum-Switched Optical Network
SSON：スペクトルスイッチ光ネットワーク
TDM: Time-Division Multiplex Capable [RFC3471]
TDM：時分割多重可能[RFC3471]
TE-LSP: Traffic Engineered LSP
TE-LSP：トラフィックエンジニアリングLSP
XRO: Exclude Route Object
XRO：ルートオブジェクトを除外
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC7025] describes the set of PCEP requirements that support GMPLS TE-LSPs. This document assumes a significant familiarity with [RFC7025] and existing PCEP extensions. As a short overview, those requirements can be broken down into the following categories.
[RFC7025]は、GMPLS TE-LSPをサポートするPCEP要件のセットを説明しています。このドキュメントは、[RFC7025]と既存のPCEP拡張にかなり精通していることを前提としています。簡単な概要として、これらの要件は次のカテゴリに分類できます。
* Which data flow is switched by the LSP: a combination of a switching type (for instance, L2SC or TDM), an LSP encoding type (e.g., Ethernet, SONET/SDH), and sometimes the signal type (e.g., in case of a TDM or an LSC switching capability).
* LSPによって切り替えられるデータフロー：スイッチングタイプ（たとえば、L2SCまたはTDM）、LSPエンコーディングタイプ（たとえば、イーサネット、SONET / SDH）、および信号タイプ（たとえば、 TDMまたはLSCスイッチング機能）。
* Data-flow-specific traffic parameters, which are technology specific. For instance, in SDH/SONET and OTN networks [G.709-v3], the concatenation type and the concatenation number have an influence on the switched data and on which link it can be supported.
* テクノロジー固有のデータフロー固有のトラフィックパラメータ。たとえば、SDH / SONETおよびOTNネットワーク[G.709-v3]では、連結タイプと連結番号は、交換されたデータと、サポートされているリンクに影響を与えます。
* Support for asymmetric bandwidth requests.
* 非対称帯域幅要求のサポート。
* Support for unnumbered interface identifiers, as defined in [RFC3477].
* [RFC3477]で定義されている、番号付けされていないインターフェイス識別子のサポート。
* Label information and technology-specific label(s) such as wavelength labels as defined in [RFC6205]. A PCC should also be able to specify a label restriction similar to the one supported by RSVP-TE in [RFC3473].
* ラベル情報および[RFC6205]で定義されている波長ラベルなどのテクノロジー固有のラベル。 PCCは、[RFC3473]のRSVP-TEでサポートされているものと同様のラベル制限を指定できる必要もあります。
* Ability to indicate the requested granularity for the path ERO: node, link, or label. This is to allow the use of the explicit label control feature of RSVP-TE.
* パスEROの要求された粒度を示す機能：ノード、リンク、またはラベル。これは、RSVP-TEの明示的なラベル制御機能を使用できるようにするためです。
The requirements of [RFC7025] apply to several objects conveyed by PCEP; this is described in Section 1.3. Some of the requirements of [RFC7025] are already supported in existing documents, as described in Section 1.4.
[RFC7025]の要件は、PCEPによって伝達されるいくつかのオブジェクトに適用されます。これについては、セクション1.3で説明します。 [RFC7025]の要件の一部は、セクション1.4で説明されているように、既存のドキュメントですでにサポートされています。
This document describes a set of PCEP extensions, including new object types, TLVs, encodings, error codes, and procedures, in order to fulfill the aforementioned requirements not covered in existing RFCs.
このドキュメントでは、既存のRFCでカバーされていない前述の要件を満たすために、新しいオブジェクトタイプ、TLV、エンコーディング、エラーコード、および手順を含むPCEP拡張機能のセットについて説明します。
This section follows the organization of [RFC7025], Section 3 and indicates, for each requirement, the affected piece of information carried by PCEP and its scope.
このセクションは、[RFC7025]のセクション3の構成に従い、要件ごとに、影響を受けるPCEPによって運ばれる情報とその範囲を示します。
(1) Switching capability/type: As described in [RFC3471], this piece of information is used with the encoding type and signal type to fully describe the switching technology and data carried by the TE-LSP. This is applicable to the TE-LSP itself and also to the TE-LSP endpoint (carried in the END-POINTS object for MPLS networks in [RFC5440]) when considering multiple network layers. Inter-layer path computation requirements are addressed in [RFC8282], which focuses on the TE-LSP itself but does not address the TE-LSP endpoints.
（1）スイッチング機能/タイプ：[RFC3471]で説明されているように、この情報は、TE-LSPによって伝送されるスイッチングテクノロジーとデータを完全に記述するために、エンコーディングタイプと信号タイプとともに使用されます。これは、複数のネットワーク層を検討する場合に、TE-LSP自体と、（[RFC5440]のMPLSネットワークのEND-POINTSオブジェクトに含まれる）TE-LSPエンドポイントに適用されます。レイヤ間パス計算の要件は、[RFC8282]で対処されています。これは、TE-LSP自体に焦点を当てていますが、TE-LSPエンドポイントには対処していません。
(2) Encoding type: See (1).
（2）符号化タイプ：（1）を参照してください。
(3) Signal type: See (1).
（3）信号タイプ：（1）を参照してください。
(4) Concatenation type: This parameter and the concatenation number (see (5)) are specific to some TDM (SDH and ODU) switching technologies. They MUST be described together and are used to derive the requested resource allocation for the TE-LSP. It is scoped to the TE-LSP and is related to the BANDWIDTH object [RFC5440] in MPLS networks. See concatenation information in [RFC4606] and [RFC4328].
（4）連結タイプ：このパラメーターと連結番号（（5）を参照）は、一部のTDM（SDHおよびODU）スイッチングテクノロジーに固有です。それらは一緒に記述されなければならず、TE-LSPの要求されたリソース割り当てを導出するために使用されます。これはTE-LSPを範囲とし、MPLSネットワークのBANDWIDTHオブジェクト[RFC5440]に関連しています。 [RFC4606]および[RFC4328]の連結情報を参照してください。
(5) Concatenation number: See (4).
（5）連結番号：（4）を参照してください。
(6) Technology-specific label(s): As described in [RFC3471], the GMPLS labels are specific to each switching technology. They can be specified on each link and also on the TE-LSP endpoints, in WSON networks, for instance, as described in [RFC6163]. The label restriction can apply to endpoints, and on each hop, the related PCEP objects are END-POINTS, IRO, XRO, and RRO.
（6）テクノロジー固有のラベル：[RFC3471]で説明されているように、GMPLSラベルは各スイッチングテクノロジーに固有です。これらは、[RFC6163]で説明されているように、たとえばWSONネットワークの各リンクおよびTE-LSPエンドポイントで指定できます。ラベル制限はエンドポイントに適用でき、各ホップで関連するPCEPオブジェクトはEND-POINTS、IRO、XRO、およびRROです。
(7) End-to-End (E2E) path protection type: As defined in [RFC4872], this is applicable to the TE-LSP. In MPLS networks, the related PCEP object is LSPA (carrying local protection information).
（7）エンドツーエンド（E2E）UPSR保護タイプ：[RFC4872]で定義されているように、これはTE-LSPに適用されます。 MPLSネットワークでは、関連するPCEPオブジェクトはLSPA（ローカル保護情報を運ぶ）です。
(8) Administrative group: As defined in [RFC3630], this information is already carried in the LSPA object.
（8）管理グループ：[RFC3630]で定義されているように、この情報はすでにLSPAオブジェクトに含まれています。
(9) Link protection type: As defined in [RFC4872], this is applicable to the TE-LSP and is carried in association with the E2E path protection type.
（9）リンク保護タイプ：[RFC4872]で定義されているように、これはTE-LSPに適用可能であり、E2Eパス保護タイプと関連付けて伝送されます。
(10) Support for unnumbered interfaces: As defined in [RFC3477]. Its scope and related objects are the same as labels.
（10）アンナンバードインターフェイスのサポート：[RFC3477]で定義されています。そのスコープと関連オブジェクトはラベルと同じです。
(11) Support for asymmetric bandwidth requests: As defined in [RFC6387], the scope is similar to (4).
（11）非対称帯域幅要求のサポート：[RFC6387]で定義されているように、スコープは（4）と同様です。
(12) Support for explicit label control during the path computation: This affects the TE-LSP and the amount of information returned in the ERO.
（12）パス計算中の明示的なラベル制御のサポート：これは、TE-LSPおよびEROに返される情報の量に影響します。
(13) Support of label restrictions in the requests/responses: This is described in (6).
（13）リクエスト/レスポンスでのラベル制限のサポート：これは（6）で説明されています。
(1) Path computation with concatenation: This is related to the Path Computation request requirement (4). In addition, there is a specific type of concatenation, called virtual concatenation, that allows different routes to be used between the endpoints. It is similar to the semantic and scope of the LOAD-BALANCING in MPLS networks.
（1）連結によるパス計算：これは、パス計算要求要件（4）に関連しています。さらに、エンドポイント間で異なるルートを使用できるようにする、仮想連結と呼ばれる特定のタイプの連結があります。これは、MPLSネットワークのLOAD-BALANCINGのセマンティックとスコープに似ています。
(2) Label constraint: The PCE should be able to include labels in the path returned to the PCC; the related object is the ERO object.
（2）ラベル制約：PCEは、PCCに返されるパスにラベルを含めることができる必要があります。関連オブジェクトはEROオブジェクトです。
(3) Roles of the routes: As defined in [RFC4872], this is applicable to the TE-LSP and is carried in association with the E2E path protection type.
（3）ルートの役割：[RFC4872]で定義されているように、これはTE-LSPに適用可能であり、E2Eパス保護タイプと関連付けて実行されます。
The support provided by specifications in [RFC8282] and [RFC5440] for the requirements listed in [RFC7025] is summarized in Tables 1 and 2. In some cases, the support may not be complete, as noted, and additional support needs to be provided as indicated in this specification.
[RFC7025]にリストされている要件に対して[RFC8282]および[RFC5440]の仕様によって提供されるサポートは、表1および2に要約されています。場合によっては、サポートが完全ではなく、追加のサポートを提供する必要があります。この仕様に示されているとおり。
+======+====================================+===============+
| Req. | Name | Support |
+======+====================================+===============+
| 1 | Switching capability/type | SWITCH-LAYER |
| | | (RFC 8282) |
+------+------------------------------------+---------------+
| 2 | Encoding type | SWITCH-LAYER |
| | | (RFC 8282) |
+------+------------------------------------+---------------+
| 3 | Signal type | SWITCH-LAYER |
| | | (RFC 8282) |
+------+------------------------------------+---------------+
| 4 | Concatenation type | No |
+------+------------------------------------+---------------+
| 5 | Concatenation number | No |
+------+------------------------------------+---------------+
| 6 | Technology-specific label | (Partial) ERO |
| | | (RFC 5440) |
+------+------------------------------------+---------------+
| 7 | End-to-End (E2E) path protection | No |
| | type | |
+------+------------------------------------+---------------+
| 8 | Administrative group | LSPA (RFC |
| | | 5440) |
+------+------------------------------------+---------------+
| 9 | Link protection type | No |
+------+------------------------------------+---------------+
| 10 | Support for unnumbered interfaces | (Partial) ERO |
| | | (RFC 5440) |
+------+------------------------------------+---------------+
| 11 | Support for asymmetric bandwidth | No |
| | requests | |
+------+------------------------------------+---------------+
| 12 | Support for explicit label control | No |
| | during the path computation | |
+------+------------------------------------+---------------+
| 13 | Support of label restrictions in | No |
| | the requests/responses | |
+------+------------------------------------+---------------+
Table 1: Requirements Support per RFC 7025, Section 3.1
表1：RFC 7025に基づく要件サポート、セクション3.1
+======+=====================================+=========+
| Req. | Name | Support |
+======+=====================================+=========+
| 1 | Path computation with concatenation | No |
+------+-------------------------------------+---------+
| 2 | Label constraint | No |
+------+-------------------------------------+---------+
| 3 | Roles of the routes | No |
+------+-------------------------------------+---------+
Table 2: Requirements Support per RFC 7025, Section 3.2
表2：RFC 7025に基づく要件サポート、セクション3.2
Per Section 1.3, PCEP (as described in [RFC5440], [RFC5521], and [RFC8282]) supports the following objects, included in requests and responses, that are related to the described requirements.
セクション1.3に従って、PCEP（[RFC5440]、[RFC5521]、および[RFC8282]で説明）は、要求と応答に含まれる、説明されている要件に関連する次のオブジェクトをサポートします。
From [RFC5440]:
[RFC5440]から：
END-POINTS: related to requirements 1, 2, 3, 6, 10, and 13. The object only supports numbered endpoints. The context specifies whether they are node identifiers or numbered interfaces.
エンドポイント：要件1、2、3、6、10、および13に関連します。オブジェクトは、番号付きのエンドポイントのみをサポートします。コンテキストは、それらがノード識別子であるか番号付きインターフェイスであるかを指定します。
BANDWIDTH: related to requirements 4, 5, and 11. The data rate is encoded in the BANDWIDTH object (as an IEEE 32-bit float). [RFC5440] does not include the ability to convey an encoding proper to all GMPLS-controlled networks.
BANDWIDTH：要件4、5、および11に関連。データレートは、（IEEE 32ビットフロートとして）BANDWIDTHオブジェクトでエンコードされます。 [RFC5440]には、すべてのGMPLS制御ネットワークに適切なエンコーディングを伝達する機能は含まれていません。
ERO: related to requirements 6, 10, 12, and 13. The ERO content is defined in RSVP in [RFC3209], [RFC3473], [RFC3477], and [RFC7570] and already supports all of the requirements.
ERO：要件6、10、12、13に関連しています。EROコンテンツは、RSVPの[RFC3209]、[RFC3473]、[RFC3477]、および[RFC7570]で定義されており、すべての要件をすでにサポートしています。
LSPA: related to requirements 7, 8, and 9. Requirement 8 (Administrative group) is already supported.
LSPA：要件7、8、9に関連。要件8（管理グループ）はすでにサポートされています。
From [RFC5521]:
[RFC5521]から：
XRO:
XRO：
- This object allows excluding (strict or not) resources and is related to requirements 6, 10, and 13. It also includes the requested diversity (node, link, or SRLG).
- このオブジェクトを使用すると、リソースを（厳密に、または厳密に）除外でき、要件6、10、および13に関連します。また、要求された多様性（ノード、リンク、またはSRLG）も含まれます。
- When the F bit is set, the request indicates that the existing path has failed, and the resources present in the RRO can be reused.
- Fビットが設定されている場合、要求は既存のパスが失敗したことを示し、RROに存在するリソースを再利用できます。
From [RFC8282]:
[RFC8282]から：
SWITCH-LAYER: addresses requirements 1, 2, and 3 for the TE-LSP and indicates which layer(s) should be considered. The object can be used to represent the RSVP-TE Generalized Label Request. It does not address the endpoints case of requirements 1, 2, and 3.
SWITCH-LAYER：TE-LSPの要件1、2、および3に対応し、どのレイヤーを考慮する必要があるかを示します。このオブジェクトは、RSVP-TE Generalized Label Requestを表すために使用できます。要件1、2、3のエンドポイントのケースは扱いません。
REQ-ADAP-CAP: indicates the adaptation capabilities requested; it can also be used for the endpoints in case of mono-layer computation.
REQ-ADAP-CAP：要求された適応機能を示します。単層計算の場合は、エンドポイントにも使用できます。
The gaps in functional coverage of the base PCEP objects are:
基本PCEPオブジェクトの機能範囲のギャップは次のとおりです。
* The BANDWIDTH and LOAD-BALANCING objects do not describe the details of the traffic request (requirements 4 and 5, for example, NVC and multiplier) in the context of GMPLS networks, for instance, in TDM or OTN networks.
* BANDWIDTHオブジェクトおよびLOAD-BALANCINGオブジェクトは、GMPLSネットワークのコンテキスト（TDMまたはOTNネットワークなど）でのトラフィック要求の詳細（要件4および5、たとえば、NVCおよび乗数）を記述しません。
* The END-POINTS object does not allow specifying an unnumbered interface, nor potential label restrictions on the interface (requirements 6, 10, and 13). Those parameters are of interest in case of switching constraints.
* END-POINTSオブジェクトでは、番号付けされていないインターフェイスを指定することも、インターフェイスにラベルの制限を課すこともできません（要件6、10、13）。これらのパラメータは、スイッチング制約の場合に重要です。
* The IROs/XROs do not allow the inclusion/exclusion of labels (requirements 6, 10, and 13).
* IRO / XROはラベルの包含/除外を許可しません（要件6、10、および13）。
* Base attributes do not allow expressing the requested link protection level and/or the end-to-end protection attributes.
* 基本属性では、要求されたリンク保護レベルやエンドツーエンド保護属性、あるいはその両方を表現できません。
As defined later in this document, the PCEP extensions that cover the gaps are:
このドキュメントの後半で定義されているように、ギャップをカバーするPCEP拡張は次のとおりです。
* Two new object types are defined for the BANDWIDTH object (Generalized bandwidth and Generalized bandwidth of an existing TE-LSP for which a reoptimization is requested).
* BANDWIDTHオブジェクトに対して2つの新しいオブジェクトタイプが定義されています（一般化帯域幅と再最適化が要求されている既存のTE-LSPの一般化帯域幅）。
* A new object type is defined for the LOAD-BALANCING object (Generalized Load Balancing).
* LOAD-BALANCINGオブジェクト（一般化負荷分散）に新しいオブジェクトタイプが定義されています。
* A new object type is defined for the END-POINTS object (Generalized Endpoint).
* END-POINTSオブジェクト（一般化エンドポイント）に新しいオブジェクトタイプが定義されています。
* A new TLV is added to the Open message for capability negotiation.
* 新しいTLVが機能ネゴシエーションのためのOpenメッセージに追加されます。
* A new TLV is added to the LSPA object.
* 新しいTLVがLSPAオブジェクトに追加されます。
* The Label subobject is now allowed in the IRO and XRO objects.
* LabelサブオブジェクトがIROおよびXROオブジェクトで許可されるようになりました。
* In order to indicate the routing granularity used in the response, a new flag is added in the RP object.
* 応答で使用されるルーティングの細分性を示すために、新しいフラグがRPオブジェクトに追加されます。
This section describes the necessary PCEP objects and extensions. The PCReq and PCRep messages are defined in [RFC5440]. This document does not change the existing grammar.
このセクションでは、必要なPCEPオブジェクトと拡張機能について説明します。 PCReqおよびPCRepメッセージは[RFC5440]で定義されています。このドキュメントは既存の文法を変更しません。
IGP-based PCE Discovery (PCED) is defined in [RFC5088] and [RFC5089] for the OSPF and IS-IS protocols. Those documents have defined bit 0 in the PCE-CAP-FLAGS Sub-TLV of the PCED TLV as "Path computation with GMPLS link constraints". This capability is optional and can be used to detect GMPLS-capable PCEs. PCEs that set the bit to indicate support of GMPLS path computation MUST follow the procedures in Section 2.1.2 to further qualify the level of support during PCEP session establishment.
IGPベースのPCEディスカバリー（PCED）は、OSPFおよびIS-ISプロトコルの[RFC5088]および[RFC5089]で定義されています。これらのドキュメントでは、PCED TLVのPCE-CAP-FLAGS Sub-TLVのビット0を「GMPLSリンク制約を使用したパス計算」として定義しています。この機能はオプションであり、GMPLS対応のPCEを検出するために使用できます。 GMPLSパス計算のサポートを示すビットを設定するPCEは、セクション2.1.2の手順に従って、PCEPセッションの確立中のサポートのレベルをさらに限定する必要があります。
In addition to the IGP advertisement, a PCEP speaker MUST be able to discover the other peer GMPLS capabilities during the Open message exchange. This capability is also useful to avoid misconfigurations. This document defines a GMPLS-CAPABILITY TLV for use in the OPEN object to negotiate the GMPLS capability. The inclusion of this TLV in the Open message indicates that the PCEP speaker supports the PCEP extensions defined in the document. A PCEP speaker that is able to support the GMPLS extensions defined in this document MUST include the GMPLS-CAPABILITY TLV in the Open message. If one of the PCEP peers does not include the GMPLS-CAPABILITY TLV in the Open message, the peers MUST NOT make use of the objects and TLVs defined in this document.
IGPアドバタイズメントに加えて、PCEPスピーカーは、オープンメッセージ交換中に他のピアGMPLS機能を検出できる必要があります。この機能は、設定ミスを防ぐのにも役立ちます。このドキュメントでは、OPENオブジェクトでGMPLS機能をネゴシエートするために使用するGMPLS-CAPABILITY TLVを定義しています。このTLVがOpenメッセージに含まれていることは、PCEPスピーカーがドキュメントで定義されているPCEP拡張機能をサポートしていることを示しています。このドキュメントで定義されているGMPLS拡張をサポートできるPCEPスピーカーは、OpenメッセージにGMPLS-CAPABILITY TLVを含める必要があります。 PCEPピアの1つがOpenメッセージにGMPLS-CAPABILITY TLVを含まない場合、ピアは、このドキュメントで定義されているオブジェクトとTLVを使用してはなりません（MUST NOT）。
If the PCEP speaker supports the extensions of this specification but did not advertise the GMPLS-CAPABILITY capability, upon receipt of a message from the PCE including an extension defined in this document, it MUST generate a PCEP Error (PCErr) with Error-Type=10 (Reception of an invalid object) and Error-value=31 (Missing GMPLS-CAPABILITY TLV), and it SHOULD terminate the PCEP session.
PCEPスピーカーがこの仕様の拡張をサポートしているが、GMPLS-CAPABILITY機能をアドバタイズしなかった場合、このドキュメントで定義されている拡張を含むPCEからのメッセージの受信時に、Error-Type =でPCEPエラー（PCErr）を生成する必要があります。 10（無効なオブジェクトの受信）およびError-value = 31（GMPLS-CAPABILITY TLVの欠落）、およびPCEPセッションを終了する必要があります（SHOULD）。
As documented in Section 5.3 ("New PCEP TLVs"), IANA has allocated value 45 (GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" sub-registry. The format for the GMPLS-CAPABILITY TLV is shown in the following figure.
セクション5.3（「新しいPCEP TLV」）に記載されているように、IANAは「PCEP TLVタイプインジケーター」サブレジストリから値45（GMPLS-CAPABILITY）を割り当てています。 GMPLS-CAPABILITY 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=45 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No flags are defined in this document; they are reserved for future use. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
このドキュメントではフラグは定義されていません。それらは将来の使用のために予約されています。割り当てられていないフラグは、送信時にゼロに設定する必要があり、受信時に無視する必要があります。
Explicit Label Control (ELC) is a procedure supported by RSVP-TE, where the outgoing labels are encoded in the ERO. As a consequence, the PCE can provide such labels directly in the path ERO. Depending on the policies or switching layer, it might be necessary for the PCC to use explicit label control or explicit link ids; thus, it needs to indicate in the PCReq which granularity it is expecting in the ERO. This corresponds to requirement 12 in Section 3.1 of [RFC7025]. The possible granularities can be node, link, or label. The granularities are interdependent, in the sense that link granularity implies the presence of node information in the ERO; similarly, a label granularity implies that the ERO contains node, link, and label information.
明示的ラベル制御（ELC）は、送信ラベルがEROでエンコードされるRSVP-TEでサポートされる手順です。その結果、PCEはそのようなラベルをEROパスで直接提供できます。ポリシーまたはスイッチング層によっては、PCCが明示的なラベル制御または明示的なリンクIDを使用する必要がある場合があります。そのため、EROでどの粒度が期待されているかをPCReqで示す必要があります。これは、[RFC7025]のセクション3.1の要件12に対応しています。可能な粒度は、ノード、リンク、またはラベルです。リンクの粒度がERO内のノード情報の存在を意味するという意味で、粒度は相互に依存しています。同様に、ラベルの粒度は、EROにノード、リンク、およびラベル情報が含まれていることを意味します。
A new 2-bit Routing Granularity (RG) flag (bits 15-16) is defined in the RP object. The values are defined as follows:
新しい2ビットのルーティング細分性（RG）フラグ（ビット15〜16）がRPオブジェクトで定義されています。値は次のように定義されます。
0: reserved
0：予約済み
1: node
１： ので
2: link
2：リンク
3: label
3：ラベル
The RG flag in the RP object indicates the requested route granularity. The PCE SHOULD follow this granularity and MAY return a NO-PATH if the requested granularity cannot be provided. The PCE MAY return any granularity on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content.
RPオブジェクトのRGフラグは、要求されたルートの粒度を示します。 PCEはこの細分性に従う必要があり（SHOULD）、要求された細分性を提供できない場合はNO-PATHを返すことができます（MAY）。 PCEは、そのポリシーに基づいて、ルートの細分性を返す場合があります。 PCCは、その内容に基づいてEROが許容可能かどうかを判断できます。
If a PCE honored the requested routing granularity for a request, it MUST indicate the selected routing granularity in the RP object included in the response. Otherwise, the PCE MUST use the reserved RG to leave the check of the ERO to the PCC. The RG flag is backward compatible with [RFC5440]: the value sent by an implementation (PCC or PCE) not supporting it will indicate a reserved value.
PCEが要求に対して要求されたルーティングの細分性を尊重した場合、それは応答に含まれるRPオブジェクトで選択されたルーティングの細分性を示さなければなりません（MUST）。それ以外の場合、PCEは予約済みのRGを使用して、EROのチェックをPCCに任せる必要があります。 RGフラグは[RFC5440]と下位互換性があります。それをサポートしない実装（PCCまたはPCE）によって送信された値は、予約済みの値を示します。
Per [RFC5440], the object carrying the requested size for the TE-LSP is the BANDWIDTH object. Object types 1 and 2 defined in [RFC5440] do not provide enough information to describe the TE-LSP bandwidth in GMPLS networks. The BANDWIDTH object encoding has to be extended to allow the object to express the bandwidth as described in [RFC7025]. RSVP-TE extensions for GMPLS provide a set of encodings that allow such representation in an unambiguous way; this is encoded in the RSVP-TE Traffic Specification (TSpec) and Flow Specification (FlowSpec) objects. This document extends the BANDWIDTH object with new object types reusing the RSVP-TE encoding.
[RFC5440]によると、TE-LSPに要求されたサイズを運ぶオブジェクトはBANDWIDTHオブジェクトです。 [RFC5440]で定義されているオブジェクトタイプ1および2は、GMPLSネットワークでTE-LSP帯域幅を説明するのに十分な情報を提供していません。 [RFC7025]で説明されているように、BANDWIDTHオブジェクトエンコーディングを拡張して、オブジェクトが帯域幅を表現できるようにする必要があります。 GMPLSのRSVP-TE拡張は、そのような表現を明確な方法で可能にする一連のエンコーディングを提供します。これは、RSVP-TEトラフィック仕様（TSpec）およびフロー仕様（FlowSpec）オブジェクトでエンコードされます。このドキュメントは、RSVP-TEエンコーディングを再利用する新しいオブジェクトタイプでBANDWIDTHオブジェクトを拡張します。
The following possibilities are supported by the extended encoding:
以下の可能性が拡張エンコーディングによってサポートされています。
* Asymmetric bandwidth (different bandwidth in forward and reverse direction), as described in [RFC6387].
* [RFC6387]で説明されている非対称帯域幅（順方向と逆方向で異なる帯域幅）。
* GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) parameters.
* GMPLS（SDH / SONET、G.709、ATM、MEFなど）パラメータ。
This corresponds to requirements 3, 4, 5, and 11 in Section 3.1 of [RFC7025].
これは、[RFC7025]のセクション3.1の要件3、4、5、11に対応しています。
This document defines two object types for the BANDWIDTH object:
このドキュメントでは、BANDWIDTHオブジェクトの2つのオブジェクトタイプを定義します。
3: Generalized bandwidth
3：一般化された帯域幅
4: Generalized bandwidth of an existing TE-LSP for which a reoptimization is requested
4：再最適化が要求されている既存のTE-LSPの一般化された帯域幅
The definitions below apply for object types 3 and 4. The body is as follows:
以下の定義は、オブジェクトタイプ3および4に適用されます。本文は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Spec Length | Rev. Bandwidth Spec Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bw Spec Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Generalized Bandwidth ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Reverse Generalized Bandwidth (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BANDWIDTH object types 3 and 4 have a variable length. The 16-bit Bandwidth Spec Length field indicates the length of the Generalized Bandwidth field. The Bandwidth Spec Length MUST be strictly greater than 0. The 16-bit Reverse Bandwidth Spec Length field indicates the length of the Reverse Generalized Bandwidth field. The Reverse Bandwidth Spec Length MAY be equal to 0.
BANDWIDTHオブジェクトタイプ3および4は可変長です。 16ビット帯域幅仕様長フィールドは、一般化帯域幅フィールドの長さを示します。帯域幅仕様長は必ず0より大きくなければなりません。16ビットの逆帯域幅仕様長フィールドは、逆一般化帯域幅フィールドの長さを示します。リバース帯域幅の仕様の長さは0に等しくてもかまいません。
The Bw Spec Type field determines which type of bandwidth is represented by the object.
[Bw Spec Type]フィールドは、オブジェクトが表す帯域幅のタイプを決定します。
The Bw Spec Type corresponds to the RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.
Bwスペックタイプは、RSVP-TE SENDER_TSPEC（オブジェクトクラス12）Cタイプに対応しています。
The encoding of the Generalized Bandwidth and Reverse Generalized Bandwidth fields is the same as the traffic parameters carried in RSVP-TE; they can be found in the following references. Note that the RSVP-TE traffic specification MAY also include TLVs that are different from the PCEP TLVs (e.g., the TLVs defined in [RFC6003]).
Generalized BandwidthフィールドとReverse Generalized Bandwidthフィールドのエンコーディングは、RSVP-TEで伝送されるトラフィックパラメータと同じです。それらは以下の参考文献にあります。 RSVP-TEトラフィック仕様には、PCEP TLVとは異なるTLV（たとえば、[RFC6003]で定義されているTLV）も含まれる場合があることに注意してください。
+==============+===========+===========+
| Bw Spec Type | Name | Reference |
+==============+===========+===========+
| 2 | Intserv | [RFC2210] |
+--------------+-----------+-----------+
| 4 | SONET/SDH | [RFC4606] |
+--------------+-----------+-----------+
| 5 | G.709 | [RFC4328] |
+--------------+-----------+-----------+
| 6 | Ethernet | [RFC6003] |
+--------------+-----------+-----------+
| 7 | OTN-TDM | [RFC7139] |
+--------------+-----------+-----------+
| 8 | SSON | [RFC7792] |
+--------------+-----------+-----------+
Table 3: Generalized Bandwidth and Reverse Generalized Bandwidth Field Encoding
表3：一般化された帯域幅と逆一般化された帯域幅フィールドエンコーディング
When a PCC requests a bidirectional path with symmetric bandwidth, it SHOULD only specify the Generalized Bandwidth field and set the Reverse Bandwidth Spec Length to 0. When a PCC needs to request a bidirectional path with asymmetric bandwidth, it SHOULD specify the different bandwidth in the forward and reverse directions with Generalized Bandwidth and Reverse Generalized Bandwidth fields.
PCCが対称帯域幅の双方向パスを要求する場合、それは一般化帯域幅フィールドのみを指定し、逆帯域幅仕様長を0に設定する必要があります。PCCが非対称帯域幅の双方向パスを要求する必要がある場合、PCCは異なる帯域幅を指定する必要があります（SHOULD）。 Generalized BandwidthおよびReverse Generalized Bandwidthフィールドを使用して、順方向および逆方向。
The procedure described in [RFC5440] for the PCRep is unchanged: a PCE MAY include the BANDWIDTH objects in the response to indicate the BANDWIDTH of the path.
PCRepの[RFC5440]で説明されている手順は変更されていません。PCEは、パスのBANDWIDTHを示すために応答にBANDWIDTHオブジェクトを含めることができます（MAY）。
As specified in [RFC5440], in the case of the reoptimization of a TE-LSP, the bandwidth of the existing TE-LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. The object type 4 MAY be used instead of the previously specified object type 2 to indicate the existing TE-LSP bandwidth, which was originally specified with object type 3. A PCC that requested a path with a BANDWIDTH object of object type 1 MUST use object type 2 to represent the existing TE-LSP bandwidth.
[RFC5440]で指定されているように、TE-LSPの再最適化の場合、2つの値が異なる場合に限り、要求された帯域幅に加えて、既存のTE-LSPの帯域幅も含める必要があります。以前にオブジェクトタイプ3で指定された既存のTE-LSP帯域幅を示すために、以前に指定されたオブジェクトタイプ2の代わりにオブジェクトタイプ4を使用できます（MAY）。オブジェクトタイプ1のBANDWIDTHオブジェクトのパスを要求したPCCは、オブジェクトを使用する必要があります。タイプ2は、既存のTE-LSP帯域幅を表します。
Optional TLVs MAY be included within the object body to specify more specific bandwidth requirements. No TLVs for object types 3 and 4 are defined by this document.
より具体的な帯域幅要件を指定するために、オプションのTLVをオブジェクト本体に含めることができます。このドキュメントでは、オブジェクトタイプ3および4のTLVは定義されていません。
The LOAD-BALANCING object [RFC5440] is used to request a set of at most Max-LSP TE-LSPs having in total the bandwidth specified in BANDWIDTH, with each TE-LSP having at least a specified minimum bandwidth. The LOAD-BALANCING object follows the bandwidth encoding of the BANDWIDTH object; thus, the existing definition from [RFC5440] does not describe enough details for the bandwidth specification expected by GMPLS.
LOAD-BALANCINGオブジェクト[RFC5440]を使用して、合計でBANDWIDTHで指定された帯域幅を持ち、各TE-LSPが少なくとも指定された最小帯域幅を持つ最大-LSP TE-LSPのセットを要求します。 LOAD-BALANCINGオブジェクトは、BANDWIDTHオブジェクトの帯域幅エンコーディングに従います。したがって、[RFC5440]の既存の定義では、GMPLSが期待する帯域幅の仕様について十分な詳細を説明していません。
Similar to the BANDWIDTH object, a new object type is defined to allow a PCC to represent the bandwidth types supported by GMPLS networks.
BANDWIDTHオブジェクトと同様に、PCCがGMPLSネットワークでサポートされる帯域幅タイプを表すことができるように、新しいオブジェクトタイプが定義されています。
This document defines object type 2 (Generalized Load Balancing) for the LOAD-BALANCING object. The Generalized Load Balancing object type has a variable length.
このドキュメントでは、LOAD-BALANCINGオブジェクトのオブジェクトタイプ2（一般化された負荷分散）を定義します。 Generalized Load Balancingオブジェクトタイプは可変長です。
The format of the Generalized Load Balancing object type is as follows:
Generalized Load Balancingオブジェクトタイプの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Spec Length | Reverse Bandwidth Spec Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bw Spec Type | Max-LSP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth Spec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Reverse Bandwidth Spec (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bandwidth Spec Length (16 bits): the total length of the Min Bandwidth Spec field. The length MUST be strictly greater than 0.
帯域幅仕様長（16ビット）：最小帯域幅仕様フィールドの全長。長さは厳密に0より大きくなければなりません。
Reverse Bandwidth Spec Length (16 bits): the total length of the Min Reverse Bandwidth Spec field. It MAY be equal to 0.
逆帯域幅仕様長（16ビット）：最小逆帯域幅仕様フィールドの全長。それは0に等しいかもしれません。
Bw Spec Type (8 bits): the bandwidth specification type; it corresponds to RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.
帯域幅仕様タイプ（8ビット）：帯域幅仕様タイプ。 RSVP-TE SENDER_TSPEC（オブジェクトクラス12）Cタイプに対応します。
Max-LSP (8 bits): the maximum number of TE-LSPs in the set.
Max-LSP（8ビット）：セット内のTE-LSPの最大数。
Min Bandwidth Spec (variable): specifies the minimum bandwidth specification of each element of the TE-LSP set.
最小帯域幅仕様（変数）：TE-LSPセットの各要素の最小帯域幅仕様を指定します。
Min Reverse Bandwidth Spec (variable): specifies the minimum reverse bandwidth specification of each element of the TE-LSP set.
最小逆帯域幅仕様（変数）：TE-LSPセットの各要素の最小逆帯域幅仕様を指定します。
The encoding of the Min Bandwidth Spec and Min Reverse Bandwidth Spec fields is the same as in the RSVP-TE SENDER_TSPEC object; it can be found in Table 3 in Section 2.3 of this document.
Min Bandwidth SpecおよびMin Reverse Bandwidth Specフィールドのエンコーディングは、RSVP-TE SENDER_TSPECオブジェクトと同じです。このドキュメントのセクション2.3の表3に記載されています。
When a PCC requests a bidirectional path with symmetric bandwidth while specifying load-balancing constraints, it SHOULD specify the Min Bandwidth Spec field and set the Reverse Bandwidth Spec Length to 0. When a PCC needs to request a bidirectional path with asymmetric bandwidth while specifying load-balancing constraints, it MUST specify the different bandwidth in forward and reverse directions through Min Bandwidth Spec and Min Reverse Bandwidth Spec fields.
PCCがロードバランシング制約を指定しているときに対称帯域幅の双方向パスを要求する場合、最小帯域幅仕様フィールドを指定し、逆帯域幅仕様の長さを0に設定する必要があります。PCCが負荷を指定しながら非対称帯域幅の双方向パスを要求する必要がある場合-制約のバランスをとるには、最小帯域幅仕様フィールドと最小逆帯域幅仕様フィールドを使用して、順方向と逆方向に異なる帯域幅を指定する必要があります。
Optional TLVs MAY be included within the object body to specify more specific bandwidth requirements. No TLVs for the Generalized Load Balancing object type are defined by this document.
より具体的な帯域幅要件を指定するために、オプションのTLVをオブジェクト本体に含めることができます。このドキュメントでは、一般化負荷分散オブジェクトタイプのTLVは定義されていません。
The semantic of the LOAD-BALANCING object is not changed. If a PCC requests the computation of a set of TE-LSPs with at most N TE-LSPs so that it can carry Generalized bandwidth X, each TE-LSP must at least transport bandwidth B; it inserts a BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALANCING object with the Max-LSP and Min Bandwidth Spec fields set to N and B, respectively. When the BANDWIDTH and Min Bandwidth Spec can be summarized as scalars, the sum of the bandwidth for all TE-LSPs in the set is greater than X. The mapping of the X over N path with (at least) bandwidth B is technology and possibly node specific. Each standard definition of the transport technology is defining those mappings and are not repeated in this document. A simplified example for SDH is described in Appendix A.
LOAD-BALANCINGオブジェクトのセマンティクスは変更されません。 PCCが一般化された帯域幅Xを伝送できるように、最大N個のTE-LSPを持つTE-LSPのセットの計算を要求する場合、各TE-LSPは少なくともトランスポート帯域幅Bでなければなりません。必要な帯域幅としてXを指定するBANDWIDTHオブジェクトと、Max-LSPおよびMin Bandwidth SpecフィールドがそれぞれNおよびBに設定されたLOAD-BALANCINGオブジェクトを挿入します。 BANDWIDTHおよびMin Bandwidth Specをスカラーとして要約できる場合、セット内のすべてのTE-LSPの帯域幅の合計はXよりも大きくなります。（少なくとも）帯域幅Bを持つX over Nパスのマッピングはテクノロジーであり、おそらくノード固有。トランスポートテクノロジーの各標準定義はこれらのマッピングを定義するものであり、このドキュメントでは繰り返されません。 SDHの簡単な例を付録Aで説明します。
In all other cases, including technologies based on statistical multiplexing (e.g., InterServ and Ethernet), the exact bandwidth management (e.g., the Ethernet's Excessive Rate) is left to the PCE's policies, according to the operator's configuration. If required, further documents may introduce a new mechanism to finely express complex load-balancing policies within PCEP.
統計的多重化に基づくテクノロジー（InterServやイーサネットなど）を含む他のすべてのケースでは、正確な帯域幅管理（イーサネットの過剰レートなど）は、オペレーターの設定に従ってPCEのポリシーに任されています。必要に応じて、PCEP内で複雑なロードバランシングポリシーを細かく表現するための新しいメカニズムを追加のドキュメントで紹介する場合があります。
The BANDWIDTH and LOAD-BALANCING Bw Spec Type can be different depending on the architecture of the endpoint node. When the PCE is not able to handle those two Bw Spec Types, it MUST return a NO-PATH with the bit "LOAD-BALANCING could not be performed with the bandwidth constraints" set in the NO-PATH-VECTOR TLV.
BANDWIDTHおよびLOAD-BALANCING Bw Spec Typeは、エンドポイントノードのアーキテクチャによって異なる場合があります。 PCEがこれら2つの帯域幅仕様タイプを処理できない場合、NO-PATH-VECTOR TLVに設定されたビット "LOAD-BALANCINGを帯域幅制約で実行できませんでした"を含むNO-PATHを返す必要があります。
The END-POINTS object is used in a PCEP request message to specify the source and the destination of the path for which a path computation is requested. Per [RFC5440], the source IP address and the destination IP address are used to identify those. A new object type is defined to address the following possibilities:
END-POINTSオブジェクトは、PCEP要求メッセージで使用され、パス計算が要求されるパスの送信元と宛先を指定します。 [RFC5440]によると、送信元IPアドレスと宛先IPアドレスは、それらを識別するために使用されます。新しいオブジェクトタイプは、次の可能性に対処するために定義されています。
* Different source and destination endpoint types.
* ソースと宛先のエンドポイントタイプが異なります。
* Label restrictions on the endpoint.
* エンドポイントのラベル制限。
* Specification of unnumbered endpoints type as seen in GMPLS networks.
* GMPLSネットワークで見られるような番号なしのエンドポイントタイプの指定。
The object encoding is described in the following sections.
オブジェクトのエンコードについては、次のセクションで説明します。
In path computation within a GMPLS context, the endpoints can:
GMPLSコンテキスト内のパス計算では、エンドポイントは次のことができます。
* Be unnumbered as described in [RFC3477].
* [RFC3477]で説明されているように、番号付けしないでください。
* Have labels associated to them, specifying a set of constraints on the allocation of labels.
* ラベルの割り当てに関する一連の制約を指定して、ラベルを関連付けます。
* Have different switching capabilities.
* さまざまな切り替え機能があります。
The IPv4 and IPv6 endpoints are used to represent the source and destination IP addresses. The scope of the IP address (node or numbered link) is not explicitly stated. It is also possible to request a path between a numbered link and an unnumbered link, or a P2MP path between different types of endpoints.
IPv4およびIPv6エンドポイントは、送信元および宛先IPアドレスを表すために使用されます。 IPアドレスの範囲（ノードまたは番号付きリンク）は明示的に述べられていません。番号付きリンクと番号なしリンク間のパス、または異なるタイプのエンドポイント間のP2MPパスを要求することもできます。
This document defines object type 5 (Generalized Endpoint) for the END-POINTS object. This new type also supports the specification of constraints on the endpoint label to be used. The PCE might know the interface restrictions, but this is not a requirement. This corresponds to requirements 6 and 10 in Section 3.1 of [RFC7025].
このドキュメントでは、END-POINTSオブジェクトのオブジェクトタイプ5（一般化エンドポイント）を定義します。この新しいタイプは、使用するエンドポイントラベルの制約の指定もサポートしています。 PCEはインターフェースの制限を知っているかもしれませんが、これは要件ではありません。これは、[RFC7025]のセクション3.1の要件6と10に対応しています。
The Generalized Endpoint object type format consists of a body and a list of TLVs scoped to this object. The TLVs give the details of the endpoints and are described in Section 2.5.2. For each endpoint type, a different grammar is defined. The TLVs defined to describe an endpoint are:
Generalized Endpointオブジェクトタイプの形式は、本文と、このオブジェクトをスコープとするTLVのリストで構成されます。 TLVはエンドポイントの詳細を提供し、セクション2.5.2で説明されています。エンドポイントタイプごとに、異なる文法が定義されています。エンドポイントを説明するために定義されたTLVは次のとおりです。
1. IPV4-ADDRESS
1. IPV4-ADDRESS
2. IPV6-ADDRESS
2. IPV6-ADDRESS
3. UNNUMBERED-ENDPOINT
3. 番号なしエンドポイント
4. LABEL-REQUEST
4. LABEL-REQUEST
5. LABEL-SET
5. ラベルセット
The LABEL-SET TLV is used to restrict or suggest the label allocation in the PCE. This TLV expresses the set of restrictions that may apply to signaling. Label restriction support can be an explicit or a suggested value (LABEL-SET describing one label, with the L bit cleared or set, respectively), mandatory range restrictions (LABEL-SET with the L bit cleared), and optional range restriction (LABEL-SET with the L bit set). Endpoints label restriction may not be part of the RRO or IRO. They can be included when following [RFC4003] in signaling for the egress endpoint, but ingress endpoint properties can be local to the PCC and not signaled. To support this case, the LABEL-SET allows indication of which labels are used in case of reoptimization. The label range restrictions are valid in GMPLS-controlled networks, depending on either the PCC policy or the switching technology used, for instance, on a given Ethernet or ODU equipment having limited hardware capabilities restricting the label range. Label set restriction also applies to WSON networks where the optical senders and receivers are limited in their frequency tunability ranges, consequently restricting the possible label ranges on the interface in GMPLS. The END-POINTS object with the Generalized Endpoint object type is encoded as follows:
LABEL-SET TLVは、PCEでのラベル割り当てを制限または提案するために使用されます。このTLVは、シグナリングに適用される可能性がある一連の制限を表します。ラベル制限のサポートは、明示的な値または推奨値（それぞれ、Lビットがクリアまたは設定された1つのラベルを表すLABEL-SET）、必須の範囲制限（LビットがクリアされたLABEL-SET）、およびオプションの範囲制限（LABEL -SET（Lビットを設定）。エンドポイントのラベル制限は、RROまたはIROの一部ではない場合があります。 [RFC4003]に従って出力エンドポイントのシグナリングに含めることができますが、入力エンドポイントプロパティはPCCに対してローカルであり、シグナリングされない場合があります。このケースをサポートするために、LABEL-SETは、再最適化の場合に使用されるラベルを示すことができます。ラベル範囲の制限は、GMPLS制御のネットワークで有効です。たとえば、PCCポリシーまたはスイッチングテクノロジーのいずれかが、ラベル範囲を制限するハードウェア機能が制限されている特定のイーサネットまたはODU機器で使用されます。ラベルセットの制限は、WSONネットワークにも適用されます。WSONネットワークでは、光送信機と受信機の周波数調整範囲が制限されているため、GMPLSのインターフェイスで可能なラベル範囲が制限されています。 Generalized EndpointオブジェクトタイプのEND-POINTSオブジェクトは、次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits SHOULD be set to 0 when a message is sent and ignored when the message is received.
予約済みビットは、メッセージが送信されるときに0に設定され、メッセージが受信されるときに無視される必要があります（SHOULD）。
The values for the Endpoint Type field are defined as follows:
[Endpoint Type]フィールドの値は次のように定義されています。
+=========+======================================+
| Value | Type |
+=========+======================================+
| 0 | Point-to-Point |
+---------+--------------------------------------+
| 1 | Point-to-Multipoint with leaf type 1 |
+---------+--------------------------------------+
| 2 | Point-to-Multipoint with leaf type 2 |
+---------+--------------------------------------+
| 3 | Point-to-Multipoint with leaf type 3 |
+---------+--------------------------------------+
| 4 | Point-to-Multipoint with leaf type 4 |
+---------+--------------------------------------+
| 5-244 | Unassigned |
+---------+--------------------------------------+
| 245-255 | Experimental Use |
+---------+--------------------------------------+
Table 4: Generalized Endpoint Types
表4：一般化されたエンドポイントタイプ
The Endpoint Type field is used to cover both point-to-point and different point-to-multipoint endpoints. A PCE may only accept endpoint type 0; endpoint types 1-4 apply if the PCE implementation supports P2MP path calculation. The leaf types for P2MP are as per [RFC8306]. A PCE not supporting a given endpoint type SHOULD respond with a PCErr with Error-Type=4 (Not supported object) and Error-value=7 (Unsupported endpoint type in END-POINTS Generalized Endpoint object type). As per [RFC5440], a PCE unable to process Generalized Endpoints may respond with Error-Type=3 (Unknown Object) and Error-value=2 (Unrecognized object type) or with Error-Type=4 (Not supported object) and Error-value=2 (Not supported object Type). The TLVs present in the request object body MUST follow the grammar per [RFC5511]:
エンドポイントタイプフィールドは、ポイントツーポイントと異なるポイントツーマルチポイントエンドポイントの両方をカバーするために使用されます。 PCEはエンドポイントタイプ0のみを受け入れることができます。 PCE実装がP2MPパス計算をサポートする場合、エンドポイントタイプ1〜4が適用されます。 P2MPのリーフタイプは[RFC8306]によるものです。特定のエンドポイントタイプをサポートしていないPCEは、Error-Type = 4（サポートされていないオブジェクト）およびError-value = 7（END-POINTS Generalized Endpointオブジェクトタイプでサポートされていないエンドポイントタイプ）のPCErrで応答する必要があります。 [RFC5440]に従って、汎用エンドポイントを処理できないPCEは、Error-Type = 3（不明なオブジェクト）およびError-value = 2（認識されないオブジェクトタイプ）またはError-Type = 4（サポートされていないオブジェクト）およびエラーで応答する場合があります-value = 2（サポートされていないオブジェクトタイプ）。リクエストオブジェクトの本文にあるTLVは、[RFC5511]の文法に従う必要があります。
<generalized-endpoint-tlvs>::=
<p2p-endpoints> | <p2mp-endpoints>
<p2p-endpoints> ::=
<endpoint> [<endpoint-restriction-list>]
<endpoint> [<endpoint-restriction-list>]
<p2mp-endpoints> ::=
<endpoint> [<endpoint-restriction-list>]
<endpoint> [<endpoint-restriction-list>]
[<endpoint> [<endpoint-restriction-list>]]...
For endpoint type Point-to-Point, two endpoint TLVs MUST be present in the message. The first endpoint is the source, and the second is the destination.
エンドポイントタイプのポイントツーポイントの場合、2つのエンドポイントTLVがメッセージに存在する必要があります。最初のエンドポイントはソースで、2番目のエンドポイントは宛先です。
For endpoint type Point-to-Multipoint, several END-POINTS objects MAY be present in the message, and the exact meaning depends on the endpoint type defined for the object. The first endpoint TLV is the root, and other endpoint TLVs are the leaves. The root endpoint MUST be the same for all END-POINTS objects for that P2MP tree request. If the root endpoint is not the same for all END-POINTS, a PCErr with Error-Type=17 (P2MP END-POINTS Error) and Error-value=4 (The PCE cannot satisfy the request due to inconsistent END-POINTS) MUST be returned. The procedure defined in [RFC8306], Section 3.10 also applies to the Generalized Endpoint with Point-to-Multipoint endpoint types.
エンドポイントタイプがポイントツーマルチポイントの場合、メッセージにいくつかのEND-POINTSオブジェクトが存在する可能性があり、正確な意味は、オブジェクトに定義されているエンドポイントタイプによって異なります。最初のエンドポイントTLVはルートで、他のエンドポイントTLVはリーフです。ルートエンドポイントは、そのP2MPツリー要求のすべてのEND-POINTSオブジェクトで同じでなければなりません。ルートエンドポイントがすべてのEND-POINTSで同じでない場合、Error-Type = 17（P2MP END-POINTS Error）およびError-value = 4（一貫性のないEND-POINTSによりPCEが要求を満たすことができない）のPCErr返されます。 [RFC8306]のセクション3.10で定義されている手順は、ポイントツーマルチポイントエンドポイントタイプの一般化エンドポイントにも適用されます。
An endpoint is defined as follows:
エンドポイントは次のように定義されます。
<endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT>
<endpoint-restriction-list> ::= <endpoint-restriction>
[<endpoint-restriction-list>]
<endpoint-restriction> ::=
[<LABEL-REQUEST>][<label-restriction-list>]
<label-restriction-list> ::= <label-restriction>
[<label-restriction-list>]
<label-restriction> ::= <LABEL-SET>
The different TLVs are described in the following sections. A PCE MAY support any or all of the IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT TLVs. When receiving a PCReq, a PCE unable to resolve the identifier in one of those TLVs MUST respond by using a PCRep with NO-PATH and setting the bit "Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV. The response SHOULD include the END-POINTS object with only the unsupported TLV(s).
次のセクションでは、さまざまなTLVについて説明します。 PCEは、IPV4-ADDRESS、IPV6-ADDRESS、およびUNNUMBERED-ENDPOINT TLVのいずれかまたはすべてをサポートする場合があります。 PCReqを受信すると、これらのTLVのいずれかで識別子を解決できないPCEは、NO-PATHを指定したPCRepを使用し、NO-PATH-VECTOR TLVでビット「不明な宛先」または「不明なソース」を設定して応答する必要があります。応答には、サポートされていないTLVのみを含むEND-POINTSオブジェクトを含める必要があります（SHOULD）。
A PCE MAY support either or both of the LABEL-REQUEST and LABEL-SET TLVs. If a PCE finds a non-supported TLV in the END-POINTS, the PCE MUST respond with a PCErr message with Error-Type=4 (Not supported object) and Error-value=8 (Unsupported TLV present in END-POINTS Generalized Endpoint object type), and the message SHOULD include the END-POINTS object in the response with only the endpoint and endpoint restriction TLV it did not understand. A PCE supporting those TLVs but not being able to fulfill the label restriction MUST send a response with a NO-PATH object that has the bit "No endpoint label resource" or "No endpoint label resource in range" set in the NO-PATH-VECTOR TLV. The response SHOULD include an END-POINTS object containing only the TLV(s) related to the constraints the PCE could not meet.
PCEは、LABEL-REQUESTおよびLABEL-SET TLVのいずれかまたは両方をサポートする場合があります。 PCEがサポートされていないTLVをEND-POINTSで検出した場合、PCEはPCErrメッセージでError-Type = 4（サポートされていないオブジェクト）およびError-value = 8（END-POINTS一般化エンドポイントにサポートされていないTLVが存在する）で応答する必要がありますオブジェクトタイプ）、およびメッセージは、エンドポイントとエンドポイント制限TLVのみが応答に含まれていないEND-POINTSオブジェクトを応答に含める必要があります（SHOULD）。それらのTLVをサポートするがラベルの制限を満たせないPCEは、NO-PATH-にビット「No endpoint label resource」または「No endpoint label resource in range」が設定されたビットを持つNO-PATHオブジェクトで応答を送信する必要がありますVECTOR TLV。応答には、PCEが満たすことができなかった制約に関連するTLVのみを含むEND-POINTSオブジェクトを含める必要があります（SHOULD）。
All endpoint TLVs have the standard PCEP TLV header as defined in [RFC5440], Section 7.1. For the Generalized Endpoint object type, the TLVs MUST follow the ordering defined in Section 2.5.1.
[RFC5440]のセクション7.1で定義されているように、すべてのエンドポイントTLVには標準のPCEP TLVヘッダーがあります。 Generalized Endpointオブジェクトタイプの場合、TLVはセクション2.5.1で定義された順序に従う必要があります。
The IPV4-ADDRESS TLV (Type 39) represents a numbered endpoint using IPv4 numbering. The format of the TLV value is as follows:
IPV4-ADDRESS TLV（タイプ39）は、IPv4番号を使用した番号付きエンドポイントを表します。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be returned, as described in Section 2.5.1.
このTLVは無視される場合があります。その場合、セクション2.5.1で説明されているように、NO-PATHを指定したPCRepが返される必要があります。
The IPv6-ADDRESS TLV (Type 40) represents a numbered endpoint using IPV6 numbering. The format of the TLV value is as follows:
IPv6-ADDRESS TLV（タイプ40）は、IPV6番号付けを使用した番号付きエンドポイントを表します。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be returned, as described in Section 2.5.1.
このTLVは無視される場合があります。その場合、セクション2.5.1で説明されているように、NO-PATHを指定したPCRepが返される必要があります。
The UNNUMBERED-ENDPOINT TLV (Type 41) represents an unnumbered interface. This TLV has the same semantic as in [RFC3477]. The TLV value is encoded as follows:
UNNUMBERED-ENDPOINT TLV（タイプ41）は、番号なしインターフェースを表します。このTLVの意味は[RFC3477]と同じです。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be returned, as described in Section 2.5.1.
このTLVは無視される場合があります。その場合、セクション2.5.1で説明されているように、NO-PATHを指定したPCRepが返される必要があります。
The LABEL-REQUEST TLV (Type 42) indicates the switching capability and encoding type of the following label restriction list for the endpoint. The value format and encoding is the same as described in Section 3.1 of [RFC3471] for the Generalized Label Request. The LSP Encoding Type field indicates the encoding type, e.g., SONET, SDH, GigE, etc., of the LSP with which the data is associated. The Switching Type field indicates the type of switching that is being requested on the endpoint. The Generalized Protocol Identifier (G-PID) field identifies the payload. This TLV and the following one are defined to satisfy requirement 13 in Section 3.1 of [RFC7025] for the endpoint. It is not directly related to the TE-LSP label request, which is expressed by the SWITCH-LAYER object.
LABEL-REQUEST TLV（タイプ42）は、エンドポイントの次のラベル制限リストのスイッチング機能と符号化タイプを示します。値の形式とエンコードは、[RFC3471]のセクション3.1で説明されているGeneralized Label Requestと同じです。 LSPエンコーディングタイプフィールドは、データが関連付けられているLSPのエンコーディングタイプ（SONET、SDH、GigEなど）を示します。 Switching Typeフィールドは、エンドポイントで要求されているスイッチングのタイプを示します。 Generalized Protocol Identifier（G-PID）フィールドは、ペイロードを識別します。このTLVと次のTLVは、エンドポイントの[RFC7025]のセクション3.1の要件13を満たすように定義されています。 SWITCH-LAYERオブジェクトによって表されるTE-LSPラベル要求とは直接関係ありません。
On the path calculation request, only the GENERALIZED-BANDWIDTH and SWITCH-LAYER need to be coherent; the endpoint labels could be different (supporting a different LABEL-REQUEST). Hence, the label restrictions include a Generalized Label Request in order to interpret the labels. This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be returned, as described in Section 2.5.1.
パス計算リクエストでは、GENERALIZED-BANDWIDTHとSWITCH-LAYERのみが一貫している必要があります。エンドポイントラベルは異なる場合があります（異なるLABEL-REQUESTをサポート）。したがって、ラベル制限には、ラベルを解釈するためのGeneralized Label Requestが含まれます。このTLVは無視される場合があります。その場合、セクション2.5.1で説明されているように、NO-PATHを指定したPCRepが返される必要があります。
Label or label range restrictions can be specified for the TE-LSP endpoints. Those are encoded using the LABEL-SET TLV. The label value needs to be interpreted with a description on the encoding and switching type. The REQ-ADAP-CAP object [RFC8282] can be used in case of a mono-layer request; however, in case of a multi-layer request, it is possible to have more than one object, so it is better to have a dedicated TLV for the label and label request. These TLVs MAY be ignored, in which case a response with NO-PATH SHOULD be returned, as described in Section 2.5.1. Per [RFC5440], the LABEL-SET TLV is encoded as follows. The type of the LABEL-SET TLV is 43. The TLV Length is variable, and the value encoding follows Section 3.5 of [RFC3471], with the addition of a U bit, O bit, and L bit. The L bit is used to represent a suggested set of labels, following the semantic of Suggested Label as defined by [RFC3471].
ラベルまたはラベル範囲の制限は、TE-LSPエンドポイントに指定できます。これらは、LABEL-SET TLVを使用してエンコードされます。ラベル値は、エンコーディングとスイッチングタイプの説明で解釈する必要があります。単層リクエストの場合、REQ-ADAP-CAPオブジェクト[RFC8282]を使用できます。ただし、マルチレイヤリクエストの場合は、複数のオブジェクトが存在する可能性があるため、ラベルとラベルリクエスト専用のTLVを用意することをお勧めします。これらのTLVは無視される場合があります。その場合、セクション2.5.1で説明されているように、NO-PATHを含む応答が返されるべきです（SHOULD）。 [RFC5440]によると、LABEL-SET TLVは次のようにエンコードされます。 LABEL-SET TLVのタイプは43です。TLVの長さは可変であり、値のエンコーディングは[RFC3471]のセクション3.5に従い、Uビット、Oビット、Lビットが追加されています。 Lビットは、[RFC3471]で定義されている推奨ラベルのセマンティクスに従って、推奨ラベルのセットを表すために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |L|O|U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A LABEL-SET TLV represents a set of possible labels that can be used on an interface. If the L bit is cleared, the label allocated on the first endpoint MUST be within the label set range. The Action parameter in the LABEL-SET indicates the type of list provided. These parameters are described by [RFC3471], Section 3.5.1.
LABEL-SET TLVは、インターフェイスで使用できる一連の可能なラベルを表します。 Lビットがクリアされている場合、最初のエンドポイントに割り当てられたラベルは、ラベルセットの範囲内にある必要があります。 LABEL-SETのActionパラメーターは、提供されるリストのタイプを示します。これらのパラメータは、[RFC3471]のセクション3.5.1で説明されています。
The U, O, and L bits are defined as follows:
U、O、およびLビットは次のように定義されます。
U: Upstream direction. Set for the upstream (reverse) direction in case of bidirectional LSP.
U：上流方向。双方向LSPの場合、上流（逆）方向に設定します。
O: Old label. Set when the TLV represents the old (previously allocated) label in case of reoptimization. The R bit of the RP object MUST be set to 1. If the L bit is set, this bit SHOULD be set to 0 and ignored on receipt. When this bit is set, the Action field MUST be set to 0 (Inclusive List), and the LABEL-SET MUST contain one subchannel.
O：古いラベル。再最適化の場合にTLVが古い（以前に割り当てられた）ラベルを表すときに設定されます。 RPオブジェクトのRビットは1に設定する必要があります。Lビットが設定されている場合、このビットは0に設定され、受信時に無視される必要があります（SHOULD）。このビットが設定されている場合、アクションフィールドは0（包括的リスト）に設定する必要があり、LABEL-SETは1つのサブチャネルを含む必要があります。
L: Loose label. Set when the TLV indicates to the PCE that a set of preferred (ordered) labels are to be used. The PCE MAY use those labels for label allocation.
L：ゆるいラベル。 TLVがPCEに一連の優先（順序付け）ラベルが使用されることを示しているときに設定されます。 PCEはこれらのラベルをラベル割り当てに使用できます。
Several LABEL_SET TLVs MAY be present with the O bit cleared; LABEL_SET TLVs with the L bit set can be combined with a LABEL_SET TLV with the L bit cleared. There MUST NOT be more than two LABEL_SET TLVs present with the O bit set. If there are two LABEL_SET TLVs present, there MUST NOT be more than one with the U bit set, and there MUST NOT be more than one with the U bit cleared. For a given U bit value, if more than one LABEL_SET TLV with the O bit set is present, the first TLV MUST be processed, and the following TLVs that have the same U and O bits MUST be ignored.
Oビットをクリアした状態で、いくつかのLABEL_SET TLVが存在する場合があります。 Lビットが設定されたLABEL_SET TLVは、LビットがクリアされたLABEL_SET TLVと組み合わせることができます。 Oビットが設定されたLABEL_SET TLVが3つ以上存在してはなりません（MUST NOT）。 2つのLABEL_SET TLVが存在する場合、Uビットが設定された状態で複数存在してはならず、Uビットがクリアされた状態で複数存在してはなりません。特定のUビット値について、Oビットが設定された複数のLABEL_SET TLVが存在する場合、最初のTLVを処理する必要があり、同じUビットとOビットを持つ次のTLVは無視する必要があります。
A LABEL-SET TLV with the O and L bits set MUST trigger a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=29 (Wrong LABEL-SET TLV present with O and L bits set).
OおよびLビットが設定されたLABEL-SET TLVは、Error-Type = 10（無効なオブジェクトの受信）およびError-value = 29（OおよびLビットが設定された誤ったLABEL-SET TLVが存在する）でPCErrメッセージをトリガーする必要があります。
A LABEL-SET TLV that has the O bit set and an Action field not set to 0 (Inclusive List) or that contains more than one subchannel MUST trigger a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=30 (Wrong LABEL-SET TLV present with O bit set and wrong format).
Oビットが設定され、アクションフィールドが0に設定されていない、または複数のサブチャネルを含むLABEL-SET TLVは、Error-Type = 10（無効なオブジェクトの受信）およびエラーでPCErrメッセージをトリガーする必要があります-value = 30（誤ったLABEL-SET TLVがOビットセットと誤ったフォーマットで存在する）。
If a LABEL-SET TLV is present with the O bit set, the R bit of the RP object MUST be set; otherwise, a PCErr message MUST be sent with Error-Type=10 (Reception of an invalid object) and Error-value=28 (LABEL-SET TLV present with O bit set but without R bit set in RP).
LABEL-SET TLVがOビットセットとともに存在する場合、RPオブジェクトのRビットを設定する必要があります。それ以外の場合、PCErrメッセージは、Error-Type = 10（無効なオブジェクトの受信）およびError-value = 28（Oビットセットあり、RPでRビットセットなしで存在するLABEL-SET TLV）で送信する必要があります。
The IRO as defined in [RFC5440] is used to include specific objects in the path. RSVP-TE allows the inclusion of a label definition. In order to fulfill requirement 13 in Section 3.1 of [RFC7025], the IRO needs to support the new subobject type as defined in [RFC3473]:
[RFC5440]で定義されているIROは、パスに特定のオブジェクトを含めるために使用されます。 RSVP-TEでは、ラベル定義を含めることができます。 [RFC7025]のセクション3.1の要件13を満たすために、IROは[RFC3473]で定義されている新しいサブオブジェクトタイプをサポートする必要があります。
+======+===========+
| Type | Subobject |
+======+===========+
| 10 | Label |
+------+-----------+
Table 5
表5
The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface ID (Type 4) subobject. If an IP address subobject is used, then the given IP address MUST be associated with a link. More than one Label subobject MAY follow each subobject identifying a link. The procedure associated with this subobject is as follows.
ラベルサブオブジェクトは、リンクを識別するサブオブジェクト（現在はIPアドレスサブオブジェクト（タイプ1または2）またはインターフェースID（タイプ4）サブオブジェクト）に従う必要があります。 IPアドレスサブオブジェクトが使用される場合、指定されたIPアドレスはリンクに関連付けられている必要があります。リンクを識別する各サブオブジェクトの後に複数のラベルサブオブジェクトが続く場合があります。このサブオブジェクトに関連付けられている手順は次のとおりです。
If the PCE is able to allocate labels (e.g., via explicit label control), the PCE MUST allocate one label from within the set of label values for the given link. If the PCE does not assign labels, then it sends a response with a NO-PATH object, containing a NO-PATH-VECTOR TLV with the bit "No label resource in range" set.
PCEがラベルを割り当てることができる場合（たとえば、明示的なラベル制御を介して）、PCEは所定のリンクのラベル値のセット内から1つのラベルを割り当てなければなりません（MUST）。 PCEがラベルを割り当てない場合、PCEは、NO-PATH-VECTOR TLVとビット「No label resource in range」が設定されたNO-PATHオブジェクトを含む応答を送信します。
The XRO as defined in [RFC5521] is used to exclude specific objects in the path. RSVP-TE allows the exclusion of certain labels [RFC6001]. In order to fulfill requirement 13 in Section 3.1 of [RFC7025], the PCEP's XRO needs to support a new subobject to enable label exclusion.
[RFC5521]で定義されているXROは、パス内の特定のオブジェクトを除外するために使用されます。 RSVP-TEでは、特定のラベルを除外できます[RFC6001]。 [RFC7025]のセクション3.1の要件13を満たすために、PCEPのXROは、ラベルの除外を可能にする新しいサブオブジェクトをサポートする必要があります。
The encoding of the XRO Label subobject follows the encoding of the ERO Label subobject defined in [RFC3473] and the XRO subobject defined in [RFC5521]. The XRO Label subobject (Type 10) represents one label and is defined as follows:
XROラベルサブオブジェクトのエンコーディングは、[RFC3473]で定義されたEROラベルサブオブジェクトと[RFC5521]で定義されたXROサブオブジェクトのエンコーディングに従います。 XROラベルサブオブジェクト（タイプ10）は1つのラベルを表し、次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=10 | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X (1 bit): See [RFC5521]. 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 it MAY be included subject to the PCE policy and the absence of a viable path that meets the other constraints and excludes the resource.
X（1ビット）：[RFC5521]を参照してください。 Xビットは、除外が必須か望ましいかを示します。 0は、指定されたリソースがPCEによって計算されたパスから除外されなければならないことを示します。 1は、指定されたリソースがPCEによって計算されたパスから除外される必要があることを示しますが、他の制約を満たし、リソースを除外する実行可能なパスがない場合は、PCEポリシーに従って含めることができます（MAY）。
Type (7 bits): The type of the XRO Label subobject is 10.
タイプ（7ビット）：XROラベルサブオブジェクトのタイプは10です。
Length (8 bits): See [RFC5521]. The total length of the subobject in bytes (including the Type and Length fields). The length is always divisible by 4.
長さ（8ビット）：[RFC5521]を参照してください。サブオブジェクトの全長（バイト）（タイプおよび長さフィールドを含む）。長さは常に4で割り切れる。
U (1 bit): See [RFC3471], Section 6.1.
U（1ビット）：[RFC3471]、セクション6.1を参照してください。
C-Type (8 bits): The C-Type of the included Label object as defined in [RFC3473].
Cタイプ（8ビット）：[RFC3473]で定義されている、含まれているLabelオブジェクトのCタイプ。
Label: See [RFC3471].
ラベル：[RFC3471]を参照してください。
The Label subobject MUST follow a subobject identifying a link, currently an IP address subobject (Type 1 or 2) or an interface ID (Type 4) subobject. If an IP address subobject is used, the given IP address MUST be associated with a link. More than one label subobject MAY follow a subobject identifying a link.
ラベルサブオブジェクトは、リンクを識別するサブオブジェクト（現在はIPアドレスサブオブジェクト（タイプ1または2）またはインターフェースID（タイプ4）サブオブジェクト）に従う必要があります。 IPアドレスサブオブジェクトが使用される場合、指定されたIPアドレスはリンクに関連付けられている必要があります。リンクを識別するサブオブジェクトの後に複数のラベルサブオブジェクトが続く場合があります。
+======+===========+
| Type | Subobject |
+======+===========+
| 10 | Label |
+------+-----------+
Table 6
表6
The LSPA carries the LSP attributes. In the end-to-end recovery context, this also includes the protection state information. A new TLV is defined to fulfill requirement 7 in Section 3.1 of [RFC7025] and requirement 3 in Section 3.2 of [RFC7025]. This TLV contains the information of the PROTECTION object defined by [RFC4872] and can be used as a policy input. The LSPA object MAY carry a PROTECTION-ATTRIBUTE TLV (Type 44), which is defined as follows:
LSPAはLSP属性を伝達します。エンドツーエンドの回復コンテキストでは、これには保護状態情報も含まれます。新しいTLVは、[RFC7025]のセクション3.1の要件7と[RFC7025]のセクション3.2の要件3を満たすように定義されています。このTLVには、[RFC4872]で定義されたPROTECTIONオブジェクトの情報が含まれており、ポリシー入力として使用できます。 LSPAオブジェクトは、PROTECTION-ATTRIBUTE TLV（タイプ44）を運ぶことができます。これは、次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is as defined in [RFC4872], Section 14 and [RFC4873], Section 6.1.
コンテンツは、[RFC4872]、セクション14および[RFC4873]、セクション6.1で定義されています。
The LSP (protection) Flags field or the Link Flags field can be used by a PCE implementation for routing policy input. The other attributes are only meaningful for a stateful PCE.
LSP（保護）フラグフィールドまたはリンクフラグフィールドは、ルーティングポリシー入力用のPCE実装で使用できます。その他の属性は、ステートフルPCEに対してのみ意味があります。
This TLV is OPTIONAL and MAY be ignored by the PCE. If ignored by the PCE, it MUST NOT include the TLV in the LSPA of the response. When the TLV is used by the PCE, an LSPA object and the PROTECTION-ATTRIBUTE TLV MUST be included in the response. Fields that were not considered MUST be set to 0.
このTLVはオプションであり、PCEによって無視される場合があります。 PCEによって無視される場合、応答のLSPAにTLVを含めてはなりません（MUST NOT）。 PCEがTLVを使用する場合、LSPAオブジェクトとPROTECTION-ATTRIBUTE TLVを応答に含める必要があります。考慮されなかったフィールドは0に設定する必要があります。
The NO-PATH object is used in PCRep messages in response to an unsuccessful Path Computation Request (the PCE could not find a path satisfying the set of constraints). In this scenario, the PCE MUST include a NO-PATH object in the PCRep message. The NO-PATH object MAY carry the NO-PATH-VECTOR TLV that specifies more information on the reasons that led to a negative reply. In case of GMPLS networks, there could be some additional constraints that led to the failure such as protection mismatch, lack of resources, and so on. Several new flags have been defined in the 32-bit Flag field of the NO-PATH-VECTOR TLV, but no modifications have been made in the NO-PATH object.
NO-PATHオブジェクトは、失敗したパス計算要求への応答としてPCRepメッセージで使用されます（PCEは一連の制約を満たすパスを見つけることができませんでした）。このシナリオでは、PCEはPCRepメッセージにNO-PATHオブジェクトを含める必要があります。 NO-PATHオブジェクトは、否定応答につながった理由に関する詳細情報を指定するNO-PATH-VECTOR TLVを運ぶことができます（MAY）。 GMPLSネットワークの場合、保護の不一致、リソースの不足など、障害につながるいくつかの追加の制約がある可能性があります。 NO-PATH-VECTOR TLVの32ビットフラグフィールドでいくつかの新しいフラグが定義されていますが、NO-PATHオブジェクトには変更が加えられていません。
The modified NO-PATH-VECTOR TLV carrying the additional information is as follows:
追加情報を含む変更されたNO-PATH-VECTOR TLVは次のとおりです。
Bit number 18: Protection Mismatch (1 bit). Specifies the mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in the request.
ビット番号18：保護ミスマッチ（1ビット）。リクエストのPROTECTION-ATTRIBUTE TLVで保護タイプの不一致を指定します。
Bit number 17: No Resource (1 bit). Specifies that the resources are not currently sufficient to provide the path.
ビット番号17：リソースなし（1ビット）。現在、パスを提供するにはリソースが不十分であることを指定します。
Bit number 16: Granularity not supported (1 bit). Specifies that the PCE is not able to provide a path with the requested granularity.
ビット番号16：細分性はサポートされていません（1ビット）。 PCEが要求された粒度でパスを提供できないことを指定します。
Bit number 15: No endpoint label resource (1 bit). Specifies that the PCE is not able to provide a path because of the endpoint label restriction.
ビット番号15：エンドポイントラベルリソースなし（1ビット）。エンドポイントラベルの制限により、PCEがパスを提供できないことを指定します。
Bit number 14: No endpoint label resource in range (1 bit). Specifies that the PCE is not able to provide a path because of the endpoint label set restriction.
ビット番号14：範囲内のエンドポイントラベルリソースはありません（1ビット）。エンドポイントラベルセットの制限のため、PCEがパスを提供できないことを指定します。
Bit number 13: No label resource in range (1 bit). Specifies that the PCE is not able to provide a path because of the label set restriction.
ビット番号13：範囲内にラベルリソースがありません（1ビット）。ラベルセットの制限のため、PCEがパスを提供できないことを指定します。
Bit number 12: LOAD-BALANCING could not be performed with the bandwidth constraints (1 bit). Specifies that the PCE is not able to provide a path because it could not map the BANDWIDTH into the parameters specified by the LOAD-BALANCING.
ビット番号12：帯域幅の制約（1ビット）でLOAD-BALANCINGを実行できませんでした。 PCEは、BANDWIDTHをLOAD-BALANCINGで指定されたパラメーターにマップできなかったため、パスを提供できないことを指定します。
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. An additional Error-Type and several Error-values are defined to represent some of the errors related to the newly identified objects, which are related to GMPLS networks. For each PCEP error, an Error-Type and an Error-value are defined. Error-Types 1 to 10 are already defined in [RFC5440]. Additional Error-values are defined for Error-Types 4 and 10. A new Error-Type 29 (Path computation failure) is defined in this document.
PCEP-ERRORオブジェクトは、PCEPエラーを報告するために使用され、エラーのタイプを指定するError-Typeと、エラーに関する追加情報を提供するError-valueによって特徴付けられます。追加のエラータイプといくつかのエラー値が定義され、GMPLSネットワークに関連する、新しく識別されたオブジェクトに関連するエラーの一部を表します。 PCEPエラーごとに、Error-TypeとError-valueが定義されています。エラータイプ1〜10は、[RFC5440]ですでに定義されています。エラータイプ4および10には、追加のエラー値が定義されています。このドキュメントでは、新しいエラータイプ29（パス計算の失敗）が定義されています。
Error-Type 29 (Path computation failure) is used to reflect constraints not understood by the PCE, for instance, when the PCE is not able to understand the Generalized bandwidth. If the constraints are understood, but the PCE is unable to find those constraints, NO-PATH is to be used.
エラータイプ29（パス計算障害）は、PCEが一般化された帯域幅を理解できない場合など、PCEが理解できない制約を反映するために使用されます。制約は理解されているが、PCEがそれらの制約を検出できない場合は、NO-PATHが使用されます。
+============+===============+==============================+
| Error-Type | Meaning | Error-value |
+============+===============+==============================+
| 4 | Not supported | |
| | object | |
+------------+---------------+------------------------------+
| | | 6: BANDWIDTH object type 3 |
| | | or 4 not supported |
+------------+---------------+------------------------------+
| | | 7: Unsupported endpoint type |
| | | in END-POINTS Generalized |
| | | Endpoint object type |
+------------+---------------+------------------------------+
| | | 8: Unsupported TLV present |
| | | in END-POINTS Generalized |
| | | Endpoint object type |
+------------+---------------+------------------------------+
| | | 9: Unsupported granularity |
| | | in the RP object flags |
+------------+---------------+------------------------------+
| 10 | Reception of | |
| | an invalid | |
| | object | |
+------------+---------------+------------------------------+
| | | 24: Bad BANDWIDTH object |
| | | type 3 or 4 |
+------------+---------------+------------------------------+
| | | 25: Unsupported LSP |
| | | Protection Flags in |
| | | PROTECTION-ATTRIBUTE TLV |
+------------+---------------+------------------------------+
| | | 26: Unsupported Secondary |
| | | LSP Protection Flags in |
| | | PROTECTION-ATTRIBUTE TLV |
+------------+---------------+------------------------------+
| | | 27: Unsupported Link |
| | | Protection Type in |
| | | PROTECTION-ATTRIBUTE TLV |
+------------+---------------+------------------------------+
| | | 28: LABEL-SET TLV present |
| | | with O bit set but without R |
| | | bit set in RP |
+------------+---------------+------------------------------+
| | | 29: Wrong LABEL-SET TLV |
| | | present with O and L bits |
| | | set |
+------------+---------------+------------------------------+
| | | 30: Wrong LABEL-SET TLV |
| | | present with O bit set and |
| | | wrong format |
+------------+---------------+------------------------------+
| | | 31: Missing GMPLS-CAPABILITY |
| | | TLV |
+------------+---------------+------------------------------+
| 29 | Path | |
| | computation | |
| | failure | |
+------------+---------------+------------------------------+
| | | 0: Unassigned |
+------------+---------------+------------------------------+
| | | 1: Unacceptable request |
| | | message |
+------------+---------------+------------------------------+
| | | 2: Generalized bandwidth |
| | | value not supported |
+------------+---------------+------------------------------+
| | | 3: Label set constraint |
| | | could not be met |
+------------+---------------+------------------------------+
| | | 4: Label constraint could |
| | | not be met |
+------------+---------------+------------------------------+
Table 7
表7
This section follows the guidance of [RFC6123].
このセクションは、[RFC6123]のガイダンスに従います。
This document makes no change to the basic operation of PCEP, so the requirements described in [RFC5440], Section 8.1 also apply to this document. In addition to those requirements, a PCEP implementation may allow the configuration of the following parameters:
このドキュメントはPCEPの基本的な操作に変更を加えないため、[RFC5440]のセクション8.1で説明されている要件もこのドキュメントに適用されます。これらの要件に加えて、PCEP実装では、次のパラメーターの構成が可能になる場合があります。
* Accepted RG in the RP object.
* RPオブジェクトで受け入れられたRG。
* Default RG to use (overriding the one present in the PCReq).
* 使用するデフォルトのRG（PCReqに存在するものをオーバーライドします）。
* Accepted BANDWIDTH object type 3 and 4 parameters in the request and default mapping to use when not specified in the request.
* リクエストで受け入れられたBANDWIDTHオブジェクトタイプ3および4のパラメーターと、リクエストで指定されていない場合に使用するデフォルトのマッピング。
* Accepted LOAD-BALANCING object type 2 parameters in request.
* リクエストでLOAD-BALANCINGオブジェクトタイプ2パラメータを受け入れました。
* Accepted endpoint type and allowed TLVs in object END-POINTS with the object type Generalized Endpoint.
* エンドポイントタイプを受け入れ、オブジェクトタイプGeneralized EndpointのオブジェクトEND-POINTSでTLVを許可しました。
* Accepted range for label restrictions in END-POINTS or IRO/XRO objects.
* END-POINTSまたはIRO / XROオブジェクトのラベル制限の許容範囲。
* Acceptance and suppression of the PROTECTION-ATTRIBUTE TLV.
* PROTECTION-ATTRIBUTE TLVの受け入れと抑制。
The configuration of the above parameters is applicable to the different sessions as described in [RFC5440], Section 8.1 (by default, per PCEP peer, etc.).
上記のパラメータの設定は、[RFC5440]、セクション8.1（デフォルトでは、PCEPピアごとなど）で説明されているように、さまざまなセッションに適用できます。
This document makes no change to the basic operation of PCEP, so the requirements described in [RFC5440], Section 8.2 also apply to this document. This document does not introduce any new ERO subobjects; the ERO information model is already covered in [RFC4802].
このドキュメントはPCEPの基本操作に変更を加えないため、[RFC5440]のセクション8.2に記載されている要件がこのドキュメントにも適用されます。このドキュメントでは、新しいEROサブオブジェクトを紹介していません。 ERO情報モデルはすでに[RFC4802]でカバーされています。
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 [RFC5440], Section 8.3.
このドキュメントはPCEPの基本的な動作に変更を加えないため、[RFC4657]および[RFC5440]のセクション8.3の活性検出および監視の要件に変更はありません。
This document makes no change to the basic operations of PCEP and the considerations described in [RFC5440], Section 8.4. New errors defined by this document should satisfy the requirement to log error events.
このドキュメントでは、PCEPの基本的な操作と、[RFC5440]のセクション8.4で説明されている考慮事項は変更されません。このドキュメントで定義されている新しいエラーは、エラーイベントをログに記録するための要件を満たす必要があります。
No new requirements on other protocols and functional components are made by this document. This document does not require ERO object extensions. Any new ERO subobject defined in the TEAS or CCAMP Working Groups can be adopted without modifying the operations defined in this document.
このドキュメントでは、他のプロトコルおよび機能コンポーネントに関する新しい要件は作成されていません。このドキュメントでは、EROオブジェクト拡張は必要ありません。 TEASまたはCCAMPワーキンググループで定義されている新しいEROサブオブジェクトは、このドキュメントで定義されている操作を変更せずに採用できます。
This document makes no change to the basic operations of PCEP and the considerations described in [RFC5440], Section 8.6. In addition to the limit on the rate of messages sent by a PCEP speaker, a limit MAY be placed on the size of the PCEP messages.
このドキュメントでは、PCEPの基本的な操作と、[RFC5440]、セクション8.6で説明されている考慮事項は変更されません。 PCEPスピーカーが送信するメッセージのレートの制限に加えて、PCEPメッセージのサイズに制限を課してもよい（MAY）。
IANA assigns values to PCEP objects and TLVs. IANA has made allocations for the newly defined objects and TLVs defined in this document. In addition, IANA manages the space of flags that have been newly added in the TLVs.
IANAはPCEPオブジェクトとTLVに値を割り当てます。 IANAは、このドキュメントで定義されている新しく定義されたオブジェクトとTLVに割り当てを行いました。さらに、IANAはTLVに新しく追加されたフラグのスペースを管理します。
New object types are defined in Sections 2.3, 2.4, and 2.5.1. IANA has made the following Object-Type allocations in the "PCEP Objects" subregistry.
新しいオブジェクトタイプは、セクション2.3、2.4、および2.5.1で定義されています。 IANAは、「PCEPオブジェクト」サブレジストリで次のオブジェクトタイプの割り当てを行いました。
+==============+================+=================+===========+
| Object-Class | Name | Object-Type | Reference |
| Value | | | |
+==============+================+=================+===========+
| 5 | BANDWIDTH | 3: Generalized | RFC 8779, |
| | | bandwidth | Section |
| | | | 2.3 |
+--------------+----------------+-----------------+-----------+
| | | 4: Generalized | RFC 8779, |
| | | bandwidth of an | Section |
| | | existing TE-LSP | 2.3 |
| | | for which a | |
| | | reoptimization | |
| | | is requested | |
+--------------+----------------+-----------------+-----------+
| 14 | LOAD-BALANCING | 2: Generalized | RFC 8779, |
| | | Load Balancing | Section |
| | | | 2.4 |
+--------------+----------------+-----------------+-----------+
| 4 | END-POINTS | 5: Generalized | RFC 8779, |
| | | Endpoint | Section |
| | | | 2.5 |
+--------------+----------------+-----------------+-----------+
Table 8
表8
IANA has created a new "Generalized Endpoint Types" registry to manage the Endpoint Type field of the END-POINTS object, the object type Generalized Endpoint, and the code space.
IANAは、END-POINTSオブジェクトのエンドポイントタイプフィールド、オブジェクトタイプの一般化エンドポイント、およびコードスペースを管理するための新しい「一般化エンドポイントタイプ」レジストリを作成しました。
New endpoint types in the Unassigned range are assigned by Standards Action [RFC8126]. Each endpoint type should be tracked with the following attributes:
未割り当て範囲の新しいエンドポイントタイプは、標準アクション[RFC8126]によって割り当てられます。各エンドポイントタイプは、次の属性で追跡する必要があります。
* Value
* 値
* Type
* タイプ
* Defining RFC
* RFCの定義
New endpoint types in the Experimental Use range will not be registered with IANA and MUST NOT be mentioned by any RFCs.
試験運用範囲の新しいエンドポイントタイプはIANAに登録されず、RFCで言及されてはなりません。
The following values are defined by this document (see Table 4 in Section 2.5.1):
このドキュメントでは、次の値が定義されています（2.5.1節の表4を参照）。
+=========+======================================+
| Value | Type |
+=========+======================================+
| 0 | Point-to-Point |
+---------+--------------------------------------+
| 1 | Point-to-Multipoint with leaf type 1 |
+---------+--------------------------------------+
| 2 | Point-to-Multipoint with leaf type 2 |
+---------+--------------------------------------+
| 3 | Point-to-Multipoint with leaf type 3 |
+---------+--------------------------------------+
| 4 | Point-to-Multipoint with leaf type 4 |
+---------+--------------------------------------+
| 5-244 | Unassigned |
+---------+--------------------------------------+
| 245-255 | Experimental Use |
+---------+--------------------------------------+
Table 9
表9
IANA manages a registry for PCEP TLV code points (see [RFC5440]), which is maintained as the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated the following per this document:
IANAはPCEP TLVコードポイント（[RFC5440]を参照）のレジストリを管理します。これは、「パス計算要素プロトコル（PCEP）番号」レジストリの「PCEP TLVタイプインジケーター」サブレジストリとして維持されます。 IANAはこのドキュメントごとに以下を割り当てました。
+=======+======================+===========================+
| Value | Meaning | Reference |
+=======+======================+===========================+
| 39 | IPV4-ADDRESS | RFC 8779, Section 2.5.2.1 |
+-------+----------------------+---------------------------+
| 40 | IPV6-ADDRESS | RFC 8779, Section 2.5.2.2 |
+-------+----------------------+---------------------------+
| 41 | UNNUMBERED-ENDPOINT | RFC 8779, Section 2.5.2.3 |
+-------+----------------------+---------------------------+
| 42 | LABEL-REQUEST | RFC 8779, Section 2.5.2.4 |
+-------+----------------------+---------------------------+
| 43 | LABEL-SET | RFC 8779, Section 2.5.2.5 |
+-------+----------------------+---------------------------+
| 44 | PROTECTION-ATTRIBUTE | RFC 8779, Section 2.8 |
+-------+----------------------+---------------------------+
| 45 | GMPLS-CAPABILITY | RFC 8779, Section 2.1.2 |
+-------+----------------------+---------------------------+
Table 10
表10
A new flag is defined in Section 2.2 for the Flags field of the RP object. IANA has made the following allocation in the "RP Object Flag Field" subregistry:
新しいフラグは、RPオブジェクトのFlagsフィールドのセクション2.2で定義されています。 IANAは、「RPオブジェクトフラグフィールド」サブレジストリに次の割り当てを行いました。
+=======+==========================+=======================+
| Bit | Description | Reference |
+=======+==========================+=======================+
| 15-16 | Routing Granularity (RG) | RFC 8779, Section 2.2 |
+-------+--------------------------+-----------------------+
Table 11
表11
New PCEP Error-Types and Error-values are defined in Section 3. IANA has made the following allocations in the "PCEP-ERROR Object Error Types and Values" registry:
新しいPCEPエラータイプとエラー値はセクション3で定義されています。IANAは「PCEP-ERRORオブジェクトエラータイプと値」レジストリに次の割り当てを行いました。
+============+=============+==========================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+=============+==========================+===========+
| 4 | Not | | [RFC5440] |
| | supported | | |
| | object | | |
+------------+-------------+--------------------------+-----------+
| | | 6: BANDWIDTH object type | RFC 8779 |
| | | 3 or 4 not supported | |
+------------+-------------+--------------------------+-----------+
| | | 7: Unsupported endpoint | RFC 8779 |
| | | type in END-POINTS | |
| | | Generalized Endpoint | |
| | | object type | |
+------------+-------------+--------------------------+-----------+
| | | 8: Unsupported TLV | RFC 8779 |
| | | present in END-POINTS | |
| | | Generalized Endpoint | |
| | | object type | |
+------------+-------------+--------------------------+-----------+
| | | 9: Unsupported | RFC 8779 |
| | | granularity in the RP | |
| | | object flags | |
+------------+-------------+--------------------------+-----------+
| 10 | Reception | | [RFC5440] |
| | of an | | |
| | invalid | | |
| | object | | |
+------------+-------------+--------------------------+-----------+
| | | 24: Bad BANDWIDTH object | RFC 8779 |
| | | type 3 or 4 | |
+------------+-------------+--------------------------+-----------+
| | | 25: Unsupported LSP | RFC 8779 |
| | | Protection Flags in | |
| | | PROTECTION-ATTRIBUTE TLV | |
+------------+-------------+--------------------------+-----------+
| | | 26: Unsupported | RFC 8779 |
| | | Secondary LSP Protection | |
| | | Flags in PROTECTION- | |
| | | ATTRIBUTE TLV | |
+------------+-------------+--------------------------+-----------+
| | | 27: Unsupported Link | RFC 8779 |
| | | Protection Type in | |
| | | PROTECTION-ATTRIBUTE TLV | |
+------------+-------------+--------------------------+-----------+
| | | 28: LABEL-SET TLV | RFC 8779 |
| | | present with O bit set | |
| | | but without R bit set in | |
| | | RP | |
+------------+-------------+--------------------------+-----------+
| | | 29: Wrong LABEL-SET TLV | RFC 8779 |
| | | present with O and L | |
| | | bits set | |
+------------+-------------+--------------------------+-----------+
| | | 30: Wrong LABEL-SET TLV | RFC 8779 |
| | | present with O bit set | |
| | | and wrong format | |
+------------+-------------+--------------------------+-----------+
| | | 31: Missing GMPLS- | RFC 8779 |
| | | CAPABILITY TLV | |
+------------+-------------+--------------------------+-----------+
| 29 | Path | | RFC 8779 |
| | computation | | |
| | failure | | |
+------------+-------------+--------------------------+-----------+
| | | 0: Unassigned | RFC 8779 |
+------------+-------------+--------------------------+-----------+
| | | 1: Unacceptable request | RFC 8779 |
| | | message | |
+------------+-------------+--------------------------+-----------+
| | | 2: Generalized bandwidth | RFC 8779 |
| | | value not supported | |
+------------+-------------+--------------------------+-----------+
| | | 3: Label set constraint | RFC 8779 |
| | | could not be met | |
+------------+-------------+--------------------------+-----------+
| | | 4: Label constraint | RFC 8779 |
| | | could not be met | |
+------------+-------------+--------------------------+-----------+
Table 12
表12
New NO-PATH-VECTOR TLV bits are defined in Section 2.9.1. IANA has made the following allocations in the "NO-PATH-VECTOR TLV Flag Field" subregistry:
新しいNO-PATH-VECTOR TLVビットは、セクション2.9.1で定義されています。 IANAは、「NO-PATH-VECTOR TLVフラグフィールド」サブレジストリに次の割り当てを行いました。
+=====+=======================================+===========+
| Bit | Description | Reference |
+=====+=======================================+===========+
| 18 | Protection Mismatch | RFC 8779 |
+-----+---------------------------------------+-----------+
| 17 | No Resource | RFC 8779 |
+-----+---------------------------------------+-----------+
| 16 | Granularity not supported | RFC 8779 |
+-----+---------------------------------------+-----------+
| 15 | No endpoint label resource | RFC 8779 |
+-----+---------------------------------------+-----------+
| 14 | No endpoint label resource in range | RFC 8779 |
+-----+---------------------------------------+-----------+
| 13 | No label resource in range | RFC 8779 |
+-----+---------------------------------------+-----------+
| 12 | LOAD-BALANCING could not be performed | RFC 8779 |
| | with the bandwidth constraints | |
+-----+---------------------------------------+-----------+
Table 13
表13
IANA has added a new subobject in the "IRO Subobjects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリの「IRO Subobjects」サブレジストリに新しいサブオブジェクトを追加しました。
IANA has added a new subobject that can be carried in the IRO as follows:
IANAは、次のようにIROに含めることができる新しいサブオブジェクトを追加しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 10 | Label | RFC 8779 |
+-------+-------------+-----------+
Table 14
表14
IANA has added a new subobject in the "XRO Subobjects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリの「XRO Subobjects」サブレジストリに新しいサブオブジェクトを追加しました。
IANA has added a new subobject that can be carried in the XRO as follows:
IANAは、次のようにXROで実行できる新しいサブオブジェクトを追加しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 10 | Label | RFC 8779 |
+-------+-------------+-----------+
Table 15
表15
IANA has created a new "GMPLS-CAPABILITY TLV Flag Field" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the GMPLS-CAPABILITY TLV.
IANAは、GMPLS-CAPABILITY TLVのフラグフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に新しい「GMPLS-CAPABILITY TLVフラグフィールド」サブレジストリを作成しました。
New bit numbers are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
新しいビット番号は、Standards Action [RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとしてカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
The initial contents of the subregistry are empty, with bits 0-31 marked as Unassigned.
サブレジストリの最初の内容は空で、ビット0〜31は未割り当てとしてマークされています。
GMPLS controls multiple technologies and types of network elements. The LSPs that are established using GMPLS, whose paths can be computed using the PCEP extensions to support GMPLS described in this document, can carry a high volume of traffic and can be a critical part of a network infrastructure. The PCE can then play a key role in the use of the resources and in determining the physical paths of the LSPs; thus, it is important to ensure the identity of the PCE and PCC, as well as the communication channel. In many deployments, there will be a completely isolated network where an external attack is of very low probability. However, there are other deployment cases in which the PCC-PCE communication can be more exposed, and there could be more security considerations. There are three main situations in case an attack in the GMPLS PCE context happens:
GMPLSは、複数のテクノロジーとネットワーク要素のタイプを制御します。このドキュメントで説明されているGMPLSをサポートするためにPCEP拡張を使用してパスを計算できるGMPLSを使用して確立されたLSPは、大量のトラフィックを伝送し、ネットワークインフラストラクチャの重要な部分になる可能性があります。 PCEは、リソースの使用とLSPの物理パスの決定において重要な役割を果たすことができます。したがって、PCEとPCC、および通信チャネルのIDを確認することが重要です。多くの展開では、外部からの攻撃の可能性が非常に低い完全に分離されたネットワークが存在します。ただし、PCC-PCE通信をより公開できる他の展開ケースがあり、セキュリティに関する考慮事項が増える可能性があります。 GMPLS PCEコンテキストで攻撃が発生した場合の主な状況は3つあります。
PCE Identity theft: A legitimate PCC could request a path for a GMPLS LSP to a malicious PCE, which poses as a legitimate PCE. The response may be that the LSP traverses some geographical place known to the attacker where confidentiality (sniffing), integrity (traffic modification), or availability (traffic drop) attacks could be performed by use of an attacker-controlled middlebox device. Also, the resulting LSP can omit constraints given in the requests (e.g., excluding certain fibers and avoiding some SRLGs), which could make the LSP that will be set up later look perfectly fine, but it will be in a risky situation. Also, the result can lead to the creation of an LSP that does not provide the desired quality and gives less resources than necessary.
PCE ID盗難：正当なPCCが、正当なPCEを装った悪意のあるPCEへのGMPLS LSPのパスを要求する可能性があります。 LSPは、攻撃者が制御するミドルボックスデバイスを使用して機密性（スニッフィング）、整合性（トラフィックの変更）、または可用性（トラフィックのドロップ）の攻撃を実行できる、攻撃者に知られている地理的な場所を通過する可能性があります。また、結果のLSPは、リクエストで指定された制約（たとえば、特定のファイバーを除外し、一部のSRLGを回避する）を省略できます。これにより、後で設定されるLSPが完全に問題なく見えるようになりますが、危険な状況になります。また、結果として、希望の品質を提供せず、必要以上のリソースを提供しないLSPが作成される可能性があります。
PCC Identity theft: A malicious PCC, acting as a legitimate PCC, requesting LSP paths to a legitimate PCE can obtain a good knowledge of the physical topology of a critical infrastructure. It could learn enough details to plan a later physical attack.
PCC IDの盗難：正当なPCCとして機能し、正当なPCEへのLSPパスを要求する悪意のあるPCCは、重要なインフラストラクチャの物理トポロジに関する十分な知識を得ることができます。後で物理的な攻撃を計画するのに十分な詳細を学習できます。
Message inspection: As in the previous case, knowledge of an infrastructure can be obtained by sniffing PCEP messages.
メッセージ検査：前のケースと同様に、PCEPメッセージをスニッフィングすることでインフラストラクチャの知識を得ることができます。
The security mechanisms can provide authentication and confidentiality for those scenarios where PCC-PCE communication cannot be completely trusted. [RFC8253] provides origin verification, message integrity, and replay protection, and it ensures that a third party cannot decipher the contents of a message.
セキュリティメカニズムは、PCC-PCE通信を完全に信頼できないシナリオに認証と機密性を提供できます。 [RFC8253]は、発信元の検証、メッセージの整合性、および再生保護を提供し、第三者がメッセージの内容を解読できないようにします。
In order to protect against the malicious PCE case, the PCC SHOULD have policies in place to accept or not accept the path provided by the PCE. Those policies can verify if the path follows the provided constraints. In addition, a technology-specific data-plane mechanism can be used (following [RFC5920], Section 5.8) to verify the data-plane connectivity and deviation from constraints.
悪意のあるPCEケースから保護するために、PCCは、PCEによって提供されるパスを受け入れるか受け入れないかのポリシーを設定する必要があります（SHOULD）。これらのポリシーは、パスが指定された制約に従っているかどうかを確認できます。さらに、テクノロジー固有のデータプレーンメカニズムを使用して（[RFC5920]、セクション5.8に従って）、データプレーンの接続性と制約からの逸脱を確認できます。
The usage of Transport Layer Security (TLS) to enhance PCEP security is described in [RFC8253]. The document describes the initiation of TLS procedures, the TLS handshake mechanisms, the TLS methods for peer authentication, the applicable TLS ciphersuites for data exchange, and the handling of errors in the security checks. PCE and PCC SHOULD use the mechanism in [RFC8253] to protect against malicious PCC and PCE.
PCEPセキュリティを強化するためのトランスポート層セキュリティ（TLS）の使用法は、[RFC8253]で説明されています。このドキュメントでは、TLSプロシージャの開始、TLSハンドシェイクメカニズム、ピア認証のTLSメソッド、データ交換に適用可能なTLS暗号スイート、およびセキュリティチェックでのエラーの処理について説明します。 PCEとPCCは、[RFC8253]のメカニズムを使用して、悪意のあるPCCとPCEから保護する必要があります（SHOULD）。
Finally, as mentioned by [RFC7025], the PCEP extensions that support GMPLS should be considered under the same security as current PCE work, and this extension will not change the underlying security issues. However, given the critical nature of the network infrastructures under control by GMPLS, the security issues described above should be seriously considered when deploying a GMPLS-PCE-based control plane for such networks. For an overview of the security considerations, not only related to PCE/PCEP, and vulnerabilities of a GMPLS control plane, see [RFC5920].
最後に、[RFC7025]で述べられているように、GMPLSをサポートするPCEP拡張機能は、現在のPCE作業と同じセキュリティの下で検討する必要があり、この拡張機能は根本的なセキュリティ問題を変更しません。ただし、GMPLSの制御下にあるネットワークインフラストラクチャの重要な性質を考慮すると、このようなネットワークにGMPLS-PCEベースのコントロールプレーンを展開する場合は、上記のセキュリティ問題を真剣に検討する必要があります。 PCE / PCEPだけでなく、GMPLSコントロールプレーンの脆弱性に関連するセキュリティの考慮事項の概要については、[RFC5920]を参照してください。
[G.709-v3] ITU-T, "Interfaces for the optical transport network", Recommendation G.709/Y.1331, June 2016, <https://www.itu.int/rec/T-REC-G.709-201606-I/en>.
[G.709-v3] ITU-T、「光トランスポートネットワークのインターフェイス」、勧告G.709 / Y.1331、2016年6月、<https://www.itu.int/rec/T-REC-G .709-201606-I / en>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, <https://www.rfc-editor.org/info/rfc2210>.
[RFC2210] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、RFC 2210、DOI 10.17487 / RFC2210、1997年9月、<https://www.rfc-editor.org/info/rfc2210>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[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>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<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>.
[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、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, <https://www.rfc-editor.org/info/rfc3477>.
[RFC3477] Kompella、K。およびY. Rekhter、「Resource ReSerVation Protocol-Traffic Engineering（RSVP-TE）での番号なしリンクのシグナリング」、RFC 3477、DOI 10.17487 / RFC3477、2003年1月、<https：//www.rfc- editor.org/info/rfc3477>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, <https://www.rfc-editor.org/info/rfc4003>.
[RFC4003] Berger、L。、「GMPLS Signaling Procedure for Egress Control」、RFC 4003、DOI 10.17487 / RFC4003、2005年2月、<https://www.rfc-editor.org/info/rfc4003>。
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006, <https://www.rfc-editor.org/info/rfc4328>.
[RFC4328] Papadimitriou、D。、編、「G.709光トランスポートネットワーク制御のための一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張」、RFC 4328、DOI 10.17487 / RFC4328、2006年1月、<https：// www .rfc-editor.org / info / rfc4328>。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, DOI 10.17487/RFC4606, August 2006, <https://www.rfc-editor.org/info/rfc4606>.
[RFC4606]マニー、E。およびD.パパディミトリウ、「同期光ネットワーク（SONET）および同期デジタル階層（SDH）制御用の汎用マルチプロトコルラベルスイッチング（GMPLS）拡張」、RFC 4606、DOI 10.17487 / RFC4606、2006年8月、<https://www.rfc-editor.org/info/rfc4606>。
[RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, DOI 10.17487/RFC4802, February 2007, <https://www.rfc-editor.org/info/rfc4802>.
[RFC4802]ナドー、T。、エド。およびA.ファレル編、「Generalized Multiprotocol Label Switching（GMPLS）Traffic Engineering Management Information Base」、RFC 4802、DOI 10.17487 / RFC4802、2007年2月、<https://www.rfc-editor.org/info/rfc4802 >。
[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>.
[RFC4872] Lang、JP、編、Rekhter、Y、編、D。Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張機能」 、RFC 4872、DOI 10.17487 / RFC4872、2007年5月、<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>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<https：//www.rfc-editor .org / info / rfc4873>。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、DOI 10.17487 / RFC5088、2008年1月、<https://www.rfc-editor.org/info/rfc5088>。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、DOI 10.17487 / RFC5089、2008年1月、<https://www.rfc-editor.org/info/rfc5089>。
[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>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<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>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジの機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<https://www.rfc-editor.org/info/rfc5520>。
[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>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、DOI 10.17487 / RFC5521、2009年4月、<https：/ /www.rfc-editor.org/info/rfc5521>。
[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>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、およびY. Lee、「Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）」、RFC 5541、DOI 10.17487 / RFC5541、2009年6月、<https： //www.rfc-editor.org/info/rfc5541>。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, <https://www.rfc-editor.org/info/rfc6001>.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Shiomoto、K.、Brungard、D。、およびJL。 Le Roux、「Multilayer- Multi-Region Networks（MLN / MRN）用のGeneralized MPLS（GMPLS）Protocol Extensions」、RFC 6001、DOI 10.17487 / RFC6001、2010年10月、<https://www.rfc-editor.org / info / rfc6001>。
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, <https://www.rfc-editor.org/info/rfc6003>.
[RFC6003] Papadimitriou、D。、「イーサネットトラフィックパラメータ」、RFC 6003、DOI 10.17487 / RFC6003、2010年10月、<https://www.rfc-editor.org/info/rfc6003>。
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <https://www.rfc-editor.org/info/rfc6205>.
[RFC6205] Otani、T.、Ed。およびD. Li、編、「Lambda-Switch-Capable（LSC）ラベルスイッチングルーターの一般化されたラベル」、RFC 6205、DOI 10.17487 / RFC6205、2011年3月、<https://www.rfc-editor.org/info / rfc6205>。
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011, <https://www.rfc-editor.org/info/rfc6387>.
[RFC6387] Takacs、A.、Berger、L.、Caviglia、D.、Fedyk、D。、およびJ. Meuric、「GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths（LSPs）」、RFC 6387、DOI 10.17487 / RFC6387、9月2011、<https://www.rfc-editor.org/info/rfc6387>。
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014, <https://www.rfc-editor.org/info/rfc7139>.
[RFC7139] Zhang、F.、Ed。、Zhang、G.、Belotti、S.、Ceccarelli、D.、and K. Pithewan、 "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"、RFC 7139、 DOI 10.17487 / RFC7139、2014年3月、<https://www.rfc-editor.org/info/rfc7139>。
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <https://www.rfc-editor.org/info/rfc7570>.
[RFC7570] Margaria、C.、Ed。、Martinelli、G.、Balls、S。、およびB. Wright、「明示的ルートオブジェクト（ERO）のラベルスイッチドパス（LSP）属性」、RFC 7570、DOI 10.17487 / RFC7570、2015年7月、<https://www.rfc-editor.org/info/rfc7570>。
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., and D. Ceccarelli, "RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7792, DOI 10.17487/RFC7792, March 2016, <https://www.rfc-editor.org/info/rfc7792>.
[RFC7792] Zhang、F.、Zhang、X.、Farrel、A.、Gonzalez de Dios、O。、およびD. Ceccarelli、「Flexi-Grid Dense Wavelength Division Multiplexing（DWDM）ネットワークをサポートするRSVP-TEシグナリング拡張"、RFC 7792、DOI 10.17487 / RFC7792、2016年3月、<https://www.rfc-editor.org/info/rfc7792>。
[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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）のセキュアなトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[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>.
[RFC8282] Oki、E.、Takeda、T.、Farrel、A。、および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、2017年12月、<https://www.rfc-editor.org/info/rfc8282>。
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, <https://www.rfc-editor.org/info/rfc8306>.
[RFC8306] Zhao、Q.、Dhody、D.、Ed。、Palleti、R。、およびD. King、「ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパスのPath Computation Element Communication Protocol（PCEP）への拡張」 、RFC 8306、DOI 10.17487 / RFC8306、2017年11月、<https://www.rfc-editor.org/info/rfc8306>。
[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>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<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>.
[RFC4657] Ash、J.、Ed。およびJ.L. Le Roux編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[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>.
[RFC6123] Farrel、A。、「経路計算要素（PCE）ワーキンググループドラフトに管理セクションを含める」、RFC 6123、DOI 10.17487 / RFC6123、2011年2月、<https://www.rfc-editor.org/info / rfc6123>。
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <https://www.rfc-editor.org/info/rfc6163>.
[RFC6163] Lee、Y.、Ed。、Bernstein、G.、Ed。、およびW. Imajuku、「GMPLSおよびPath Computation Element（PCE）Control for Wavelength Switched Optical Networks（WSONs）」、RFC 6163、DOI 10.17487 / RFC6163、2011年4月、<https://www.rfc-editor.org/info/rfc6163>。
[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>.
[RFC7025] Otani、T.、Ogaki、K.、Caviglia、D.、Zhang、F。、およびC. Margaria、「PCEのGMPLSアプリケーションの要件」、RFC 7025、DOI 10.17487 / RFC7025、2013年9月、<https ：//www.rfc-editor.org/info/rfc7025>。
[RFC7449] Lee, Y., Ed., Bernstein, G., Ed., Martensson, J., Takeda, T., Tsuritani, T., and O. Gonzalez de Dios, "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, DOI 10.17487/RFC7449, February 2015, <https://www.rfc-editor.org/info/rfc7449>.
[RFC7449] Lee、Y.、Ed。、Bernstein、G.、Ed。、Martensson、J.、Takeda、T.、Turitani、T。、およびO. Gonzalez de Dios、「Path Computation Element Communication Protocol（PCEP） Wavelength Switched Optical Network（WSON）Routing and Wavelength Assignment」、RFC 7449、DOI 10.17487 / RFC7449、2015年2月、<https://www.rfc-editor.org/info/rfc7449>の要件。
As an example, a request for one co-signaled n x VC-4 TE-LSP will not use LOAD-BALANCING. In case the VC-4 components can use different paths, the BANDWIDTH with object type 3 will contain the complete n x VC-4 traffic specification, and the LOAD-BALANCING object will contain the minimum co-signaled VC-4. For an SDH network, a request for a TE-LSP group with 10 VC-4 containers, with each path using at minimum 2 x VC-4 containers, can be represented with a BANDWIDTH object with object type 3, the Bw Spec Type set to 4, and the content of the Generalized Bandwidth field with ST=6, RCC=0, NCC=0, NVC=10, and MT=1. The LOAD-BALANCING with object type 2 with the Bw Spec Type set to 4 and Max-LSP=5, Min Bandwidth Spec is ST=6, RCC=0, NCC=0, NVC=2, MT=1. The PCE can respond with a maximum of 5 paths, with each path having a BANDWIDTH object type 3 and a Generalized Bandwidth field matching the Min Bandwidth Spec from the LOAD-BALANCING object of the corresponding request.
例として、1つの共同通知されたn x VC-4 TE-LSPに対する要求は、LOAD-BALANCINGを使用しません。 VC-4コンポーネントが異なるパスを使用できる場合、オブジェクトタイプ3のBANDWIDTHには完全なn x VC-4トラフィック仕様が含まれ、LOAD-BALANCINGオブジェクトには最小の共同信号VC-4が含まれます。 SDHネットワークの場合、10個のVC-4コンテナーを持つTE-LSPグループの要求は、各パスが少なくとも2 x VC-4コンテナーを使用し、オブジェクトタイプ3、BWスペックタイプセットを持つBANDWIDTHオブジェクトで表すことができます。 〜4、およびST = 6、RCC = 0、NCC = 0、NVC = 10、およびMT = 1のGeneralized Bandwidthフィールドの内容。 Bw Spec Typeが4に設定され、Max-LSP = 5のオブジェクトタイプ2のLOAD-BALANCING、最小帯域幅仕様はST = 6、RCC = 0、NCC = 0、NVC = 2、MT = 1です。 PCEは最大5つのパスで応答できます。各パスには、BANDWIDTHオブジェクトタイプ3と、対応する要求のLOAD-BALANCINGオブジェクトの最小帯域幅仕様に一致する一般化帯域幅フィールドがあります。
Acknowledgments
謝辞
The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar Gonzalez de Dios, Cyril Margaria, and Franz Rambach that led to the results in this document received funding from the European Community's Seventh Framework Program FP7/2007-2013 under grant agreement no. 247674 and no. 317999.
このドキュメントの結果につながったラモンカセラス、フランシスコハビエルヒメネスチコ、オスカーゴンザレスデディオス、キリルマルガリア、フランツランバッハの研究は、欧州共同体の第7フレームワークプログラムFP7 / 2007-2013から助成金契約なしで資金提供を受けました。 247674といいえ。 317999。
The authors would like to thank Julien Meuric, Lyndon Ong, Giada Lander, Jonathan Hardwick, Diego Lopez, David Sinicrope, Vincent Roca, Dhruv Dhody, Adrian Farrel, and Tianran Zhou for their review and useful comments.
著者らは、レビューと有益なコメントを提供してくれたJulien Meuric、Lyndon Ong、Giada Lander、Jonathan Hardwick、Diego Lopez、David Sinicrope、Vincent Roca、Dhruv Dhody、Adrian Farrel、およびTianran Zhouに感謝します。
Thanks to Alisa Cooper, Benjamin Kaduk, Elwyn Davies, Martin Vigoureux, Roman Danyliw, and Suresh Krishnan for the IESG-related comments.
IESG関連のコメントを提供してくれたAlisa Cooper、Benjamin Kaduk、Elwyn Davies、Martin Vigoureux、Roman Danyliw、Suresh Krishnanに感謝します。
Contributors
貢献者
Elie Sfeir Coriant St. Martin Strasse 76 81541 Munich Germany
Elie Sfeir Coriant St. Martin Strasse 76 81541ミュンヘンドイツ
Email: elie.sfeir@coriant.com
Franz Rambach Nockherstrasse 2-4 81541 Munich Germany
Franz Rambach Nockherstrasse 2-4 81541ミュンヘンドイツ
Phone: +49 178 8855738
Email: franz.rambach@cgi.com
Francisco Javier Jimenez Chico Telefonica Investigacion y Desarrollo C/ Emilio Vargas 6 28043 Madrid Spain
フランシスコハビエルヒメネスチコテレフォニカリサーチアンドデベロップメントC /エミリオバルガス6 28043マドリードスペイン
Phone: +34 91 3379037
Email: fjjc@tid.es
Suresh Babu
シュレシュバブ
Email: sureshhimnish@gmail.com
Young Lee Samsung Electronics
ヤングリーサムスンエレクトロニクス
Email: younglee.tx@gmail.com
Senthil Kumar S
センティルクマール
Email: ssenthilkumar@gmail.com
Jun Sun Huawei Technologies Shenzhen China
Jun Sun Huawei Technologies深セン中国
Email: johnsun@huawei.com
Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya PMT Ed B4 Av. Carl Friedrich Gauss 7 08660 Castelldefels, Barcelona Spain
Ramon Casellas CTTC-カタロニア通信技術センターPMT Ed B4 Av。カールフリードリヒガウス7 08660カステルデフェルス、バルセロナスペイン
Phone: +34 93 6452916
Email: ramon.casellas@cttc.e
Authors' Addresses
著者のアドレス
Cyril Margaria (editor) Juniper
シリル・マルガリア（編集者）ジュニパー
Email: cmargaria@juniper.net
Oscar Gonzalez de Dios (editor) Telefonica Investigacion y Desarrollo C/ Ronda de la Comunicacion 28050 Madrid Spain
オスカーゴンザレスデディオス（編集者）Telefonica Investigacion y Desarrollo C /ロンダデラコミュニカシオン28050マドリードスペイン
Phone: +34 91 4833441
Email: oscar.gonzalezdedios@telefonica.com
Fatai Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China
fa too Zhang（editor）hu AはテクノロジーF3-5-br＆Dセンター、hu Aは基本禁止日、長いギャング地区は非常に現実的な518129中国
Email: zhangfatai@huawei.com