Network Working Group JL. Le Roux, Ed.
Request for Comments: 5088 France Telecom
Category: Standards Track JP. Vasseur, Ed.
Cisco System Inc.
Y. Ikejiri
NTT Communications
R. Zhang
BT
January 2008
Network Working Group JL. Le Roux, Ed.
Request for Comments: 5088 France Telecom
Category: Standards Track JP. Vasseur, Ed.
Cisco System Inc.
Y. Ikejiri
NTT Communications
R. Zhang
BT
January 2008
OSPF Protocol Extensions for Path Computation Element (PCE) Discovery
用于路径计算元素（PCE）发现的OSPF协议扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain.
存在各种情况，其中路径计算客户端（PCC）能够动态且自动地发现一组路径计算元素（PCE）以及PCC可用于PCE选择的信息是非常期望的。当PCE是参与内部网关协议（IGP）的标签交换路由器（LSR），或者甚至是被动参与IGP的服务器时，宣布PCE的简单而有效的方法包括使用IGP泛洪。为此，本文件定义了开放式最短路径优先（OSPF）路由协议的扩展，用于在OSPF区域或整个OSPF路由域内公布PCE发现信息。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. PCE Discovery Information ..................................5
3.2. Flooding Scope .............................................5
4. The OSPF PCED TLV ...............................................6
4.1. PCE-ADDRESS Sub-TLV ........................................7
4.2. PATH-SCOPE Sub-TLV .........................................8
4.3. PCE-DOMAIN Sub-TLV ........................................10
4.4. NEIG-PCE-DOMAIN Sub-TLV ...................................11
4.5. PCE-CAP-FLAGS Sub-TLV .....................................12
5. Elements of Procedure ..........................................13
6. Backward Compatibility .........................................14
7. IANA Considerations ............................................14
7.1. OSPF TLV ..................................................14
7.2. PCE Capability Flags Registry .............................14
8. Security Considerations ........................................15
9. Manageability Considerations ...................................16
9.1. Control of Policy and Functions ...........................16
9.2. Information and Data Model ................................16
9.3. Liveness Detection and Monitoring .........................16
9.4. Verify Correct Operations .................................16
9.5. Requirements on Other Protocols and Functional
Components ................................................16
9.6. Impact on Network Operations ..............................17
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. PCE Discovery Information ..................................5
3.2. Flooding Scope .............................................5
4. The OSPF PCED TLV ...............................................6
4.1. PCE-ADDRESS Sub-TLV ........................................7
4.2. PATH-SCOPE Sub-TLV .........................................8
4.3. PCE-DOMAIN Sub-TLV ........................................10
4.4. NEIG-PCE-DOMAIN Sub-TLV ...................................11
4.5. PCE-CAP-FLAGS Sub-TLV .....................................12
5. Elements of Procedure ..........................................13
6. Backward Compatibility .........................................14
7. IANA Considerations ............................................14
7.1. OSPF TLV ..................................................14
7.2. PCE Capability Flags Registry .............................14
8. Security Considerations ........................................15
9. Manageability Considerations ...................................16
9.1. Control of Policy and Functions ...........................16
9.2. Information and Data Model ................................16
9.3. Liveness Detection and Monitoring .........................16
9.4. Verify Correct Operations .................................16
9.5. Requirements on Other Protocols and Functional
Components ................................................16
9.6. Impact on Network Operations ..............................17
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
[RFC4655] describes the motivations and architecture for a Path Computation Element (PCE)-based path computation model for Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE LSPs). The model allows for the separation of the PCE from a Path Computation Client (PCC) (also referred to as a non co-located PCE) and allows for cooperation between PCEs (where one PCE acts as a PCC to make requests of the other PCE). This relies on a communication protocol between a PCC and PCE, and also between PCEs. The requirements for such a communication protocol can be found in [RFC4657], and the communication protocol is defined in [PCEP].
[RFC4655]描述了用于多协议标签交换（MPLS）和广义MPLS（GMPLS）流量工程标签交换路径（TE LSP）的基于路径计算元素（PCE）的路径计算模型的动机和体系结构。该模型允许将PCE与路径计算客户端（PCC）（也称为非同址PCE）分离，并允许PCE之间的合作（其中一个PCE充当PCC向另一个PCE发出请求）。这依赖于PCC和PCE之间以及PCE之间的通信协议。此类通信协议的要求见[RFC4657]，通信协议定义见[PCEP]。
The PCE architecture requires that a PCC be aware of the location of one or more PCEs in its domain, and, potentially, of PCEs in other domains, e.g., in the case of inter-domain TE LSP computation.
PCE体系结构要求PCC知道其域中的一个或多个PCE的位置，并且可能知道其他域中的PCE的位置，例如，在域间TE LSP计算的情况下。
A network may contain a large number of PCEs, each with potentially distinct capabilities. In such a context, it is highly desirable to have a mechanism for automatic and dynamic PCE discovery that allows PCCs to automatically discover a set of PCEs, along with additional information about each PCE that may be used by a PCC to perform PCE selection. Additionally, it is valuable for a PCC to dynamically detect new PCEs, failed PCEs, or any modification to the PCE information. Detailed requirements for such a PCE discovery mechanism are provided in [RFC4674].
一个网络可能包含大量的PCE，每个PCE具有潜在的不同功能。在这样的上下文中，非常希望具有用于自动和动态PCE发现的机制，该机制允许PCC自动发现一组PCE，以及关于PCC可用于执行PCE选择的每个PCE的附加信息。此外，PCC动态检测新PCE、故障PCE或对PCE信息的任何修改是有价值的。[RFC4674]中提供了此类PCE发现机制的详细要求。
Note that the PCE selection algorithm applied by a PCC is out of the scope of this document.
请注意，PCC应用的PCE选择算法超出了本文档的范围。
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements.
当pcc是参与IGP（OSPF或IS-IS）的lsr，并且PCE是也参与IGP的lsr或服务器时，IGP路由域内PCE发现的有效机制包括利用IGP广告。
This document defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC2740] to allow a PCE in an OSPF routing domain to advertise its location, along with some information useful to a PCC for PCE selection, so as to satisfy dynamic PCE discovery requirements set forth in [RFC4674].
本文档定义了对OSPFv2[RFC2328]和OSPFv3[RFC2740]的扩展，以允许OSPF路由域中的PCE公布其位置，以及一些对PCC选择PCE有用的信息，从而满足[RFC4674]中规定的动态PCE发现要求。
Generic capability advertisement mechanisms for OSPF are defined in [RFC4970]. These allow a router to advertise its capabilities within an OSPF area or an entire OSPF routing domain. This document leverages this generic capability advertisement mechanism to fully satisfy the dynamic PCE discovery requirements.
[RFC4970]中定义了OSPF的通用能力公布机制。这些允许路由器在OSPF区域或整个OSPF路由域内公布其功能。本文档利用此通用功能发布机制，完全满足动态PCE发现需求。
This document defines a new TLV (named the PCE Discovery TLV (PCED TLV)) to be carried within the OSPF Router Information LSA ([RFC4970]).
本文档定义了OSPF路由器信息LSA（[RFC4970]）中携带的新TLV（名为PCE发现TLV（PCED TLV））。
The PCE information advertised is detailed in Section 3. Protocol extensions and procedures are defined in Sections 4 and 5.
第3节详细介绍了公布的PCE信息。第4节和第5节定义了协议扩展和程序。
The OSPF extensions defined in this document allow for PCE discovery within an OSPF routing domain. Solutions for PCE discovery across Autonomous System boundaries are beyond the scope of this document, and are for further study.
本文档中定义的OSPF扩展允许在OSPF路由域中发现PCE。跨自主系统边界的PCE发现解决方案超出了本文档的范围，有待进一步研究。
ABR: OSPF Area Border Router.
OSPF区域边界路由器。
AS: Autonomous System.
AS：自治系统。
IGP: Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
IGP：内部网关协议。两种路由协议之一，开放最短路径优先（OSPF）或中间系统到中间系统（IS-IS）。
Intra-area TE LSP: A TE LSP whose path does not cross an IGP area boundary.
区域内TE LSP：路径不穿过IGP区域边界的TE LSP。
Intra-AS TE LSP: A TE LSP whose path does not cross an AS boundary.
内部AS TE LSP：路径不跨越AS边界的TE LSP。
Inter-area TE LSP: A TE LSP whose path transits two or more IGP areas. That is, a TE LSP that crosses at least one IGP area boundary.
区域间TE LSP：路径穿过两个或多个IGP区域的TE LSP。即，穿过至少一个IGP区域边界的TE LSP。
Inter-AS TE LSP: A TE LSP whose path transits two or more ASes or sub-ASes (BGP confederations). That is, a TE LSP that crosses at least one AS boundary.
内部AS TE LSP：路径通过两个或多个ASE或子ASE（BGP联盟）的TE LSP。即，跨越至少一个AS边界的TE LSP。
LSA: Link State Advertisement.
链接状态广告。
LSR: Label Switching Router.
标签交换路由器。
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：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCED: PCE Discovery.
PCE：PCE发现。
PCE-Domain: In a PCE context, this refers to any collection of network elements within a common sphere of address management or path computational responsibility (referred to as a "domain" in [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. This should be distinguished from an OSPF routing domain.
PCE域：在PCE上下文中，这是指地址管理或路径计算责任（在[RFC4655]中称为“域”）的公共范围内的任何网络元素集合。PCE结构域的示例包括IGP区域和ASE。这应该区别于OSPF路由域。
PCEP: Path Computation Element communication Protocol.
PCEP：路径计算元素通信协议。
TE LSP: Traffic Engineered Label Switched Path.
TE LSP：流量工程标签交换路径。
TLV: Type-Length-Variable data encoding.
TLV：类型长度变量数据编码。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
IS-IS extensions for PCE discovery are defined in [RFC5089].
[RFC5089]中定义了用于PCE发现的IS-IS扩展。
The PCE discovery information is composed of:
PCE发现信息由以下部分组成：
- The PCE location: an IPv4 and/or IPv6 address that is used to reach the PCE. It is RECOMMENDED to use an address that is always reachable if there is any connectivity to the PCE;
- PCE位置：用于到达PCE的IPv4和/或IPv6地址。如果与PCE有任何连接，建议使用始终可访问的地址；
- The PCE path computation scope (i.e., intra-area, inter-area, inter-AS, or inter-layer);
- PCE路径计算范围（即，区域内、区域间、AS间或层间）；
- The set of one or more PCE-Domain(s) into which the PCE has visibility and for which the PCE can compute paths;
- 一个或多个PCE域的集合，其中PCE具有可见性并且PCE可以为其计算路径；
- The set of zero, one, or more neighbor PCE-Domain(s) toward which the PCE can compute paths;
- 零个、一个或多个相邻PCE域的集合，PCE可向其计算路径；
- A set of communication capabilities (e.g., support for request prioritization) and path computation-specific capabilities (e.g., supported constraints).
- 一组通信能力（例如，支持请求优先级）和路径计算特定能力（例如，支持的约束）。
PCE discovery information is, by nature, fairly static and does not change with PCE activity. Changes in PCE discovery information may occur as a result of PCE configuration updates, PCE deployment/activation, PCE deactivation/suppression, or PCE failure. Hence, this information is not expected to change frequently.
PCE发现信息本质上是静态的，不随PCE活动而变化。PCE发现信息的更改可能是PCE配置更新、PCE部署/激活、PCE停用/抑制或PCE故障的结果。因此，该信息预计不会经常更改。
The flooding scope for PCE information advertised through OSPF can be limited to one or more OSPF areas the PCE belongs to, or can be extended across the entire OSPF routing domain.
通过OSPF公布的PCE信息的泛洪范围可以限制在PCE所属的一个或多个OSPF区域，或者可以扩展到整个OSPF路由域。
Note that some PCEs may belong to multiple areas, in which case the flooding scope may comprise these areas. This could be the case for an ABR, for instance, advertising its PCE information within the backbone area and/or a subset of its attached IGP area(s).
注意，一些PCE可能属于多个区域，在这种情况下，洪水范围可能包括这些区域。这可能是ABR的情况，例如，在主干区域和/或其连接的IGP区域的子集内宣传其PCE信息。
The OSPF PCE Discovery TLV (PCED TLV) contains a non-ordered set of sub-TLVs.
OSPF PCE发现TLV（PCED TLV）包含一组非有序的子TLV。
The format of the OSPF PCED TLV and its sub-TLVs is identical to the TLV format used by the Traffic Engineering Extensions to OSPF [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a value field. The Length field defines the length of the value portion in octets.
OSPF PCED TLV及其子TLV的格式与OSPF[RFC3630]流量工程扩展使用的TLV格式相同。也就是说，TLV由类型的2个八位字节、指定TLV长度的2个八位字节和一个值字段组成。长度字段定义值部分的长度（以八位字节为单位）。
The TLV is padded to 4-octet alignment; padding is not included in the Length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 4-octet aligned. Unrecognized types are ignored.
TLV填充为4-八位组对齐；长度字段中不包括填充（因此3个八位字节的值的长度为3，但TLV的总大小为8个八位字节）。嵌套TLV也是4-八位组对齐的。将忽略无法识别的类型。
The OSPF PCED TLV has the following format:
OSPF PCED TLV具有以下格式：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 Length: Variable Value: This comprises one or more sub-TLVs
类型：6长度：变量值：这包括一个或多个子TLV
Five sub-TLVs are defined: Sub-TLV type Length Name 1 variable PCE-ADDRESS sub-TLV 2 4 PATH-SCOPE sub-TLV 3 4 PCE-DOMAIN sub-TLV 4 4 NEIG-PCE-DOMAIN sub-TLV 5 variable PCE-CAP-FLAGS sub-TLV
定义了五个子TLV：子TLV类型长度名称1变量PCE地址子TLV 2 4路径范围子TLV 3 4 PCE域子TLV 4 NEIG-PCE域子TLV 5变量PCE-CAP-FLAGS子TLV
The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within the PCED TLV.
PCE地址和路径范围子TLV必须始终存在于PCED TLV中。
The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY be present in the PCED TLV to facilitate selection of inter-domain PCEs.
PCE域和NEIG-PCE域子TLV是可选的。它们可能存在于PCED TLV中，以促进域间PCE的选择。
The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED TLV to facilitate the PCE selection process.
PCE-CAP-FLAGS子TLV是可选的，可以存在于PCED TLV中，以促进PCE选择过程。
Malformed PCED TLVs or sub-TLVs not explicitly described in this document MUST cause the LSA to be treated as malformed according to the normal procedures of OSPF.
本文件中未明确描述的畸形PCED TLV或子TLV必须根据OSPF的正常程序将LSA视为畸形。
Any unrecognized sub-TLV MUST be silently ignored.
任何无法识别的子TLV都必须以静默方式忽略。
The PCED TLV is carried within an OSPF Router Information LSA defined in [RFC4970].
PCED TLV在[RFC4970]中定义的OSPF路由器信息LSA中携带。
No additional sub-TLVs will be added to the PCED TLV in the future. If a future application requires the advertisement of additional PCE information in OSPF, this will not be carried in the Router Information LSA.
未来不会向PCED TLV添加额外的子TLV。如果未来的应用程序需要在OSPF中公布额外的PCE信息，这将不会在路由器信息LSA中进行。
The following sub-sections describe the sub-TLVs that may be carried within the PCED TLV.
以下小节描述了PCED TLV内可能携带的子TLV。
The PCE-ADDRESS sub-TLV specifies an IP address that can be used to reach the PCE. It is RECOMMENDED to make use of an address that is always reachable, provided that the PCE is alive and reachable.
PCE-ADDRESS子TLV指定可用于访问PCE的IP地址。建议使用始终可访问的地址，前提是PCE处于活动状态且可访问。
The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 address. It MUST NOT appear more than once for the same address type. If it appears more than once for the same address type, only the first occurrence is processed and any others MUST be ignored.
PCE地址子TLV是强制性的；它必须存在于PCED TLV内。当PCE同时具有IPv4和IPv6地址时，它可能会出现两次。对于同一地址类型，它不能出现多次。如果同一地址类型多次出现，则只处理第一次出现的内容，而必须忽略任何其他内容。
The format of the PCE-ADDRESS sub-TLV is as follows:
PCE-ADDRESS子TLV的格式如下：
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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP Address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP Address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-ADDRESS sub-TLV format
PCE地址子TLV格式
Type: 1 Length: 8 (IPv4) or 20 (IPv6)
类型：1长度：8（IPv4）或20（IPv6）
Address-type: 1 IPv4 2 IPv6
地址类型：1 IPv4 2 IPv6
Reserved: SHOULD be set to zero on transmission and MUST be ignored on receipt.
保留：传输时应设置为零，接收时必须忽略。
PCE IP Address: The IP address to be used to reach the PCE.
PCE IP地址：用于到达PCE的IP地址。
The PATH-SCOPE sub-TLV indicates the PCE path computation scope, which refers to the PCE's ability to compute or take part in the computation of paths for intra-area, inter-area, inter-AS, or inter-layer TE LSPs.
PATH-SCOPE子TLV指示PCE路径计算范围，其指PCE计算或参与区域内、区域间、AS间或层间TE LSP的路径计算的能力。
The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub-TLV within each PCED TLV. If it appears more than once, only the first occurrence is processed and any others MUST be ignored.
路径范围子TLV是强制性的；它必须存在于PCED TLV内。在每个PCED TLV中必须恰好有一个PATH-SCOPE子TLV实例。如果它出现多次，则只处理第一次出现的内容，而必须忽略任何其他内容。
The PATH-SCOPE sub-TLV contains a set of bit-flags indicating the supported path scopes, and four fields indicating PCE preferences.
PATH-SCOPE子TLV包含一组指示支持的路径范围的位标志，以及四个指示PCE首选项的字段。
The PATH-SCOPE sub-TLV has the following format:
PATH-SCOPE子TLV具有以下格式：
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 = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 Length: 4 Value: This comprises a 2-octet flags field where each bit represents a supported path scope, as well as four preference fields used to specify PCE preferences.
类型：2长度：4值：这包括一个2位八位组标志字段，其中每个位表示支持的路径范围，以及四个用于指定PCE首选项的首选项字段。
The following bits are defined:
定义了以下位：
Bit Path Scope
位路径范围
0 L bit: Can compute intra-area paths. 1 R bit: Can act as PCE for inter-area TE LSP computation. 2 Rd bit: Can act as a default PCE for inter-area TE LSP computation. 3 S bit: Can act as PCE for inter-AS TE LSP computation. 4 Sd bit: Can act as a default PCE for inter-AS TE LSP computation. 5 Y bit: Can act as PCE for inter-layer TE LSP computation.
0 L位：可以计算区域内路径。1 R位：可用作区域间TE LSP计算的PCE。第2位：可作为区域间TE LSP计算的默认PCE。3s位：可作为PCE用于内部as TE LSP计算。4 Sd位：可作为as TE LSP计算的默认PCE。5Y位：可作为层间TE LSP计算的PCE。
PrefL field: PCE's preference for intra-area TE LSP computation.
PrefL字段：PCE对区域内TE LSP计算的偏好。
PrefR field: PCE's preference for inter-area TE LSP computation.
PrefR字段：PCE对区域间TE LSP计算的偏好。
PrefS field: PCE's preference for inter-AS TE LSP computation.
PrefS字段：PCE对内部AS TE LSP计算的偏好。
PrefY field: PCE's preference for inter-layer TE LSP computation.
PrefY字段：PCE对层间TE LSP计算的偏好。
Res: Reserved for future use.
Res：保留供将来使用。
The L, R, S, and Y bits are set when the PCE can act as a PCE for intra-area, inter-area, inter-AS, or inter-layer TE LSP computation, respectively. These bits are non-exclusive.
当PCE可以分别作为用于区域内、区域间、as间或层间TE LSP计算的PCE时，设置L、R、S和Y比特。这些位是非独占的。
When set, the Rd bit indicates that the PCE can act as a default PCE for inter-area TE LSP computation (that is, the PCE can compute a path toward any neighbor area). Similarly, when set, the Sd bit indicates that the PCE can act as a default PCE for inter-AS TE LSP computation (the PCE can compute a path toward any neighbor AS).
当设置时，Rd位指示PCE可以充当用于区域间TE LSP计算的默认PCE（即，PCE可以计算到任何相邻区域的路径）。类似地，当设置时，Sd位指示PCE可以充当as-TE-LSP计算的默认PCE（PCE可以计算到任何相邻as的路径）。
When the Rd and Sd bit are set, the PCED TLV MUST NOT contain a NEIG-PCE-DOMAIN sub-TLV (see Section 4.4).
设置Rd和Sd位时，PCED TLV不得包含NEIG-PCE域子TLV（见第4.4节）。
When the R bit is clear, the Rd bit SHOULD be clear on transmission and MUST be ignored on receipt. When the S bit is clear, the Sd bit SHOULD be clear on transmission and MUST be ignored on receipt.
当R位清除时，Rd位在传输时应清除，在接收时必须忽略。当S位清除时，Sd位在传输时应清除，在接收时必须忽略。
The PrefL, PrefR, PrefS, and PrefY fields are each three bits long and allow the PCE to specify a preference for each computation scope, where 7 reflects the highest preference. Such preferences can be used for weighted load balancing of path computation requests. An operator may decide to configure a preference for each computation scope at each PCE so as to balance the path computation load among
PrefL、PrefR、PrefS和PrefY字段的长度均为三位，允许PCE为每个计算范围指定首选项，其中7表示最高首选项。这样的首选项可用于路径计算请求的加权负载平衡。操作员可以决定在每个PCE处为每个计算范围配置偏好，以便平衡路径计算负载
them. The algorithms used by a PCC to load balance its path computation requests according to such PCE preferences is out of the scope of this document and is a matter for local or network-wide policy. The same or different preferences may be used for each scope. For instance, an operator that wants a PCE capable of both inter-area and inter-AS computation to be preferred for use for inter-AS computations may configure PrefS higher than PrefR.
他们PCC根据此类PCE首选项对其路径计算请求进行负载平衡所使用的算法不在本文档的范围内，属于本地或网络范围内的策略问题。每个作用域可以使用相同或不同的首选项。例如，希望能够同时进行区域间和区域间AS计算的PCE优先用于区域间AS计算的运营商可以将PREF配置为高于PrefR。
When the L, R, S, or Y bits are cleared, the PrefL, PrefR, PrefS, and PrefY fields SHOULD respectively be set to 0 on transmission and MUST be ignored on receipt.
清除L、R、S或Y位时，传输时应将PrefL、PrefR、PrefS和PrefY字段分别设置为0，接收时必须忽略。
Both reserved fields SHOULD be set to zero on transmission and MUST be ignored on receipt.
两个保留字段在传输时都应设置为零，在接收时必须忽略。
The PCE-DOMAIN sub-TLV specifies a PCE-Domain (area or AS) where the PCE has topology visibility and through which the PCE can compute paths.
PCE-DOMAIN子TLV指定PCE具有拓扑可见性的PCE域（区域或AS），PCE可以通过该域计算路径。
The PCE-DOMAIN sub-TLV SHOULD be present when PCE-Domains for which the PCE can operate cannot be inferred by other IGP information: for instance, when the PCE is inter-domain capable (i.e., when the R bit or S bit is set) and the flooding scope is the entire routing domain (see Section 5 for a discussion of how the flooding scope is set and interpreted).
当PCE可操作的PCE域不能由其他IGP信息推断时，应存在PCE域子TLV：例如，当PCE具有域间能力（即，设置了R位或S位）且泛洪范围为整个路由域时（有关如何设置和解释洪水范围的讨论，请参见第5节）。
A PCED TLV may include multiple PCE-DOMAIN sub-TLVs when the PCE has visibility into multiple PCE-Domains.
当PCE可以看到多个PCE域时，PCE TLV可以包括多个PCE域子TLV。
The PCE-DOMAIN sub-TLV has the following format:
PCE域子TLV具有以下格式：
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 = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-DOMAIN sub-TLV format
PCE域子TLV格式
Type: 3 Length: 8
类型：3长度：8
Two domain-type values are defined: 1 OSPF Area ID 2 AS Number
定义了两个域类型值：1 OSPF区域ID 2作为编号
Domain ID: With the domain-type set to 1, this indicates the 32-bit Area ID of an area where the PCE has visibility and can compute paths. With domain-type set to 2, this indicates an AS number of an AS where the PCE has visibility and can compute paths. When the AS number is coded in two octets, the AS Number field MUST have its first two octets set to 0.
域ID：域类型设置为1时，表示PCE具有可见性并可以计算路径的区域的32位区域ID。当域类型设置为2时，这表示PCE具有可见性并可以计算路径的AS数。当AS编号编码为两个八位字节时，AS编号字段的前两个八位字节必须设置为0。
The NEIG-PCE-DOMAIN sub-TLV specifies a neighbor PCE-Domain (area or AS) toward which a PCE can compute paths. It means that the PCE can take part in the computation of inter-domain TE LSPs with paths that transit this neighbor PCE-Domain.
NEIG-PCE-DOMAIN子TLV指定PCE可以计算路径的相邻PCE域（区域或AS）。这意味着PCE可以参与域间TE LSP的计算，其路径通过该相邻PCE域。
A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the PCE can compute paths towards several neighbor PCE-Domains.
当PCE可以计算到多个相邻PCE域的路径时，PCE子TLV可以包括多个NEIG-PCE域子TLV。
The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN sub-TLV:
NEIG-PCE域子TLV与PCE域子TLV的格式相同：
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 = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEIG-PCE-DOMAIN sub-TLV format
NEIG-PCE-DOMAIN子TLV格式
Type: 4 Length: 8
类型：4长度：8
Two domain-type values are defined: 1 OSPF Area ID 2 AS Number
定义了两个域类型值：1 OSPF区域ID 2作为编号
Domain ID: With the domain-type set to 1, this indicates the 32-bit Area ID of a neighbor area toward which the PCE can compute paths. With domain-type set to 2, this indicates the AS number of
域ID：域类型设置为1时，表示PCE可以计算路径的相邻区域的32位区域ID。当域类型设置为2时，这表示的是
a neighbor AS toward which the PCE can compute paths. When the AS number is coded in two octets, the AS Number field MUST have its first two octets set to 0.
PCE可以计算路径的邻居AS。当AS编号编码为两个八位字节时，AS编号字段的前两个八位字节必须设置为0。
The NEIG-PCE-DOMAIN sub-TLV MUST be present at least once with domain-type set to 1 if the R bit is set and the Rd bit is cleared, and MUST be present at least once with domain-type set to 2 if the S bit is set and the Sd bit is cleared.
如果设置了R位且清除了Rd位，则NEIG-PCE-DOMAIN子TLV必须在域类型设置为1时至少出现一次，如果设置了S位且清除了Sd位，则必须在域类型设置为2时至少出现一次。
The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE capabilities. It MAY be present within the PCED TLV. It MUST NOT be present more than once. If it appears more than once, only the first occurrence is processed and any others MUST be ignored.
PCE-CAP-FLAGS子TLV是用于指示PCE能力的可选子TLV。它可能存在于PCED TLV内。它不能出现超过一次。如果它出现多次，则只处理第一次出现的内容，而必须忽略任何其他内容。
The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array of units of 32-bit flags numbered from the most significant bit as bit zero, where each bit represents one PCE capability.
PCE-CAP-FLAGS子TLV的值字段由一组32位标志组成，这些标志从最高有效位开始编号为零位，其中每个位表示一个PCE能力。
The format of the PCE-CAP-FLAGS sub-TLV is as follows:
PCE-CAP-FLAGS子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 = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE Capability Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE Capability Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 Length: Multiple of 4 octets Value: This contains an array of units of 32-bit flags numbered from the most significant as bit zero, where each bit represents one PCE capability.
类型：5长度：4个八位字节值的倍数：该值包含一个32位标志单元数组，从最高有效位开始编号为零位，其中每个位表示一个PCE功能。
IANA will manage the space of the PCE Capability Flags.
IANA将管理PCE能力标志的空间。
The following bits have been assigned by IANA:
IANA分配了以下位：
Bit Capabilities
比特能力
0 Path computation with GMPLS link constraints 1 Bidirectional path computation 2 Diverse path computation 3 Load-balanced path computation 4 Synchronized path computation 5 Support for multiple objective functions 6 Support for additive path constraints (max hop count, etc.) 7 Support for request prioritization 8 Support for multiple requests per message
0带有GMPLS链路约束的路径计算1双向路径计算2不同路径计算3负载平衡路径计算4同步路径计算5支持多目标函数6支持附加路径约束（最大跳数等）7对请求优先级的支持8对每条消息的多个请求的支持
9-31 Reserved for future assignments by IANA.
9-31保留供IANA未来分配。
These capabilities are defined in [RFC4657].
这些功能在[RFC4657]中有定义。
Reserved bits SHOULD be set to zero on transmission and MUST be ignored on receipt.
保留位在传输时应设置为零，在接收时必须忽略。
The PCED TLV is advertised within OSPFv2 Router Information LSAs (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router Information LSAs (function code of 12), which are defined in [RFC4970]. As such, elements of procedure are inherited from those defined in [RFC4970].
PCED TLV在[RFC4970]中定义的OSPFv2路由器信息LSA（不透明类型为4，不透明ID为0）或OSPFv3路由器信息LSA（功能代码为12）中公布。因此，程序元素继承自[RFC4970]中定义的元素。
In OSPFv2, the flooding scope is controlled by the opaque LSA type (as defined in [RFC2370]) and in OSPFv3, by the S1/S2 bits (as defined in [RFC2740]). If the flooding scope is area local, then the PCED TLV MUST be carried within an OSPFv2 type 10 router information LSA or an OSPFV3 Router Information LSA with the S1 bit set and the S2 bit clear. If the flooding scope is the entire IGP domain, then the PCED TLV MUST be carried within an OSPFv2 type 11 Router Information LSA or OSPFv3 Router Information LSA with the S1 bit clear and the S2 bit set. When only the L bit of the PATH-SCOPE sub-TLV is set, the flooding scope MUST be area local.
在OSPFv2中，泛洪范围由不透明LSA类型（定义见[RFC2370]）控制，在OSPFv3中由S1/S2位（定义见[RFC2740]）控制。如果泛洪范围为区域本地，则PCED TLV必须携带在设置了S1位且清除了S2位的OSPFv2类型10路由器信息LSA或OSPFV3路由器信息LSA内。如果泛洪范围是整个IGP域，则PCED TLV必须在S1位清除和S2位设置的OSPFv2类型11路由器信息LSA或OSPFv3路由器信息LSA内携带。当仅设置PATH-SCOPE子TLV的L位时，泛洪范围必须为区域本地。
When the PCE function is deactivated, the OSPF speaker advertising this PCE MUST originate a new Router Information LSA that no longer includes the corresponding PCED TLV, provided there are other TLVs in the LSA. If there are no other TLVs in the LSA, it MUST either send an empty Router Information LSA or purge it by prematurely aging it.
当PCE功能停用时，播发该PCE的OSPF扬声器必须发起新的路由器信息LSA，该信息LSA不再包括相应的PCED TLV，前提是LSA中存在其他TLV。如果LSA中没有其他TLV，它必须向LSA发送一个空的路由器信息，或者通过提前老化将其清除。
The PCE address (i.e., the address indicated within the PCE-ADDRESS sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF.
PCE地址（即PCE-address子TLV中指示的地址）应可通过OSPF公布的某些前缀访问。
The PCED TLV information regarding a specific PCE is only considered current and useable when the router advertising this information is itself reachable via OSPF calculated paths in the same area of the LSA in which the PCED TLV appears.
仅当播发该信息的路由器本身可通过出现PCED-TLV的LSA的同一区域中的OSPF计算路径到达时，才认为关于特定PCE的PCED-TLV信息是当前的和可用的。
A change in the state of a PCE (activate, deactivate, parameter change) MUST result in a corresponding change in the PCED TLV information advertised by an OSPF router (inserted, removed, updated) in its LSA. The way PCEs determine the information they advertise, and how that information is made available to OSPF, is out of the scope of this document. Some information may be configured (e.g., address, preferences, scope) and other information may be automatically determined by the PCE (e.g., areas of visibility).
PCE状态的变化（激活、停用、参数变化）必须导致OSPF路由器（插入、移除、更新）在其LSA中公布的PCED TLV信息发生相应变化。PCE确定其广告信息的方式，以及如何向OSPF提供这些信息，不在本文件的范围之内。一些信息可以配置（例如，地址、偏好、范围），其他信息可以由PCE自动确定（例如，可视区域）。
A change in information in the PCED TLV MUST NOT trigger any SPF computation at a receiving router.
PCED TLV中信息的变化不得触发接收路由器上的任何SPF计算。
The PCED TLV defined in this document does not introduce any interoperability issues.
本文件中定义的PCED TLV不引入任何互操作性问题。
A router not supporting the PCED TLV will just silently ignore the TLV as specified in [RFC4970].
不支持PCED TLV的路由器只会按照[RFC4970]中的规定默默忽略TLV。
IANA has defined a registry for TLVs carried in the Router Information LSA defined in [RFC4970]. IANA has assigned a new TLV codepoint for the PCED TLV carried within the Router Information LSA.
IANA已经为[RFC4970]中定义的路由器信息LSA中携带的TLV定义了一个注册表。IANA已为路由器信息LSA中携带的PCED TLV分配了新的TLV码点。
Value TLV Name Reference
----- -------- ----------
6 PCED (this document)
Value TLV Name Reference
----- -------- ----------
6 PCED (this document)
This document provides new capability bit flags, which are present in the PCE-CAP-FLAGS TLV referenced in Section 4.1.5.
本文件提供了新的功能位标志，这些标志出现在第4.1.5节中引用的PCE-CAP-flags TLV中。
The IANA has created a new top-level OSPF registry, the "PCE Capability Flags" registry, and will manage the space of PCE capability bit flags numbering them in the usual IETF notation starting at zero and continuing at least through 31, with the most significant bit as bit zero.
IANA已经创建了一个新的顶级OSPF注册表，“PCE能力标志”注册表，并将管理PCE能力位标志的空间，以通常的IETF符号对其进行编号，从零开始，至少持续到31，最高有效位为零位。
New bit numbers may be allocated only by an IETF Consensus action.
新的位号只能由IETF一致行动分配。
Each bit should be tracked with the following qualities:
应按照以下质量跟踪每个位：
- Bit number - Capability Description - Defining RFC
- 位号-能力描述-定义RFC
Several bits are defined in this document. The following values have been assigned:
本文档中定义了几个位。已指定以下值：
Bit Capability Description
比特能力描述
0 Path computation with GMPLS link constraints 1 Bidirectional path computation 2 Diverse path computation 3 Load-balanced path computation 4 Synchronized paths computation 5 Support for multiple objective functions 6 Support for additive path constraints (max hop count, etc.) 7 Support for request prioritization 8 Support for multiple requests per message
0带有GMPLS链路约束的路径计算1双向路径计算2多样路径计算3负载平衡路径计算4同步路径计算5支持多目标函数6支持附加路径约束（最大跳数等）7对请求优先级的支持8对每条消息的多个请求的支持
This document defines OSPF extensions for PCE discovery within an administrative domain. Hence the security of the PCE discovery relies on the security of OSPF.
本文档定义了用于管理域内PCE发现的OSPF扩展。因此，PCE发现的安全性依赖于OSPF的安全性。
Mechanisms defined to ensure authenticity and integrity of OSPF LSAs [RFC2154], and their TLVs, can be used to secure the PCE Discovery information as well.
为确保OSPF LSA[RFC2154]及其TLV的真实性和完整性而定义的机制也可用于保护PCE发现信息。
OSPF provides no encryption mechanism for protecting the privacy of LSAs and, in particular, the privacy of the PCE discovery information.
OSPF不提供加密机制来保护LSA的隐私，尤其是PCE发现信息的隐私。
Manageability considerations for PCE Discovery are addressed in Section 4.10 of [RFC4674].
[RFC4674]第4.10节介绍了PCE发现的可管理性注意事项。
Requirements for the configuration of PCE discovery parameters on PCCs and PCEs are discussed in Section 4.10.1 of [RFC4674].
[RFC4674]第4.10.1节讨论了PCC和PCE上PCE发现参数的配置要求。
In particular, a PCE implementation SHOULD allow the following parameters to be configured on the PCE:
具体而言，PCE实现应允许在PCE上配置以下参数：
- The PCE IPv4/IPv6 address(es) (see Section 4.1).
- PCE IPv4/IPv6地址（见第4.1节）。
- The PCE Scope, including the inter-domain functions (inter-area, inter-AS, inter-layer), the preferences, and whether the PCE can act as default PCE (see Section 4.2).
- PCE范围，包括域间功能（区域间、AS间、层间）、首选项以及PCE是否可以作为默认PCE（见第4.2节）。
- The PCE-Domains (see Section 4.3).
- PCE领域（见第4.3节）。
- The neighbor PCE-Domains (see Section 4.4).
- 相邻的PCE域（见第4.4节）。
- The PCE capabilities (see Section 4.5).
- PCE能力（见第4.5节）。
A MIB module for PCE Discovery is defined in [PCED-MIB].
用于PCE发现的MIB模块在[PCED-MIB]中定义。
This document specifies the use of OSPF as a PCE Discovery Protocol. The requirements specified in [RFC4674] include the ability to determine liveness of the PCE Discovery protocol. Normal operation of the OSPF protocol meets these requirements.
本文件规定了OSPF作为PCE发现协议的使用。[RFC4674]中规定的要求包括确定PCE发现协议活性的能力。OSPF协议的正常运行符合这些要求。
The correlation of information advertised against information received can be achieved by comparing the information in the PCED TLV received by the PCC with that stored at the PCE using the PCED MIB [PCED-MIB]. The number of dropped, corrupt, and rejected information elements are available through the PCED MIB.
通过将PCC接收到的PCED TLV中的信息与使用PCED MIB[PCED-MIB]存储在PCE中的信息进行比较，可以实现广告信息与接收到的信息的相关性。丢弃、损坏和拒绝的信息元素的数量可通过PCED MIB获得。
The OSPF extensions defined in this document do not imply any requirement on other protocols.
本文件中定义的OSPF扩展并不意味着对其他协议有任何要求。
Frequent changes in PCE information advertised in the PCED TLV, may have a significant impact on OSPF and might destabilize the operation of the network by causing the PCCs to swap between PCEs.
PCED TLV中公布的PCE信息的频繁变化可能对OSPF产生重大影响，并可能导致PCC在PCE之间交换，从而使网络运行不稳定。
As discussed in Section 4.10.4 of [RFC4674], it MUST be possible to apply at least the following controls:
如[RFC4674]第4.10.4节所述，必须能够至少应用以下控制：
- Configurable limit on the rate of announcement of changed parameters at a PCE.
- 在PCE上公布更改参数的速率的可配置限制。
- Control of the impact on PCCs, such as through rate-limiting the processing of PCED TLVs.
- 控制对PCC的影响，例如通过限制PCED TLV的处理速率。
- Configurable control of triggers that cause a PCC to swap to another PCE.
- 可配置触发器控制，使PCC交换到另一个PCE。
We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike Shand, and Lou Berger for their useful comments and suggestions.
我们要感谢Lucy Wong、Adrian Farrel、Les Ginsberg、Mike Shand和Lou Berger提出的有用意见和建议。
We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, Tim Polk, and Lisa Dusseault for their comments during the final stages of publication.
我们还要感谢Dave Ward、Lars Eggert、Sam Hartman、Tim Polk和Lisa Dusseault在本书最后阶段发表的评论。
[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月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370]Coltun，R.，“OSPF不透明LSA选项”，RFC 23701998年7月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[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月。
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 49702007年7月。
[PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path Computation Element Discovery", Work in Progress, March 2007.
[PCED-MIB]Stephan，E.“路径计算元素发现的托管对象定义”，正在进行的工作，2007年3月。
[PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) ", Work in Progress, November 2007.
[PCEP]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.，“路径计算元素（PCE）通信协议（PCEP）”，正在进行的工作，2007年11月。
[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月。
[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月。
Authors' Addresses
作者地址
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux（编辑）法国电信2号，Pierre Marzin大街22307 Lannion Cedex法国电子邮件：jeanlouis。leroux@orange-ftgroup.com
Jean-Philippe Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur（编辑）思科系统公司，地址：美国马萨诸塞州伯斯堡马萨诸塞大道1414号邮编：01719电子邮件：jpv@cisco.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 JAPAN EMail: y.ikejiri@ntt.com
Yuichi Ikejiri NTT通信公司1-1-6，日本东京千代田区内井町100-8019电子邮件：y。ikejiri@ntt.com
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: raymond.zhang@bt.com
雷蒙德张BT 2160东大大道埃尔塞贡多，加利福尼亚州90025美国电子邮件：雷蒙德。zhang@bt.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.