[要約] RFC 5441は、異なるドメイン間のトラフィックエンジニアリングのための最短経路計算手法であるBRPCの手順を提案している。このRFCの目的は、制約条件下での最短経路を計算するための効果的な手法を提供することである。
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.
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 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領域や自律システムなどのアドレス管理またはパス計算責任の共通の領域内のネットワーク要素のコレクションです。このドキュメントは、複数のパス計算要素（PCES）の使用に依存する手順を指定して、ドメイン間の最も短い制約されたパスを、後方再帰パス計算手法を使用して、ドメインの所定のシーケンスを横切る最短の制約パスを計算します。この手法は、ドメイン全体の機密性を保持します。これは、ドメインが異なるサービスプロバイダーによって管理される場合に必要な場合があります。
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）の要件は、それぞれ[RFC4105]および[RFC4216]でトラフィックエンジニアリングワーキンググループ（TE WG）によって開発されています。
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]で定義されています。このドキュメントの目的は、PCEベースのパス計算手順を記述して、最適なドメイン間拘束（G）MPLS TE LSPを計算することです。
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：エリアボーダールーター。2つのIGP領域（OSPFの領域またはIS-ISのレベル）を接続するために使用されるルーター。
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：自律システムボーダールーター。ルーターは、1つまたは複数のリンクを介して、同じまたは異なるサービスプロバイダーのASEを接続するために使用されます。
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.
ドメイン（n）のエントリBN：ドメイン（n-1）をドメイン（n）に接続するBnは、ドメインの決定されたシーケンスに沿ってドメイン（n）に到達します。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains.
ドメイン（n）の出口BN：ドメイン（n）をドメイン（n 1）に接続するBnは、ドメインの決定されたシーケンスに沿ってドメイン（n 1）に及ぼします。
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
Inter-Areae LSP：IGP領域の境界を越えるTE LSP。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-as te lsp：境界を横切るte lsp。
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 Inter-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.
o IGP/BGPのスケーラビリティと機密性を維持するために重要なドメイン（[RFC4105]および[RFC4216]ごとに義務付けられている場合）間にトポロジまたはリソース情報は分配されていません。
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制約（リソースアフィニティ、色、メトリックなど）はドメイン境界で翻訳できます。必要に応じて、ドメイン境界ノードには、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 それぞれがいくつかのIGP領域で構成されています。このドキュメントで説明されているパス計算手順は、複数のIGP領域、単一のIGP領域で作られた複数のAS、または上記の任意の組み合わせで構成された単一の場合に適用されます。簡単にするために、それぞれがこのドキュメントの単一の領域で作られていると見なされます。これらのASEの一部が複数のIGP領域で作られている複数のASESにまたがる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はPCREQをそのドメイン内のPCEに送信します。リクエストは、LSP宛先を含むドメインの原因となるPCEが到達するまで、ドメインごとのPCESの間で転送されます。宛先ドメインのPCEは、宛先への潜在的なパスのツリー（仮想最短パスツリー-VSPT）を作成し、これをPCREPで以前のPCEに戻します。各PCEはVSPTに追加され、ソースドメインのPCEがVSPTを使用してPCCがPCCに送信するエンドツーエンドパスを選択するまで渡します。
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).
さらに、PCEが使用している実際のパス計算アルゴリズムには、マルチコンストレント最適化の問題を解決するための線形プログラミングに基づいて、制約された最短パス（CSPF）またはアルゴリズムのバリアントになります）。
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]で定義されているincludeルートオブジェクト（IRO）を使用して移動するドメインのシーケンスを示している場合があります。また、PCCのポリシーによって一連のPCESが施行される可能性があり、この制約はPCEPパス計算要求（[PCE-Monitor]で定義されているように）で実行できることに注意してください。
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.
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）エントリBNSのセットがあります。Bn-en（k、i）では、Bn-en（k、i）はドメイン（i）のkthエントリ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）出口BNS BN-EX（K、I）に記載されているX-EX（I）出口BNSのセットがあります。ここで、BN-EX（K、I）はドメイン（I）のKTH出口BNです。
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1):
VSPT（I）：MP2P（Multipoint-to-Point）PCE（I）からPCE（I-1）から返されたツリー：
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)]
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).
PCE（i）は、ドメイン（i）のエントリBNSのみを考慮していること、つまりドメイン（I-1）からの接続を提供するBNSのみを考慮していることに注意してください。言い換えれば、SET BN-EN（K、I）は、ドメイン（I-1）からドメイン（I）への接続性を提供するBNでのみ構成されています。さらに、一部のBNは、ポリシーの制約に従って除外される場合があります（Path Computation Requestで指示されたローカルポリシーまたはポリシーのいずれか）。
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はパス計算リクエストを提供できるPCEを決定する必要があります（これはローカル構成で、またはIGP発見を介して実行できます（[RFC5088]および[RFC5089]を参照））。次に、PATH計算要求がPCE（n）に到達するまで中継され、TE LSP宛先がドメイン（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）は、適切なパス計算アルゴリズム（CSPFなど）を使用して、すべてのBN-EN（J、N）とTE LSP宛先の間の最短制約付きパスのリストで作成されたVSPT（n）を計算するVSPT（n）を計算します。計算された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).
TELSP計算の間で、これには、ドメイン（i）をドメイン（I 1）に接続する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は、そのようなすべてのドメインに対してこの計算を実行してから、PCREPをシーケンスの前のPCEに渡す必要があります。
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手順では、宛先からエントリ境界ノードのセットまでの制約を満たす最短パスが要求されることを指定するために、PCREQメッセージ（[RFC5440]で定義）内にある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メッセージ内で運ばれるメトリックオブジェクトの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がBNから対応するPCREQメッセージのエンドポイントオブジェクトで指定された宛先までのパスセグメントを表す明示的なルートオブジェクト（ERO）の非秩序化リストで構成されています。
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:
図2に示す簡単な例では、各ABRと宛先Dの間に制約されたパスが存在すると仮定した場合、PCEサービングエリア2で計算されたVSPTは、次の非秩序化されたEROSセットで構成されています。
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].
TELSPパス計算の間で、BRPC手順では、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がASBR間リンクに関連するTE情報に浸水できるようにすることで構成されています。これにより、ドメインのPCEは、[RFC5316]および[RFC5392]で定義されているIGP拡張機能を参照）を下流ドメインのエントリASBRSのセットにすることができます。
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.
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：ドメインパスに沿った1つ以上のPCESによってサポートされていない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トラフィックエンジニアリングの要件は、トラフィックエンジニアリングワーキンググループ（TE WG）によって開発されており、それぞれ[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は、SVECオブジェクトのフラグL、N、またはSをそれぞれリンク、ノード、またはSRLG（共有リスクリンクグループ）の多様性を要求するように設定することにより、多様なTE LSPの計算を要求できます。。このような要求は、VSPT計算中にパス計算チェーンに沿った各PCEによって考慮される必要があります。BRPC手順のコンテキストでは、VSPTのパスセグメントが特定のPCEによって同時に計算されるため、2つのLSR間で多様にルーティングされたTE LSPのセットを計算できます。BRPCプロシージャは、さまざまな目的関数の下での多様なパスの計算を可能にします（N Diberse Pathsなどのコストの合計を最小限に抑えるなど）。
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]で定義されている再最適化手順は、使用中のパス（ヘッドエンドで利用可能な場合）がパス計算要求の一部として提供され、再最適化に関与するPCESが適用されるときに適用されます。リクエストは、二重帯域幅の会計を回避できます。
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がこのドキュメントで定義されているBRPC手順に従って下流のPCEに定義され、そのようなPCEが使用できない場合、PCEは[[]で指定されたPCREQメッセージを使用してネガティブパス計算応答を要求者に送信する必要がある場合RFC5440]これには、パスなしオブジェクトが含まれています。そのような場合、NO-PATHオブジェクトは、「BRPC PATH COMPUTATIONチェーンの利用できない」セットという名前の新しく定義されたビットを使用して、NO-PATH-VECTOR TLV（[RFC5440]で定義）を運ぶ必要があります。
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]).
局間の場合、同じIGP/TEメトリックスキームが通常、すべてのIGP領域に採用されます（たとえば、リンク速度、伝播遅延、またはリンク属性のその他の組み合わせに基づいて）。したがって、提案されている一連のメカニズムは、指定された目的関数に関して必要な制約セットに従う複数の領域にわたって常に最短パスを計算します。逆に、このパス計算が意味のあるものになるためには、inter-as teの場合、ASE間のメトリック正規化が必要になる場合があります。IGPメトリックの変更を回避するための1つの解決策は、サービスプロバイダーがTEメトリック正規化スキームに同意し、TEメトリックをTE LSPパス計算に使用することです（その場合、PCEPパス計算でTEメトリックの使用を要求する必要があります。要求）メトリックオブジェクトを使用します（[RFC5440]で定義）。
This section follows the guidance of [PCE-MANAGE].
このセクションは、[PCE-Manage]のガイダンスに従います。
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手順（リクエストの原点、1秒あたりのリクエスト数など）に参加する条件を管理するポリシーモジュールによって制御される場合があります。BRPCがPCEでサポート/許可されていない場合、セクション9で指定されているように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パス計算手法であり、PCESのセットがパス計算チェーンに関与しています。少なくとも1つのPCEがBRPCプロシージャをサポートしていないため、またはパス計算チェーンに関与しなければならないPCEの1つが利用できないため、パス計算チェーンが動作していない場合、セクション9およびセクション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
o PCEごとに成功したBRPC手順の完了の数
o Number of BRPC procedure completion failures because the VSPT flag was not recognized (on a per-PCE-peer basis)
o VSPTフラグが認識されなかったため（PCEごとに）BRPC手順完了障害の数）
o Number of BRPC procedure completion failures because the BRPC procedure was not supported (on a per-PCE-peer basis)
o BRPC手順がサポートされていないため（PCEごとに）BRPC手順完了障害の数）
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は、「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メッセージで使用するためのエラータイプとエラー値のレジストリを維持しています。これは、「PATH計算要素プロトコル（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
Error-value=4: Unsupported parameter This document
エラー値= 4：サポートされていないパラメーターこのドキュメント
A new Error-Type is defined in this document as follows:
このドキュメントでは、新しいエラータイプが次のように定義されています。
Error-Type Meaning Reference
13 BRPC procedure completion failure This document
Error-value=1: BRPC procedure not This document supported by one or more PCEs along the domain path
エラー値= 1：BRPC手順ドメインパスに沿った1つ以上のPCESによってサポートされていないこのドキュメント
A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is specified in this document.
[RFC5440]で定義されているNo-Path-Vector 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は、「PATH-VECTOR TLV FLAGフィールド」で、「PATH計算要素プロトコル（PCEP）数値」数字」のサブレジストリに、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手順は、ASEと保存の間で交換される情報を増加させません。[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、Dimitri Papadimitriou、Siva Sivabalan、Meral Shirazipour、Mach Chenの有用なコメントに感謝したいと思います。有用なコメントと提案をしてくれたエイドリアンファレルに感謝します。
[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月。
[RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2009.
[RFC5440] Vasseur、J.、ed。and J. Roux、ed。、「Path Computation Element（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] Bradford、R.、Vasseur、J。、およびA. Farrel、「キーベースのメカニズムを使用したドメイン間パス計算におけるトポロジの機密性の保存」、2008年11月、Work in Progress。
[PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
[PCE-Manage] Farrel、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.、Roux、J。、およびY. Ikejiri、「パス計算要素ベースのアーキテクチャ用の一連の監視ツール」、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.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「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] Le Roux、J.、Vasseur、J。、およびJ. Boyle、「エリア間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] Zhang、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] Farrel、A.、Vasseur、J。、およびJ. Ash、「パス計算要素（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] Farrel、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] Le Roux、Jl。、Vasseur、JP。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、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] Le Roux、Jl。、Vasseur、JP。、Ikejiri、Y。、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのISプロトコル拡張」、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. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、RFC 5152、2008年2月。
[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] Chen、M.、Zhang、R。、およびX. Duan、「自律システム（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] Chen、M.、Zhang、R。、およびX. Duan、「自律システム（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張」、RFC 5392、2009年1月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集者）Cisco Systems、Inc 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
Raymond Zhang Bt Infonet 2160 E. Grand Ave. El Segundo、CA 90025 USA
EMail: raymond.zhang@bt.com
Nabil Bitar Verizon 117 West Street Waltham, MA 02451 USA
Nabil Bitar Verizon 117 West Street Waltham、MA 02451 USA
EMail: nabil.n.bitar@verizon.com
JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE
Jl Le Roux France Telecom 2、Avenue Pierre-Marzin Lannion、22307 France
EMail: jeanlouis.leroux@orange-ftgroup.com