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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
経路計算エレメント（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を要求すると、それが明示的になるべき経路計算に制約、抽象化ノード、リソース、および共有リスクリンクグループ（SRLGs）として、指定するPCCのために有用である可能性があります計算されたルートから除外。このような制約は、「ルートの除外」と呼ばれています。
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）をのPCCとPCEとの間の通信プロトコルとして設計されています。この文書では、ルートの除外のための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を要求すると、それが明示的にルートから除外される抽象化ノード、リソース、および共有リスクリンクグループ（SRLGs）を指定するにはPCCのために有用である可能性があります。
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間の協働によって計算することができます。二次（バックアップ）パスの経路計算を達成するために、PCEは、プライマリ（ワーキング）パスからのノード/リンク/ SRLGの互いに素でなければならないルートの別のPCEを要求するPCCとして作用することができます。指定されたノードは、近い将来に圏外になるかもしれないので、ネットワークオペレータは、管理上の理由で、指定したノードを回避するために、パスを望んでいる場所別の例はあります。
[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]はのPCCとPCEとの間の通信プロトコルのための一般的な要件を指定します。 [RFC4657]で説明ジェネリック制約は、リンク、ノード、及びSRLGsのルートの除外を含みます。つまり、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）はのPCCとPCEとの間の通信プロトコルとして設計されており、[RFC5440]で定義されています。この文書は、セクション5.1.4と[RFC4657]の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).
なおは、MPLS-TEやGMPLSは、[RFC4874]に記載されているパス（LSPを）スイッチ特定のラベルのためのネットワークノード間の経路の除外を通信するための拡張をシグナリング。ルートの除外をfalseに[RFC3812]で定義されたMPLS-TE-STD-MIBのmplsTunnelHopIncludeオブジェクトを設定することにより、特定のLSPの要求をプロビジョニング時に指定することができる（2）。
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]の既存含めるルートオブジェクト（IRO）は、明示的経路除外を伝えるために、新たなIROサブオブジェクトは、明示的な除外ルートサブオブジェクト（EXRS）を導入することによって改変されます。
The XRO is OPTIONAL and MAY be carried within Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages.
XROはオプションで、経路計算要求（PCReq）とパス計算返信（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を指示します。
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を防止原XROの要素のセットを示すNO-PATHオブジェクト（経路計算失敗を報告すなわち1）を運ぶ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].
PCEは、予約プロトコル（RSVP）-TE [RFC4874]をリソースへの拡張を使用してLSPセットアップ時にシグナリングする除外のセットを提供することを望む場合XROはまた、成功した経路計算用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（フェイル - 1ビット）：セットは、要求PCCが故障している既存のTE LSPのための新しい経路の計算を必要とします。 Fビットが設定されている場合、既存のTE LSPの経路は、[RFC5440]で定義されたレコードルートオブジェクト（RRO）によって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サブオブジェクトは、明示的にSRLGを識別またはサブオブジェクトによって識別されたリソースまたはリソースに関連SRLGsの全てを示しています。同定されたもので、任意の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のプレフィックスサブオブジェクト
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プレフィックスのサブオブジェクト
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サブオブジェクト
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].
[RFC3477]で定義されるようにTEルータのID及びインタフェースIDフィールドがあります。
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オクテット自律システム（AS）番号のためのサポートが提供されないことに留意されたいです。 AS番号4オクテットは、より一般的になるように、両方のPCEPとRSVP-TEは、このサポートを追加するための一貫した方法で更新される、と予想されます。
SRLG Subobject
SRLGサブオブジェクト
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（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.
PCCは、それを計算するために要求された経路から除外するPCEを希望するすべてのリソースを符号化するXROを構築します。各除外するため、PCCは、PCEがリソースを排除する必要があることを示すためにXビットをクリアし、またはPCCは、単にリソースが除外されることを望むことを示すためにXビットをセットします。各除外について、PCCはまた、PCEが除外サブオブジェクトの内容をどのように解釈すべきかを示すために、属性フィールドを設定します。
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が見つかった場合、それは、メッセージの最初のいずれかを使用する必要があり、後続のインスタンスを無視しなければなりません。
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を処理できない場合は、エラー・タイプ「サポートされていませんオブジェクト」とPCErrメッセージを返して、[RFC5440]で説明され、関連する手順に従わなければなりません。
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信号SHOULD川下の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.
明示的経路除外は、または明示的に含めるルートオブジェクト（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サブオブジェクトは、この文書によるXROに含めるためか、将来の文書で定義されたサブオブジェクトのいずれかを運ぶことができます。除外の範囲は、IROの前の以降の要素の間の単一のホップに限定される以外はサブオブジェクトは、EXRSに含まれている場合XROサブオブジェクトのフィールドの意味は変わりません。
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つまたは複数のEXRSs含めることによって、明示的な除外を指定するかもしれません。
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はまた、IROがすぐに認識されていないEXRS後に終了すべき場合に示すためPCErrに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でEXRSをサポートしていPCEがIROを解析し、それをサポートしたり、認識しないというサブオブジェクトが含まれているEXRSに遭遇した場合、それは、サブオブジェクトにおけるX-ビットの設定に従って行動しなければなりません。 X-ビットがクリアされている場合、PCE（セクション4を参照）エラー型「認識できないEXRSサブオブジェクト」とPCErrで応答し、EXRSサブオブジェクトタイプコードに誤り数値を設定しなければなりません。 X-ビットがセットされていれば、PCEは既に述べたようPCErrで応答することができるか、EXRSのサブオブジェクトを無視する可能性があります。この選択は、ローカルの政策決定です。
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ビットが設定されている場合、構築することができない場合を除き、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]で指定されるようEXRSを使用して、特定のルートの除外を含むかもしれません。
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がNO-PATHオブジェクトに返された場合、PCEは、[RFC5440]に記載されるように適合することができなかったホップを報告するIROを含むことができ、そのIROはEXRSsを含むかもしれません。
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バックアップ（セカンダリ）パスを見つけるために使用されてもよいです。シーケンシャル経路計算手法は、作業（一次）パス経路は、第1および現用パスからのノード/リンク/ 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.
ドメイン間の計算（例えば、ドメインが異なるサービスプロバイダによって投与される場合）のいくつかのケースでは、機密性が保たれなければなりません。プライマリパス計算のために、明示的に計算された経路を発現するのではなく、機密性を維持するために、パスキーサブオブジェクト（のPKS）[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によって表される経路の多様性を要求する必要があるかもしれません。これは、PKSはPCReqメッセージにXROのサブオブジェクトとして存在してもよいことを意味します。
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.
[RFC5520]で定義されるようにフォーマットおよびPKSの定義がXROサブオブジェクトとして表示されるLビットの定義を除いて、です。 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のサブオブジェクトが含まれている場合、これらはまた、PCEは、多様性を確保できるようにするためにXROに含まれています。
A set of PCEs for backup path computation may be the same as ones for working path computation, or they may be different.
予備パス計算のためのPCEのセットは、経路計算を操作するためのものと同じであってもよく、またはそれらは異なっていてもよいです。
- 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が両方のパス計算のために使用される場合には、処理は以下の通りです。それはそれ自身のドメイン内の仮想パスツリー（VPT）を作成するとき、それはXROを処理するように予備パス計算のためBRPCのプロセスの間、PCEは、PKSを発生する可能性があります。 PCEは、それ自体を認識し、PKSからPCE-IDを取得し、それがVPTを作成するためにローカル計算に使用XROサブオブジェクトのセットにPKSを変換します。このようにして作成され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.
予備パス計算のためのPCEのセットは、経路計算を操作するため使用されるものと異なっている場合には、処理は以下の通りです。 PCEは、それが自身のドメイン内の仮想パスツリーを作成しているXROにおけるPKSに遭遇した場合、PCEは、PKSからPCE-IDを取得し、PKSを拡大する同定PCEにPCReqメッセージを送信します。 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]
32ビットのPCEのIDとサブオブジェクトタイプ参照1 IPv4プレフィクス[RFC3209] 2 IPv6プレフィックス[RFC3209] 4アンナンバードインターフェイスID [RFC3477] 32自律システム番号[RFC3209] 34 SRLG [RFC4874] 64パスキー[RFC5520] 65 Path- 128ビットのPCE IDをキー[RFC5520]
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO).
「PCEPパラメータ」レジストリを含めるルートオブジェクト（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明示的な除外ルートサブオブジェクト（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サブオブジェクト[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）のFlagsフィールドで搬送されるビットのための「PCEPパラメータ」の副登録を作成しました。副登録は「XROフラグ・フィールド」と呼ばれています。
New bits may be allocated only by an IETF Consensus action.
新しいビットは、IETF Consensus動作によって割り当てられてもよいです。
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-ビット失敗[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によって計算されたパスの細かい、より具体的な制御を可能にします。それは、攻撃者は、PCEが計算するか、経路計算を不可能にする経路上に制御を発揮することを可能にするため、このような制御は、PCEPメッセージは、傍受、変更、または偽装された場合にリスクを増加させます。したがって、[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（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。、編、およびJL。ル・ルー、エド。、 "パス計算要素（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。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[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]ブラッドフォード、R.、エド。、Vasseur、JP。、およびA.ファレル、「パス・キー・ベースのメカニズムを使用したドメイン間の経路計算で保存トポロジ機密性」、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]コウシク、A. S. K.、およびE.ステファン、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2008年11月の作業。
[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]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（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]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張をリソースへの予約プロトコル - トラフィックエンジニアリング（RSVP-TE）"、RFC 4874、2007年4月。
[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]武田、T.、エド。、ファレル、A.編、池尻、Y.、およびJP。 Vasseur、RFC 5298、2008年8月 "ドメイン間ラベルスイッチパス（LSP）の回復の分析"。
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.
著者は、サブオブジェクトの形式上の貴重なコメントをファビアンVerhaegheに感謝したいと思います。 IESGレビュー中のコメントのためのマグヌスウェスター、ダンRomascanu、ティムポーク、そしてデイブ・ワードに感謝します。
Authors' Addresses
著者のアドレス
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
えいじ おき うにゔぇｒしｔｙ おｆ えぇｃｔろーこっむにかちおんｓ １ー５ー１ ちょふがおか ちょふ、 ときょ １８２ー８５８５ じゃぱん
EMail: oki@ice.uec.ac.jp
メールアドレス：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
とものり たけだ んっｔ ３ー９ー１１ みどりーちょ、 むさしのーし、 ときょ １８０ー８５８５、 じゃぱん えまいｌ： たけだ。とものり＠ぁｂ。んっｔ。こ。ｊｐ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk