Network Working Group Y. Lee
Request for Comments: 5557 Huawei
Category: Standards Track JL. Le Roux
France Telecom
D. King
Old Dog Consulting
E. Oki
University of Electro Communications
July 2009
Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization
経路計算要素通信プロトコル（PCEP）グローバル同時最適化のサポートにおける要件とプロトコル拡張
Abstract
抽象
The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.
パス計算要素通信プロトコル（PCEP）はパス計算クライアント（のPCC）はパス計算要素（のPCE）からパス計算を要求することができます、とのPCEは応答を返すことができます。ネットワークを通じてパス（TE LSPを）スイッチ計算またはトラフィックエンジニアリングラベルのセットのルートをreoptimizing場合は、ブロッキングの問題を回避し、より最適なネットワーク全体のソリューションを達成するために、バルクパス計算を実行することが有利であり得ます。このようなバルク最適化は、グローバル同時最適化（GCO）と呼ばれています。 GCOは、同時にネットワークのトポロジ全体および既存のTE LSPの完全なセット、およびそれぞれの制約を考慮し、すべてのTEのLSPのためのすべての制約を満たすために、ネットワーク全体を最適化または再最適化するために見ることができます。 GCOは、ネットワークにおけるTE LSPのサブセットに適用することができます。 GCOアプリケーションは、主にネットワーク管理システム（NMS）ソリューションです。
This document provides application-specific requirements and the PCEP extensions in support of GCO applications.
この文書では、アプリケーション固有の要件とGCOアプリケーションのサポートでPCEPの拡張機能を提供します。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Applicability of Global Concurrent Optimization (GCO) ...........6
3.1. Application of the PCE Architecture ........................7
3.2. Greenfield Optimization ....................................8
3.2.1. Single-Layer Traffic Engineering ....................8
3.2.2. Multi-Layer Traffic Engineering .....................8
3.3. Reoptimization of Existing Networks ........................8
3.3.1. Reconfiguration of the Virtual Network
Topology (VNT) ......................................9
3.3.2. Traffic Migration ...................................9
4. PCECP Requirements .............................................10
5. Protocol Extensions for Support of Global Concurrent
Optimization ...................................................13
5.1. Global Objective Function (GOF) Specification .............14
5.2. Indication of Global Concurrent Optimization Requests .....15
5.3. Request for the Order of TE LSP ...........................15
5.4. The Order Response ........................................16
5.5. GLOBAL CONSTRAINTS (GC) Object ............................17
5.6. Error Indicator ...........................................18
5.7. NO-PATH Indicator .........................................19
6. Manageability Considerations ...................................19
6.1. Control of Function and Policy ............................19
6.2. Information and Data Models (e.g., MIB Module) ............20
6.3. Liveness Detection and Monitoring .........................20
6.4. Verifying Correct Operation ...............................20
6.5. Requirements on Other Protocols and Functional
Components ................................................20
6.6. Impact on Network Operation ...............................20
7. Security Considerations ........................................21
8. IANA Considerations ............................................21
8.1. Request Parameter Bit Flags ...............................21
8.2. New PCEP TLV ..............................................21
8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED .................22
8.4. New PCEP Object ...........................................22
8.5. New PCEP Error Codes ......................................22
8.5.1. New Error-Values for Existing Error-Types ..........22
8.5.2. New Error-Types and Error-Values ...................23
8.6. New No-Path Reasons .......................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................24
10. Acknowledgments ...............................................24
Appendix A. RBNF Code Fragments ...................................25
[RFC4655] defines the Path Computation Element (PCE)-based architecture and explains how a PCE may compute Label Switched Paths (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the request of Path Computation Clients (PCCs). A PCC is shown to be any network component that makes such a request and may be, for instance, a Label Switching Router (LSR) or a Network Management System (NMS). The PCE, itself, is shown to be located anywhere within the network, and it may be within an LSR, an NMS or Operational Support System (OSS), or may be an independent network server.
[RFC4655]はパス計算要素（PCE）ベースのアーキテクチャを定義し、ラベルを計算することができるPCEは、経路リクエストにトラフィックエンジニアリング（MPLS-TE）及び一般化MPLS（GMPLS）ネットワークをマルチプロトコルラベルスイッチングのパス（LSPを）交換方法について説明します計算クライアント（のPCC）。 PCCは、例えば、そのような要求を行うことができる任意のネットワーク構成要素であることが示され、ラベルスイッチングルータ（LSR）またはネットワーク管理システム（NMS）。 PCEは、それ自体は、ネットワーク内の任意の場所に位置するように示され、そしてそれはLSR、NMS又は運用支援システム（OSS）の範囲内であってもよいし、独立したネットワークサーバであってもよいです。
The PCE Communication Protocol (PCEP) is the communication protocol used between PCC and PCE, and it may also be used between cooperating PCEs. [RFC4657] sets out generic protocol requirements for PCEP. Additional application-specific requirements for PCEP are defined in separate documents.
PCE通信プロトコル（PCEP）をPCCとPCEとの間で使用される通信プロトコルであり、協働のPCE間にも使用され得ます。 [RFC4657]はPCEPのための汎用的なプロトコル要件を定めています。 PCEPのための追加のアプリケーション固有の要件は、別の文書で定義されています。
This document provides a set of requirements and PCEP extensions in support of concurrent path computation applications. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a concurrent path computation is referred to as "global concurrent optimization" in this document. Appropriate computation algorithms to perform this type of optimization are out of the scope of this document.
この文書では、要件と同時経路計算アプリケーションをサポートするPCEP拡張機能のセットを提供します。並行経路計算は、TEパスのセットを効率的にネットワーク資源を利用するために同時に計算される経路計算アプリケーションです。同時経路計算に関わる計算方法は、このドキュメントの「グローバル同時最適化」と呼ばれています。このタイプの最適化を実行するための適切な計算アルゴリズムは、この文書の範囲外です。
The Global Concurrent Optimization (GCO) application is primarily an NMS or a PCE-Server-based solution. Owing to complex synchronization issues associated with GCO applications, the management-based PCE architecture defined in Section 5.5 of [RFC4655] is considered as the most suitable usage to support GCO application. This does not preclude other architectural alternatives to support GCO application, but they are NOT RECOMMENDED. For instance, GCO might be enabled by distributed LSRs through complex synchronization mechanisms. However, this approach might suffer from significant synchronization overhead between the PCE and each of the PCCs. It would likely affect the network stability and hence significantly diminish the benefits of deploying PCEs.
グローバル同時最適化（GCO）アプリケーションは、主として、NMS又はPCE-Serverベースのソリューションです。 GCOアプリケーションに関連付けられている複雑な同期の問題のために、[RFC4655]のセクション5.5で定義された管理ベースPCEアーキテクチャはGCOアプリケーションをサポートするために最も適切な使用であると考えられます。これは、GCOアプリケーションをサポートするために、他の建築の選択肢を排除するものではないが、彼らはお勧めできません。例えば、GCOは、複雑な同期メカニズムを通じて配布のLSRで有効になっている可能性があります。しかし、このアプローチは、PCEとのPCCのそれぞれとの間に有意な同期オーバーヘッドに苦しむかもしれません。これは、おそらくネットワークの安定性に影響を与えるので、大幅に導入するのPCEの利点を減少させるでしょう。
The need for global concurrent path computation may also arise when network operators need to establish a set of TE LSPs in their network planning process. It is also envisioned that network operators might require global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted. The nature of this work promotes the use of such systems for off-line processing. Online application of this work should only be considered with proven empirical validation.
ネットワーク事業者がネットワークの計画プロセスにおけるTE LSPのセットを確立する必要があるときに、グローバル同時経路計算の必要性も生じる可能性があります。また、ネットワーク事業者は、TE LSPのセットが最適に再ルーティングする必要が壊滅的なネットワーク障害のイベントにおける世界的な同時経路計算を必要とするかもしれないことが想定されます。この作業の性質は、オフライン処理のためにそのようなシステムの使用を促進します。この作品のオンラインアプリケーションは、実績のある経験的検証で考慮されるべきです。
As new TE LSPs are added or removed from the network over time, the global network resources become fragmented and the existing placement of TE LSPs within the network no longer provides optimal use of the available capacity. A global concurrent path computation is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs and their respective constraints, and is able to look to reoptimize the entire network to satisfy all constraints for all TE LSPs. Alternatively, the application may consider a subset of the TE LSPs and/or a subset of the network topology. Note that other preemption can also help reduce the fragmentation issues.
新しいTEのLSPが時間をかけて追加またはネットワークから削除されると、グローバルなネットワークリソースが断片化しないと、ネットワーク内のTE LSPの既存の配置は、もはや利用可能な容量の最適な使用を提供します。グローバル同時経路計算は、同時にネットワークと既存のTE LSPをと、それぞれの制約の完全なセットの全体のトポロジーを考慮することができ、そしてすべてのTEのLSPのためにすべての制約を満たすために、ネットワーク全体を再最適化するために見ることができます。あるいは、アプリケーションは、TEのLSPおよび/またはネットワークトポロジのサブセットのサブセットを考慮することができます。他のプリエンプションも断片化の問題を軽減できることに注意してください。
While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is NOT RECOMMENDED that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is NOT RECOMMENDED because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels.
GCOは、複数のTE LSPのための任意の同時要求に適用可能であるが（例えば、要求がエンドツーエンド保護）、それはグローバル同時再最適化は、ネットワークに適用されることが推奨されない（例えば、MPLS-TEネットワークなど）それは、単一のTE LSPの再最適化に問題の大きな範囲以来、非常に低い帯域幅またはゼロ帯域幅TE LSPの非常に多数の同時再最適化の相対的な小さな利益を含有するプロセスは価値するにくいです。さらに、TEのLSP（解約）の変化率とネットワークのグローバル同時再最適化を適用するために、彼らは世界的に再最適化することができる前にTEのLSPが変更される可能性をお勧めしません。グローバル再最適化は、トランスポートネットワーク又は長期TE LSPトンネルを有するものとして安定したネットワークに対してより適用可能です。
The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs.
この文書の主な焦点は、並行経路計算アプリケーションをサポートするためにPCC-PCE通信ニーズを強調するために、これらのニーズを満たすために、プロトコルの拡張機能を定義することです。
The PCC-PCE requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of performing computations in support of GCO. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [RFC4674], [RFC5088], [RFC5089]; but, that is out of the scope of this document.
本明細書に対処PCC-PCE要件は、PCEは、GCOを支援する計算を実行することができる特殊なPCEであるコンテキストに特異的です。そのような機能の発見が望ましいかもしれないとPCE発見メカニズム[RFC4674]、[RFC5088]、[RFC5089]の拡張機能を介して達成することができます。しかし、それはこのドキュメントの範囲外です。
It is to be noted that Backward Recursive Path Computation (BRPC) [RFC5441] is a multi-PCE path computation technique used to compute a shortest constrained inter-domain path, whereas this ID specifies a technique where a set of path computation requests are bundled and sent to a PCE with the objective of "optimizing" the set of computed paths.
このIDは、経路計算要求のセットがバンドルされている技術を指定し、一方、それは、逆方向再帰パス計算（BRPC）[RFC5441]は最短制約ドメイン間の経路を計算するために使用されるマルチPCE経路計算手法であることに留意すべきですそして、計算されたパスのセットを「最適化」の目的でPCEに送信されます。
Most of the terminology used in this document is explained in [RFC4655]. A few key terms are repeated here for clarity.
このドキュメントで使用される用語のほとんどは、[RFC4655]で説明されています。いくつかの重要な用語をわかりやすくするためにここで繰り返されています。
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：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
TED: Traffic Engineering Database. The TED contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means.
TED：トラフィックエンジニアリングデータベース。 TEDは、ドメインのトポロジーおよびリソース情報が含まれています。 TEDは、IGPの拡張によって、または潜在的に他の手段によって供給されてもよいです。
PCECP: The PCE Communication Protocol. PCECP is the generic abstract idea of a protocol that is used to communicate path computation requests from a PCC to a PCE and to return computed paths from the PCE to the PCC. The PCECP can also be used between cooperating PCEs.
PCECP：PCE通信プロトコル。 PCECPはPCEにPCCから経路計算要求を通信し、PCCへのPCEの計算パスを返すために使用されるプロトコルの一般的な抽象的アイデアです。 PCECPはまた協力のPCEの間で使用することができます。
PCEP: The PCE communication Protocol. PCEP is the actual protocol that implements the PCECP idea.
PCEP：PCE通信プロトコル。 PCEPはPCECPのアイデアを実装し、実際のプロトコルです。
GCO: Global Concurrent Optimization. A concurrent path computation application where a set of TE paths are computed concurrently in order to optimize network resources. A GCO path computation is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO path computation can also provide an optimal way to migrate from an existing set of TE LSPs to a reoptimized set (Morphing Problem).
GCO：世界同時最適化。 TEパスのセットは、ネットワーク資源を最適化するために並行して計算される並行経路計算アプリケーション。 GCOの経路計算は、同時にネットワークのトポロジ全体および既存のTE LSPの完全なセット、およびそれぞれの制約を考慮し、すべてのTEのLSPのためのすべての制約を満たすために、ネットワーク全体を最適化または再最適化するために見ることができます。 GCO経路計算はまた、再最適化セット（モーフィング問題）にTE LSPの既存のセットから移行するための最適な方法を提供することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These terms are used to specify requirements in this document.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。これらの用語は、この文書の要件を指定するために使用されています。
This section discusses the PCE architecture to which GCO is applied. It also discusses various application scenarios for which global concurrent path computation may be applied.
このセクションでは、GCOが適用されるPCEアーキテクチャについて説明します。それはまた、グローバル同時経路計算を適用することができるため、様々なアプリケーション・シナリオについて説明します。
Figure 1 shows the PCE-based network architecture as defined in [RFC4655] to which GCO application is applied. It must be observed that the PCC is not necessarily an LSR [RFC4655]. The GCO application is primarily an NMS-based solution in which an NMS plays the function of the PCC. Although Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. Note that in the collocated case, there is no need for a standard communication protocol; this can rely on internal APIs.
[RFC4655]で定義されるように、図1は、GCOアプリケーションが適用されるPCEベースのネットワークアーキテクチャを示します。 PCCは必ずしもLSR [RFC4655]ではないことが観察されなければなりません。 GCOアプリケーションは主にNMSはPCCの機能を果たしているNMSベースのソリューションです。図1は、NMSからリモートとしてPCEを示しているが、それはNMSと並置されるかもしれません。併置場合には、標準的な通信プロトコルを必要としないことに留意されたいです。これは、内部APIに依存することができます。
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |
| PCC | Response| ----- |
| (NMS/Server)|<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 1: PCE-Based Architecture for
Global Concurrent Optimization
Upon receipt of an application request (e.g., a traffic demand matrix is provided to the NMS by the operator's network planning procedure), the NMS requests a global concurrent path computation from the PCE. The PCE then computes the requested paths concurrently applying some algorithms. Various algorithms and computation techniques have been proposed to perform this function. Specification of such algorithms or techniques is outside the scope of this document.
アプリケーション要求（例えば、トラフィック需要行列は、オペレータのネットワーク計画手順によってNMSに提供される）を受信すると、NMSは、PCEからグローバル並行経路計算を要求します。 PCEは、次いで、同時にいくつかのアルゴリズムを適用する要求経路を計算します。様々なアルゴリズムおよび計算技術は、この機能を実行するために提案されています。そのようなアルゴリズムまたは技術の仕様は、この文書の範囲外です。
When the requested path computation completes, the PCE sends the resulting paths back to the NMS. The NMS then supplies the head-end LSRs with a fully computed explicit path for each TE LSP that needs to be established.
要求された経路計算が完了すると、PCEは、バックNMSに得られたパスを送ります。 NMSは、その後、確立される必要がある各TE LSPの完全計算明示的経路とヘッドエンドのLSRを供給する。
Greenfield optimization is a special case of GCO application when there are no TE LSPs already set up in the network. The need for greenfield optimization arises when the network planner wants to make use of a computation server to plan the TE LSPs that will be provisioned in the network. Note that greenfield operation is a one-time optimization. When network conditions change due to failure or other changes, then the reoptimization mode of operation will kick in.
すでにネットワークに設定さ何らTEのLSPが存在しないとき、グリーンフィールドの最適化は、GCOアプリケーションの特殊なケースです。ネットワーク計画担当者は、ネットワークでプロビジョニングされたTE LSPを計画するために、計算サーバの利用をしようとするとグリーンフィールドの最適化の必要性が生じます。グリーンフィールドの操作は一回の最適化であることに注意してください。ネットワークの状態が障害またはその他の変更を変更すると、操作の再最適化モードがでキックします。
When a new TE network needs to be provisioned from a greenfield perspective, a set of TE LSPs needs to be created based on traffic demand, network topology, service constraints, and network resources. In this scenario, the ability to perform concurrent computation is desirable, or required, to utilize network resources in an optimal manner and avoid blocking.
新しいTEネットワークはグリーンフィールドの観点からプロビジョニングする必要がある場合、TE LSPのセットは、交通需要、ネットワークトポロジー、サービスの制約、およびネットワークリソースに基づいて作成する必要があります。このシナリオでは、同時計算を実行する能力は、最適な方法でネットワークリソースを利用し、ブロッキングを回避するために、望ましい、または必要。
Greenfield optimization can be applied when layer-specific TE LSPs need to be created from a greenfield perspective. For example, an MPLS-TE network can be planned based on Layer 3 specific traffic demands, the network topology, and available network resources. Greenfield optimization for single-layer traffic engineering can be applied to optical transport networks such as Synchronous Digital Hierarchy/Synchronous Optical Network (SDH/SONET), Ethernet Transport, Wavelength Division Multiplexing (WDM), etc.
層固有のTEのLSPは、グリーンフィールドの観点から作成する必要がある場合にグリーンフィールドの最適化を適用することができます。例えば、MPLS-TEネットワークは、レイヤ3の特定のトラフィック需要、ネットワークトポロジ、および利用可能なネットワークリソースに基づいて計画することができます。単層のトラフィックエンジニアリングのためのグリーンフィールドの最適化など同期デジタルハイアラーキ/同期光ネットワーク（SDH / SONET）、イーサネット交通、波長分割多重（WDM）、などの光トランスポートネットワークに適用することができます
Greenfield optimization is not limited to single-layer traffic engineering. It can also be applied to multi-layer traffic engineering [PCE-MLN]. The network resources and topology (of both the client and server layers) can be considered simultaneously in setting up a set of TE LSPs that traverse the layer boundary.
グリーンフィールドの最適化は、単層のトラフィックエンジニアリングに限定されるものではありません。また、マルチレイヤトラフィックエンジニアリング[PCE-MLN]に適用することができます。ネットワークリソース及び（クライアントとサーバの両方の層の）トポロジーは、層境界を横切るTE LSPの組を設定する際に同時に考慮することができます。
The need for global concurrent path computation may arise in existing networks. When an existing TE LSP network experiences sub-optimal use of its resources, the need for reoptimization or reconfiguration may arise. The scope of reoptimization and reconfiguration may vary depending on particular situations. The scope of reoptimization may be limited to bandwidth modification to an existing TE LSP. However, it could well be that a set of TE LSPs may need to be reoptimized concurrently. In an extreme case, the TE LSPs may need to be globally reoptimized.
グローバル同時経路計算の必要性は、既存のネットワークで発生する可能性があります。既存のTE LSPネットワークがそのリソースのサブ最適な使用を経験すると、再最適化または再設定の必要性が生じる可能性があります。再最適化および再構成の範囲は、特定の状況に応じて変えることができます。再最適化の範囲は、既存のTE LSPに帯域変更に限定してもよいです。しかし、それはよくTE LSPのセットを同時に再最適化する必要があるかもしれないという可能性があります。極端な場合には、TE LSPは、グローバル再最適化する必要があるかもしれません。
In loaded networks, with large size TE LSPs, a sequential reoptimization may not produce substantial improvements in terms of overall network optimization. Sequential reoptimization refers to a path computation method that computes the reoptimized path of one TE LSP at a time without giving any consideration to the other TE LSPs that need to be reoptimized in the network. The potential for network-wide gains from reoptimization of TE LSPs sequentially is dependent upon the network usage and size of the TE LSPs being optimized. However, the key point remains: computing the reoptimized path of one TE LSP at a time without giving any consideration to the other TE LSPs in the network could result in sub-optimal use of network resources. This may be far more visible in an optical network with a low ratio of potential TE LSPs per link, and far less visible in packet networks with micro-flow TE LSPs.
ロードされたネットワークでは、大きなサイズTE LSPを用いて、逐次再最適化は、ネットワーク全体の最適化の点で大幅な改善を生じないことができます。逐次再最適化は、ネットワーク内で再最適化する必要がある他のTEのLSPに任意考慮することなく一度に一つのTE LSPの再最適化経路を計算する経路計算方法を指します。 TE LSPの順次の再最適化からネットワーク全体の利益の可能性は最適化されたTE LSPのネットワーク使用率およびサイズに依存します。しかしながら、重要な点が残って：ネットワーク資源の準最適な使用につながる可能性がネットワーク内の他のTEのLSPに任意考慮することなく一度にTE LSPの再最適化経路を計算します。これは、はるかに目に見えるリンクあたりの電位のTE LSPの低い比を有する光ネットワークで、およびはるかに少ない可視マイクロ流TE LSPを有するパケットネットワークであってもよいです。
With regards to applicability of GCO in the event of catastrophic failures, there may be a real benefit in computing the paths of the TE LSPs as a set rather than computing new paths from the head-end LSRs in a distributed manner. Distributed jittering is a technique that could prevent race condition (i.e., competing for the same resource from different head-end LSRs) with a distributed computation. GCO provides an alternative way that could also prevent race condition in a centralized manner. However, a centralized system will typically suffer from a slower response time than a distributed system.
致命的な障害が発生した場合にGCOの適用に関しては、セットとしてTE LSPの経路を計算するのではなく分散してヘッドエンドのLSRから新しいパスを計算する際に本当の利点が存在し得ます。分散ジッタは、分散計算を用いて（すなわち、異なるヘッドエンドのLSRから同じリソースについて競合）競合状態を防ぐことができる技術です。 GCOも一元的に競合状態を防ぐことができる別の方法を提供します。しかし、中央集中型のシステムは、一般的に、分散システムよりも遅い応答時間に苦しむだろう。
Reconfiguration of the VNT [RFC5212] [PCE-MLN] is a typical application scenario where global concurrent path computation may be applicable. Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes may require a set of existing TE LSPs to be re-computed.
VNT [RFC5212] [PCE-MLN]の再構成はグローバル並行経路計算を適用することができる典型的なアプリケーションのシナリオです。このような交通需要の変化、ネットワーク障害、およびトポロジー構成の変更を再計算する既存のTE LSPの組を必要とするかもしれないように、VNT再構成のためのトリガー。
When migrating from one set of TE LSPs to a reoptimized set of TE LSPs, it is important that the traffic be moved without causing disruption. Various techniques exist in MPLS and GMPLS, such as make-before-break [RFC3209], to establish the new TE LSPs before tearing down the old TE LSPs. When multiple TE LSP routes are changed according to the computed results, some of the TE LSPs may be disrupted due to the resource constraints. In other words, it may prove to be impossible to perform a direct migration from the old TE LSPs to the new optimal TE LSPs without disrupting traffic because there are insufficient network resources to support both sets of TE LSPs when make-before-break is used. However, a PCE may be able to determine a sequence of make-before-break replacement of individual
TE LSPの一組からTE LSPの再最適化のセットに移行する場合、トラフィックが中断を引き起こすことなく移動させることが重要です。種々の技術が古いTE LSPをティアダウンする前に、新しいTE LSPを確立するために、メイク・ビフォア・ブレイク[RFC3209]として、MPLSおよびGMPLSに存在します。複数のTE LSPの経路が計算された結果に応じて変更された場合、TE LSPのいくつかは、リソースの制約のために破壊されてもよいです。言い換えれば、それはメイク・ビフォア・ブレークを使用する場合はTE LSPの両方のセットをサポートするために十分なネットワークリソースがあるため、トラフィックを中断することなく、新たな最適のTEのLSPに古いのTEのLSPからの直接移行を実行することは不可能になるかもしれません。しかし、PCEは、個々のメイク・ビフォア・ブレーク交換のシーケンスを決定することができます
TE LSPs or small sets of TE LSPs so that the full set of TE LSPs can be migrated without any disruption. This scenario assumes that the bandwidth of existing TE LSP is kept during the migration, which is required in optical networks. In packet networks, this assumption can be relaxed as the bandwidth of temporary TE LSPs during migration can be zeroed.
TEのLSPを又はTE LSPの小さなセットTE LSPのフルセットは、任意の中断することなく移行することができます。このシナリオでは、既存のTE LSPの帯域幅は、光ネットワークで必要とされる移行中に維持されることを前提としています。移行中に一時的なTEのLSPの帯域幅をゼロにすることができ、パケットネットワークでは、この仮定を緩和することができます。
It may be the case that the reoptimization is radical. This could mean that it is not possible to apply make-before-break in any order to migrate from the old TE LSPs to the new TE LSPs. In this case, a migration strategy is required that may necessitate TE LSPs being rerouted using make-before-break onto temporary paths in order to make space for the full reoptimization. A PCE might indicate the order in which reoptimized TE LSPs must be established and take over from the old TE LSPs, and it may indicate a series of different temporary paths that must be used. Alternatively, the PCE might perform the global reoptimization as a series of sub-reoptimizations by reoptimizing subsets of the total set of TE LSPs.
これは、再最適化基である場合があり得ます。新しいTEのLSPに古いのTEのLSPから移行する任意の順序でメイク・ビフォア・ブレークを適用することが可能ではないことを意味するかもしれません。この場合、移行戦略は、TEのLSPがフルに再最適化のためのスペースを作るために、一時的なパスの上にメイクビフォア・ブレークを使用して再ルーティングされている必要があり、その必要とされます。 PCEは、TE LSPを確立し、古いTEのLSPから引き継ぎ、それを使用しなければならない別の一時パスのシリーズを示すことしなければならない再最適化される順序を示している可能性があります。代替的に、PCEは、TE LSPの総セットのサブセットをreoptimizingによりサブreoptimizations一連のグローバル再最適化を実行するかもしれません。
The benefit of this multi-step rerouting includes minimization of traffic disruption and optimization gain. However, this approach may imply some transient packets desequencing, jitter, as well as control plane stress.
この多段階再ルーティングの利点は、トラフィックの中断および最適化ゲインの最小化を含みます。しかし、このアプローチは、いくつかの過渡パケットdesequencing、ジッタだけでなく、制御プレーンのストレスを意味し得ます。
Note also that during reoptimization, traffic disruption may be allowed for some TE LSPs carrying low priority services (e.g., Internet traffic) and not allowed for some TE LSPs carrying mission critical services (e.g., voice traffic).
注また、その再最適化中に、トラフィックの中断は、優先度の低いサービス（例えば、インターネットトラフィック）を運ぶいくつかのTE LSPのために許可され、ミッションクリティカルなサービス（例えば、音声トラフィック）を運ぶいくつかのTE LSPのために許可されていないことがあります。
This section provides the PCECP requirements to support global concurrent path computation applications. The requirements specified here should be regarded as application-specific requirements and are justifiable based on the extensibility clause found in Section 6.1.14 of [RFC4657]:
このセクションでは、世界的な同時経路計算アプリケーションをサポートするためにPCECP要件を提供します。ここで指定された要件は、アプリケーション固有の要件とみなされるべきであり、正当[RFC4657]のセクション6.1.14に見られる拡張条項に基づいています。
The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future.
PCECPは、アプリケーション固有の要件文書で指定された要件をサポートしなければなりません。 PCECPはまた、より多くのPCEのアプリケーションは、将来的に導入されるように拡張を許容しなければなりません。
It is also to be noted that some of the requirements discussed in this section have already been discussed in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list of generic constraints while Section 5.1.17 in [RFC4657] provides a list of generic objective functions that MUST be supported by the PCECP. While using such generic requirements as the baseline, this section provides application-specific requirements in the context of global concurrent path computation and in a more detailed level than the generic requirements.
また、このセクションで説明する要件のいくつかはすでにPCECP要件ドキュメント[RFC4657]で議論されていることに留意すべきです。 [RFC4657]セクション5.1.17はPCECPによってサポートしなければならない一般的な目的関数のリストを提供しながら、例えば、[RFC4657]に、セクション5.1.16、汎用制約のリストを提供します。ベースラインのような一般的な要件を使用しながら、このセクションでは、グローバル同時経路計算のコンテキスト及び汎用要件より詳細なレベルでは、アプリケーション固有の要件を提供します。
The PCEP SHOULD support the following capabilities either via creation of new objects and/or modification of existing objects where applicable.
PCEPは、いずれかの新しいオブジェクトおよび/または適用可能な既存のオブジェクトの変更の作成を経由して次の機能をサポートする必要があります。
o An indicator to convey that the request is for a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. Note: This requirement is covered by "synchronized path computation" in [RFC4655] and [RFC4657]. However, an explicit indicator to request a global concurrent optimization is a new requirement.
Oインジケータは、要求がグローバル同時経路計算のためのものであることを伝えるために。このインジケータは、すべてのパスの計算でグローバルな目標やグローバルな制約を適用する際に一貫性を確保する必要があります。注：この要件は[RFC4655]及び[RFC4657]の「同期パス計算」によって覆われています。しかし、世界的な同時最適化を要求する明示的な指標は、新たな要件です。
o A Global Objective Function (GOF) field in which to specify the global objective function. The global objective function is the overarching objective function to which all individual path computation requests are subjected in order to find a globally optimal solution. Note that this requirement is covered by "synchronized objective functions" in Section 5.1.7 [RFC4657] and that [RFC5541] defined three global objective functions as follows. A list of available global objective functions SHOULD include the following objective functions at the minimum and SHOULD be expandable for future addition:
Oグローバル目的関数（GOF）フィールドは、グローバル目的関数を指定します。グローバル目的関数は、すべての個々の経路計算の要求がグローバルに最適解を見つけるために供された包括的目的関数です。この要件は[RFC4657]セクション5.1.7で「同期目的関数」でカバーし、次のように[RFC5541]は3つのグローバル目的関数を定義したことにしていることに注意してください。使用可能なグローバル目的関数の一覧は、最低でも、以下の目的関数を含むべきであるし、将来の追加のために拡張可能であるべきです：
* Minimize aggregate Bandwidth Consumption (MBC)
*（MBC）の集約帯域幅の消費を最小限に抑えます
* Minimize the load of the Most Loaded Link (MLL)
*ほとんどのロードされたリンク（MLL）の負荷を最小限に抑えます
* Minimize Cumulative Cost of a set of paths (MCC)
*パス（MCC）のセットの累積コストを最小限に抑えます
o A Global Constraints (GC) field in which to specify the list of global constraints to which all the requested path computations should be subjected. This list SHOULD include the following constraints at the minimum and SHOULD be expandable for future addition:
Oグローバル制約（GC）フィールドは、すべての要求された経路の計算が施さすべきグローバル制約のリストを指定します。このリストは、最低限、以下の制約を含める必要があり、将来の追加のために拡張可能であるべきです：
* Maximum link utilization value -- This value indicates the highest possible link utilization percentage set for each link. (Note: to avoid floating point numbers, the values should be integer values.)
*最大リンク使用率の値 - この値は、リンクごとに設定可能な限り最高のリンク利用率を示しています。 （注：浮動小数点数を回避するために、値は整数値でなければなりません。）
* Minimum link utilization value -- This value indicates the lowest possible link utilization percentage set for each link. (Note: same as above.)
*最小リンク使用率の値 - この値は、リンクごとに設定可能な最低のリンク利用率を示しています。 （注：上記と同じ。）
* Overbooking factor -- The overbooking factor allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit.
*因子をオーバーブッキング - オーバーブッキング係数は、予約帯域幅は、その物理的な容量制限を超えて各リンク上でオーバーブッキングされることを可能にします。
* Maximum number of hops for all the TE LSPs -- This is the largest number of hops that any TE LSP can have. Note that this constraint can also be provided on a per-TE-LSP basis (as requested in [RFC4657] and defined in [RFC5440]).
*すべてのTEのLSPの最大ホップ数は - これは、任意のTE LSPを持つことができるホップの最大数です。この制約はまた当たり-TE-LSPに基づいて提供することができることに留意されたい（[RFC4657]で要求されるように定義された[RFC5440]）。
* Exclusion of links/nodes in all TE LSP path computation (i.e., all TE LSPs should not include the specified links/nodes in their paths). Note that this constraint can also be provided on a per-TE-LSP basis (as requested in [RFC4657] and defined in [RFC5440]).
*すべてのTE LSPの経路計算のリンク/ノード（すなわち、すべてのTEのLSPは、そのパス内の指定されたリンク/ノードを含むべきではない）の排除。この制約はまた当たり-TE-LSPに基づいて提供することができることに留意されたい（[RFC4657]で要求されるように定義された[RFC5440]）。
* An indication should be available in a path computation response that further reoptimization may only become available once existing traffic has been moved to the new TE LSPs.
*表示は、さらに再最適化は一度だけ、既存のトラフィックが新しいTEのLSPのに移動された利用可能になることが経路計算応答で利用可能であるべきです。
o A Global Concurrent Vector (GCV) field in which to specify all the individual path computation requests that are subject to concurrent path computation and subject to the global objective function and all of the global constraints. Note that this requirement is entirely fulfilled by the SVEC object in the PCEP specification [RFC5440]. Since the SVEC object as defined in [RFC5440] allows identifying a set of concurrent path requests, the SVEC can be reused to specify all the individual concurrent path requests for a global concurrent optimization.
Oグローバル同時ベクター（GCV）フィールドは、並行経路計算及びグローバル目的関数の対象とグローバル制約の全ての対象となるすべての個々の経路計算要求を指定します。この要件は完全PCEP仕様[RFC5440]でSVECオブジェクトによって満たされることに留意されたいです。 [RFC5440]で定義されるようSVECオブジェクトが並行パス要求のセットを識別できるので、SVECグローバル同時最適化のためのすべての個々の並行パス要求を指定するために再利用することができます。
o An indicator field in which to indicate the outcome of the request. When the PCE cannot find a feasible solution with the initial request, the reason for failure SHOULD be indicated. This requirement is partially covered by [RFC4657], but not in this level of detail. The following indicators SHOULD be supported at the minimum:
Oにおけるインジケータフィールドは、リクエストの結果を示します。 PCEは、最初の要求で実現可能な解決策を見つけることができない場合は、失敗の理由を示すべきです。この要件は、部分的にではなく、このレベルの詳細で、[RFC4657]で覆われています。以下の指標は最低でサポートする必要があります。
* no feasible solution found. Note that this is already covered in [RFC5440].
*何も実現可能な解決策が見つかりませんでした。これはすでに[RFC5440]でカバーされることに注意してください。
* memory overflow.
*メモリ・オーバーフロー。
* PCE too busy. Note that this is already covered in [RFC5440].
* PCEあまりにも忙しいです。これはすでに[RFC5440]でカバーされることに注意してください。
* PCE not capable of concurrent reoptimization.
*同時再最適化することはできないPCE。
* no migration path available.
*利用できるノー移行パス。
* administrative privileges do not allow global reoptimization.
*管理者権限は、グローバル再最適化を許可していません。
o In order to minimize disruption associated with bulk path provisioning, the following requirements MUST be supported:
Oバルクパスプロビジョニングに関連した混乱を最小限にするために、次の要件をサポートしなければなりません。
* The request message MUST allow requesting the PCE to provide the order in which TE LSPs should be reoptimized (i.e., the migration path) in order to minimize traffic disruption during the migration. That is, the request message MUST allow indicating to the PCE that the set of paths that will be provided in the response message (PCRep) has to be ordered.
*要求メッセージは、TE LSPの移行中にトラフィックの中断を最小限にするために（すなわち、移動経路）再最適化されるべき順序を提供するPCEを要求できるようにしなければなりません。つまり、要求メッセージは、応答メッセージ（PCRep）で提供されるパスのセットを注文しなければならないPCEに示す許容しなければなりません。
* In response to the "ordering" request from the PCC, the PCE MUST be able to indicate in the response message (PCRep) the order in which TE LSPs should be reoptimized so as to minimize traffic disruption. It should indicate for each request the order in which the old TE LSP should be removed and the order in which the new TE LSP should be setup. If the removal order is lower than the setup order, this means that make-before-break cannot be done for this request. It MAY also be desirable to have the PCE indicate whether ordering is in fact required or not.
* PCCから「発注」要求に応答して、PCEは、応答メッセージ（PCRep）トラフィックの中断を最小限に抑えるようにTEのLSPを再最適化されるべき順序で示すことができなければなりません。これは、各要求古いTE LSPを削除する順序と新しいTE LSPがセットアップされる順序のために示すべきです。取り外し順序は、セットアップの順序よりも低い場合、これはメイク・ビフォア・ブレークがこの要求に対して行うことができないことを意味します。また、順序が実際に必要であるか否かを示すPCEを有することが望ましいです。
* During a migration, it may not be possible to do a make-before-break for all existing TE LSPs. The request message MUST allow indicating for each request whether make-before-break is required (e.g., voice traffic) or break-before-make is acceptable (e.g., Internet traffic). The response message must allow indicating TE LSPs for which make-before-break reoptimization is not possible (this will be deduced from the TE LSP setup and deletion orders).
*移行中に、すべての既存のTE LSPのためのメイク・ビフォア・ブレークを行うことは可能ではないかもしれません。要求メッセージは、要求ごとにメークビフォアブレークが必要である（例えば、音声トラフィック）かどうかを示す許可またはブレーク・ビフォア・メークをしなければならない（例えば、インターネットトラフィック）許容可能です。再最適化・ビフォア・ブレークを作るTE LSPを示すことができなければならないため、応答メッセージは、（これはTE LSPのセットアップと削除受注から推定される）ことはできません。
This section provides protocol extensions for support of global concurrent optimization. Protocol extensions discussed in this section are built on [RFC5440].
このセクションでは、世界的な同時最適化のサポートのためのプロトコルの拡張機能を提供します。このセクションで説明するプロトコル拡張は、[RFC5440]の上に構築されています。
The format of a PCReq message after incorporating new requirements for support of global concurrent optimization is as follows. The message format uses Reduced Backus-Naur Format as defined in [RFC5511]. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license.
次のように世界的な同時最適化のサポートのための新たな要件を取り入れた後PCReqメッセージのフォーマットがあります。 [RFC5511]で定義されるメッセージフォーマットを低減バッカス正規形式を使用します。このドキュメントおよび必要なコードのライセンスに定義されてRBNF断片のフルセットについては、付録Aを参照してください。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
The <svec-list> is changed as follows:
次のように<SVEC-list>は変更されます。
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]
Note that three optional objects are added, following the SVEC object: the OF (Objective Function) object, which is defined in [RFC5541], the GC (Global Constraints) object, which is defined in this document (Section 5.5), as well as the eXclude Route Object (XRO), which is defined in [RFC5521]. The placement of the OF object (in which the global objective function is specified) in the SVEC-list is defined in [RFC5541]. Details of this change will be discussed in the following sections.
[RFC5541]で定義されているOF（目的関数）オブジェクト、このドキュメント（セクション5.5）で定義されているGC（グローバル制約）オブジェクトを、同様に：SVECオブジェクト以下、3つのオプションのオブジェクトが追加されることに注意してください[RFC5521]で定義されている除外しルートオブジェクト（XRO）、など。 SVECリストに（グローバル目的関数が指定された）オブジェクトのの配置は[RFC5541]で定義されています。この変更の詳細については、次のセクションで説明します。
Note also that when the XRO is global to an SVEC, and F-bit is set, it SHOULD be allowed to specify multiple Record Route Objects in the PCReq message.
XROがSVECにグローバルであり、Fビットが設定されている場合、複数のレコードルートがPCReqメッセージ内のオブジェクトを指定することが許容されるべきであることにも留意されたいです。
The global objective function can be specified in the PCEP Objective Function (OF) object, defined in [RFC5541]. The OF object includes a 16-bit Objective Function identifier. As discussed in [RFC5541], Objective Function identifier code points are managed by IANA.
グローバル目的関数は、[RFC5541]で定義され、PCEP目的関数（OF）オブジェクトに指定することができます。オブジェクトの16ビット目的関数識別子を含みます。 [RFC5541]で説明したように、目的関数識別子コードポイントはIANAによって管理されています。
Three global objective functions defined in [RFC5541] are used in the context of GCO.
[RFC5541]で定義された3つのグローバル目的関数は、GCOの文脈で使用されます。
Function Code Description
機能コード説明
4 Minimize aggregate Bandwidth Consumption (MBC)
4（MBC）の総帯域幅消費を最小
5 Minimize the load of the Most Loaded Link (MLL)*
5 *ほとんどのロードされたリンク（MLL）の負荷を最小限に抑えます
6 Minimize the Cumulative Cost of a set of paths (MCC)
6パス（MCC）のセットの累積コストを最小限に抑えます
* Note: This can be achieved by the following objective function: minimize max over all links {A(i)/C(i)} where C(i) is the link capacity for link i, and A(i) is the total bandwidth allocated on link i.
*注：これは、以下の目的関数によって達成することができる：I、及び（i）は、合計である全てのリンク{（I）/ C（I）} C（i）がリンクのリンク容量がある上maxは最小帯域幅は、私がリンクに割り当てられました。
All the path requests in this application should be indicated so that the global objective function and all of the global constraints are applied to each of the requested path computation. This can be indicated implicitly by placing the GCO related objects (OF, GC, or XRO) after the SVEC object. That is, if any of these objects follows the SVEC object in the PCReq message, all of the requested path computations specified in the SVEC object are subject to OF, GC, or XRO.
グローバル目的関数とグローバル制約のすべてが要求された経路計算のそれぞれに適用されるように、このアプリケーションのすべてのパスの要求が示されなければなりません。これはSVECオブジェクト後（OF、GC、またはXRO）GCO関連オブジェクトを配置することによって暗黙的に示すことができます。すなわち、これらのオブジェクトのいずれかがPCReqメッセージ内SVECオブジェクトに従う場合、SVECオブジェクトで指定された要求された経路計算のすべてがGC、またはXROの対象とされています。
In order to minimize disruption associated with bulk path provisioning, the PCC may indicate to the PCE that the response MUST be ordered. That is, the PCE has to include the order in which TE LSPs MUST be moved so as to minimize traffic disruption. To support such indication a new flag, the D flag, is defined in the RP object as follows:
バルクパスプロビジョニングに関連した混乱を最小限に抑えるために、PCCは、応答が順序付けされなければならないPCEに示すことができます。すなわち、PCEは、トラフィックの中断を最小限に抑えるようにTEのLSPが移動しなければならない順序を含むように有しています。以下のような指示を新しいフラグ、Dフラグをサポートするために、RPオブジェクトに定義されています。
D-bit (orDer - 1 bit): when set, in a PCReq message, the requesting PCC requires the PCE to specify in the PCRep message the order in which this particular path request is to be provisioned relative to other requests.
Dビット（注文 - 1ビット）：セットは、PCReqメッセージに、要求PCCはPCRepメッセージのこの特定の経路要求が他の要求に対してプロビジョニングされる順序で指定するPCEを必要とします。
To support the determination of whether make-before-break optimization is required, a new flag, the M flag, is defined in the RP object as follows.
次のようにメイク・ビフォア・ブレーク最適化が必要とされているかどうかの決意、新しいフラグ、Mフラグをサポートするために、RPオブジェクトに定義されています。
M-bit (Make-before-break - 1 bit): when set, this indicates that a make-before-break reoptimization is required for this request.
Mビット（メイク前にブレーク - 1ビット）：セットには、これはメイク・ビフォア・ブレーク再最適化は、この要求のために必要であることを示しています。
When the M-bit is not set, this implies that a break-before-make reoptimization is allowed for this request. Note that the M-bit can be set only if the R (Reoptimization) flag is set.
Mビットが設定されていない場合、これはブレーク・ビフォア・メーク再最適化は、この要求のために許可されていることを意味します。 MビットのR（再最適化）フラグが設定されている場合にのみ設定することができます。
Two new bit flags are defined to be carried in the Flags field in the RP object.
二つの新しいビットフラグは、RPオブジェクトのFlagsフィールドで運ばれるように定義されています。
Bit 21 (M-bit): When set, make-before-break is required. Bit 22 (D-bit): When set, report of the request order is required.
ビット21（Mビット）：セット、メイクの前にブレークが必要です。ビット22（Dビット）：セット、要求の順序の報告が必要です。
The PCE MUST specify the order number in response to the Order Request made by the PCC in the PCReq message if so requested by the setting of the D-bit in the RP object in the PCReq message. To support such an ordering indication, a new optional TLV, the Order TLV, is defined in the RP object.
そうPCReqメッセージ内RPオブジェクト内のDビットの設定によって要求された場合PCEはPCReqメッセージにPCC製注文要求に応じて注文番号を指定する必要があります。そのような順序表示をサポートするために、新しいオプションTLV、注文TLVは、RPオブジェクトに定義されています。
The Order TLV is an optional TLV in the RP object, that indicates the order in which the old TE LSP must be removed and the new TE LSP must be setup during a reoptimization. It is carried in the PCRep message in response to a reoptimization request.
注文TLVは古いTE LSPを削除する必要がありますし、新しいTE LSPが再最適化時に設定する必要があります順序を示しRPオブジェクト内の任意のTLVです。これは、再最適化要求に応答してPCRepメッセージで運ばれます。
The Order TLV MUST be included in the RP object in the PCRep message if the D-bit is set in the RP object in the PCReq message.
DビットをPCReqメッセージにRPオブジェクトに設定されている場合、注文TLVはPCRepメッセージにRPオブジェクトに含まれなければなりません。
The format of the Order TLV is as follows:
次のように注文TLVの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delete Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Order TLV in the RP Object in the PCRep Message
図2：PCRepメッセージ内のRPオブジェクトで注文TLV
Type: 5 Length: Variable
種類：5長さ：可変
Delete Order: 32-bit integer that indicates the order in which the old TE LSP should be removed.
古いTE LSPが除去されるべき順序を示す32ビット整数：注文を削除します。
Setup Order: 32-bit integer that indicates the order in which the new TE LSP should be setup.
セットアップ順序：新しいTE LSPを設定する順序を示す32ビット整数。
The delete order SHOULD NOT be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner.
削除順序は、セットアップ順に等しくすべきではありません。削除順序は、セットアップの順序よりも高い場合、これは再最適化は、メイク・ビフォア・ブレーク方式で行うことができることを意味し、そうでなければ、メイク・ビフォア・ブレーク方式で行うことはできません。
For a new TE LSP, the delete order is not applicable. The value 0 is designated to specify this case. When the value of the delete order is 0, it implies that the resulting TE LSP is a new TE LSP.
新しいTE LSPのために、削除順序は適用されません。値0は、このケースを指定するために指定されています。削除順序の値が0である場合、それは結果として得られるTE LSPは、新しいTE LSPであることを意味します。
To illustrate this, consider a network with two established TE LSPs: R1 with path P1, and R2 with path P2. During a reoptimization, the PCE may provide the following ordered reply:
パスP2のパスP1にR1、及びR2：これを説明するために、確立された2つのTE LSPを有するネットワークを考えます。再最適化の際、PCEは、次の順序の回答を提供することができます。
R1, path P1', remove order 1, setup order 4 R2, path P2', remove order 3, setup order 2
R1、パスP1' 、取り除くため1、セットアップ順序4 R2、パスP2' 、取り除くため3、セットアップ注文2
This indicates that the NMS should do the following sequence of tasks:
これは、NMSは、タスクの次の一連の操作を行う必要があることを示します。
1: Remove path P1 2: Set up path P2' 3: Remove path P2 4: Set up path P1'
1：設定パスP2' 3：パスを削除P2 4：設定パスP1' パスP1 2を削除
That is, R1 is reoptimized in a break-before-make manner and R2 in a make-before-break manner.
これは、R1は、メイク・ビフォア・ブレーク方式でブレーク・ビフォア・メークの方法及びR2で再最適化されています。
The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to specify the necessary global constraints that should be applied to all individual path computations for a global concurrent path optimization request.
GLOBAL CONSTRAINTS（GC）オブジェクトは、グローバル同時経路最適化要求の全ての個々の経路の計算に適用されるべき必要なグローバル制約を指定するPCReqメッセージで使用されています。
GLOBAL-CONSTRAINTS Object-Class is 24.
GLOBAL-CONSTRAINTSは、オブジェクト・クラスは24です。
Global Constraints Object-Type is 1.
グローバル制約は、オブジェクト・タイプは1です。
The format of the GC object body that includes the global constraints is as follows:
次のようにグローバルな制約を含んGCオブジェクト本体の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MH | MU | mU | OB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GC Body Object Format
図3：GC本体のオブジェクトフォーマット
MH (Max Hop: 8 bits): 8-bit integer that indicates the maximum hop count for all the TE LSPs.
MH（最大ホップ：8ビット）：すべてのTEのLSPの最大ホップカウントを示す8ビット整数。
MU (Max Utilization Percentage: 8 bits) : 8-bit integer that indicates the upper-bound utilization percentage by which all links should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity. MU is intended to be an integer that can only be between 0 and 100.
MU（最大利用率：8ビット）：すべてのリンクが結合されるべきことで上限使用率を示す8ビット整数。利用=（リンク容量 - リンク上の割り当てられた帯域幅）/リンク容量。 MUのみ0と100の間であることができる整数であることが意図されています。
mU (minimum Utilization Percentage: 8 bits) : 8-bit integer that indicates the lower-bound utilization percentage by which all links should be bound. mU is intended to be an integer that can only be between 0 and 100.
ミュー（最小使用率：8ビット）：すべてのリンクが結合されるべきことで下限利用率を示す8ビット整数。 mUをのみ0と100の間であることができる整数であることが意図されています。
OB (Over Booking factor Percentage: 8 bits) : 8-bit integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. The value, for example, 10% means that 110 Mbps can be reserved on a 100 Mbps link.
（8ビット率パーセントを予約オーバー）：OB予約帯域が物理容量の限界を超えて各リンク上でオーバーブッキングされることを可能にするオーバーブッキング割合を示す8ビット整数。値は、例えば、10％が110 Mbpsのが100Mbpsのリンク上で予約することができることを意味します。
The exclusion of the list of nodes/links from a global path computation can be done by including the XRO object following the GC object in the new SVEC-list definition.
グローバル経路計算からノード/リンクのリストの除外は、新しいSVECリスト定義のGCオブジェクト以下XROオブジェクトを含めることによって行うことができます。
Optional TLVs may be included within the GC object body to specify additional global constraints. The TLV format and processing is consistent with Section 7.1 of RFC 5440. Any TLVs will be allocated from the "PCEP TLV Type Indicators" registry. Note that no TLVs are defined in this document.
オプションのTLVは、追加のグローバルな制約を指定するには、GCのオブジェクト本体内に含めることができます。 TLVフォーマット処理は、任意のTLVが「PCEP TLVタイプインジケータ」レジストリから割り当てられるRFC 5440の7.1節と一致しています。何のTLVは、この文書で定義されていないことに注意してください。
To indicate errors associated with the global concurrent path optimization request, a new Error-Type (14) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR Object:
PCEP-ERRORオブジェクトに含めるために、以下のようにグローバル並行経路最適化要求に関連するエラーを示すために、新しいエラータイプ（14）とそれに続くエラー値が定義されています。
A new Error-Type (15) and subsequent error-values are defined as follows:
次のように新しいエラータイプ（15）とそれに続くエラー値が定義されています。
Error-Type=15; Error-value=1: if a PCE receives a global concurrent path optimization request and the PCE is not capable of processing the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=15) and an Error-value (Error-value=1). The PCE stops processing the request. The corresponding global concurrent path optimization request MUST be cancelled at the PCC.
エラー・タイプ= 15;エラー値= 1：PCEはグローバル並行経路最適化要求を受信し、PCEは、メモリ不足のため、要求を処理できない場合、PCEは、PCEP-ERRORオブジェクトとPCErrメッセージを送らなければなりません（エラータイプ= 15 ）とエラー値（エラー値= 1）。 PCEは、要求の処理を停止します。対応するグローバル同時経路最適化要求は、PCCでキャンセルしなければなりません。
Error-Type=15; Error-value=2: if a PCE receives a global concurrent path optimization request and the PCE is not capable of global concurrent optimization, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=15) and an Error-value (Error-value=2).
エラー・タイプ= 15;エラー値= 2：PCEはグローバル並行経路最適化要求を受信し、PCEは、グローバル同時最適化しないことが可能である場合、PCEは、PCEP-ERRORオブジェクトとPCErrメッセージを送らなければなりません（エラータイプ= 15）とエラー - 値（エラー値= 2）。
The PCE stops processing the request. The corresponding global concurrent path optimization MUST be cancelled at the PCC.
PCEは、要求の処理を停止します。対応するグローバル同時パスの最適化は、PCCでキャンセルしなければなりません。
To indicate an error associated with policy violation, a new error value "global concurrent optimization not allowed" should be added to an existing error code for policy violation (Error-Type=5) as defined in [RFC5440].
ポリシー違反に関連するエラーを示すために、新しいエラー値「許可しないグローバル同時最適化」は、[RFC5440]で定義されるようにポリシー違反（エラータイプ= 5）のための既存のエラーコードに追加されるべきです。
Error-Type=5; Error-value=5: if a PCE receives a global concurrent path optimization request that is not compliant with administrative privileges (i.e., the PCE policy does not support global concurrent optimization), the PCE sends a PCErr message with a PCEP-ERROR Object (Error-Type=5) and an Error-value (Error-value=5). The PCE stops the processing the request. The corresponding global concurrent path computation MUST be cancelled at the PCC.
エラー・タイプ= 5;エラー値は= 5：PCEは（すなわち、PCEポリシーはグローバル同時最適化をサポートしていません）管理者権限に準拠していないグローバル同時経路最適化要求を受信した場合、PCEは、（PCEP-ErrorオブジェクトにPCErrメッセージを送信しますエラータイプ= 5）とエラー値（誤差値= 5）。 PCEは、処理に要求を停止します。対応するグローバル並行経路計算はPCCでキャンセルされなければなりません。
To communicate the reason(s) for not being able to find global concurrent path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is defined in [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed.
グローバル並行経路計算を見つけることができない理由（複数可）を通信するために、NO-PATHオブジェクトはPCRepメッセージに使用することができます。 NO-PATH対象体の形式は、[RFC5440]で定義されています。対象は、経路計算が失敗した理由に関する追加情報を提供するために、NO-PATH-VECTOR TLVが含まれていてもよいです。
Two new bit flags are defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object.
二つの新しいビットフラグは、NO-PATHオブジェクトで運ばNO-PATH-VECTOR TLVでFlagsフィールドで運ばれるように定義されています。
Bit 6: When set, the PCE indicates that no migration path was found.
ビット6：設定すると、PCEには移行パスが見つからなかったことを示しています。
Bit 7: When set, the PCE indicates no feasible solution was found that meets all the constraints associated with global concurrent path optimization in the PCRep message.
ビット7：設定すると、PCEには実現可能な解決策がPCRepメッセージのグローバル同時パスの最適化に関連付けられているすべての制約を満たす見つからなかったことを示します。
Manageability of global concurrent path computation with PCE must address the following considerations:
次の考慮事項に対処しなければならないPCEを持つグローバル同時経路計算の管理性：
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCC:
すでに[RFC5440]のセクション8.1に記載されているパラメータに加えて、PCEP実装はPCCで次PCEPセッションパラメータを設定可能にすべきです。
o The ability to send a GCO request.
GCO要求を送信する機能、O。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCE:
すでに[RFC5440]のセクション8.1に記載されているパラメータに加えて、PCEP実装はPCEに以下PCEPセッションパラメータを設定可能にすべきです。
o The support for Global Concurrent Optimization.
グローバル同時最適化のためのサポート、O。
o The maximum number of synchronized path requests per request message.
O同期パスの最大数は、要求メッセージごとに要求します。
o A set of GCO specific policies (authorized sender, request rate limiter, etc.).
O GCO特定のポリシー（承認送信者、要求レートリミッタなど）のセット。
These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers.
これらのパラメータは、PCEPスピーカーが参加する、または所与PCEPピアまたはピアPCEPの特定のグループとのセッションの特定のグループと特定のセッションに適用することができる任意のPCEPセッションのデフォルトパラメータとして構成されてもよいです。
Extensions to the PCEP MIB module defined in [PCEP-MIB] should be defined, so as to cover the GCO information introduced in this document.
この文書で導入GCO情報を覆うようにPCEP-MIB]で定義PCEP MIBモジュールへの拡張は、定義されるべきです。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in Section 8.3 of [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]のセクション8.3に記載されているものに加えて、新たな生存性の検出と監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new verification requirements in addition to those already listed in Section 8.4 of [RFC5440]
この文書で定義されたメカニズムは、すでに[RFC5440]のセクション8.4に記載されたものに加えて、新たな検証の要件を意味するものではありません。
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) may be used to advertise global concurrent path computation capabilities to PCCs. A new flag (value=9) in PCE-CAP-FLAGs Sub-TLV has been assigned to be able to indicate GCO capability.
PCEディスカバリメカニズム（[RFC5088]及び[RFC5089]）はのPCCにグローバル並行経路計算機能をアドバタイズするために使用することができます。新しいフラグ（値= 9）PCE-CAP-フラグサブTLVは、GCO能力を示すことができるように割り当てられています。
Mechanisms defined in this document do not imply any new network operation requirements in addition to those already listed in Section 8.6 of [RFC5440].
この文書で定義されたメカニズムは、すでに[RFC5440]のセクション8.6に記載されているものに加えて、新たなネットワーク運用の要件を意味するものではありません。
When global reoptimization is applied to an active network, it could be extremely disruptive. Although the real security and policy issues apply at the NMS, if the wrong results are returned to the NMS, the wrong actions may be taken in the network. Therefore, it is very important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy.
グローバル再最適化がアクティブなネットワークに適用されると、それは非常に破壊的である可能性があります。実際のセキュリティおよびポリシーの問題がNMSに適用されますが、誤った結果がNMSに返送された場合、間違った行動は、ネットワーク内で取ることができます。したがって、コマンドを発行し、オペレータが十分な権限を持っていると認証され、計算要求は、適切なポリシーが適用されていることが非常に重要です。
The mechanism defined in [RFC5440] to secure a PCEP session can be used to secure global concurrent path computation requests/responses.
PCEPセッションを確保するために、[RFC5440]で定義されたメカニズムは、グローバル同時経路計算要求/応答を保護するために使用することができます。
IANA maintains a registry of PCEP parameters. IANA has made allocations from the sub-registries as described in the following sections.
IANAは、PCEPパラメータのレジストリを維持します。次のセクションで説明したようにIANAは、サブレジストリから割り当てを行っています。
As described in Section 5.3, two new bit flags are defined for inclusion in the Flags field of the RP object. IANA has made the following allocations from the "RP Object Flag Field" sub-registry.
セクション5.3で説明したように、二つの新しいビットフラグは、RPオブジェクトのFlagsフィールドに含めるために定義されています。 IANAは、「RPオブジェクトフラグ・フィールド」のサブレジストリから以下の配分を行っています。
Bit Description Reference
ビット説明リファレンス
21 Make-before-break (M-bit) [RFC5557] 22 Report the request order (D-bit) [RFC5557]
21メイク・ビフォア・ブレーク（Mビット）[RFC5557] 22報告要求順序（Dビット）[RFC5557]
As described in Section 5.4, a new PCEP TLV is defined to indicate the setup and delete order of TE LSPs in a GCO. IANA has made the following allocation from the "PCEP TLV Type Indicators" sub-registry.
5.4節で述べたように、新しいPCEP TLVは、セットアップを示し、GCOにTE LSPの順序を削除するために定義されています。 IANAは「PCEP TLVタイプインジケータ」サブレジストリから以下の割り当てを行っています。
TLV Type Meaning Reference
TLVタイプの意味リファレンス
5 Order TLV [RFC5557]
5注文TLV [RFC5557]
As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV is defined to indicate a GCO capability. IANA has made the following allocation from the "Path Computation Element (PCE) Capability Flags" sub-registry, which was created by Section 7.2 of RFC 5088. It is an OSPF registry.
セクション6.5で説明したように、新たなPCE-CAP-FLAGSサブTLVは、GCO能力を示すために定義されています。 IANAはRFC 5088.それはOSPFレジストリでのセクション7.2で作成された「パス計算要素（PCE）能力フラグ」サブレジストリから以下の割り当てを行っています。
FLAG Meaning Reference
リファレンスを意味FLAG
9 Global Concurrent Optimization (GCO) [RFC5557]
9グローバル同時最適化（GCO）[RFC5557]
As descried in Section 5.5, a new PCEP object is defined to carry global constraints. IANA has made the following allocation from the "PCEP Objects" sub-registry.
5.5節でdescriedとして、新しいPCEPオブジェクトは、グローバルな制約を運ぶために定義されています。 IANAは「PCEPオブジェクト」サブレジストリから以下の割り当てを行っています。
Object Name Reference Class
名前参照クラスオブジェクト
24 GLOBAL-CONSTRAINTS [RFC5557] Object-Type 1: Global Constraints [RFC5557]
24グローバルCONSTRAINTS [RFC5557]オブジェクトタイプ1：グローバル制約[RFC5557]
As described in Section 5.6, new PCEP error codes are defined for GCO errors. IANA has made allocations from the "PCEP-ERROR Object Error Types and Values" sub-registry as set out in the following sections.
5.6節で述べたように、新しいPCEPエラーコードがGCOエラーのために定義されています。 IANAは、「PCEP-ERRORオブジェクト・エラーの種類と値」以下のセクションに記載されたように、サブレジストリから割り当てを行っています。
Error-
Type Meaning Reference
5 Policy violation Error-value=5: [RFC5557] Global concurrent optimization not allowed
5ポリシー違反のエラー値= 5：許可されていません[RFC5557]グローバル同時最適化
Error-
Type Meaning Reference
15 Global Concurrent Optimization Error [RFC5557] Error-value=1: Insufficient memory [RFC5557] Error-value=2: Global concurrent optimization not supported [RFC5557]
15グローバル同時最適化エラー[RFC5557]エラー値= 1：メモリ不足[RFC5557]エラー値= 2：グローバル同時最適化がサポートされていない[RFC5557]
IANA has made the following allocations from the "NO-PATH-VECTOR TLV Flag Field" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV in the PCEP NO-PATH object as described in Section 5.7.
IANAはセクション5.7で説明したようにPCEP NOパスオブジェクトにNO-PATHベクターTLVで搬送されるビットフラグは、「NO-PATHベクターTLVフラグ・フィールド」サブレジストリから次の割り当てを行っています。
Bit Number Name Reference
ビット数名リファレンス
25 No GCO solution found [RFC5557] 26 No GCO migration path found [RFC5557]
25いいえGCO溶液が見つかった[RFC5557] 26なしGCOの移行パスが見つかりました[RFC5557]
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)", RFC 5541, May 2009.
[RFC5541]ル・ルー、JL。、Vasseur、JP。、およびY.リー、RFC 5541、2009年5月 "パス計算要素通信プロトコル（PCEP）における目的関数のエンコーディング"。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
[RFC5521]沖、E.、武田、T.、およびA.ファレル、 "ルートの除外のためにパス計算要素通信プロトコル（PCEP）への拡張"、RFC 5521、2009年4月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., 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., Ed., Vasseur, JP., Ed., 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、1月2008。
[PCE-MLN] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", Work in Progress, March 2009.
[PCE-MLN]沖、E.、武田、T.、ル・ルー、JL。、およびA.ファレル、 "PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのための枠組み"、進歩、2009年3月に作業。
[PCEP-MIB] Koushik, K. and E. Stephan, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB]コウシク、K.およびE.ステファン、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2008年11月に働いています。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]ファレル、A.、「ルーティングバッカス記法（RBNF）：さまざまなルーティングプロトコル仕様に符号化規則を形成するのに使用される構文」を2009年4月、RFC 5511を。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコルジェネリック要件"、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]ル・ルー、J.、エド。、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212] Shiomoto、K.、Papadimitriou、D.、ルルー、JL。、Vigoureux、M.、およびD. Brungard、 "GMPLSベースのマルチリージョンとマルチレイヤネットワーク（MRN / MLN）の要件"、 RFC 5212、2008年7月。
We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So, Lucy Yong, and Fabien Verhaeghe for their useful comments and suggestions.
私たちは、彼らの役に立つコメントと提案のためにジェリー・アッシュ、エードリアンファレル、J-P Vasseur、寧ので、ルーシー・ヨンジュン、およびファビアンVerhaegheに感謝したいと思います。
Appendix A. RBNF Code Fragments
付録A. RBNFコードフラグメント
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは、著作権保持者と貢献者に制限された状態で提供し、特定目的に対する適合性の黙示の保証も行われません。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]
Authors' Addresses
著者のアドレス
Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US
ヤング・リーHuawei社1700アルマドライブ、スイート100プラノ、TX 75075米国
Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 EMail: ylee@huawei.com
電話：+1 972 509 5599 x2240ファックス：+1 469 229 5397 Eメール：ylee@huawei.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
Daniel King Old Dog Consulting United Kingdom
ダニエル・キング老犬のコンサルティングイギリス
EMail: daniel@olddog.co.uk
メールアドレス：daniel@olddog.co.uk
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
えいじ おき うにゔぇｒしｔｙ おｆ えぇｃｔろーこっむにかちおんｓ １ー５ー１ ちょふがおか ちょふ、 ときょ １８２ー８５８５ じゃぱん
EMail: oki@ice.uec.ac.jp
メールアドレス：oki@ice.uec.ac.jp