[要約] RFC 5557は、グローバルな同時最適化をサポートするためのPath Computation Element Communication Protocol（PCEP）の要件とプロトコル拡張に関するものです。このRFCの目的は、ネットワークの経路計算を効率化し、ネットワークの最適化を実現することです。
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.
PATH計算要素通信プロトコル（PCEP）により、PATH計算クライアント（PCCS）がパス計算要素（PCES）からパス計算を要求し、PCSが応答を返すことができます。ネットワークを介してトラフィックエンジニアリングラベルのスイッチパス（TE LSP）のセットのルートを計算または再最適化する場合、問題のブロックを避け、より最適なネットワーク全体のソリューションを実現するために、バルクパス計算を実行することが有利かもしれません。このようなバルク最適化は、グローバルな同時最適化（GCO）と呼ばれます。GCOは、ネットワークのトポロジ全体と既存のTE LSPの完全なセット、およびそれぞれの制約の完全なセットを同時に考慮し、すべてのTELSPのすべての制約を満たすためにネットワーク全体を最適化または再型にすることを検討することができます。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.
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としての出版または英語以外の言語に翻訳する。
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）ベースのアーキテクチャを定義し、パスの要求でマルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）および一般化されたMPLS（GMPLS）ネットワークでPCEがラベルスイッチングパス（LSP）を計算する方法を説明します。計算クライアント（PCCS）。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サーバーベースのソリューションです。GCOアプリケーションに関連する複雑な同期の問題により、[RFC4655]のセクション5.5で定義されている管理ベースのPCEアーキテクチャは、GCOアプリケーションをサポートするための最も適切な使用と見なされます。これは、GCOアプリケーションをサポートするために他の建築的代替案を排除するものではありませんが、推奨されません。たとえば、GCOは、複雑な同期メカニズムを介して分散LSRによって有効になる場合があります。ただし、このアプローチは、PCEと各PCCSの間の重大な同期オーバーヘッドに悩まされる可能性があります。それはおそらくネットワークの安定性に影響を与える可能性があり、したがって、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を確立する必要がある場合、グローバルな同時パス計算の必要性も発生する可能性があります。また、ネットワークオペレーターは、壊滅的なネットワーク障害が発生した場合にグローバルな同時パス計算を必要とする可能性があることも想定されています。この作業の性質は、オフライン処理のためにそのようなシステムの使用を促進します。この作業のオンラインアプリケーションは、実証済みの経験的検証でのみ考慮する必要があります。
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の完全なセットとそれぞれの制約を同時に考慮し、ネットワーク全体を再最適化して、すべてのTELSPのすべての制約を満たすことができます。あるいは、アプリケーションでは、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.
後方再帰パス計算（BRPC）[RFC5441]は、最短の制約付きドメイン間パスを計算するために使用されるマルチPCEパス計算手法であるのに対し、このIDはパス計算要求のセットがバンドルされる技術を指定することに注意してください。計算されたパスのセットを「最適化」する目的で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は、PCCからPCCへのパス計算要求を通信し、PCEからPCCに計算されたパスを返すために使用されるプロトコルの一般的な抽象的なアイデアです。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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
図1は、GCOアプリケーションが適用される[RFC4655]で定義されているPCEベースのネットワークアーキテクチャを示しています。PCCは必ずしもLSR [RFC4655]ではないことを観察する必要があります。GCOアプリケーションは、主にNMSベースのソリューションであり、NMSがPCCの機能を再生します。図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
図1：グローバルな同時最適化のためのPCEベースのアーキテクチャ
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.
Greenfield Optimizationは、ネットワークに既に設定されているTE LSPがない場合のGCOアプリケーションの特別なケースです。Greenfieldの最適化の必要性は、ネットワークプランナーが計算サーバーを利用して、ネットワークでプロビジョニングされるTE LSPを計画したい場合に生じます。グリーンフィールドの操作は1回限りの最適化であることに注意してください。障害やその他の変更によりネットワークの条件が変化すると、再最適化の動作モードが始まります。
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.
Greenfieldの観点から新しい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を考慮せずに、1つのTE LSPの再最適化されたパスを一度に1つのTE LSPの再最適化されたパスを計算するパス計算方法を指します。TE LSPの再最適化によるネットワーク全体の利益の可能性は、最適化されているTE LSPのネットワークの使用とサイズに依存します。ただし、重要なポイントは次のとおりです。ネットワーク内の他のTE LSPを考慮せずに、1つの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の適用性に関して、ヘッドエンドLSRからの新しいパスを分散した方法で計算するのではなく、TE LSPのパスをセットとして計算することには本当の利点があるかもしれません。分散ジッタリングは、分散計算で人種状態（つまり、異なるヘッドエンド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]の再構成は、グローバルな同時パス計算が適用できる典型的なアプリケーションシナリオです。トラフィック需要の変更、ネットワーク障害、トポロジ構成の変更など、VNT再構成のトリガーでは、既存のTE LSPのセットを再計算する必要があります。
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 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.
1セットのTE LSPから再最適化されたTE LSPのセットに移行する場合、混乱を引き起こすことなくトラフィックを移動することが重要です。古いTe LSPを破壊する前に新しいTe LSPを確立するために、Make-Be-Bebreak-Bebree-Break [RFC3209]などのMPLやGMPLにはさまざまな手法が存在します。計算された結果に従って複数のTE LSPルートが変更されると、リソースの制約のためにTE LSPの一部が破壊される可能性があります。言い換えれば、古いTE LSPからトラフィックを破壊することなく、古いTE LSPから新しい最適なTE LSPへの直接移行を実行することは不可能であることが証明される場合があります。。ただし、PCEは、個々の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に移行するために、あらゆる順序でブレイクする前に適用することができないことを意味する可能性があります。この場合、完全な再最適化のためのスペースを作るために、一時的なパスに出場する前にlspsを再ルーティングする必要がある移行戦略が必要です。PCEは、再最適化されたTE LSPを確立し、古いTe LSPから引き継ぐ必要がある順序を示している可能性があり、使用する必要がある一連の異なる一時的なパスを示している可能性があります。あるいは、PCEは、TE LSPの総セットのサブセットを再最適化することにより、一連のサブリロプティマイゼーションとしてグローバルな再最適化を実行する可能性があります。
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.
このマルチステップ再ルーティングの利点には、トラフィックの混乱と最適化の増加の最小化が含まれます。ただし、このアプローチは、いくつかの一時的なパケット、ジッター、およびコントロールプレーンの応力を意味する場合があります。
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).
また、再最適化中に、低優先度サービス（インターネットトラフィックなど）を運ぶ一部のLSPでトラフィックの混乱が許可され、ミッションクリティカルサービス（音声トラフィックなど）を運ぶ一部のTELSPでは許可されていないことに注意してください。
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.16は一般的な制約のリストを提供し、[RFC4657]のセクション5.1.17は、PCECPでサポートする必要がある一般的な目的関数のリストを提供します。ベースラインなどの一般的な要件を使用している間、このセクションは、グローバルな同時パス計算のコンテキストで、一般的な要件よりも詳細なレベルでアプリケーション固有の要件を提供します。
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）フィールド。グローバルな目的関数は、グローバルに最適なソリューションを見つけるために、すべての個々のパス計算要求が対象となる包括的な目的関数です。この要件は、セクション5.1.7 [RFC4657]の「同期された目的関数」でカバーされており、[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]).
* すべてのTELSPの最大ホップ数 - これは、TE LSPが持つことができる最大数のホップです。この制約は、[RFC4657]で要求され、[rfc5440]で定義されている）ごとにlspベースで提供できることに注意してください。
* 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は、パスに指定されたリンク/ノードを含めるべきではありません）。この制約は、[RFC4657]で要求され、[rfc5440]で定義されている）ごとにlspベースで提供できることに注意してください。
* 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は、トラフィックの破壊を最小限に抑えるために、TE LSPを再最適化する順序を応答メッセージ（PCREP）に示すことができなければなりません。各要求に対して、古いTE LSPを削除する順序と、新しいTE LSPをセットアップする順序を示す必要があります。削除順序がセットアップ順序よりも低い場合、これはこのリクエストのためにMake-Be-Be-Bree-Breakを実行できないことを意味します。また、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).
* 移行中、既存のすべての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.
SVECオブジェクトに従って、3つのオプションオブジェクトが追加されていることに注意してください：[RFC5541]で定義されている（目的関数）オブジェクト、GC（グローバル制約）オブジェクトは、このドキュメントで定義されています（セクション5.5）、[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.
* 注：これは、次の目的関数によって達成できます。すべてのリンクで最大{a（i）/c（i）}で最小化することができます。ここで、c（i）はリンクiのリンク容量であり、a（i）は総帯域幅です。リンクiに割り当てられます。
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オブジェクトの後にGCO関連オブジェクト（GC、またはXRO）を配置することにより、暗黙的に示すことができます。つまり、これらのオブジェクトのいずれかが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 -BIT（注文-1ビット）：PCREQメッセージで設定すると、リクエストPCCは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-bit（make-be-bebree-break-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.
2つの新しいビットフラグが、RPオブジェクトのフラグフィールドに運ばれるように定義されています。
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-bit）：設定すると、ブレイク前に作成する必要があります。ビット22（d-bit）：設定すると、リクエスト注文のレポートが必要です。
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.
PCEは、PCREQメッセージのRPオブジェクトのD-BITの設定によって要求された場合、PCREQメッセージのPCCによって行われた注文要求に応じて、注文番号を指定する必要があります。このような順序付け表示をサポートするために、新しいオプションのTLVであるOrder 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.
Order TLVは、RPオブジェクトのオプションTLVであり、古いTE LSPを削除する必要があり、新しいTE LSPを再最適化中にセットアップする必要がある順序を示します。再最適化リクエストに応じて、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-BITが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:
これを説明するために、2つの確立されたTE LSPを備えたネットワークを検討します：パスP1を持つR1とパスP2のR2。再最適化中、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：パスP1の削除2：パスP2 '3を設定：パスP2 4：パスP1のセットアップ'
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.
グローバル制約（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 (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.
MU（最小利用率：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.
OB（予約係数の割合：8ビット）：8ビット整数は、物理容量の制限を超えて各リンクで予約された帯域幅をオーバーブッキングできるオーバーブッキング率を示します。たとえば、10％は、100 Mbpsリンクで110 Mbpsを予約できることを意味します。
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形式と処理は、RFC 5440のセクション7.1と一致しています。すべてのTLVは、「PCEP TLVタイプインジケーター」レジストリから割り当てられます。このドキュメントでは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:
グローバルな同時パス最適化要求に関連付けられたエラーを示すために、新しいエラータイプ（14）とその後のエラー値は、PCEP-Errorオブジェクトに含めるために次のように定義されます。
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;ERROR-Value = 1：PCEがグローバルな同時パス最適化要求を受信し、PCEがメモリが不十分なためリクエストを処理できない場合、PCEはPCEP-ErrorオブジェクトでPCERRメッセージを送信する必要があります（Error-Type = 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;エラー-Value = 2：PCEがグローバルな同時パス最適化要求を受信し、PCEがグローバルな同時最適化を受けることができない場合、PCEはPCEP-Errorオブジェクト（エラータイプ= 15）とエラーを使用してPCERRメッセージを送信する必要があります。-value（error-value = 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オブジェクト（エラータイプ= 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.
グローバルな同時パス計算を見つけることができないために理由を通知するには、PCREPメッセージでNO-PATHオブジェクトを使用できます。No-Pathオブジェクト本体の形式は[RFC5440]で定義されています。オブジェクトには、パス計算が失敗した理由に関する追加情報を提供するために、オブジェクトにノーパスベクトル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.
2つの新しいビットフラグは、No-Pathオブジェクトで運ばれたNo-Path-Vector TLVのフラグフィールドに運ばれるように定義されています。
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.
o GCOリクエストを送信する機能。
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.
[PCEP-MIB]で定義されているPCEP MIBモジュールへの拡張は、このドキュメントで導入されたGCO情報をカバーするために定義する必要があります。
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]）を使用して、PCCSにグローバルな同時パス計算機能を宣伝できます。PCE-CAP-Flags Sub-TLVの新しいフラグ（Value = 9）が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.
[RFC5440]で定義されているメカニズムは、PCEPセッションを保護するために使用できます。
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オブジェクトのフラグフィールドに含めるために2つの新しいビットフラグが定義されています。IANAは、「RPオブジェクトフラグフィールド」サブレジストリから次の割り当てを行いました。
Bit Description Reference
ビット説明リファレンス
21 Make-before-break (M-bit) [RFC5557] 22 Report the request order (D-bit) [RFC5557]
21 Make-Be-Bebree-Break（M-Bit）[RFC5557] 22リクエスト注文（D-BIT）[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で説明されているように、GCOのTE LSPのセットアップと削除順序を示すために、新しいPCEP TLVが定義されています。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で説明したように、GCO機能を示すために新しいPCE-CAP-FLAGS SUB-TLVが定義されています。IANAは、RFC 5088のセクション7.2によって作成された「パス計算要素（PCE）機能フラグ」から次の割り当てを行いました。これはOSPFレジストリです。
FLAG Meaning Reference
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で説明されているように、新しいPCEPオブジェクトは、グローバルな制約を運ぶように定義されています。IANAは、「PCEPオブジェクト」サブレジストリから次の割り当てを行いました。
Object Name Reference Class
オブジェクト名参照クラス
24 GLOBAL-CONSTRAINTS [RFC5557] Object-Type 1: Global Constraints [RFC5557]
24 Global-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で説明したように、GCOエラーに対して新しいPCEPエラーコードが定義されています。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]
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-PATH-VECTOR TLVで運ばれたビットフラグの「パスなしTLVフラグフィールド」から次の割り当てを行いました。
Bit
Number Name Reference
25 No GCO solution found [RFC5557]
26 No GCO migration path found [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。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[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] Le Roux、Jl。、Vasseur、Jp。、およびY. Lee、「パス計算要素通信プロトコル（PCEP）における目的関数のエンコード」、RFC 5541、2009年5月。
[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] Oki、E.、Takeda、T。、およびA. Farrel、「ルート除外のパス計算要素通信プロトコル（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。、ed。、およびJl。Le Roux、ed。、「パス計算要素（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[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] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、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] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、ikejiri、Y.、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのIS-ISプロトコル拡張」、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] Oki、E.、Takeda、T.、Le Roux、Jl。、およびA. Farrel、「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] Koushik、K。およびE. Stephan、「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] Farrel、A。、「ルーティングバックスノーフォーム（RBNF）：さまざまなルーティングプロトコル仕様でエンコーディングルールを形成するために使用される構文」、RFC 5511、2009年4月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J.、ed。、「Path Computation Element（PCE）Discoveryの要件」、RFC 4674、2006年10月。
[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.、Le Roux、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.
Jerry Ash、Adrian Farrel、J-P Vasseur、Ning、Lucy Yong、およびFabien Verhaegheの有用なコメントと提案に感謝します。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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.
このソフトウェアは、制限された著作権所有者と貢献者によって提供されます。商品性と特定の目的に対する適合性の暗黙の保証は否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
<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
Young Lee Huawei 1700 Alma Drive、Suite 100 Plano、TX 75075 US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: ylee@huawei.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
Daniel King Old Dog Consulting United Kingdom
ダニエルキングオールドドッグコンサルティングイギリス
EMail: daniel@olddog.co.uk
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
Eiji oki Electro-communications 1-5-1 Chofugaoka Chofu、Tokyo 182-8585 Japan
EMail: oki@ice.uec.ac.jp