Network Working Group JP. Vasseur, Ed.
Request for Comments: 5441 Cisco Systems, Inc
Category: Standards Track R. Zhang
BT Infonet
N. Bitar
Verizon
JL. Le Roux
France Telecom
April 2009
A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths
最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました
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 ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers.
最短制約トラフィックエンジニアリングラベルを計算する能力は、マルチプロトコルラベルスイッチング（MPLS）及び一般化MPLS（GMPLS）複数のドメイン間のネットワークが重要な要件として同定されているのパス（TE LSPを）スイッチ。この文脈において、ドメインは、IGP領域または自律システムのようなアドレス管理や経路計算責任の共通球体内のネットワーク要素の集合です。この文書は、後方再帰経路計算技術を使用して、ドメインの所定のシーケンスを横切ってそのようなドメイン間の最短制約経路を計算するために、複数のパス計算要素（のPCE）の使用に依存する手順を特定します。この手法は、ドメインが異なるサービスプロバイダによって管理されているとき、時々必要とするドメイン、全体で機密性を保持します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 6
4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6
5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8
6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage in Conjunction with Per-Domain Path Computation . . . . 10
9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 10
10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Diverse End-to-End Path Computation . . . . . . . . . . . 11
10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12
11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
14.2. Information and Data Models . . . . . . . . . . . . . . . 13
14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13
14.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 14
14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14
14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15.1. New Flag of the RP Object . . . . . . . . . . . . . . . . 14
15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . . 16
The requirements for inter-area and inter-AS MPLS Traffic Engineering (TE) have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively.
エリア間および相互AS MPLSトラフィックエンジニアリング（TE）のための要件は、トラフィックエンジニアリングワーキンググループ（WG TE）によって開発され、それぞれ、[RFC4105]と[RFC4216]に記載されています。
The framework for inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) has been provided in [RFC4726].
ドメイン間マルチプロトコルラベルのためのフレームワーク・スイッチング（MPLS）トラフィックエンジニアリング（TE）は、[RFC4726]で提供されています。
[RFC5152] defines a technique for establishing an inter-domain Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the path is computed during the signaling process on a per-domain basis by the entry boundary node of each domain (each node responsible for triggering the computation of a section of an inter-domain TE LSP path is always along the path of such TE LSP). This path computation technique fulfills some of the requirements stated in [RFC4105] and [RFC4216] but not all of them. In particular, it cannot guarantee to find an optimal (shortest) inter-domain constrained path. Furthermore, it cannot be efficiently used to compute a set of inter-domain diversely routed TE LSPs.
[RFC5152]は、ドメイン間を確立するための手法を定義する汎用MPLS（GMPLS）経路は、各ドメインの入口境界ノードによってドメインごとにシグナリング処理中に計算されるTEラベルスイッチパス（LSP）（各ノードドメイン間のTE LSPパスのセクションの計算をトリガする責任）は、TE LSPの経路に沿って常にあります。この経路計算手法は、[RFC4105]と[RFC4216]ではなく、それらのすべてに記載された要件の一部を満たしています。特に、最適（最も短い）ドメイン間制約パスを見つけることが保証できません。さらに、それを効率的に多様TE LSPのルーティングドメイン間のセットを計算するために使用することはできません。
The Path Computation Element (PCE) architecture is defined in [RFC4655]. The aim of this document is to describe a PCE-based path computation procedure to compute optimal inter-domain constrained (G)MPLS TE LSPs.
経路計算エレメント（PCE）アーキテクチャは、[RFC4655]で定義されています。この文書の目的は、最適なドメイン間制約（G）MPLS TE LSPを計算するPCEベースの経路計算手順を記述することです。
Qualifying a path as optimal requires some clarification. Indeed, a globally optimal TE LSP placement usually refers to a set of TE LSPs whose placements optimize the network resources with regards to a specified objective function (e.g., a placement that reduces the maximum or average network load while satisfying the TE LSP constraints). In this document, an optimal inter-domain constrained TE LSP is defined as the shortest path satisfying the set of required constraints that would be obtained in the absence of multiple domains (in other words, in a totally flat IGP network between the source and destination of the TE LSP). Note that this requires the use of consistent metric schemes in each domain (see Section 13).
最適なように、パスの修飾は、いくつかの説明が必要です。実際に、全体的に最適なTE LSPの配置は、通常のプレースメント指定目的関数（例えば、TE LSPの制約を満たしながら、最大又は平均ネットワーク負荷を低減する配置）に関してネットワーク資源を最適化するTE LSPのセットを指します。この文書では、最適インタードメインは、TE LSPは、ソースと宛先の間で完全にフラットIGPネットワークでは、他の言葉で（複数のドメインの不在下で得られるであろう必要な制約条件のセットを満たす最短経路として定義される制約しましたTE LSPの）。これは、各ドメインの一貫したメトリック方式の使用を必要とすることに注意してください（第13章を参照のこと）。
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]に記載されているように解釈されます。
ABR: Area Border Routers. Routers used to connect two IGP areas (areas in OSPF or levels in IS-IS).
ABR：エリア境界ルータ。ルータは、二つのIGP領域（IS-ISでOSPFまたはレベルでの領域）を接続するために使用されます。
ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links.
ASBR：自律システム境界ルータ。ルータは、一つ以上のAS間リンクを介して一緒に同じまたは異なるサービスプロバイダののASを接続するために使用されます。
Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering.
境界ノード（BN）：境界ノードは、エリア間トラフィックエンジニアリングの文脈におけるABRまたはインターASトラフィックエンジニアリングの文脈におけるASBRのいずれかです。
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains.
ドメインのエントリBN（N）：BNは、ドメインの決定された順序に沿って（N）ドメインへのドメイン（N-1）を接続します。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains.
ドメインの出口BN（N）：ドメインの決定された順序に沿ってドメイン（N + 1）に接続BNドメイン（N）。
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
インターエリアTE LSP：TE LSP IGPエリア境界を横切ります。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
インターAS TE LSP：TE LSP AS境界を越えます。
LSP: Label Switched Path.
LSP：ラベルスイッチパス。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。経路計算要素によって実行される経路計算を要求する任意のクライアントアプリケーション。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCE(i) is a PCE with the scope of domain(i).
PCE（i）は、ドメインの範囲（I）とのPCEです。
TED: Traffic Engineering Database.
TED：トラフィックエンジニアリングデータベース。
VSPT: Virtual Shortest Path Tree.
VSPT：仮想最短パスツリー。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
、連続したステッチ、およびネストされたTE LSPの概念は、[RFC4726]で定義され、ここでは繰り返しません。
In the rest of this document, we make the following set of assumptions common to inter-area and inter-AS MPLS TE:
このドキュメントの残りの部分では、我々は、エリア間および相互AS MPLS TEに共通の仮定の次のセットを行います。
o Each IGP area or Autonomous System (AS) is assumed to be Traffic Engineering enabled.
O各IGP領域や自律システム（AS）は、トラフィックエンジニアリングが有効であると仮定されます。
o No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality.
（[RFC4105]及び[RFC4216]あたりの義務として）O無トポロジーまたはリソース情報は、IGP / BGPの拡張性と機密性を維持することが重要であり、ドメイン間に分布されていません。
o While certain constraints like bandwidth can be used across different domains, other TE constraints (such as resource affinity, color, metric, etc. [RFC2702]) could be translated at domain boundaries. If required, it is assumed that, at the domain boundary nodes, there will exist some sort of local mapping based on policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process.
帯域幅のような特定の制約が異なるドメイン間で使用することができるがO、他のTE制約（等リソースの親和性、色、メトリックとしては、[RFC2702]）ドメイン境界で換算することができます。必要な場合は、ドメイン境界ノードにおいて、インターPCEの通信処理中にドメインの境界を越えて、このような制約を翻訳するためには、政策合意に基づくローカルマッピングのいくつかの並べ替えが存在するだろう、と仮定されます。
o Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASes made of a single IGP area, or any combination of the above. For the sake of simplicity, each AS will be considered to be made of a single area in this document. The case of an inter-AS TE LSP spanning multiple ASes, where some of those ASes are themselves made of multiple IGP areas, can be easily derived from this case by applying the BRPC procedure described in this document, recursively.
O各ASは、複数のIGP領域で構成することができます。複数のIGP領域、単一のIGP領域、または上記の任意の組み合わせからなる複数のASからなるこのドキュメントに記載さ経路計算手順は、単一のケースにも適用されます。簡単にするために、各ASは、この文書に記載されている単一の領域で構成されるように考慮されます。それらのASのいくつかは、それ自体が複数のIGP領域で形成されている複数のASにまたがるインターAS TE LSPの場合は、容易に再帰的に、この文書に記載されBRPC手順を適用することによって、このような場合に由来することができます。
o The domain path (the set of domains traversed to reach the destination domain) is either administratively predetermined or discovered by some means that is outside of the scope of this document.
ドメインパスO（ドメインのセットが宛先ドメインに到達するために横断）管理この文書の範囲外であるいくつかの手段によって、所定の又は発見されますか。
The BRPC procedure is a multiple-PCE path computation technique as described in [RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR), but this is not mandated by the BRPC procedure.
BRPC手順は[RFC4655]に記載されているように、複数のPCE経路計算手法です。可能なモデルは、境界ノード（例えば、ABRまたはASBR）上のPCEの機能をホストから成り、これは、BRPC手順によって義務付けられていません。
The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain, until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that the PCE sends to the PCC.
BRPC手順は、協力のPCE間の通信に依存しています。具体的には、PCCは、そのドメインPCEにPCReqを送信します。 LSPの宛先を含むドメインを担うPCEに達するまで要求は、ドメインごとのドメインのPCE間で転送されます。宛先ドメイン内のPCEは、宛先への潜在的なパスの木（仮想最短経路ツリー - VSPT）を作成し、PCRepで前PCEにこのバックを渡します。順番に各PCEはVSPTに追加し、ソースドメイン内のPCEは、PCEがPCCに送信するエンド・ツー・エンドのパスを選択するVSPTを使用するまで戻ってそれを渡します。
The BRPC procedure does not make any assumption with regards to the nature of the inter-domain TE LSP that could be contiguous, nested, or stitched.
BRPC手順は、連続したネストされた、またはステッチすることができ、ドメイン間TE LSPの性質に関していかなる仮定を行いません。
Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (e.g., it can be any variant of Constrained Shortest Path First (CSPF) or an algorithm based on linear programming to solve multi-constraint optimization problems).
また、何の仮定が（例えば、それが制約最短パスファースト（CSPF）またはマルチ制約最適化問題を解決するために、線形計画に基づくアルゴリズムの任意の変異体であってもよい）PCEによって使用中の実際の経路計算アルゴリズムになされていません。
The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed is either administratively predetermined or discovered by some means that is outside of the scope of this document. The PCC MAY indicate the sequence of domains to be traversed using the Include Route Object (IRO) defined in [RFC5440] so that it is available to all PCEs. Note also that a sequence of PCEs MAY be enforced by policy on the PCC, and this constraint can be carried in the PCEP path computation request (as defined in [PCE-MONITOR]).
PCEベースBRPC手順は、最適な制約ドメイン間TE LSPの計算に適用されます。ドメインの配列は、行政、この文書の範囲外であり、何らかの手段によって、所定の又は発見されるか、横断します。 PCCは、すべてのPCEに利用可能であるように[RFC5440]で定義された含めるルートオブジェクト（IRO）を使用して横断するドメインの配列を示すことができます。音符ものPCEの配列は、PCC上のポリシーによって適用されてもよく、この制約は、（[PCE-MONITOR]で定義されるように）PCEP経路計算要求に行うことができること。
The BRPC procedure guarantees to compute the optimal path across a specific sequence of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get the optimal constrained path between the source and the destination of the TE LSP. The BRPC procedure can also be used across a subset of all domain sequences, and the best path among these sequences can then be selected.
BRPC手順は、（追加の制約を構成する）横断ドメインの特定の配列を横切って最適経路を計算することを保証します。噛合ドメインの任意のセットの場合、BRPC手順は、ソース及びTE LSPの宛先との間の最適な制約パスを取得するために設定された各ドメイン全体最適経路を計算するために使用することができます。 BRPC手順は、すべてのドメイン配列のサブセットにまたがって使用することができ、そしてこれらの配列の間で最良のパスは、選択することができます。
Definition of VSPT(i)
VSPTの定義（I）
In each domain i:
各ドメインにはI：
o There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN-en(k,i) is the kth entry BN of domain(i).
O X-EN（I）エントリのBNの集合があり注意BN-EN（K、I）ここで、BN-EN（k、i）は領域（i）のk番目のエントリBNです。
o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN-ex(k,i) is the kth exit BN of domain(i).
O X-EXのセットがあり（I）の出口のBNはBN-EXを指摘（K、I）BN-EX（K、i）は領域（i）のk番目の出口BNです。
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1):
VSPT（I）：PCE（I-1）〜MP2P PCEによって返される（マルチポイントツーポイント）ツリー（I）：
Root (TE LSP destination)
/ | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
where [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)]
[X-EN（I）]はiとj <= [X-EN（I）]ドメイン内のBNエントリの数であります
Figure 1: MP2P Tree
図1：MP2Pツリー
Each link of tree VSPT(i) represents the shortest constrained path between BN-en(j,i) and the TE LSP destination that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). These are path segments to reach the TE LSP destination from BN-en(j,i).
ツリーVSPTの各リンク（i）は、BN-EN（j、i）とTE LSP（帯域幅、親和性、等）のために必要な制約条件のセットを満たすTE LSPの宛先との間の最短経路制約を表します。これらは、BN-EN（J、I）からTE LSPの宛先に到達するための経路セグメントです。
Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). In other words, the set BN-en(k,i) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). Furthermore, some BNs may be excluded according to policy constraints (either due to local policy or policies signaled in the path computation request).
ドメイン（I-1）からの接続を提供するPCE（I）のみドメインのエントリのBN（i）が考慮、すなわち、唯一のBNに留意されたいです。言い換えれば、セットは、BN-EN（kは、i）は、のみ（I-1）ドメイン（I）のドメインからの接続を提供し、これらのBNで形成されています。さらに、いくつかのBNは、（ローカルポリシーまたはポリシーに起因は、経路計算要求でシグナリングいずれか）ポリシー制約に従って除外されてもよいです。
Step 1: First, the PCC needs to determine the PCE capable of serving its path computation request (this can be done with local configuration or via IGP discovery (see [RFC5088] and [RFC5089])). The path computation request is then relayed until reaching a PCE(n) such that the TE LSP destination resides in the domain(n). At each step of the process, the next PCE can either be statically configured or dynamically discovered via IGP/BGP extensions. If no next PCE can be found or the next-hop PCE of choice is unavailable, the procedure stops and a path computation error is returned (see Section 9). If PCE(i-1) discovers multiple PCEs for the adjacent domain(i), PCE(i) may select a subset of these PCEs based on some local policies or heuristics. The PCE selection process is outside of the scope of this document.
ステップ1：まず、PCCは、経路計算要求（これはローカル構成またはIGP発見を介して行うことができる（[RFC5088]及び[RFC5089]）を参照）サービング可能なPCEを決定する必要があります。経路計算要求は、その後、TE LSP先ドメイン（N）に存在するようなPCE（N）に到達するまで中継されます。プロセスの各ステップで、次のPCEは、静的に構成されるか、または動的にIGP / BGP拡張を介して発見しました。何次のPCEが見つからないか、選択の次ホップPCEが使用できない場合、手順は停止し、経路計算誤差は（セクション9を参照）が返されます。 PCE（I-1）は、隣接するドメイン（I）のために複数のPCEを発見した場合、PCE（i）は、いくつかのローカルポリシーまたは経験則に基づいて、これらのPCEのサブセットを選択することができます。 PCE選択プロセスは、この文書の範囲外です。
Step 2: PCE(n) computes VSPT(n), the tree made of the list of shortest constrained paths between every BN-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g., CSPF) and returns the computed VSPT(n) to PCE(n-1).
ステップ2：PCE（n）はVSPT（n）は、すべてのBN-EN（J、N）との間の最短拘束経路のリストからなるツリーと（例えば、CSPF）を適切な経路計算アルゴリズムを使用して、TE LSP先を計算し計算VSPT（n）は、PCE（N-1）に戻ります。
Step i: For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination. It does this by considering its own TED and the information in VSPT(i+1).
ステップI：I = N-1の2：PCE（i）は、VSPT（I）、各BN-ENの間の最短経路拘束からなるツリー（j、i）とTE LSP先を計算します。これは、独自のTEDとVSPT（I + 1）内の情報を考慮してこれを行います。
In the case of inter-AS TE LSP computation, this also requires adding the inter-AS TE links that connect the domain(i) to the domain(i+1).
インターAS TE LSP計算の場合、これは、ドメイン（I + 1）へのドメイン（i）を接続する相互AS TEリンクを追加する必要があります。
Step n: Finally, PCE(1) computes the end-to-end shortest constrained path from the source to the destination and returns the corresponding path to the requesting PCC in the form of a PCRep message as defined in [RFC5440].
ステップN：最後に、PCE（1）は、ソースから宛先へのエンドツーエンドの最短制約経路を計算し、[RFC5440]で定義されるようにPCRepメッセージの形で要求PCCに対応するパスを返します。
Each branch of the VSPT tree (path) may be returned in the form of an explicit path (in which case, all the hops along the path segment are listed) or a loose path (in which case, only the BN is specified) so as to preserve confidentiality along with the respective cost. In the latter case, various techniques can be used in order to retrieve the computed explicit paths on a per-domain basis during the signaling process, thanks to the use of path keys as described in [PATH-KEY].
VSPTツリー（経路）の各ブランチは、明示的なパス（この場合には、経路セグメントに沿ったすべてのホップが記載されている）、または緩いパスの形式で返されてもよい（この場合、唯一のBNが指定されている）のでそれぞれのコストと一緒に機密性を維持するように。後者の場合には、様々な技術が[PATH-KEY]に記載されているように、シグナリング処理中にパスキーの使用のおかげで、ドメインごとに計算された明示的なパスを取得するために使用することができます。
A PCE that can compute the requested path for more than one consecutive domain on the path SHOULD perform this computation for all such domains before passing the PCRep to the previous PCE in the sequence.
経路上の複数の連続したドメインの要求されたパスを計算することができるPCEは、シーケンス内の前のPCEにPCRepを渡す前に、すべてのそのようなドメインのためのこの計算を実行する必要があります。
BRPC guarantees to find the optimal (shortest) constrained inter-domain TE LSP according to a set of defined domains to be traversed. Note that other variants of the BRPC procedure relying on the same principles are also possible.
BRPC保証を横断するように定義ドメインのセットに応じて最適な（最短）制約ドメイン間TE LSPを検索します。同じ原理に頼るBRPC手順の他の変形も可能であることに注意してください。
Note also that in case of Equal Cost Multi-Path (ECMP) paths, more than one path could be returned to the requesting PCC.
メモはまた、等価コストマルチパス（ECMP）経路の場合には、複数のパスは、要求PCCに戻すことができます。
The BRPC procedure requires the specification of a new flag of the RP object carried within the PCReq message (defined in [RFC5440]) to specify that the shortest paths satisfying the constraints from the destination to the set of entry boundary nodes are requested (such a set of paths forms the downstream VSPT as specified in Section 4.2).
BRPC手順は、（入口境界ノードのセットに宛先からの制約を満たす最短経路が要求されることを指定する（[RFC5440]で定義される）PCReqメッセージ内で運ばRPオブジェクトの新しいフラグの指定を必要としますセクション4.2で指定されたパスのセット）が下流VSPTを形成します。
The following new flag of the RP object is defined:
RPオブジェクトの次の新しいフラグが定義されています。
VSPT Flag
VSPT旗
Bit Number Name Flag 25 VSPT
ビット番号名前旗25 VSPT
When set, the VSPT Flag indicates that the PCC requests the computation of an inter-domain TE LSP using the BRPC procedure defined in this document.
設定すると、VSPTフラグPCCは、この文書で定義されたBRPC手順を使用してドメイン間のTE LSPの計算を要求することを示しています。
Because path segments computed by a downstream PCE in the context of the BRPC procedure MUST be provided along with their respective path costs, the C flag of the METRIC object carried within the PCReq message MUST be set. It is the choice of the requester to appropriately set the O bit of the RP object.
BRPC手順の文脈における下流PCEによって計算された経路セグメントがそれぞれの経路コストと一緒に提供されなければならないので、PCReqメッセージの中で運ばMETRICオブジェクトのCフラグがセットされなければなりません。これは、適切RPオブジェクトのOビットをセットする依頼者の選択です。
The VSPT is returned within a PCRep message. The encoding consists of a non-ordered list of Explicit Route Objects (EROs) where each ERO represents a path segment from a BN to the destination specified in the END-POINT object of the corresponding PCReq message.
VSPTはPCRepメッセージの中に返されます。符号化は、各EROが対応PCReqメッセージのエンドポイントオブジェクトで指定された宛先へのBNからのパスセグメントを表す明示的経路オブジェクトの非順序付きリスト（エロス）から成ります。
Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+
| |
ABR2-----D
| |
ABR3--C--+
Figure 2: An Example of VSPT Encoding Using a Set of EROs
図2：エロスのセットを使用してVSPTエンコーディングの例
In the simple example shown in Figure 2, if we make the assumption that a constrained path exists between each ABR and the destination D, the VSPT computed by a PCE serving area 2 consists of the following non-ordered set of EROs:
我々は制約パスが各ABRと宛先Dの間に存在するという仮定を行った場合、図2に示す簡単な例では、PCEサービスエリア2によって計算VSPTはエロスの以下の非順序集合で構成されています。
o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP address)-D(TE Router ID)
O ERO1：ABR1（TEルータID）-A（インタフェースIPアドレス）-B（インタフェースIPアドレス）-D（TEルータID）
o ERO2: ABR2(TE Router ID)-D(TE Router ID)
O ERO2：ABR2（TEルータID）-D（TEルータID）
o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
O ERO3：ABR3（TEルータID）-C（インターフェイスのIPアドレス）-D（TEルータID）
The PCReq message, PCRep message, PCEP END-POINT object, and ERO object are defined in [RFC5440].
PCReqメッセージ、PCRepメッセージ、PCEPエンドポイントオブジェクト、およびEROオブジェクトは[RFC5440]で定義されています。
In the case of inter-AS TE LSP path computation, the BRPC procedure requires the knowledge of the traffic engineering attributes of the inter-AS TE links. The process by which the PCE acquires this information is out of the scope of the BRPC procedure, which is compliant with the PCE architecture defined in [RFC4655].
相互AS TE LSPの経路計算の場合には、BRPC手順は相互AS TEリンクのトラフィックエンジニアリング属性の知識が必要です。 PCEは、この情報を取得するプロセスは、[RFC4655]で定義されたPCEアーキテクチャに準拠しBRPC手順の範囲外です。
That said, a straightforward solution consists of allowing the ASBRs to flood the TE information related to the inter-ASBR links although no IGP TE is enabled over those links (there is no IGP adjacency over the inter-ASBR links). This allows the PCE of a domain to get entire TE visibility up to the set of entry ASBRs in the downstream domain (see the IGP extensions defined in [RFC5316] and [RFC5392]).
前記、簡単な解決策はのASBRはないIGP TEはこれらのリンク上イネーブルされていないものの間ASBRリンクに関連するTE情報をフラッディングさせることから成る（インターASBRリンク上全くIGP隣接関係がありません）。これは、ドメインのPCEは、（[RFC5316]及び[RFC5392]で定義されたIGP拡張を参照）下流のドメインのエントリのASBRのセットに全体TE可視性を得ることを可能にします。
The BRPC procedure may be used to compute path segments in conjunction with other path computation techniques (such as the per-domain path computation technique defined in [RFC5152]) to compute the end-to-end path. In this case, end-to-end path optimality can no longer be guaranteed.
BRPC手順は、エンドツーエンドのパスを計算するために（例えば、[RFC5152]で定義された単位のドメイン経路計算手法のような）他の経路計算技術と組み合わせて、パスセグメントを計算するために使用されてもよいです。この場合、エンド・ツー・エンドのパスの最適性はもはや保証できません。
If the BRPC procedure cannot be completed because a PCE along the domain does not recognize the procedure (VSPT flag of the RP object), as stated in [RFC5440], the PCE sends a PCErr message to the upstream PCE with an Error-Type=4 (Not supported object), Error-value=4 (Unsupported parameter). The PCE may include the parent object (RP object) up to and including (but no further than) the unknown or unsupported parameter. In this case where the unknown or unsupported parameter is a bit flag (VSPT flag), the included RP object should contain the whole bit flag field with all bits after the parameter at issue set to zero. The corresponding path computation request is then cancelled by the PCE without further notification.
[RFC5440]に記載のドメインに沿ったPCEは、（RPオブジェクトのVSPTフラグ）手順を認識しないので、BRPC手順を完了できない場合、PCEは=エラータイプ上流PCEにPCErrメッセージを送信します。 4（サポートされないオブジェクト）、エラー値= 4（サポートされていないパラメータ）。 PCEはに、未知またはサポートされていないパラメータを含めない（しかし、何よりもさらに）まで親オブジェクト（RPオブジェクト）を含んでもよいです。未知またはサポートされていないパラメータは、ビットフラグ（VSPTフラグ）であり、この場合には、含まRPオブジェクトはゼロに設定され、問題のパラメータの後に全てのビットで全ビットのフラグフィールドを含むべきです。対応する経路計算要求は、さらに通知することなく、PCEによって相殺されます。
If the BRPC procedure cannot be completed because a PCE along the domain path recognizes but does not support the procedure, it MUST return a PCErr message to the upstream PCE with an Error-Type "BRPC procedure completion failure".
ドメインパスに沿ってPCEは認識するがプロシージャをサポートしていないためBRPC手続きが完了できない場合は、エラー・タイプ「BRPC手続き完了の失敗」と上流PCEにPCErrメッセージを返さなければなりません。
The PCErr message MUST be relayed to the requesting PCC.
PCErrメッセージは、要求PCCに中継されなければなりません。
PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA.
PCEP-ERRORオブジェクトは、PCEPプロトコルエラーを報告するために使用され、エラーの種類およびエラーのタイプに関する追加情報を提供するエラー値を指定するエラータイプによって特徴付けられます。エラー・タイプとエラー値の両方がIANAによって管理されています。
A new Error-Type is defined that relates to the BRPC procedure.
新しいError-TypeがBRPC手続きに関し、その定義されています。
Error-Type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path
エラー・タイプ意味13 BRPC手順完了失敗エラー値1：ドメイン経路に沿って一の以上のPCEによってサポートされていないBRPC手順
As discussed in Section 3, the requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. Among the set of requirements, both documents indicate the need for some solution that provides the ability to compute an optimal (shortest) constrained inter-domain TE LSP and to compute a set of diverse inter-domain TE LSPs.
第3節で述べたように、エリア間および相互AS MPLSトラフィックエンジニアリングのための要件は、トラフィックエンジニアリングワーキンググループ（WG TE）によって開発され、それぞれ、[RFC4105]と[RFC4216]に記載されています。要件のセットのうち、両方の文書は、最適（最も短い）制約ドメイン間TE LSPを計算するために、多様なドメイン間TE LSPのセットを計算する能力を提供するいくつかの解決策の必要性を示します。
PCEP (see [RFC5440]) allows a PCC to request the computation of a set of diverse TE LSPs by setting the SVEC object's flags L, N, or S to request link, node, or SRLG (Shared Risk Link Group) diversity, respectively. Such requests MUST be taken into account by each PCE along the path computation chain during the VSPT computation. In the context of the BRPC procedure, a set of diversely routed TE LSPs between two LSRs can be computed since the path segments of the VSPT are simultaneously computed by a given PCE. The BRPC procedure allows for the computation of diverse paths under various objective functions (such as minimizing the sum of the costs of the N diverse paths, etc.).
それぞれPCEP（[RFC5440]を参照）PCCは、リンク、ノード、またはSRLG（共有リスクリンクグループ）多様性を要求するSVECオブジェクトのフラグL、N、またはSを設定することにより、多様なTEのLSPのセットの計算を要求することができ、 。そのような要求は、VSPT計算時経路計算チェーンに沿った各PCEによって考慮されなければなりません。 VSPTの経路セグメントが同時に与えられたPCEによって計算されるので、BRPC手順の文脈では、二つのLSRの間で多様にルーティングされたTE LSPのセットを計算することができます。 BRPC手順は、（N、多様な経路、等のコストの和を最小化するような）様々な目的関数の下で多様な経路の計算を可能にします。
By contrast, with a 2-step approach consisting of computing the first path followed by computing the second path after having removed the set of network elements traversed by the first path (if that does not violate confidentiality preservation), one cannot guarantee that a solution will be found even if such solution exists. Furthermore, even if a solution is found, it may not be the most optimal one with respect to an objective function such as minimizing the sum of the paths' costs, bounding the path delays of both paths, and so on. Finally, it must be noted that such a 2-step path computation approach is usually less efficient in terms of signaling delays since it requires that two serialized TE LSPs be set up.
対照的に、（すなわち、機密保全に違反していない場合）最初のパスによって横断ネットワーク要素のセットを除去した後、第2の経路を計算することによって、続いて第一の経路を計算からなる2段階のアプローチを用いて、一つはその解決策を保証することはできませんそのような解決策が存在していても検出されます。さらに、溶液が発見された場合でも、そのようなように、パスコストの和を最小両方のパスのパス遅延を境界、および目的関数に対して最も最適なものではないかもしれません。最後に、2つのシリアル化されたTEのLSPが設定されている必要があるため、このような2段階の経路計算手法は、シグナリング遅延の点で通常あまり効率的であることに留意しなければなりません。
BRPC guarantees that the optimal (shortest) constrained inter-domain path will always be found, subject to policy constraints. Both in the case where local path computation techniques are used (such as to build stitched or nested TE LSPs), and in the case where a domain has more than one BN-en or more than one BN-ex, it is only possible to guarantee optimality after some network change within the domain by completely re-executing the BRPC procedure.
最適な（最短）は、ドメイン間のパスを制約することをBRPC保証は常に、ポリシーの制約を受ける見つかります。局所経路計算技術は、（例えば、縫合またはネストされたTE LSPを構築するなど）を使用し、ドメインが複数のBN-EN又は複数のBN-EXを有する場合、それはにのみ可能である場合に、両方の完全BRPC手順を再実行することによって、ドメイン内のいくつかのネットワーク変更後の保証最適。
The ability to reoptimize an existing inter-domain TE LSP path has been explicitly listed as a requirement in [RFC4105] and [RFC4216]. In the case of a TE LSP reoptimization request, the reoptimization procedure defined in [RFC5440] applies when the path in use (if available on the head-end) is provided as part of the path computation request so that the PCEs involved in the reoptimization request can avoid double bandwidth accounting.
既存のドメイン間のTE LSPパスを再最適化する能力は、明示的に[RFC4105]及び[RFC4216]に要件として記載されています。 TE LSPの再最適化を要求する場合には、[RFC5440]で定義された再最適化手順は、のPCEは、再最適化に関与するように使用されているパス（ヘッドエンドで利用可能な場合）が経路計算要求の一部として提供される場合に適用されます要求は、二重帯域幅課金を回避することができます。
If a PCE requires to relay a path computation request according to the BRPC procedure defined in this document to a downstream PCE and no such PCE is available, the PCE MUST send a negative path computation reply to the requester using a PCReq message as specified in [RFC5440] that contains a NO-PATH object. In such case, the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440]) with the newly defined bit named "BRPC path computation chain unavailable" set.
PCEは、下流PCEと、そのようなPCEが利用できないこの文書で定義さBRPC手順に従って経路計算リクエストを中継するために必要な場合に指定されるように、PCEはPCReqメッセージを使用して要求者にネガティブパス計算応答を送信しなければなりません[ RFC5440] NO-PATHのオブジェクトが含まれています。このような場合には、NO-PATHオブジェクトは「BRPC経路計算鎖利用不可能」という名前のセット新しく定義されたビットと（[RFC5440]で定義される）NO-PATHベクターTLVを運ばなければなりません。
Bit number Name Flag 28 BRPC path computation chain unavailable
ビット数名フラグ28 BRPCパス計算チェーン使用不能
In the case of inter-area TE, the same IGP/TE metric scheme is usually adopted for all the IGP areas (e.g., based on the link-speed, propagation delay, or some other combination of link attributes). Hence, the proposed set of mechanisms always computes the shortest path across multiple areas that obey the required set of constraints with respect to a specified objective function. Conversely, in the case of inter-AS TE, in order for this path computation to be meaningful, metric normalization between ASes may be required. One solution to avoid IGP metric modification would be for the service providers to agree on a TE metric normalization scheme and use the TE metric for TE LSP path computation (in that case, the use of the TE metric must be requested in the PCEP path computation request) using the METRIC object (defined in [RFC5440]).
相互領域TEの場合には、同じIGP / TEメトリック方式は、通常、すべてのIGP領域（例えば、リンク速度、伝搬遅延、またはリンク属性のいくつかの他の組み合わせに基づいて）のために採用されています。したがって、機構の提案されたセットは、常に指定された目的関数に対する制約の必要なセットに従う複数の領域を横切る最短経路を計算します。逆に、インターAS TEの場合には、意味のあるものにするには、この経路計算用のために、AS間メトリック正規化が必要とされ得ます。サービスプロバイダーはTEメトリック正規化方式に同意し、その場合には（TE LSPの経路計算のためのTEメトリックを使用するためにIGPメトリックの変更を回避する1つの解決策は次のようになり、TEメトリックの使用はPCEPの経路計算に要求する必要があります[RFC5440]で定義されたメトリックオブジェクト（）を使用して要求）。
This section follows the guidance of [PCE-MANAGE].
このセクションでは、[PCE-管理]の指導に従います。
The only configurable item is the support of the BRPC procedure on a PCE. The support of the BRPC procedure by the PCE MAY be controlled by a policy module governing the conditions under which a PCE should participate in the BRPC procedure (origin of the requests, number of requests per second, etc.). If the BRPC is not supported/allowed on a PCE, it MUST send a PCErr message as specified in Section 9.
のみ設定可能な項目は、PCEのBRPC手続きのサポートです。 PCEによってBRPC手順のサポートは、PCEがBRPC手順（要求の起源、等秒あたりの要求の数）に参加すべき条件を支配するポリシーモジュールによって制御することができます。 BRPCがサポートされていない場合は、セクション9で指定されている/ PCE上で許可され、それがPCErrメッセージを送らなければなりません。
A BRPC MIB module will be specified in a separate document.
BRPC MIBモジュールは、別の文書で指定されます。
The BRPC procedure is a multiple-PCE path computation technique and, as such, a set of PCEs are involved in the path computation chain. If the path computation chain is not operational either because at least one PCE does not support the BRPC procedure or because one of the PCEs that must be involved in the path computation chain is not available, procedures are defined to report such failures in Sections 9 and 12, respectively. Furthermore, a built-in diagnostic tool to check the availability and performances of a PCE chain is defined in [PCE-MONITOR].
BRPC手順は、複数のPCE経路計算手法であり、等、のPCEのセットは、経路計算チェーンに関与しています。経路計算チェーンが動作していない場合のいずれかの少なくとも一つのPCEは、BRPC手順をサポートしていないか、経路計算チェーンに関与しなければならないのPCEのいずれかが使用できないため、手順はセクション9にそのような障害を報告するために定義されているためと12、それぞれ。また、内蔵の診断ツールPCE鎖の可用性および性能を確認するため、[PCE-MONITOR]で定義されています。
Verifying the correct operation of BRPC can be performed by monitoring a set of parameters. A BRPC implementation SHOULD provide the following parameters:
BRPCの正しい動作を検証するパラメータのセットを監視することによって行うことができます。 BRPC実装は、次のパラメータを提供する必要があります。
o Number of successful BRPC procedure completions on a per-PCE-peer basis
あたり-PCEピアごとに成功したBRPC手続きの完了のO数
o Number of BRPC procedure completion failures because the VSPT flag was not recognized (on a per-PCE-peer basis)
VSPTフラグが（毎PCEピア単位で）認識されなかったため、BRPC手順の完了の失敗回数O
o Number of BRPC procedure completion failures because the BRPC procedure was not supported (on a per-PCE-peer basis)
BRPC手順は（あたり-PCEピアごとに）サポートされていなかったため、BRPC手順の完了の失敗回数O
The BRPC procedure does not put any new requirements on other protocols. That said, since the BRPC procedure relies on the PCEP protocol, there is a dependency between BRPC and PCEP; consequently, the BRPC procedure inherently makes use of the management functions developed for PCEP.
BRPC手順は、他のプロトコル上の任意の新しい要件を入れていません。すなわち、BRPC手順がPCEPプロトコルに依存しているので、BRPC及びPCEPの間に依存性がある、と述べました。その結果、BRPC手順は、本質的にPCEPために開発管理機能を利用します。
The BRPC procedure does not have any significant impact on network operation: indeed, BRPC is a multiple-PCE path computation scheme as defined in [RFC4655] and does not differ from any other path computation request.
BRPC手順は、ネットワーク運用に重大な影響を有していない。実際、BRPCは[RFC4655]で定義された任意の他の経路計算要求異ならないように、複数のPCE経路計算方式です。
[PCE-MONITOR] specifies a set of mechanisms that can be used to gather PCE state metrics. Because BRPC is a multiple-PCE path computation technique, such mechanisms could be advantageously used in the context of the BRPC procedure to check the liveness of the path computation chain, locate a faulty component, monitor the overall performance, and so on.
[PCE-MONITOR]はPCEの状態メトリックを収集するために使用することができる機構の集合を指定します。 BRPCは、複数のPCE経路計算手法であるため、そのような機構は、有利ように、経路計算チェーンの生存性をチェックし、不良部品を見つけ、全体的なパフォーマンスを監視し、そしてするBRPC手順の文脈で使用することができます。
A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
RPオブジェクトの新しいフラグ（[RFC5440]で指定）は、この文書で定義されています。 IANAは、「パス計算エレメントプロトコル（PCEP）番号」レジストリの「RPオブジェクトフラグ・フィールド」サブレジストリにRPオブジェクトフラグのレジストリを維持します。
IANA has allocated the following value:
IANAは、次の値を割り当てました。
Bit Description Reference
25 VSPT This document
IANA maintains a registry of Error-Types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、PCEPメッセージで使用するためのエラー・タイプとエラー値のレジストリを維持します。これは、「経路計算要素プロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラーの種類と値」サブレジストリとして維持されます。
A new Error-value is defined for the Error-Type "Not supported object" (type 4).
新しいエラー値がエラー型「サポートされていませんオブジェクト」（タイプ4）のために定義されています。
Error-Type Meaning and error values Reference 4 Not supported object
エラー・タイプ意味とエラーの値が4サポートされていないオブジェクトを参照します
Error-value=4: Unsupported parameter This document
エラー値= 4：サポートされていないパラメータこのドキュメント
A new Error-Type is defined in this document as follows:
次のように新しいError-Typeは、この文書で定義されています。
Error-Type Meaning Reference 13 BRPC procedure completion failure This document
このドキュメントエラー-型意味リファレンス13 BRPC手続き完了の失敗
Error-value=1: BRPC procedure not This document
supported by one or more PCEs along
the domain path
A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is specified in this document.
[RFC5440]で定義されたNO-PATHベクターTLV）の新しいフラグは、この文書で指定されています。
IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリの「NO-PATH-VECTOR TLVフラグ・フィールド」サブレジストリにNO-PATH-VECTOR TLVのためのフラグのレジストリを維持します。
IANA has allocated the following allocation value:
IANAは、次の割り当て値を割り当てました。
Bit number Meaning Reference 4 BRPC path computation This document chain unavailable
ビット番号文献4 BRPC経路計算利用できない。この文書鎖を意味
The BRPC procedure relies on the use of the PCEP protocol and as such is subjected to the potential attacks listed in Section 10 of [RFC5440]. In addition to the security mechanisms described in [RFC5440] with regards to spoofing, snooping, falsification, and denial of service, an implementation MAY support a policy module governing the conditions under which a PCE should participate in the BRPC procedure.
BRPC手順は、PCEPプロトコルの使用に依存し、そのように[RFC5440]のセクション10に記載されている潜在的な攻撃にさらされます。スプーフィングに関して、スヌーピング、改ざん、及びサービスの拒否と[RFC5440]に記載されているセキュリティ・メカニズムに加えて、実装は、PCEがBRPC手順に参加する条件を支配するポリシーモジュールをサポートするかもしれません。
The BRPC procedure does not increase the information exchanged between ASes and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216].
情報を増加させないBRPC手順はAS間で交換して、[RFC4105]と[RFC4216]に準拠して、トポロジの機密性を保持します。
The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for their useful comments. A special thanks to Adrian Farrel for his useful comments and suggestions.
作者は彼らの役に立つコメントをArthi Ayyangar、ディミトリPapadimitriou、シヴァシババラン、Meral Shirazipour、マッハチェンに感謝したいと思います。彼の役に立つコメントと提案のためのエードリアンファレルに感謝します。
[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月。
[RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2009.
[RFC5440] Vasseur、J.、エド。そして、J.ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年4月。
[PATH-KEY] Bradford, R., Vasseur, J., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, November 2008.
[PATH-KEY]ブラッドフォード、R.、Vasseur、J.、およびA.ファレル、進歩、2008年11月の作業 "キーベースのメカニズムを使用したドメイン間の経路計算にトポロジ機密性の保持"。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-管理]ファレル、A.、「PCEワーキンググループドラフトでの管理性のセクションを含める」、進歩、2009年1月に作業。
[PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008.
[PCE-MONITOR] Vasseur、J.、ルー、J.、およびY.池尻、「パス計算要素ベースのアーキテクチャのための監視ツールのセット」、進歩、2008年11月の作業。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.、Vasseur、J.、およびJ.ボイル、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]チャン、R.とJ. Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]ファレル、A.、Vasseur、J.、およびA. Ayyangar、RFC 4726、2006年11月 "トラフィックエンジニアリングの切り替えドメイン間マルチプロトコルラベルのためのフレームワーク"。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]ル・ルー、JL。、Vasseur、JP。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素（PCE）ディスカバリー"、RFC 5088、2008年1月。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]ル・ルー、JL。、Vasseur、JP。、池尻、Y.、およびR.張は、 "IS-IS経路計算エレメント（PCE）の発見のためのプロトコル拡張"、RFC 5089、2008年1月。
[RFC5152] Vasseur, JP., Ayyangar, A., 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.張は、RFC 5152、2008年2月 "Aドメイン単位の経路計算方法は、ドメイン間トラフィックエンジニアリング（TE）ラベルを確立するためのパス（LSPは）スイッチ"。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
[RFC5316]チェン、M.、チャン、R.、およびX.ドゥアン、 "インター自律システム（AS）MPLSおよびGMPLSトラフィックエンジニアリングのサポートでISIS拡張機能"、RFC 5316、2008年12月。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
[RFC5392]チェン、M.、チャン、R.、およびX.ドゥアン、 "OSPF拡張インター自律システム（AS）MPLSおよびGMPLSトラフィックエンジニアリングのサポートで"、RFC 5392、2009年1月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（エディタ）は、シスコシステムズ、株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンド・チャンBTインフォネット2160 E.グランドアベニューエル・セグンド、CA 90025 USA
EMail: raymond.zhang@bt.com
メールアドレス：raymond.zhang@bt.com
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA
ナビル・ビタールベライゾン117西ストリートウォルサム、MA 02451 USA
EMail: nabil.n.bitar@verizon.com
メールアドレス：nabil.n.bitar@verizon.com
JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE
JLルルーフランステレコム2、アベニューピエールMarzinラニオン、22307 FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com