[要約] RFC 5521は、PCEPの拡張であり、ルート除外のための機能を提供します。このRFCの目的は、PCEPを使用してネットワーク経路の計算を行う際に、特定の経路を除外するためのメカニズムを提供することです。
Network Working Group E. Oki
Request for Comments: 5521 University of Electro-Communications
Category: Standards Track T. Takeda
NTT
A. Farrel
Old Dog Consulting
April 2009
Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
ルート除外のためのパス計算要素通信プロトコル（PCEP）への拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
PATH計算要素（PCE）は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワークのトラフィックエンジニアリング（TE）をサポートするパス計算の関数を提供します。
When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".
パス計算クライアント（PCC）がルートのPCEを要求する場合、PCCがパス計算の制約として、抽象ノード、リソース、および共有リスクリンクグループ（SRLG）を明示的に指定することが役立つ場合があります。計算されたルートから除外。このような制約は、「ルート除外」と呼ばれます。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions.
PCE通信プロトコル（PCEP）は、PCCSとPCES間の通信プロトコルとして設計されています。このドキュメントは、ルート除外のPCEP拡張機能を示しています。
Table of Contents
目次
1. Introduction ................................................. 3
1.1. Conventions Used in This Document .......................3
2. Protocol Procedures and Extensions ........................... 4
2.1. Exclude Route Object (XRO) ............................. 4
2.1.1. Definition ..................................... 4
2.1.2. Processing Rules ............................... 8
2.2. Explicit Route Exclusion ............................... 9
2.2.1. Definition ..................................... 9
2.2.2. Processing Rules .............................. 10
3. Exclude Route with Confidentiality .......................... 11
3.1. Exclude Route Object (XRO) Carrying Path-Key .......... 11
3.1.1. Definition .................................... 11
3.1.2. Processing Rules .............................. 12
4. IANA Considerations ......................................... 13
4.1. PCEP Objects .......................................... 13
4.2. New Subobject for the Include Route Object ............ 13
4.3. Error Object Field Values ............................. 13
4.4. Exclude Route Flags ................................... 14
5. Manageability Considerations ................................ 14
6. Security Considerations ..................................... 14
7. References .................................................. 15
7.1. Normative References .................................. 15
7.2. Informative References ................................ 15
Acknowledgements ................................................ 16
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティです。パス計算クライアント（PCC）は、計算するパスのPCEにリクエストを行う場合があります。
When a PCC requests a PCE for a route, it may be useful for the PCC to specify abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the route.
PCCがルートのPCEを要求する場合、PCCがルートから明示的に除外される抽象ノード、リソース、および共有リスクリンクグループ（SRLG）を指定することが役立つ場合があります。
For example, disjoint paths for inter-domain Label Switched Paths (LSPs) may be computed by cooperation between PCEs, each of which computes segments of the paths across one domain. In order to achieve path computation for a secondary (backup) path, a PCE may act as a PCC to request another PCE for a route that must be node/link/SRLG disjoint from the primary (working) path. Another example is where a network operator wants a path to avoid specified nodes for administrative reasons, perhaps because the specified nodes will be out-of-service in the near future.
たとえば、ドメイン間ラベルスイッチされたパス（LSP）の分離パスは、PCE間の協力によって計算される場合があります。これは、それぞれが1つのドメインを横切るパスのセグメントを計算します。セカンダリ（バックアップ）パスのパス計算を実現するために、PCEはPCCとして機能し、プライマリ（作業）パスからノード/リンク/srlgの分離でなければならないルートの別のPCEを要求する場合があります。もう1つの例は、ネットワークオペレーターが、指定されたノードが近い将来にサービス外になるため、管理上の理由で指定されたノードを回避するパスを望んでいる場合です。
[RFC4657] specifies generic requirements for a communication protocol between PCCs and PCEs. Generic constraints described in [RFC4657] include route exclusions for links, nodes, and SRLGs. That is, the requirement for support of route exclusions within the PCC-PCE communication protocol is already established.
[RFC4657]は、PCCSとPCES間の通信プロトコルの一般的な要件を指定します。[RFC4657]で説明されている一般的な制約には、リンク、ノード、およびSRLGのルート除外が含まれます。つまり、PCC-PCE通信プロトコル内のルート除外のサポートの要件はすでに確立されています。
The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. This document presents PCEP extensions to satisfy the requirements for route exclusions as described in Sections 5.1.4 and 5.1.16 of [RFC4657].
PCE通信プロトコル（PCEP）は、PCCSとPCES間の通信プロトコルとして設計されており、[RFC5440]で定義されています。このドキュメントでは、[RFC4657]のセクション5.1.4および5.1.16で説明されているように、ルート除外の要件を満たすためのPCEP拡張機能を提示します。
Note that MPLS-TE and GMPLS signaling extensions for communicating route exclusions between network nodes for specific Label Switched Paths (LSPs) are described in [RFC4874]. Route exclusions may be specified during provisioning requests for specific LSPs by setting the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812] to false (2).
特定のラベルスイッチ付きパス（LSP）のネットワークノード間のルート除外を通信するためのMPLS-TEおよびGMPLSシグナリング拡張は[RFC4874]で説明されていることに注意してください。ルート除外は、[RFC3812]で定義されているMPLS-TE-STD-MIBのMPLSTUNNELHOPINCLUDEオブジェクトをFALSE（2）に設定することにより、特定のLSPのプロビジョニングリクエスト中に指定できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes the procedures adopted by a PCE handling a request for path computation with route exclusions received from a PCC, and defines how those exclusions are encoded.
このセクションでは、PCCから受信したルート除外を使用してパス計算のリクエストを処理するPCEによって採用された手順について説明し、それらの除外のエンコードを定義します。
There are two types of route exclusion described in [RFC4874].
[RFC4874]で説明されているルート除外には2つのタイプがあります。
1. Exclusion of certain abstract nodes or resources from the whole path. This set of abstract nodes is referred to as the Exclude Route List.
1. パス全体から特定の抽象ノードまたはリソースを除外します。この抽象ノードのセットは、除外ルートリストと呼ばれます。
2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an explicit path. Such specific exclusions are referred to as an Explicit Route Exclusion.
2. 明示的なパスに存在する特定の抽象ノード間の特定の抽象ノードまたはリソースの除外。このような特定の除外は、明示的なルート除外と呼ばれます。
This document defines protocol extensions to allow a PCC to specify both types of route exclusions to a PCE on a path computation request.
このドキュメントでは、PCCがパス計算リクエストでPCEへの両方のタイプのルート除外を指定できるように、プロトコル拡張機能を定義します。
A new PCEP object, the Exclude Route Object (XRO), is defined to convey the Exclude Route List. The existing Include Route Object (IRO) in PCEP [RFC5440] is modified by introducing a new IRO subobject, the Explicit Exclusion Route subobject (EXRS), to convey Explicit Route Exclusions.
新しいPCEPオブジェクトである除外ルートオブジェクト（XRO）は、除外ルートリストを伝達するために定義されています。PCEP [RFC5440]の既存のLOUTEオブジェクト（IRO）は、明示的なルート除外を伝えるために、明示的な除外ルートサブオブジェクト（EXRS）である新しいIROサブオブジェクトを導入することにより変更されます。
The XRO is OPTIONAL and MAY be carried within Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages.
XROはオプションであり、Path Computation Request（PCREQ）およびPATH計算応答（PCREP）メッセージ内で携帯できます。
When present in a PCReq message, the XRO provides a list of network resources that the PCE is requested to exclude from the path that it computes. Flags associated with each list member instruct the PCE as to whether the network resources must be excluded from the computed path, or whether the PCE should make best efforts to exclude the resources from the computed path.
PCREQメッセージに存在する場合、XROは、PCEが計算するパスから除外するようにPCEが要求されるネットワークリソースのリストを提供します。各リストメンバーに関連付けられているフラグは、PCEに、計算されたパスからネットワークリソースを除外する必要があるかどうか、またはPCEが計算されたパスからリソースを除外するために最善の努力をする必要があるかどうかを指示します。
The XRO MAY be used on a PCRep message that carries the NO-PATH object (i.e., one that reports a path computation failure) to indicate the set of elements of the original XRO that prevented the PCE from finding a path.
XROは、PCEがPCEのパスを見つけるのを妨げる元のXROの要素のセットを示すために、パスなしオブジェクト（つまり、パス計算障害を報告するもの）を運ぶPCREPメッセージ（つまり、パス計算障害を報告するもの）で使用できます。
The XRO MAY also be used on a PCRep message for a successful path computation when the PCE wishes to provide a set of exclusions to be signaled during LSP setup using the extensions to Resource Reservation Protocol (RSVP)-TE [RFC4874].
XROは、PCEがリソース予約プロトコル（RSVP）-TE [RFC4874]への拡張機能を使用してLSPセットアップ中にシグナルを提供する一連の除外を提供したい場合に、パス計算を成功させるためにPCREPメッセージで使用することもできます。
The XRO Object-Class is 17.
Xroオブジェクトクラスは17です。
The XRO Object-Type is 1.
XROオブジェクトタイプは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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XRO Body Format
図1：XROボディ形式
Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be ignored on receipt.
予約済み：16ビット - 送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Flags: 16 bits - The following flags are currently defined:
フラグ：16ビット - 現在、次のフラグが定義されています。
F (Fail - 1 bit): when set, the requesting PCC requires the computation of a new path for an existing TE LSP that has failed. If the F bit is set, the path of the existing TE LSP MUST be provided in the PCReq message by means of a Record Route Object (RRO) defined in [RFC5440]. This allows the path computation to take into account the previous path and reserved resources to avoid double bandwidth booking should the Traffic Engineering Database (TED) have not yet been updated or the corresponding resources not be yet been released. This will usually be used in conjunction with the exclusion from the path computation of the failed resource that caused the LSP to fail.
f（fail -1ビット）：設定すると、リクエストPCCには、失敗した既存のTE LSPの新しいパスの計算が必要です。Fビットが設定されている場合、[RFC5440]で定義されたレコードルートオブジェクト（RRO）を使用して、既存のTE LSPのパスをPCREQメッセージに提供する必要があります。これにより、パス計算は、トラフィックエンジニアリングデータベース（TED）がまだ更新されていない場合、または対応するリソースがまだリリースされていない場合、二重帯域幅の予約を回避するために、以前のパスと予約リソースを考慮します。これは通常、LSPを失敗させた失敗したリソースのパス計算から除外されることと組み合わせて使用されます。
Subobjects: The XRO is made up of one or more subobject(s). An XRO with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.
サブオブジェクト：XROは1つ以上のサブオブジェクトで構成されています。サブオブジェクトのないXROを送信してはならず、受領時に無視する必要があります。
In the following subobject definitions, a set of fields have consistent meaning as follows:
次のサブオブジェクトの定義では、一連のフィールドに次のように一貫した意味があります。
X The X-bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the resource.
X Xビットは、除外が必須か希望かを示します。0は、指定されたリソースがPCEによって計算されたパスから除外する必要があることを示します。1は、指定されたリソースをPCEによって計算されたパスから除外する必要があることを示しますが、PCEポリシーと、他の制約を満たし、リソースを除外する実行可能なパスの欠如の対象となる場合があります。
Type The type of the subobject. The following subobject types are defined.
サブオブジェクトのタイプを入力します。次のサブオブジェクトタイプが定義されています。
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Length The length of the subobject including the Type and Length fields.
長さタイプと長さのフィールドを含むサブオブジェクトの長さ。
Prefix Length Where present, this field can be used to indicate a set of addresses matching a prefix. If the subobject indicates a single address, the prefix length MUST be set to the full length of the address.
プレフィックスの長さが存在する場合、このフィールドを使用して、プレフィックスに一致するアドレスのセットを示すことができます。サブオブジェクトが単一のアドレスを示している場合、プレフィックスの長さをアドレスの全長に設定する必要があります。
Attribute The Attribute field indicates how the exclusion subobject is to be interpreted.
属性属性フィールドは、除外サブオブジェクトの解釈方法を示します。
0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, and 3.
0インターフェイスサブオブジェクトは、インターフェイスまたはインターフェイスのセットとして解釈されます。サブオブジェクトによって識別されるすべてのインターフェイスは、Xビットの設定に従って計算されたパスから除外されます。この値は、サブオブジェクトタイプ1、2、および3に対してのみ有効です。
1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, 3, and 4.
1ノードサブオブジェクトは、ノードまたはノードのセットとして解釈されます。サブオブジェクトによって識別されるすべてのノードは、Xビットの設定に従って計算されたパスから除外されます。この値は、サブオブジェクトタイプ1、2、3、および4に対してのみ有効です。
2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects.
2 srlg subobjectは、srlgを明示的に識別するか、サブオブジェクトによって識別されたリソースまたはリソースに関連付けられたすべてのSRLGを示します。特定されたものとSRLGを共有するリソースは、Xビットの設定に従って計算されたパスから除外されます。この値は、すべてのサブオブジェクトに対して有効です。
Reserved Reserved fields within subobjects MUST be transmitted as zero and SHOULD be ignored on receipt.
サブオブジェクト内の予約済みフィールドは、ゼロとして送信する必要があり、受信時に無視する必要があります。
The subobjects are encoded as follows:
サブオブジェクトは次のようにエンコードされます。
IPv4 prefix Subobject
IPv4プレフィックスsubobject
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 = 1 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 prefix Subobject
IPv6プレフィックスsubobject
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 = 2 | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unnumbered Interface ID Subobject
非番号インターフェイスID subobject
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 = 3 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TE Router ID and Interface ID fields are as defined in [RFC3477].
TEルーターIDおよびインターフェイスIDフィールドは、[RFC3477]で定義されています。
Autonomous System Number Subobject
自律システム番号サブオブジェクト
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 = 4 | Length | 2-Octet AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided. It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support.
他のPCEPオブジェクト[RFC5440]およびRSVP-TEオブジェクト[RFC3209]と同様に、4-OCTET自律システム（AS）番号のサポートは提供されていないことに注意してください。数字がより一般的になるにつれて4-OCTETとして、PCEPとRSVP-TEの両方が、このサポートを追加するための一貫した方法で更新されると予想されます。
SRLG Subobject
srlg subobject
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 = 5 | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt.
属性は2つに設定する必要があり、受信時に無視する必要があります。
A PCC builds an XRO to encode all of the resources that it wishes the PCE to exclude from the path that it is requested to compute. For each exclusion, the PCC clears the X-bit to indicate that the PCE is required to exclude the resources, or sets the X-bit to indicate that the PCC simply desires that the resources are excluded. For each exclusion, the PCC also sets the Attribute field to indicate how the PCE should interpret the contents of the exclusion subobject.
When a PCE receives a PCReq message it looks for an XRO to see if exclusions are required. If the PCE finds more than one XRO, it MUST use the first one in the message and MUST ignore subsequent instances.
PCEがPCREQメッセージを受信すると、除外が必要かどうかを確認するXROを探します。PCEが複数のXROを見つけた場合、メッセージの最初のXROを使用し、後続のインスタンスを無視する必要があります。
If the PCE does not recognize the XRO, it MUST return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440].
PCEがXROを認識していない場合、[RFC5440]に記載されているように、エラータイプの「不明なオブジェクト」を使用してPCERRメッセージを返す必要があります。
If the PCE is unwilling or unable to process the XRO, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440].
PCEがXROを処理したくないか、または処理したくない場合は、[RFC5440]に記載されている関連する手順に従って、エラータイプの「サポートオブジェクト」でPCERRメッセージを返す必要があります。
If the PCE processes the XRO and attempts to compute a path, it MUST adhere to the requested exclusions as expressed in the XRO. That is, the returned path MUST NOT include any resources encoded with the X-bit clear, and SHOULD NOT include any with the X-bit set unless alternate paths that match the other constraints expressed in the PCReq are unavailable.
PCEがXROを処理し、パスを計算しようとする場合、XROで表されるように要求された除外に準拠する必要があります。つまり、返されたパスには、Xビットクリアでエンコードされたリソースを含めるべきではありません。PCREQで表現された他の制約に一致する代替パスが利用できない限り、Xビットセットに含まれてはなりません。
When a PCE returns a path in a PCRep, it MAY also supply an XRO. An XRO in a PCRep message with the NO-PATH object indicates that the set of elements of the original XRO prevented the PCE from finding a path. On the other hand, if an XRO is present in a PCRep message without a NO-PATH object, the PCC SHOULD apply the contents using the same rules as in [RFC4874] and the PCC or a corresponding LSR SHOULD signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs should apply. This may be particularly useful in per-domain path computation scenarios [RFC5152].
PCEがPCREPのパスを返すと、XROも供給する場合があります。No-Pathオブジェクトを使用したPCREPメッセージのXROは、元のXROの要素のセットがPCEがパスを見つけるのを妨げたことを示しています。一方、XROがNO-PATHオブジェクトのないPCREPメッセージに存在する場合、PCCは[RFC4874]と同じルールを使用してコンテンツを適用し、PCCまたは対応するLSRはRSVP-TE Xroを信号する必要があります。下流のLSRが適用する除外を示すために。これは、ドメインごとのパス計算シナリオ[RFC5152]で特に役立つ場合があります。
Explicit Route Exclusion defines network elements that must not or should not be used on the path between two abstract nodes or resources explicitly indicated in the Include Route Object (IRO) [RFC5440]. This information is encoded by defining a new subobject for the IRO.
明示的なルート除外は、include routeオブジェクト（IRO）[RFC5440]に明示的に示されている2つの抽象ノードまたはリソースの間のパスで使用してはならない、または使用すべきではないネットワーク要素を定義します。この情報は、IROの新しいサブオブジェクトを定義することによりエンコードされます。
The new IRO subobject, the Explicit Exclusion Route subobject (EXRS), has type 33 (see Section 4). The EXRS contains one or more subobjects in its own right. An EXRS MUST NOT be sent with no subobjects, and if received with no subobjects, MUST be ignored.
新しいIROサブオブジェクト、明示的な除外ルートサブオブジェクト（EXRS）には33型があります（セクション4を参照）。EXRSには、それ自体に1つ以上のサブオブジェクトが含まれています。exrsはサブオブジェクトなしで送信してはなりません。サブオブジェクトなしで受信した場合は無視する必要があります。
The format of the EXRS is as follows:
EXRSの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// One or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L MUST be set to zero on transmission and MUST be ignored on receipt.
Lは送信時にゼロに設定する必要があり、受信時に無視する必要があります。
Reserved MUST be set to zero on transmission and SHOULD be ignored on receipt.
予約されたものは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The EXRS subobject may carry any of the subobjects defined for inclusion in the XRO by this document or by future documents. The meanings of the fields of the XRO subobjects are unchanged when the subobjects are included in an EXRS, except that scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO.
EXRS Subobjectは、このドキュメントまたは将来のドキュメントでXroに含めるために定義されたサブオブジェクトのいずれかを搭載する場合があります。XROサブオブジェクトのフィールドの意味は、サブオブジェクトがEXRに含まれている場合に変更されませんが、除外の範囲は、IROの以前の要素と後続の要素の間の単一ホップに限定されています。
A PCC that supplies a partial explicit route to a PCE in an IRO MAY also specify explicit exclusions by including one or more EXRSs in the IRO.
IROでPCEへの部分的な明示的なルートを提供するPCCは、IROに1つ以上のEXRSを含めることにより、明示的除外を指定する場合があります。
If a PCE that does not support the use of EXRS receives an IRO in a PCReq message that contains an EXRS, it will respond according to the rules for a malformed object as described in [RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized EXRS.
EXRSの使用をサポートしていないPCEが、EXRSを含むPCREQメッセージでIROを受信する場合、[RFC5440]で説明されているように、奇形オブジェクトのルールに従って応答します。PCEには、PCERRにIROが含まれている場合があり、その場合、認識されていないEXRの直後にIROを終了する必要があります。
If a PCE that supports the EXRS in an IRO parses an IRO and encounters an EXRS that contains a subobject that it does not support or recognize, it MUST act according to the setting of the X-bit in the subobject. If the X-bit is clear, the PCE MUST respond with a PCErr with Error-Type "Unrecognized EXRS subobject" and set the Error-Value to the EXRS subobject type code (see Section 4). If the X-bit is set, the PCE MAY respond with a PCErr as already stated or MAY ignore the EXRS subobject: this choice is a local policy decision.
IROでEXRをサポートするPCEがIROを解析し、サポートまたは認識していないサブオブジェクトを含むEXRSに遭遇する場合、サブオブジェクトのXビットの設定に従って行動する必要があります。X-Bitがクリアな場合、PCEはエラータイプの「認識されていないEXRSサブオブジェクト」を使用してPCERRで応答する必要があり、エラー値をEXRSサブオブジェクトタイプコードに設定する必要があります（セクション4を参照）。X-Bitが設定されている場合、PCEは既に述べたようにPCERRで応答する場合があります。
If a PCE parses an IRO and encounters an EXRS subobject that it recognizes, it MUST act according to the requirements expressed in the subobject. That is, if the X-bit is clear, the PCE MUST NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO. If the X-bit is set, the PCE SHOULD NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO unless it is not possible to construct a path that avoids that resource while still complying with the other constraints expressed in the PCReq message.
PCEがIROを解析し、認識しているEXRSサブオブジェクトに遭遇した場合、サブオブジェクトで表明された要件に従って行動する必要があります。つまり、Xビットが明確な場合、PCEは、IROの前の抽象ノードとIROの次の抽象ノードの間のEXRSサブオブジェクトによって識別されるリソースを含むパスを生成してはなりません。X-Bitが設定されている場合、PCEは、IROの前の抽象ノードとIROの次の要約ノードの間のEXRSサブオブジェクトによって識別されたリソースを含むパスを生成してはなりません。PCREQメッセージで表現されている他の制約を順守しながら、そのリソースを回避するパス。
A successful path computation reported in a PCRep message MUST include an ERO to specify the path that has been computed as specified in [RFC5440]. That ERO MAY contain specific route exclusions using the EXRS as specified in [RFC4874].
PCREPメッセージで報告された成功したパス計算には、[RFC5440]で指定されているように計算されたパスを指定するためのEROを含める必要があります。そのEROには、[RFC4874]で指定されているEXRを使用して特定のルート除外が含まれる場合があります。
If the path computation fails and a PCErr is returned with a NO-PATH object, the PCE MAY include an IRO to report the hops that could not be complied with as described in [RFC5440], and that IRO MAY include EXRSs.
パス計算が失敗し、PCERRがノーパスオブジェクトで返される場合、PCEには[RFC5440]に記載されているとおりに順守できないホップを報告するIROが含まれ、IROにはEXRSが含まれる場合があります。
In PCE-based inter-domain diverse path computation, an XRO may be used to find a backup (secondary) path. A sequential path computation approach may be applied for this purpose, where a working (primary) path route is computed first and a backup path route that must be a node/link/SRLG disjoint route from the working path is then computed [RFC5298]. Backward Recursive Path Computation (BRPC) may be used for inter-domain path computation [RFC5441].
PCEベースのドメイン間の多様なパス計算では、XROを使用してバックアップ（セカンダリ）パスを見つけることができます。この目的には、シーケンシャルパス計算アプローチが適用される場合があります。この目的では、作業（プライマリ）パスルートが最初に計算され、作業パスからノード/リンク/SRLGの分離ルートである必要があるバックアップパスルートが計算されます[RFC5298]。後方再帰経路計算（BRPC）は、ドメイン間パス計算[RFC5441]に使用できます。
In some cases of inter-domain computation (e.g., where domains are administered by different service providers), confidentiality must be kept. For primary path computation, to preserve confidentiality, instead of explicitly expressing the computed route, Path-Key Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object (ERO) in the PCRep Message.
ドメイン間計算の場合（例：ドメインが異なるサービスプロバイダーによって管理される場合）、機密性を保持する必要があります。プライマリパス計算のために、機密性を維持するために、計算されたルートを明示的に表現する代わりに、Path-Key Subobjects（PKSS）[RFC5520]がPCREPメッセージの明示的なルートオブジェクト（ERO）に運ばれます。
Therefore, during inter-domain diverse path computation, it may be necessary to request diversity from a path that is not fully known and where a segment of the path is represented by a PKS. This means that a PKS may be present as a subobject of the XRO on a PCReq message.
したがって、ドメイン間の多様なパス計算中は、完全に知られていないパスからの多様性を要求する必要があり、パスのセグメントがPKSで表される場合があります。これは、PCREQメッセージのXROのサブオブジェクトとしてPKSが存在する可能性があることを意味します。
The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. The L bit of the PKS subobject in the XRO MUST be ignored.
XROサブオブジェクトのように表示される場合のPKSの形式と定義は、Lビットの定義を除き、[RFC5520]で定義されています。XROのPKSサブオブジェクトのLビットは無視する必要があります。
Consider that BRPC is applied for both working and backup path computation in a sequential manner. First, PCC requests PCE for the computation of a working path. After BRPC processing has completed, the PCC receives the results of the working-path computation expressed in an ERO in a PCRep message. The ERO may include PKSs if certain segments of the path are to be kept confidential.
BRPCは、動作とバックアップの両方のパス計算に連続的に適用されることを考えてください。まず、PCCは作業パスの計算に対してPCEを要求します。BRPC処理が完了した後、PCCはPCREPメッセージでEROで表された作業パス計算の結果を受け取ります。EROには、パスの特定のセグメントが機密に保たれる場合、PKSが含まれる場合があります。
For backup path computation, when the PCC constructs a PCReq Message, it includes the entire working-path in the XRO so that the computed path is node/link disjoint from the working path. The XRO may also include SRLGs to ensure SRLG diversity from the working path. If the working path ERO includes PKS subobjects, these are also included in the XRO to allow the PCE to ensure diversity.
バックアップパス計算の場合、PCCがPCREQメッセージを構築する場合、XROのワーキングパス全体が含まれているため、計算されたパスがノード/リンクが作業パスから切り離されます。XROには、作業経路からのSRLGの多様性を確保するためのSRLGSも含まれている場合があります。作業パスEROにPKSサブオブジェクトが含まれている場合、これらはXROにも含まれており、PCEが多様性を確保できるようにします。
A set of PCEs for backup path computation may be the same as ones for working path computation, or they may be different.
バックアップパス計算用のPCESセットは、動作パス計算の場合と同じであるか、それらが異なる場合があります。
- Identical PCEs
- 同一のPCE
In the case where the same PCEs are used for both path computations, the processing is as follows. During the process of BRPC for backup path computation, a PCE may encounter a PKS as it processes the XRO when it creates a virtual path tree (VPT) in its own domain. The PCE retrieves the PCE-ID from the PKS, recognizes itself, and converts the PKS into a set of XRO subobjects that it uses for the local calculation to create the VPT. The XRO subobjects created in this way MUST NOT be shared with other PCEs. Other operations are the same as BRPC.
両方のパス計算に同じPCEが使用される場合、処理は次のとおりです。バックアップパス計算用のBRPCのプロセス中、PCEは、独自のドメインで仮想パスツリー（VPT）を作成するとXROを処理するときにPKに遭遇する可能性があります。PCEは、PKSからPCE-IDを取得し、それ自体を認識し、PKSを使用してVPTを作成するために使用するXROサブオブジェクトのセットに変換します。この方法で作成されたXROサブオブジェクトは、他のPCEと共有してはなりません。他の操作はBRPCと同じです。
- Different PCEs
- 異なるpce
In the case where a set of PCEs for backup path computation is different from the ones used for working path computation, the processing is as follows. If a PCE encounters a PKS in an XRO when it is creating a virtual path tree in its own domain, the PCE retrieves the PCE-ID from the PKS and sends a PCReq message to the identified PCE to expand the PKS. The PCE computing the VPT treats the path segment in the response as a set of XRO subobjects in performing its path computation. The XRO subobjects determined in this way MUST NOT be shared with other PCEs.
バックアップパス計算のPCESのセットが、動作パス計算に使用されるものとは異なる場合、処理は次のとおりです。PCEが独自のドメインで仮想パスツリーを作成しているときにXROでPKSに遭遇した場合、PCEはPKSからPCE-IDを取得し、識別されたPCEにPCREQメッセージを送信してPKSを拡張します。VPTのPCE計算により、応答のパスセグメントがパス計算を実行する際にXROサブオブジェクトのセットとして扱います。この方法で決定されたXROサブオブジェクトは、他のPCEと共有してはなりません。
The "PCEP Parameters" registry contains a subregistry "PCEP Objects". IANA has made the following allocations from this registry.
「PCEPパラメーター」レジストリには、サブレジストリ「PCEPオブジェクト」が含まれています。IANAは、このレジストリから次の割り当てを行いました。
Object Name Reference Class 17 XRO [RFC5521] Object-Type 1: Route exclusion
オブジェクト名参照クラス17 XRO [RFC5521]オブジェクトタイプ1：ルート除外
This object should be registered as being allowed to carry the following subobjects:
このオブジェクトは、次のサブオブジェクトを運ぶことを許可されているために登録する必要があります。
Subobject Type Reference
1 IPv4 prefix [RFC3209]
2 IPv6 prefix [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
34 SRLG [RFC4874]
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO).
「PCEPパラメーター」レジストリには、include routeオブジェクト（IRO）のエントリを備えたサブレジストリ「PCEPオブジェクト」が含まれています。
IANA added a further subobject that can be carried in the IRO as follows:
IANAは、次のようにIROで持ち運ぶことができる追加のサブオブジェクトを追加しました。
Subobject Type Reference
サブオブジェクトタイプリファレンス
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
33明示的な除外ルートSubobject（EXRS）[RFC4874]
The "PCEP Parameters" registry contains a subregistry "Error Types and Values". IANA made the following allocations from this subregistry.
「PCEPパラメーター」レジストリには、サブレジストリ「エラータイプと値」が含まれています。IANAは、このサブレジストリから次の割り当てを行いました。
Error Type Meaning Reference
エラータイプ意味参照
11 Unrecognized EXRS subobject [RFC5521]
11認識されていないEXRS subobject [rfc5521]
IANA created a subregistry of the "PCEP Parameters" for the bits carried in the Flags field of the Exclude Route Object (XRO). The subregistry is called "XRO Flag Field".
IANAは、除外ルートオブジェクト（XRO）のフラグフィールドに運ばれるビットの「PCEPパラメーター」のサブレジストリを作成しました。サブレジストリは「XROフラグフィールド」と呼ばれます。
New bits may be allocated only by an IETF Consensus action.
新しいビットは、IETFコンセンサスアクションによってのみ割り当てられる場合があります。
The field contains 16 bits numbered from bit 0 as the most significant bit.
フィールドには、ビット0から最も重要なビットとして番号が付けられた16ビットが含まれています。
Bit Name Description Reference
ビット名説明リファレンス
15 F-bit Fail [RFC5221]
15 f-bit失敗[RFC5221]
A MIB module for management of the PCEP is being specified in a separate document [PCEP-MIB]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors.
PCEPの管理のためのMIBモジュールは、別のドキュメント[PCEP-MIB]で指定されています。そのMIBモジュールにより、個々のPCEPメッセージ、特にリクエスト、応答、エラーを調べることができます。
The MIB module MUST be extended to include the ability to view the route exclusion extensions defined in this document.
MIBモジュールは、このドキュメントで定義されているルート除外拡張機能を表示する機能を含めるように拡張する必要があります。
Several local policy decisions should be made at the PCE. Firstly, the exact behavior with regard to desired exclusions must be available for examination by an operator and may be configurable. Second, the behavior on receipt of an unrecognized XRO or EXRS subobject with the X-bit set should be configurable and must be available for inspection. The inspection and control of these local policy choices may be part of the PCEP MIB module.
PCEでいくつかのローカルポリシーの決定を下す必要があります。第一に、目的の除外に関する正確な動作は、オペレーターが検査するために利用できる必要があり、構成可能である場合があります。第二に、Xビットセットを使用して認識されていないXROまたはEXRSサブオブジェクトを受信した動作は構成可能であり、検査に利用できる必要があります。これらのローカルポリシーの選択の検査と制御は、PCEP MIBモジュールの一部である可能性があります。
The new exclude route mechanisms defined in this document allow finer and more specific control of the path computed by a PCE. Such control increases the risk if a PCEP message is intercepted, modified, or spoofed because it allows the attacker to exert control over the path that the PCE will compute or to make the path computation impossible. Therefore, the security techniques described in [RFC5440] are considered more important.
このドキュメントで定義されている新しい除外ルートメカニズムにより、PCEによって計算されたパスのより細かく具体的な制御が可能になります。PCEPメッセージが傍受、変更、またはスプーフィングされた場合、このような制御は、攻撃者がPCEが計算するパスを制御したり、パス計算を不可能にしたりするため、リスクを増加させます。したがって、[RFC5440]で説明されているセキュリティ手法がより重要であると考えられています。
Note, however, that the route exclusion mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security.
ただし、ルート除外メカニズムは、ネットワークの脆弱な部分をルーティングする機能をオペレーターに提供し、ネットワークセキュリティ全体を増やすために使用できることに注意してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、Jp。、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、RFC 5152、2008年2月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、Jp。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[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, April 2009.
[RFC5520] Bradford、R.、ed。、Ed。、Vasseur、JP。、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算のトポロジの機密性の保存」、RFC 5520、2009年4月。
[PCEP-MIB] Koushik, A. S. K., and E. Stephan, "PCE Communication Protocol(PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB] Koushik、A。S. K.、およびE. Stephan、「PCE Communication Protocol（PCEP）管理情報ベース」、2008年11月、Work in Progress。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）、RFC 3812、2004年6月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874] Lee、Cy。、Farrel、A。、およびS. de Cnodder、「除外ルート - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張」、2007年4月、RFC 4874。
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RFC5298] Takeda、T.、Ed。、Farrel、A.、ed。、Ikejiri、Y。、およびJP。Vasseur、「ドメイン間標識スイッチ付きパス（LSP）回復の分析」、RFC 5298、2008年8月。
Acknowledgements
謝辞
The authors would like to thank Fabien Verhaeghe for valuable comments on subobject formats. Thanks to Magnus Westerlund, Dan Romascanu, Tim Polk, and Dave Ward for comments during IESG review.
著者は、サブオブジェクト形式に関する貴重なコメントについて、Fabien Verhaegheに感謝したいと思います。IESGレビュー中にコメントをしてくれたマグナスウェスターランド、ダンロマスカヌ、ティムポーク、デイブウォードに感謝します。
Authors' Addresses
著者のアドレス
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
Eiji oki Electro-communications 1-5-1 Chofugaoka Chofu、Tokyo 182-8585 Japan
EMail: oki@ice.uec.ac.jp
Tomonori Takeda NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan EMail: takeda.tomonori@lab.ntt.co.jp
Tomonori Takeda NTT 3-9-11 Midori-Cho、Musashino-Shi、Tokyo 180-8585、日本メール：takeda.tomonori@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk