Internet Engineering Task Force (IETF) T. Otani
Request for Comments: 7025 K. Ogaki
Category: Informational KDDI
ISSN: 2070-1721 D. Caviglia
Ericsson
F. Zhang
Huawei Technologies
C. Margaria
Coriant R&D GmbH
September 2013
Internet Engineering Task Force (IETF) T. Otani
Request for Comments: 7025 K. Ogaki
Category: Informational KDDI
ISSN: 2070-1721 D. Caviglia
Ericsson
F. Zhang
Huawei Technologies
C. Margaria
Coriant R&D GmbH
September 2013
Requirements for GMPLS Applications of PCE
四氯乙烯GMPLS应用要求
Abstract
摘要
The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.
PCE（路径计算元素）工作组最初的工作主要集中在MPLS上。作为下一步，本文件描述了PCE GMPLS应用的功能要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7025.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7025.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. GMPLS Applications of PCE . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation in GMPLS Networks . . . . . . . . . . . . 3
2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 5
2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 5
3. Requirements for GMPLS Applications of PCE . . . . . . . . . . 6
3.1. Requirements on Path Computation Request . . . . . . . . . 6
3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. GMPLS Applications of PCE . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation in GMPLS Networks . . . . . . . . . . . . 3
2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 5
2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 5
3. Requirements for GMPLS Applications of PCE . . . . . . . . . . 6
3.1. Requirements on Path Computation Request . . . . . . . . . 6
3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
The initial effort of the PCE (Path Computation Element) WG focused mainly on solving the path computation problem within a domain or over different domains in MPLS networks. As with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLS-controlled networks [RFC3945], such as those based on Wavelength Division Multiplexing (WDM), Time Division Multiplexing (TDM), or Ethernet.
PCE（路径计算元素）工作组最初的工作主要集中于解决MPLS网络中一个域内或不同域上的路径计算问题。与MPLS一样，服务提供商（SP）也提出了GMPLS控制网络[RFC3945]中路径计算的要求，例如基于波分复用（WDM）、时分复用（TDM）或以太网的网络。
[RFC4655] and [RFC4657] discuss the framework and requirements for PCE on both packet MPLS networks and GMPLS-controlled networks. This document complements those RFCs by providing considerations of GMPLS applications in the intradomain and interdomain networking environments and indicating a set of requirements for the extended definition of PCE-related protocols.
[RFC4655]和[RFC4657]讨论了分组MPLS网络和GMPLS控制网络上PCE的框架和要求。本文件通过提供域内和域间网络环境中GMPLS应用的注意事项，并指出PCE相关协议扩展定义的一系列要求，对这些RFC进行了补充。
Note that the requirements for interlayer and inter-area traffic engineering (TE) described in [RFC6457] and [RFC4927] are outside of the scope of this document.
注意，[RFC6457]和[RFC4927]中描述的层间和区域间交通工程（TE）要求不在本文件范围内。
Constrained Shortest Path First (CSPF) computation within a domain or over domains for signaling GMPLS Label Switched Paths (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216], because the additional constraints, e.g., interface switching capability, link encoding, link protection capability, Shared Risk Link Group (SRLG) [RFC4202], and so forth, need to be considered to establish GMPLS LSPs. The GMPLS signaling protocol [RFC3473] is designed taking into account bidirectionality, switching type, encoding type, and protection attributes of the TE links spanned by the path, as well as LSP encoding and switching type of the endpoints, appropriately.
为GMPLS标签交换路径（LSP）发信号的域内或域外受限最短路径优先（CSPF）计算通常比MPLS TE LSP[RFC4216]更严格，因为附加约束，例如接口交换能力、链路编码、链路保护能力、共享风险链路组（SRLG）[RFC4202]，等等，需要考虑建立GMPLS LSP。GMPLS信令协议[RFC3473]的设计考虑了路径跨越的TE链路的双向性、切换类型、编码类型和保护属性，以及端点的LSP编码和切换类型。
This document provides requirements for GMPLS applications of PCE in support of GMPLS path computation, included are requirements for both intradomain and interdomain environments.
本文件提供了支持GMPLS路径计算的PCE的GMPLS应用要求，包括域内和域间环境的要求。
Figure 1 depicts a model GMPLS network, consisting of an ingress link, a transit link, as well as an egress link. We will use this model to investigate consistent guidelines for GMPLS path computation. Each link at each interface has its own switching capability, encoding type, and bandwidth.
图1描述了模型GMPLS网络，包括入口链路、传输链路以及出口链路。我们将使用该模型研究GMPLS路径计算的一致性准则。每个接口上的每个链路都有自己的交换能力、编码类型和带宽。
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 1: Path Computation in GMPLS Networks
图1:GMPLS网络中的路径计算
For the simplicity in consideration, the following basic assumptions are made when the LSP is created.
为了简单起见，在创建LSP时，进行了以下基本假设。
(1) Switching capabilities of outgoing links from the ingress and egress nodes (link1-2 and link4-3 in Figure 1) are consistent with each other.
(1) 来自入口和出口节点（图1中的link1-2和link4-3）的传出链路的交换能力彼此一致。
(2) Switching capabilities of all transit links, including incoming links to the ingress and egress nodes (link2-1 and link3-4) are consistent with switching type of an LSP to be created.
(2) 所有传输链路的交换能力，包括到入口和出口节点（链路2-1和链路3-4）的传入链路，与要创建的LSP的交换类型一致。
(3) Encoding types of all transit links are consistent with the encoding type of an LSP to be created.
(3) 所有中转链路的编码类型与要创建的LSP的编码类型一致。
GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are usually responsible for transmitting data for the client layer. These GMPLS-controlled networks can provide different types of connections for customer services based on different service bandwidth requests.
GMPLS控制的网络（例如，基于GMPLS的TDM网络）通常负责为客户层传输数据。这些GMPLS控制的网络可以根据不同的服务带宽请求为客户服务提供不同类型的连接。
The applications and the corresponding additional requirements for applying PCE to GMPLS-based TDM networks are described in this section. In order to simplify the description, this document only discusses the scenario in Synchronous Digital Hierarchy (SDH) networks as an example (see Figure 2). The scenarios in Synchronous Optical Network (SONET) or Optical Transport Network (OTN) are similar.
本节描述了将PCE应用于基于GMPLS的TDM网络的应用和相应的附加要求。为了简化描述，本文档仅以同步数字体系（SDH）网络中的场景为例进行讨论（见图2）。同步光网络（SONET）或光传输网络（OTN）中的场景类似。
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
Figure 2: A Simple TDM (SDH) Network
图2：一个简单的TDM（SDH）网络
Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, N4, and N5 are all SDH switches; A1 and A2 are client devices (e.g., Ethernet switches). Assume that one Ethernet service with 100 Mbit/s bandwidth is required from A1 to A2 over this network. The client Ethernet service could be provided by a Virtual Container 4 (VC-4) container from N1 to N4; it could also be provided by three concatenated VC-3s (contiguous or virtual concatenation) from N1 to N4.
图2显示了一个简单的TDM（SDH）网络拓扑，其中N1、N2、N3、N4和N5都是SDH交换机；A1和A2是客户端设备（例如以太网交换机）。假设此网络上A1到A2需要一个100 Mbit/s带宽的以太网服务。客户端以太网服务可以由从N1到N4的虚拟容器4（VC-4）容器提供；它也可以由从N1到N4的三个串联VC-3（连续或虚拟串联）提供。
In this scenario, when the ingress node (e.g., N1) receives a client service transmitting request, the type of containers (one VC-4 or three concatenated VC-3s) could be determined by the PCC (Path Computation Client), e.g., N1 or Network Management System (NMS). However, it could also be determined automatically by the PCE based on policy [RFC5394]. If it is determined by the PCC, then the PCC should be capable of specifying the ingress node and egress node, signal type, the type of the concatenation, and the number of the concatenation in a PCReq (Path Computation Request) message. The PCE should consider those parameters during path computation. The route information (co-routing or diverse routing) should be specified in a PCRep (Path Computation Reply) message if path computation is performed successfully.
在该场景中，当入口节点（例如N1）接收到客户端服务发送请求时，容器的类型（一个VC-4或三个串联的VC-3）可由PCC（路径计算客户端）确定，例如N1或网络管理系统（NMS）。但是，它也可以由PCE根据策略自动确定[RFC5394]。如果由PCC确定，则PCC应能够在PCReq（路径计算请求）消息中指定入口节点和出口节点、信号类型、连接类型和连接数量。PCE在路径计算时应考虑这些参数。如果路径计算成功执行，则应在PCRep（路径计算回复）消息中指定路由信息（共同路由或不同路由）。
As described above, the PCC should be capable of specifying TE attributes defined in the next section, and the PCE should compute a path accordingly.
如上所述，PCC应该能够指定下一节中定义的TE属性，并且PCE应该相应地计算路径。
Where a GMPLS network consists of interdomain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path computation follow [RFC5376] and [RFC4726].
当GMPLS网络由域间（例如，AS间或区域间）GMPLS控制网络组成时，路径计算要求遵循[RFC5376]和[RFC4726]。
GMPLS supports unnumbered interface IDs as defined in [RFC3477]; this means that the endpoints of the path may be unnumbered. It should also be possible to request a path consisting of the mixture of numbered links and unnumbered links, or a P2MP (Point-to-Multipoint) path with different types of endpoints. Therefore, the PCC should be capable of indicating the unnumbered interface ID of the endpoints in the PCReq message.
GMPLS支持[RFC3477]中定义的未编号接口ID；这意味着路径的端点可能没有编号。还可以请求由编号链接和未编号链接混合组成的路径，或具有不同类型端点的P2MP（点对多点）路径。因此，PCC应该能够在PCReq消息中指示端点的未编号接口ID。
Per [RFC6387], GMPLS signaling can be used for setting up an asymmetric bandwidth bidirectional LSP. If a PCE is responsible for path computation, it should be capable of computing a path for the bidirectional LSP with asymmetric bandwidth. This means that the PCC should be able to indicate the asymmetric bandwidth requirements in forward and reverse directions in the PCReq message.
根据[RFC6387]，GMPLS信令可用于建立非对称带宽双向LSP。如果PCE负责路径计算，它应该能够计算具有不对称带宽的双向LSP的路径。这意味着PCC应该能够在PCReq消息的正向和反向指示不对称带宽要求。
As for path computation in GMPLS-controlled networks as discussed in Section 2, the PCE should appropriately consider the GMPLS TE attributes listed below once a PCC or another PCE requests a path computation. The path calculation request message from the PCC or the PCE must contain the information specifying appropriate attributes. According to [RFC5440], [PCE-WSON-REQ], and RSVP procedures such as explicit label control (ELC), the additional attributes introduced are as follows:
至于在第2节中讨论的GMPLS控制网络中的路径计算，PCC应该适当地考虑一旦PCC或另一PCE请求路径计算，下面列出的GMPLS TE属性。来自PCC或PCE的路径计算请求消息必须包含指定适当属性的信息。根据[RFC5440]、[PCE-WSON-REQ]和RSVP程序，如显式标签控制（ELC），引入的附加属性如下：
(1) Switching capability/type: as defined in [RFC3471], [RFC4203], and all current and future values.
(1) 切换能力/类型：如[RFC3471]、[RFC4203]以及所有当前和未来值中所定义。
(2) Encoding type: as defined in [RFC3471], [RFC4203], and all current and future values.
(2) 编码类型：如[RFC3471]、[RFC4203]以及所有当前和未来值中所定义。
(3) Signal type: as defined in [RFC4606] and all current and future values.
(3) 信号类型：如[RFC4606]中定义，以及所有当前和未来值。
(4) Concatenation type: In SDH/SONET and OTN, two kinds of concatenation modes are defined: contiguous concatenation, which requires co-routing for each member signal and that all the interfaces along the path support this capability, and virtual concatenation, which allows diverse routing for member signals and requires that only the ingress and egress interfaces support this capability. Note that for the virtual concatenation, it may also specify co-routing or diverse routing. See [RFC4606] and [RFC4328] about concatenation information.
(4) 级联类型：在SDH/SONET和OTN中，定义了两种级联模式：连续级联，需要每个成员信号的共同路由，并且路径上的所有接口都支持此功能，以及虚拟级联，这允许成员信号的不同路由，并要求只有入口和出口接口支持此功能。请注意，对于虚拟连接，它还可以指定共同路由或不同路由。有关连接信息，请参见[RFC4606]和[RFC4328]。
(5) Concatenation number: Indicates the number of signals that are requested to be contiguously or virtually concatenated. Also see [RFC4606] and [RFC4328].
(5) 串联数：表示请求连续或虚拟串联的信号数。另请参见[RFC4606]和[RFC4328]。
(6) Technology-specific label(s): as defined in [RFC4606], [RFC6060], [RFC6002], or [RFC6205].
(6) 技术特定标签：如[RFC4606]、[RFC6060]、[RFC6002]或[RFC6205]中所定义。
(7) End-to-End (E2E) path protection type: as defined in [RFC4872], e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting, etc.
(7) 端到端（E2E）路径保护类型：如[RFC4872]中所定义，例如1+1保护、1:1保护、（预先计划的）重新路由等。
(8) Administrative group: as defined in [RFC3630].
(8) 管理组：如[RFC3630]中所定义。
(9) Link protection type: as defined in [RFC4203].
(9) 链路保护类型：如[RFC4203]中所定义。
(10) Support for unnumbered interfaces: as defined in [RFC3477].
（10） 支持未编号的接口：如[RFC3477]中所定义。
(11) Support for asymmetric bandwidth requests: as defined in [RFC6387].
（11） 支持不对称带宽请求：如[RFC6387]中所定义。
(12) Support for explicit label control during the path computation.
（12） 在路径计算期间支持显式标签控制。
(13) Support of label restrictions in the requests/responses, similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude Route Object), as defined in [RFC3473] and [RFC4874].
（13） 支持请求/响应中的标签限制，类似于[RFC3473]和[RFC4874]中定义的RSVP-TE ERO（显式路由对象）和XRO（排除路由对象）。
As described above, a PCE should compute the path that satisfies the constraints specified in the PCReq message. Then, the PCE should send a PCRep message, including the computation result, to the PCC. For a Path Computation Reply message (PCRep) in GMPLS networks, there are some additional requirements. The PCEP (PCE communication protocol) PCRep message must be extended to meet the following requirements.
如上所述，PCE应计算满足PCReq消息中指定的约束的路径。然后，PCE应向PCC发送PCRep消息，包括计算结果。对于GMPLS网络中的路径计算回复消息（PCRep），有一些额外的要求。必须扩展PCEP（PCE通信协议）PCRep消息以满足以下要求。
(1) Path computation with concatenation
(1) 级联路径计算
In the case of path computation involving concatenation, when a PCE receives the PCReq message specifying the concatenation constraints described in Section 3.1, the PCE should compute a path accordingly.
在涉及级联的路径计算的情况下，当PCE接收到指定第3.1节中描述的级联约束的PCReq消息时，PCE应相应地计算路径。
For path computation involving contiguous concatenation, a single route is required, and all the interfaces along the route should support contiguous concatenation capability. Therefore, the PCE should compute a path based on the contiguous concatenation capability of each interface and only one ERO that should carry the route information for the response.
对于涉及连续连接的路径计算，需要单个路由，并且路由上的所有接口都应支持连续连接功能。因此，PCE应基于每个接口的连续连接能力计算路径，并且仅一个ERO应携带响应的路由信息。
For path computation involving virtual concatenation, only the ingress/egress interfaces need to support virtual concatenation capability, and there may be diverse routes for the different member signals. Therefore, multiple EROs may be needed for the response. Each ERO may represent the route of one or multiple member signals. When one ERO represents multiple member signals, the number must be specified.
对于涉及虚拟级联的路径计算，只有入口/出口接口需要支持虚拟级联能力，并且对于不同的成员信号可能有不同的路由。因此，响应可能需要多个ERO。每个ERO可代表一个或多个成员信号的路由。当一个ERO代表多个成员信号时，必须指定编号。
(2) Label constraint
(2) 标签约束
In the case that a PCC does not specify the exact label(s) when requesting a label-restricted path and the PCE is capable of performing the route computation and label assignment computation procedure, the PCE needs to be able to specify the label of the path in a PCRep message.
在PCC在请求标签受限路径时未指定确切标签且PCE能够执行路由计算和标签分配计算过程的情况下，PCE需要能够在PCRep消息中指定路径的标签。
Wavelength restriction is a typical case of label restriction. More generally, label switching and selection constraints may apply in GMPLS-controlled networks, and a PCC may request a PCE to take label constraint into account and return an ERO containing the label or set of labels that fulfill the PCC request.
波长限制是标签限制的典型情况。更一般地，标签交换和选择约束可应用于GMPLS控制的网络中，并且PCC可请求PCE考虑标签约束并返回包含满足PCC请求的标签或标签集的ERO。
(3) Roles of the routes
(3) 路线的作用
When a PCC specifies the protection type of an LSP, the PCE should compute the working route and the corresponding protection route(s). Therefore, the PCRep should allow to distinguish the working (nominal) and the protection routes. According to these routes, the RSVP-TE procedure appropriately creates both the working and the protection LSPs, for example, with the ASSOCIATION object [RFC6689].
当PCC指定LSP的保护类型时，PCE应计算工作路由和相应的保护路由。因此，PCRep应允许区分工作（标称）和保护路径。根据这些路由，RSVP-TE过程适当地创建工作LSP和保护LSP，例如，使用关联对象[RFC6689]。
This document does not change any of the management or operational details for networks that utilize PCE. (Please refer to [RFC4655] for manageability considerations for a PCE-based architecture.) However, this document proposes the introduction of several PCEP objects and data for the better integration of PCE with GMPLS networks. Those protocol elements will need to be visible in any management tools that apply to the PCE, PCC, and PCEP. That includes, but is not limited to, adding appropriate objects to existing PCE MIB modules that are used for modeling and monitoring PCEP deployments [PCEP-MIB]. Ideas for what objects are needed may be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB [RFC4802].
本文件不改变使用PCE的网络的任何管理或操作细节。（请参考[RFC4655]了解基于PCE的体系结构的可管理性注意事项。）但是，本文件建议引入几个PCEP对象和数据，以便更好地将PCE与GMPLS网络集成。这些协议元素需要在适用于PCE、PCC和PCEP的任何管理工具中可见。这包括但不限于向用于建模和监控PCEP部署的现有PCE MIB模块添加适当的对象[PCEP-MIB]。关于需要什么对象的想法可以由GMPLS-TE-STD-MIB[RFC4802]中的相关GMPLS扩展来指导。
PCEP extensions to support GMPLS should be considered under the same security as current PCE work, and this extension will not change the underlying security issues. Section 10 of [RFC5440] describes the list of security considerations in PCEP. At the time [RFC5440] was published, TCP Authentication Option (TCP-AO) had not been fully
支持GMPLS的PCEP扩展应在与当前PCE工作相同的安全性下考虑，并且该扩展不会改变潜在的安全问题。[RFC5440]第10节描述了PCEP中的安全注意事项列表。在[RFC5440]发布时，TCP身份验证选项（TCP-AO）尚未完全启用
specified for securing the TCP connections that underlie PCEP sessions. TCP-AO [RFC5925] has now been published, and PCEP implementations should fully support TCP-AO according to [RFC6952].
指定用于保护作为PCEP会话基础的TCP连接。TCP-AO[RFC5925]现已发布，根据[RFC6952]，PCEP实现应完全支持TCP-AO。
The authors would like to express thanks to Ramon Casellas, Julien Meuric, Adrian Farrel, Yaron Sheffer, and Shuichi Okamoto for their comments.
作者要感谢Ramon Casellas、Julien Meuria、Adrian Farrel、Yaron Sheffer和Okamoto的评论。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.和Y.Rekhter，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.和Y.Rekhter，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328]Papadimitriou，D.，“G.709光传输网络控制的通用多协议标签交换（GMPLS）信令扩展”，RFC 4328，2006年1月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606]Mannie，E.和D.Papadimitriou，“同步光网络（SONET）和同步数字体系（SDH）控制的通用多协议标签交换（GMPLS）扩展”，RFC 4606，2006年8月。
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]Nadeau，T.和A.Farrel，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 48022007年2月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Rekhter，Y.，和D.Papadimitriou，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927]Le Roux，J.“区域间MPLS和GMPLS流量工程的路径计算元素通信协议（PCECP）特定要求”，RFC 4927，2007年6月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376]Bitar，N.，Zhang，R.，和K.Kumaki，“路径计算元素通信协议（PCECP）的内部AS要求”，RFC 5376，2008年11月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP。和JL。Le Roux，“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", RFC 6002, October 2010.
[RFC6002]Berger，L.和D.Fedyk，“通用MPLS（GMPLS）数据信道交换功能（DCSC）和信道集标签扩展”，RFC6002，2010年10月。
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011.
[RFC6060]Fedyk，D.，Shah，H.，Bitar，N.，和A.Takacs，“以太网提供商主干流量工程（PBB-TE）的通用多协议标签交换（GMPLS）控制”，RFC 6060，2011年3月。
[RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, March 2011.
[RFC6205]Otani，T.和D.Li，“Lambda交换机功能（LSC）标签交换路由器的通用标签”，RFC 62052011年3月。
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, September 2011.
[RFC6387]Takacs，A.，Berger，L.，Caviglia，D.，Fedyk，D.，和J.Meuria，“GMPLS非对称带宽双向标签交换路径（LSP）”，RFC 6387，2011年9月。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012.
[RFC6689]Berger，L.“RSVP关联对象的使用”，RFC 6689，2012年7月。
[PCE-WSON-REQ] Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Tsuritani, T., and O. Dios, "PCEP Requirements for WSON Routing and Wavelength Assignment", Work in Progress, June 2013.
[PCE-WSON-REQ]Lee，Y.，Bernstein，G.，Martenson，J.，Takeda，T.，Tsuritani，T.，和O.Dios，“WSON路由和波长分配的PCEP要求”，正在进行的工作，2013年6月。
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2013.
[PCEP-MIB]Koushik，K.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2013年7月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.和J.Le Roux，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", RFC 6457, December 2011.
[RFC6457]武田，T.和A.法雷尔，“层间流量工程的PCC-PCE通信和PCE发现要求”，RFC 6457，2011年12月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月。
Authors' Addresses
作者地址
Tomohiro Otani KDDI Corporation 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo Japan Phone: +81-(3) 3347-6006 EMail: tm-otani@kddi.com
大谷智博KDDI公司2-3-2日本东京西新宿新宿电话：+81-（3）3347-6006电子邮件：tm-otani@kddi.com
Kenichi Ogaki KDDI Corporation 3-10-10 Iidabashi Chiyoda-ku, Tokyo Japan Phone: +81-(3) 6678-0284 EMail: ke-oogaki@kddi.com
小垣健一KDDI公司3-10-10-10-Iidabashi Chiyoda ku，日本东京电话：+81-（3）6678-0284电子邮件：ke-oogaki@kddi.com
Diego Caviglia Ericsson 16153 Genova Cornigliano Italy Phone: +390106003736 EMail: diego.caviglia@ericsson.com
Diego Caviglia Ericsson 16153 Genova Cornigliano意大利电话：+390106003736电子邮件：Diego。caviglia@ericsson.com
Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District, Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: zhangfatai@huawei.com
张法泰华为技术有限公司中国深圳市龙岗区华为基地坂田F3-5-B研发中心邮编：518129电话：+86-755-28972912电子邮件：zhangfatai@huawei.com
Cyril Margaria Coriant R&D GmbH St Martin Strasse 76 Munich 81541 Germany Phone: +49 89 5159 16934 EMail: cyril.margaria@coriant.com
Cyril Margaria Coriant R&D GmbH St Martin Strasse 76慕尼黑81541德国电话：+49 89 5159 16934电子邮件：Cyril。margaria@coriant.com