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
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）的路由时，执行批量路径计算以避免阻塞问题并实现更优的网络范围解决方案可能是有利的。这种批量优化称为全局并行优化（GCO）。GCO能够同时考虑网络的整个拓扑结构和现有TE LSPS的完整集合，以及它们各自的约束，并着眼于优化或重新优化整个网络，以满足所有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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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如何应路径计算客户端（PCC）的请求计算多协议标签交换流量工程（MPLS-TE）和通用MPLS（GMPLS）网络中的标签交换路径（LSP）。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和每个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
当网络运营商需要在其网络规划过程中建立一组TE LSP时，也可能需要全局并发路径计算。还可以设想，在发生灾难性网络故障时，网络运营商可能需要全局并发路径计算，其中需要一组TE LSP
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.
最佳重新路由。这项工作的性质促进了离线处理系统的使用。这项工作的在线应用应仅考虑经验证的经验验证。
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 LSPS的完整集合及其各自的约束，并且能够查看重新优化整个网络以满足所有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.
需要注意的是，反向递归路径计算（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.
路径计算客户端。任何请求由路径计算元素执行的路径计算的客户端应用程序。
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可以通过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传送到PCE，并将计算出的路径从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 LSPS的完整集合，以及它们各自的约束，并着眼于优化或重新优化整个网络，以满足所有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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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显示了[RFC4655]中定义的基于PCE的网络体系结构，其中应用了GCO应用程序。必须注意，PCC不一定是LSR[RFC4655]。GCO应用程序主要是基于NMS的解决方案，其中NMS发挥PCC的功能。尽管图1显示PCE远离NMS，但它可能与NMS并置。注意，在并置的情况下，不需要标准通信协议；这可以依赖于内部API。
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |
| PCC | Response| ----- |
| (NMS/Server)|<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
-----------
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为前端LSR提供需要建立的每个TE LSP的完全计算的显式路径。
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.
绿地优化是GCO应用的一个特例，当网络中尚未设置TE LSP时。当网络规划者想要利用计算服务器来规划将在网络中供应的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]的重新配置是一种典型的应用场景，其中可能适用全局并发路径计算。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 LSP迁移到一组重新优化的TE LSP时，重要的是在不造成中断的情况下移动通信量。MPLS和GMPLS中存在各种技术，如先通后断[RFC3209]，用于在拆除旧TE LSP之前建立新的TE LSP。当根据计算结果改变多个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集合的子集，将全局重新优化作为一系列子重新优化来执行。
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).
还请注意，在重新优化期间，可能允许某些承载低优先级服务（例如，互联网流量）的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
还需要注意的是，本节中讨论的一些需求已经在PCECP需求文件[RFC4657]中讨论过。例如，[RFC4657]中的第5.1.16节提供了通用约束列表，[RFC4657]中的第5.1.17节提供了PCECP必须支持的通用目标函数列表。在使用诸如
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.
基线，本节提供了全局并发路径计算上下文中的特定于应用程序的需求，并且比一般需求更详细。
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]定义了三个全局目标函数，如下所示。可用的全局目标函数列表应至少包括以下目标函数，并应可扩展以供将来添加：
* 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.
* 请求消息必须允许请求PCE提供重新优化TE LSP的顺序（即迁移路径），以便将迁移期间的流量中断降至最低。也就是说，请求消息必须允许向PCE指示将在响应消息（PCRep）中提供的路径集必须被排序。
* 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无法进行先通后断再优化（这将从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]中定义的简化巴科斯Naur格式。有关本文档中定义的全套RBNF片段和必要的代码许可证，请参见附录A。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
The <svec-list> is changed as follows:
<svec列表>更改如下：
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<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对象之后添加了三个可选对象：OF（目标函数）对象（在[RFC5541]中定义）、GC（全局约束）对象（在本文档中定义）（第5.5节）以及排除路线对象（XRO）（在[RFC5521]中定义）。[RFC5541]中定义了SVEC列表中对象的位置（其中指定了全局目标函数）。有关此更改的详细信息将在以下章节中讨论。
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]中定义的三个全局目标函数用于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.
应指示此应用程序中的所有路径请求，以便将全局目标函数和所有全局约束应用于每个请求的路径计算。这可以通过将GCO相关对象（OF、GC或XRO）放在SVEC对象之后来隐式表示。也就是说，如果这些对象中的任何一个遵循PCReq消息中的SVEC对象，那么在SVEC对象中指定的所有请求的路径计算都受of、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必须移动的顺序，以便将交通中断降至最低。为支持此类指示，RP对象中定义了一个新标志，即D标志，如下所示：
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要求PCE在PCRep消息中指定此特定路径请求相对于其他请求的设置顺序。
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.
为了支持确定是否需要先通后断优化，在RP对象中定义了一个新标志，即M标志，如下所示。
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位时，这意味着此请求允许先中断再进行重新优化。请注意，仅当设置了R（重新优化）标志时，才能设置M位。
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.
PCE必须指定订单号，以响应PCC在PCReq消息中发出的订单请求（如果PCReq消息中RP对象中的D位设置有此请求）。为了支持这种排序指示，在RP对象中定义了一个新的可选TLV，Order TLV。
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是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.
如果在PCReq消息的RP对象中设置了D位，则订单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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
删除顺序：32位整数，指示旧TE LSP的删除顺序。
Setup Order: 32-bit integer that indicates the order in which the new TE LSP should be setup.
设置顺序：32位整数，指示新TE LSP的设置顺序。
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以指定这种情况。当delete order的值为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:
为了说明这一点，考虑具有两个建立的TE LSPS的网络：具有路径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.
全局约束对象类为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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位）：8位整数，表示所有TE LSP的最大跳数。
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 (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（Over-Booking factor Percentage: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；错误值=1：如果PCE接收到全局并发路径优化请求，并且PCE由于内存不足而无法处理该请求，则PCE必须发送带有PCEP-Error对象（错误类型=15）和错误值（错误值=1）的PCErr消息。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对象（错误类型=15）和错误值（错误值=2）的PCErr消息。
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）的PCErr消息。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对象。无路径对象体的格式在[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.
两个新的位标志被定义为在NO-PATH对象中携带的NO-PATH向量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]）可用于向PCC公布全局并发路径计算能力。PCE CAP FLAGs Sub TLV中的一个新标志（值=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对象的标志字段中。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从“路径计算元素（PCE）能力标志”子注册表进行了以下分配，该子注册表由RFC 5088第7.2节创建。这是一个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全局约束[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]
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已从“无路径向量TLV标志字段”子注册表中为PCEP无路径对象中的无路径向量TLV中携带的位标志进行了以下分配，如第5.7节所述。
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.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年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 55412009年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 55212009年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 54402009年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，2001年12月。
[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，“路径计算元素（PCE）发现的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，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[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.，“路由Backus-Naur形式（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 46552006年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.，“路径计算元件（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.，编辑，“路径计算元素（PCE）发现的要求”，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 52122008年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 So、Lucy Yong和Fabien Verhaeghe提出的有用意见和建议。
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 Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
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>
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]
Authors' Addresses
作者地址
Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US
美国德克萨斯州普莱诺市阿尔玛大道1700号100室杨利华为75075
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: ylee@huawei.com
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
法国勒鲁电信2号，皮埃尔·马津·拉尼翁大街，邮编22307
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com
Daniel King Old Dog Consulting United Kingdom
丹尼尔·金英国老狗咨询公司
EMail: daniel@olddog.co.uk
EMail: daniel@olddog.co.uk
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585 JAPAN
伊吉电子通信大学1-5-1 CHOUUGAKA CHOFU，东京182-85 85日本
EMail: oki@ice.uec.ac.jp
EMail: oki@ice.uec.ac.jp