Network Working Group J.L. Le Roux, Ed.
Request for Comments: 4674 France Telecom
Category: Informational October 2006
Network Working Group J.L. Le Roux, Ed.
Request for Comments: 4674 France Telecom
Category: Informational October 2006
Requirements for Path Computation Element (PCE) Discovery
路径计算元素（PCE）发现的要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.
本文档介绍了一组路径计算元素（PCE）发现机制的要求，该机制允许路径计算客户端（PCC）动态自动地发现一组PCE以及与PCE选择相关的某些信息。旨在为此类PCE发现指定程序和协议或现有协议扩展的解决方案满足这些要求。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Problem Statement and Requirements Overview .....................4
2.1. Problem Statement ..........................................4
2.2. Requirements Overview ......................................5
3. Example of Application Scenario .................................6
4. Detailed Requirements ...........................................7
4.1. PCE Information to Be Disclosed ............................7
4.1.1. General PCE Information (Mandatory Support) .........8
4.1.1.1. Discovery of PCE Location ..................8
4.1.1.2. Discovery of PCE Domains and
Inter-domain Functions .....................8
4.1.2. Detailed PCE Information (Optional Support) .........9
4.1.2.1. Discovery of PCE Capabilities ..............9
4.1.2.2. Discovery of Alternate PCEs ...............10
4.2. Scope of PCE Discovery ....................................10
4.2.1. Inter-AS Specific Requirements .....................10
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Problem Statement and Requirements Overview .....................4
2.1. Problem Statement ..........................................4
2.2. Requirements Overview ......................................5
3. Example of Application Scenario .................................6
4. Detailed Requirements ...........................................7
4.1. PCE Information to Be Disclosed ............................7
4.1.1. General PCE Information (Mandatory Support) .........8
4.1.1.1. Discovery of PCE Location ..................8
4.1.1.2. Discovery of PCE Domains and
Inter-domain Functions .....................8
4.1.2. Detailed PCE Information (Optional Support) .........9
4.1.2.1. Discovery of PCE Capabilities ..............9
4.1.2.2. Discovery of Alternate PCEs ...............10
4.2. Scope of PCE Discovery ....................................10
4.2.1. Inter-AS Specific Requirements .....................10
4.3. PCE Information Synchronization ...........................11
4.4. Discovery of PCE Deactivation .............................11
4.5. Policy Support ............................................12
4.6. Security Requirements .....................................12
4.7. Extensibility .............................................13
4.8. Scalability ...............................................13
4.9. Operational Orders of Magnitudes ..........................13
4.10. Manageability Considerations .............................14
4.10.1. Configuration of PCE Discovery Parameters .........14
4.10.2. PCE Discovery MIB Modules .........................14
4.10.2.1. PCC MIB Module ...........................14
4.10.2.2. PCE MIB module ...........................15
4.10.3. Monitoring Protocol Operations ....................15
4.10.4. Impact on Network Operations ......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Contributors ...................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
4.3. PCE Information Synchronization ...........................11
4.4. Discovery of PCE Deactivation .............................11
4.5. Policy Support ............................................12
4.6. Security Requirements .....................................12
4.7. Extensibility .............................................13
4.8. Scalability ...............................................13
4.9. Operational Orders of Magnitudes ..........................13
4.10. Manageability Considerations .............................14
4.10.1. Configuration of PCE Discovery Parameters .........14
4.10.2. PCE Discovery MIB Modules .........................14
4.10.2.1. PCC MIB Module ...........................14
4.10.2.2. PCE MIB module ...........................15
4.10.3. Monitoring Protocol Operations ....................15
4.10.4. Impact on Network Operations ......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Contributors ...................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
The PCE-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing TE-LSP paths based on a network graph, and applying computational constraints. A PCE serves path computation requests sent by Path Computation Clients (PCC).
基于PCE的网络体系结构[RFC4655]将路径计算元素（PCE）定义为能够基于网络图计算TE-LSP路径并应用计算约束的实体。PCE为路径计算客户端（PCC）发送的路径计算请求提供服务。
A PCC is a client application requesting a path computation to be performed by a PCE. This can be, for instance, an LSR requesting a path for a TE-LSP for which it is the head-end, or a PCE requesting a path computation of another PCE (inter-PCE communication). The communication between a PCC and a PCE requires a client-server protocol whose generic requirements are listed in [RFC4657].
PCC是请求由PCE执行的路径计算的客户端应用程序。例如，这可以是LSR请求作为其前端的TE-LSP的路径，或者PCE请求另一PCE的路径计算（PCE间通信）。PCC和PCE之间的通信需要客户端-服务器协议，其一般要求在[RFC4657]中列出。
The PCE based architecture requires that a PCC be aware of the location of one or more PCEs in its domain, and also potentially of some PCEs in other domains, e.g., in case of inter-domain path computation.
基于PCE的体系结构要求PCC知道其域中的一个或多个PCE的位置，并且还可能知道其他域中的一些PCE的位置，例如，在域间路径计算的情况下。
In that context, it would be highly desirable to define a mechanism for automatic and dynamic PCE discovery, which would allow PCCs to automatically discover a set of PCEs, to determine additional information required for PCE selection, and to dynamically detect new PCEs or any modification of the PCEs' information. This includes the discovery by a PCC of a set of one or more PCEs in its domain, and potentially in some other domains. The latter is a desirable function in the case of inter-domain path computation, for example.
在这种情况下，非常希望定义一种自动和动态PCE发现机制，该机制将允许PCC自动发现一组PCE，确定PCE选择所需的附加信息，并动态检测新PCE或PCE信息的任何修改。这包括PCC在其域中发现一组或多个PCE，并且可能在一些其他域中发现。例如，在域间路径计算的情况下，后者是理想的函数。
This document lists a set of functional requirements for such an automatic and dynamic PCE discovery mechanism. Section 2 points out the problem statement. Section 3 illustrates an application scenario. Finally, Section 4 addresses detailed requirements.
本文档列出了此类自动和动态PCE发现机制的一组功能需求。第2节指出了问题陈述。第3节演示了一个应用程序场景。最后，第4节讨论了详细的需求。
It is intended that solutions that specify procedures and protocols or protocol extensions for PCE discovery satisfy these requirements. There is no intent either to specify solution-specific requirements or to make any assumption on the protocols that could be used for the discovery.
指定PCE发现程序和协议或协议扩展的解决方案旨在满足这些要求。不打算指定特定于解决方案的需求，也不打算对可用于发现的协议进行任何假设。
Note that requirements listed in this document apply equally to PCEs that are capable of computing paths in MPLS-TE-enabled networks and PCEs that are capable of computing paths in GMPLS-enabled networks (and PCEs capable of both).
请注意，本文件中列出的要求同样适用于能够在支持MPLS TE的网络中计算路径的PCE和能够在支持GMPLS的网络中计算路径的PCE（以及能够同时计算两者的PCE）。
It is also important to note that the notion of a PCC encompasses a PCE acting as PCC when requesting a path computation of another PCE (inter-PCE communication). Hence, this document does not make the distinction between PCE discovery by PCCs and PCE discovery by PCEs.
还必须注意，PCC的概念包括在请求另一PCE的路径计算（PCE间通信）时充当PCC的PCE。因此，本文件不区分PCC发现的PCE和PCE发现的PCE。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Terminology used in this document:
本文件中使用的术语：
LSR: Label Switch Router.
标签交换路由器。
TE-LSP: Traffic Engineered Label Switched Path.
TE-LSP：流量工程标签交换路径。
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：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
路径计算客户端。任何请求由路径计算元素执行的路径计算的客户端应用程序。
Interior Gateway Protocol (IGP) Area: OSPF Area or ISIS level/area.
内部网关协议（IGP）区域：OSPF区域或ISIS级别/区域。
ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router).
ABR:IGP区域边界路由器（OSPF ABR或ISIS L1L2路由器）。
AS: Autonomous System.
AS：自治系统。
ASBR: AS Border Router.
ASBR：作为边界路由器。
Intra-area TE LSP: A TE LSP whose path does not cross IGP area boundaries.
区域内TE LSP：路径不跨越IGP区域边界的TE LSP。
Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
区域间TE LSP：路径通过两个或多个IGP区域的TE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASs or sub-ASs (BGP confederations).
Inter-AS MPLS TE LSP：一种TE LSP，其路径通过两个或多个ASs或子ASs（BGP联盟）进行传输。
Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas and Autonomous Systems.
域：地址管理或路径计算责任的公共范围内的任何网络元素集合。域的示例包括IGP区域和自治系统。
A routing domain may, in practice, contain multiple PCEs:
实际上，路由域可能包含多个PCE：
- The path computation load may be balanced among a set of PCEs to improve scalability. - For the purpose of redundancy, primary and backup PCEs may be used. - PCEs may have distinct path computation capabilities (multi-constrained path computation, backup path computation, etc.). - In an inter-domain context, there can be several PCEs with distinct inter-domain functions (inter-area, inter-AS, inter-layer), each PCE being responsible for path computation in one or more domains.
- 可在一组PCE之间平衡路径计算负载，以提高可伸缩性。-出于冗余目的，可使用主PCE和备用PCE。-PCE可能具有不同的路径计算能力（多约束路径计算、备份路径计算等）——在域间上下文中，可以有多个具有不同域间功能（域间、域间、层间）的PCE，每个PCE负责一个或多个域中的路径计算。
In order to allow for effective PCE selection by PCCs, that is, to select the appropriate PCE based on its capabilities and perform efficient load balancing of requests, a PCC needs to know the location of PCEs in its domain, along with some information relevant to PCE selection, and also potentially needs to know the location of some PCEs in other domains, for inter-domain path computation purpose.
为了允许PCC进行有效的PCE选择，即根据其能力选择适当的PCE并对请求执行有效的负载平衡，PCC需要知道PCE在其域中的位置，以及与PCE选择相关的一些信息，还可能需要知道某些PCE在其他域中的位置，以便进行域间路径计算。
Such PCE information could be learned through manual configuration, on each PCC, of the set of PCEs along with their capabilities. Such a manual configuration approach may be sufficient, and even desired in some particular situations (e.g., inter-AS PCE discovery, where manual configuration of neighbor PCEs may be preferred for security reasons), but it obviously faces several limitations:
这种PCE信息可以通过在每个PCC上手动配置一组PCE及其功能来学习。这种手动配置方法可能足够了，甚至在某些特定情况下是需要的（例如，AS间PCE发现，出于安全原因，可能首选手动配置相邻PCE），但它显然面临一些限制：
- This may imply a substantial configuration overhead. - This would not allow a PCC to dynamically detect that a new PCE is available, that an existing PCE is no longer available, or that there is a change in the PCE's information.
- 这可能意味着大量的配置开销。-这将不允许PCC动态检测新PCE可用、现有PCE不再可用或PCE信息发生变化。
Furthermore, as with any manual configuration approach, there is a risk of configuration errors.
此外，与任何手动配置方法一样，存在配置错误的风险。
As an example, in a multi-area network made up of one backbone area and N peripheral areas, and where inter-area MPLS-TE path computation relies on multiple-PCE path computation with ABRs acting as PCEs, the backbone area would comprise at least N PCEs, and the configuration of PCC would be too cumbersome (e.g., in existing multi-area networks, N can be beyond fifty).
例如，在由一个主干区域和N个外围区域组成的多区域网络中，并且在区域间MPLS-TE路径计算依赖于多个PCE路径计算且abr充当PCE的情况下，主干区域将包括至少N个PCE，并且PCC的配置将过于繁琐（例如，在现有的多区域网络中，N可以超过50）。
Hence, an automated PCE discovery mechanism allowing a PCC to dynamically discover a set of PCEs is highly desirable.
因此，允许PCC动态地发现一组PCE的自动PCE发现机制是非常理想的。
A PCE discovery mechanism that satisfies the requirements set forth in this document MUST allow a PCC to automatically discover the location of one or more of the PCEs in its domain.
满足本文件规定要求的PCE发现机制必须允许PCC自动发现其域中一个或多个PCE的位置。
Where inter-domain path computation is required and policy permits, the PCE discovery method MUST allow a PCC to automatically discover the location of PCEs in other domains that can assist with inter-domain path computation.
在需要域间路径计算且策略允许的情况下，PCE发现方法必须允许PCC自动发现可协助域间路径计算的其他域中PCE的位置。
A PCE discovery mechanism MUST allow a PCC to discover the set of one or more domains where a PCE has TE topology visibility and can compute paths. It MUST also allow the discovery of the potential inter-domain path computation functions of a PCE (inter-area, inter-AS, inter-layer, etc.).
PCE发现机制必须允许PCC发现PCE具有TE拓扑可见性并可以计算路径的一个或多个域集。它还必须允许发现PCE的潜在域间路径计算功能（区域间、AS间、层间等）。
A PCE discovery mechanism MUST allow the control of the discovery scope, that is the set of one or more domains (areas, ASs) where information related to a given PCE has to be disclosed.
PCE发现机制必须允许控制发现范围，即一个或多个域（区域、ASs）的集合，其中必须披露与给定PCE相关的信息。
A PCE discovery mechanism MUST allow PCCs in a given discovery scope to dynamically discover that a new PCE has appeared or that there is a change in a PCE's information.
PCE发现机制必须允许给定发现范围内的PCC动态发现新PCE已出现或PCE信息有变化。
A PCE discovery mechanism MUST allow PCCs to dynamically discover that a PCE is no longer available.
PCE发现机制必须允许PCC动态发现PCE不再可用。
A PCE discovery mechanism MUST support security procedures. In particular, key consideration MUST be given in terms of how to establish a trust model for PCE discovery.
PCE发现机制必须支持安全过程。特别是，必须考虑如何为PCE发现建立信任模型。
OPTIONALLY, a PCE discovery mechanism MAY be used so as to disclose a set of detailed PCE capabilities so that the PCC may make advanced and informed choices about which PCE to use.
可选地，可以使用PCE发现机制以公开一组详细的PCE能力，从而PCC可以对使用哪个PCE做出高级和知情的选择。
<----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | |
| | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14
|
|
--
|S1|
--
<----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | |
| | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14
|
|
--
|S1|
--
Figure 1
图1
Figure 1 illustrates a multi-area/AS network with several PCEs:
图1显示了具有多个PCE的多区域/AS网络：
- The ABR R3 is a PCE that can take part in inter-area path computation. It can compute paths in area 1 and area 0. - The ABR R6 is a PCE that can take part in inter-area path computation. It can compute paths in area 0 and area 2. - The ASBR R9 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS1 towards AS2. - The ASBR R12 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS2 towards AS1. - The server S1 is a PCE that can be used to compute diverse paths and backup paths in area 1.
- The ABR R3 is a PCE that can take part in inter-area path computation. It can compute paths in area 1 and area 0. - The ABR R6 is a PCE that can take part in inter-area path computation. It can compute paths in area 0 and area 2. - The ASBR R9 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS1 towards AS2. - The ASBR R12 is a PCE that can take part in inter-AS path computation. It is responsible for path computation in AS2 towards AS1. - The server S1 is a PCE that can be used to compute diverse paths and backup paths in area 1.translate error, please retry
By meeting the requirements set out in this document, the PCE discovery mechanism will allow:
通过满足本文件规定的要求，PCE发现机制将允许：
- each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for inter-area path computation, and that R3 can compute paths in area 0 and area 1. - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for inter-area path computation, and that R6 can compute paths in area 2 and area 0. - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover R9 as a PCE for inter-AS path computation in AS1 towards AS2. - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover R12 as a PCE for inter-AS path computation in AS2 towards AS1. - each PCC in area 1 to dynamically discover S1, as a PCE for intra-area path computation in area1, and optionally to discover its path computation capabilities (diverse path computation and backup path computation).
- 区域1和0中的每个PCC动态发现R3，作为区域间路径计算的PCE，并且R3可以计算区域0和区域1中的路径。-区域0和2中的每个PCC动态发现R6，作为区域间路径计算的PCE，并且R6可以计算区域2和区域0中的路径。-AS1中的每个PCC和AS2中的一个或多个PCC动态发现R9作为PCE，用于AS1中通向AS2的as间路径计算。-AS2中的每个PCC和AS1中的一个或多个PCC动态发现R12作为PCE，用于AS2中通向AS1的as间路径计算。-区域1中的每个PCC动态发现S1，作为区域1中区域内路径计算的PCE，并可选地发现其路径计算能力（多样路径计算和备份路径计算）。
We distinguish two levels of PCE information to be disclosed by a PCE discovery mechanism:
我们将PCE发现机制披露的PCE信息分为两个级别：
- General information. Disclosure MUST be supported by the PCE discovery mechanism. - Detailed information. Disclosure MAY be supported by the PCE discovery mechanism.
- 一般信息。披露必须得到PCE发现机制的支持。-详细资料。本发明可由PCE发现机制支持。
The PCE discovery mechanism MUST allow disclosure of general PCE information that will allow PCCs to select appropriate PCEs. This comprises discovery of PCE location, PCE domains supported by the PCEs, and PCE inter-domain functions.
PCE发现机制必须允许披露一般PCE信息，以便PCC选择适当的PCE。这包括发现PCE位置、PCE支持的PCE域以及PCE域间功能。
The PCE discovery mechanism MAY also allow disclosure of detailed PCE information. This comprises any or all information about PCE path computation capabilities and alternate PCEs. This information is not part of PCE discovery; this is additional information that can facilitate the selection of a PCE by a PCC. Support of the exchange of this information is optional in the context of the PCE discovery mechanism itself. This does not mean that the availability of this information is optional in the PCE-based architecture, but such information could also be obtained by other mechanisms, such as the PCC-PCE communication protocol.
PCE发现机制还允许披露详细的PCE信息。这包括关于PCE路径计算能力和备用PCE的任何或所有信息。此信息不是PCE发现的一部分；这是可促进PCC选择PCE的附加信息。在PCE发现机制本身的上下文中，支持此信息的交换是可选的。这并不意味着该信息的可用性在基于PCE的体系结构中是可选的，但此类信息也可以通过其他机制获得，例如PCC-PCE通信协议。
The PCE discovery mechanism MUST allow the discovery, for a given PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE. This address will typically be an address that is always reachable, if there is any connectivity to the PCE.
PCE发现机制必须允许针对给定PCE发现用于到达PCE的IPv4和/或IPv6地址。如果与PCE有任何连接，则该地址通常是始终可访问的地址。
This address will be used by PCCs to communicate with a PCE, through a PCC-PCE communication protocol.
PCC将使用该地址通过PCC-PCE通信协议与PCE通信。
Inter-domain path computation is a key application of the PCE-based architecture. This can rely on a multiple-PCE path computation, where PCEs in each domain compute a part of the end-to-end path and collaborate with each other to find the end-to-end-path. Inter-domain path computation can also rely on a single-PCE path computation where a PCE has visibility inside multiple domains and can compute an entire end-to-end inter-domain path (that is, a path from the inter-domain TE-LSP head-end to the inter-domain TE-LSP tail end).
域间路径计算是基于PCE架构的关键应用。这可以依赖于多个PCE路径计算，其中每个域中的PCE计算端到端路径的一部分，并相互协作以找到端到端路径。域间路径计算还可以依赖于单个PCE路径计算，其中PCE在多个域内具有可见性，并且可以计算整个端到端域间路径（即，从域间TE-LSP前端到域间TE-LSP后端的路径）。
Hence, the PCE discovery mechanism MUST allow the discovery of the set of one or more domains where a PCE has visibility and can compute paths. These domains could be identified using a domain identifier: For instance, an IGP area can be identified by the Area ID (OSPF or ISIS), and an AS can be identified by the AS number.
因此，PCE发现机制必须允许发现一个或多个域集，其中PCE具有可见性并可以计算路径。这些域可以使用域标识符进行标识：例如，IGP区域可以通过区域ID（OSPF或ISIS）进行标识，AS区域可以通过AS编号进行标识。
Also the PCE discovery mechanism MUST allow discovery of the inter-domain functions of a PCE, i.e., whether a PCE can be used to compute or to take part in the computation of end-to-end paths across domain borders. The inter-domain functions include nonexhaustively: inter-area, inter-AS and inter-layer path computation. Note that these functions are not mutually exclusive.
此外，PCE发现机制必须允许发现PCE的域间功能，即PCE是否可用于计算或参与跨域边界的端到端路径的计算。域间函数包括非穷举的：域间、域间和层间路径计算。请注意，这些函数不是相互排斥的。
Note that the inter-domain functions are not necessarily inferred from the set of domains where a PCE has visibility. For instance, a PCE may have visibility limited to a single domain, but may be able to take part in the computation of inter-domain paths by collaborating with PCEs in other domains. Conversely, a PCE may have visibility in multiple domains, but the operator may not want the PCE to be used for inter-domain path computations.
请注意，域间函数不一定是从PCE具有可见性的域集合推断出来的。例如，PCE的可视性可能仅限于单个域，但是可以通过与其他域中的PCE协作来参与域间路径的计算。相反，PCE可以在多个域中具有可见性，但是操作员可能不希望PCE用于域间路径计算。
The PCE discovery mechanisms MUST also allow discovery of the set of one or more domains toward which a PCE can compute paths. For instance, in an inter-AS path computation context, there may be
PCE发现机制还必须允许发现PCE可以计算路径的一个或多个域集。例如，在内部AS路径计算上下文中，可能存在
several PCEs in an AS, each one responsible for taking part in the computation of inter-AS paths toward a set of one or more destination ASs, and a PCC may have to discover the destination ASs each PCE is responsible for.
AS中的多个PCE，每个PCE负责参与到一组一个或多个目的地ASs的AS间路径的计算中，PCC可能必须发现每个PCE负责的目的地ASs。
In the case where there are several PCEs with distinct capabilities available, a PCC has to select one or more appropriate PCEs.
如果有多个具有不同功能的PCE可用，PCC必须选择一个或多个合适的PCE。
For that purpose, the PCE discovery mechanism MAY support the disclosure of some detailed PCE capabilities.
为此目的，PCE发现机制可支持披露一些详细的PCE能力。
For the sake of illustration, this could include the following path-computation-related PCE capabilities:
为了便于说明，这可能包括以下与路径计算相关的PCE功能：
- The link constraints supported: e.g., bandwidth, affinities. - The path constraints supported: maximum IGP/TE cost, maximum hop count. - The objective functions supported: e.g., shortest path, widest path. - The capability to compute multiple correlated paths: e.g., diverse paths, load balanced paths. - The capability to compute bidirectional paths. - The GMPLS-technology-specific constraints supported: e.g., the supported interface switching capabilities, encoding types.
- 支持的链接约束：例如，带宽、亲和力。-支持的路径约束：最大IGP/TE成本、最大跃点计数。-支持的目标函数：例如，最短路径、最宽路径。-计算多个相关路径的能力：例如，多样路径、负载平衡路径。-计算双向路径的能力。-支持的GMPLS技术特定约束：例如，支持的接口交换能力、编码类型。
And this could also include some specific PCE capabilities:
这还可能包括一些特定的PCE功能：
- The capability to handle request prioritization. - The maximum size of a request message. - The maximum number of path requests in a request message. - The PCE computation power (static parameters to be used for weighted load balancing of requests).
- 处理请求优先级的能力。-请求消息的最大大小。-请求消息中的最大路径请求数。-PCE计算能力（用于请求加权负载平衡的静态参数）。
Such information regarding PCE capabilities could then be used by a PCC to select an appropriate PCE from a list of candidate PCEs.
然后，PCC可以使用关于PCE能力的此类信息从候选PCE列表中选择适当的PCE。
Note that the exact definition and description of PCE capabilities are out of the scope of this document. It is expected that this will be described in one or more separate documents which may be application specific.
请注意，PCE功能的准确定义和描述不在本文档范围内。预计这将在一个或多个单独的文件中描述，这些文件可能是特定于应用的。
In the case of a PCE failure, a PCC has to select another PCE, if one is available. It could be useful in various situations for a PCE to indicate a set of one or more alternate PCEs that can be selected in case the given PCE fails.
如果PCE出现故障，PCC必须选择另一个PCE（如果有）。在各种情况下，PCE可以指示一组一个或多个备用PCE，以防给定PCE出现故障。
Hence, the PCE discovery mechanism MAY allow the discovery, for a given PCE, of the location of one or more assigned alternate PCEs.
因此，PCE发现机制可允许针对给定PCE发现一个或多个分配的备用PCE的位置。
The PCE discovery mechanism MAY also allow the discovery, for a given PCE, of the set of one or more PCEs for which it acts as alternate PCE.
PCE发现机制还可允许针对给定PCE发现其充当备用PCE的一个或多个PCE的集合。
The PCE discovery mechanism MUST allow control of the scope of the PCE information disclosure on a per-PCE basis. In other words, it MUST allow control of to which PCC or group of PCCs the information related to a PCE may be disclosed.
PCE发现机制必须允许对每个PCE的PCE信息披露范围进行控制。换句话说，它必须允许控制与PCE相关的信息可以披露给哪个PCC或PCC组。
The choice for the discovery scope of a given PCE MUST include at least the followings settings:
给定PCE发现范围的选择必须至少包括以下设置：
- All PCCs in a single IGP area.
- 单个IGP区域中的所有PCC。
- All PCCs in a set of adjacent IGP areas.
- 一组相邻IGP区域内的所有PCC。
- All PCCs in a single AS.
- 在单个AS中的所有PCC。
- All PCCs in a set of ASs.
- 一组ASs中的所有PCC。
- A set of one or more PCCs in a set of one or more ASs.
- 一个或多个ASs集合中的一个或多个PCC集合。
In particular, this also implies that the PCE discovery mechanism MUST allow for the discovery of PCE information across IGP areas and across AS boundaries.
特别是，这也意味着PCE发现机制必须允许跨IGP区域和AS边界发现PCE信息。
The discovery scope MUST be configurable on a per PCE basis.
发现范围必须可根据每个PCE进行配置。
It MUST be possible to deactivate PCE discovery on a per PCE basis.
必须能够在每个PCE的基础上停用PCE发现。
When using a PCE-based approach for inter-AS path computation, a PCC in one AS may need to learn information related to inter-AS capable PCEs located in other ASs. For that purpose, and as pointed out in the previous section, the PCE discovery mechanism MUST allow
当使用基于PCE的方法进行AS间路径计算时，一个AS中的PCC可能需要学习与位于另一个ASs中的具有AS间能力的PCE相关的信息。为此，如前一节所述，PCE发现机制必须允许
disclosure of information related to inter-AS-capable PCEs across AS boundaries.
跨AS边界披露与具有AS能力的内部PCE相关的信息。
Such inter-AS PCE discovery must be carefully controlled. For security and confidentiality reasons, particularly in an inter-provider context, the discovery mechanism MUST allow the discovery scope to be limited to a set of ASs and MUST also provide control of the PCE information to be disclosed across ASs. This is achieved by applying policies (see also Section 4.4). This implies the capability to contain a PCE advertisement to a restricted set of one or more ASs, and to filter and translate any PCE parameter (PCE domains, PCE inter-domain functions, PCE capabilities, etc.) in disclosures that cross AS borders. For the sake of illustration, it may be useful to disclose detailed PCE information (such as detailed capabilities) locally in the PCE's AS but only general information (such as location and supported domains) in other ASs.
必须仔细控制诸如PCE发现之类的内部控制。出于安全和保密原因，特别是在提供商间环境中，发现机制必须允许发现范围限于一组ASs，并且还必须提供对要在整个ASs中披露的PCE信息的控制。这是通过应用策略实现的（另请参见第4.4节）。这意味着能够将PCE广告包含在一组受限的一个或多个ASs中，并能够过滤和转换作为边界的披露中的任何PCE参数（PCE域、PCE域间功能、PCE能力等）。为了说明，在PCE的as中本地公开详细的PCE信息（例如详细的能力）可能有用，但在其他ASs中仅公开一般信息（例如位置和支持的域）。
The PCE discovery mechanism MUST allow a PCC to discover any change in the information related to a PCE that it has previously discovered. This includes changes to both general information (e.g., a change in the PCE domains supported) and detailed information if supported (e.g., a modification of the PCE's capabilities).
PCE发现机制必须允许PCC发现其先前发现的PCE相关信息的任何变化。这包括对一般信息（例如，支持的PCE域中的更改）和详细信息（如果支持）的更改（例如，对PCE功能的修改）。
In addition, the PCE discovery mechanism MUST allow dynamic discovery of new PCEs in a given discovery scope.
此外，PCE发现机制必须允许在给定的发现范围内动态发现新的PCE。
Note that there is no requirement for real-time detection of these changes; the PCE discovery mechanism SHOULD rather allow discovery of these changes in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
注意，不需要实时检测这些变化；PCE发现机制应该允许在60秒内发现这些变化，并且操作员应该能够配置发现延迟。
Note that PCE information is relatively static and is expected to be fairly stable and not to change frequently.
请注意，PCE信息相对静态，预计相当稳定，不会频繁更改。
The PCE discovery mechanism MUST allow a PCC to discover when a PCE that it has previously discovered is no longer alive or is deactivated. This may help in reducing or avoiding path computation service disruption.
PCE发现机制必须允许PCC在其先前发现的PCE不再活动或停用时进行发现。这可能有助于减少或避免路径计算服务中断。
Note that there is no requirement for real-time detection of PCE failure/deactivation; the PCE discovery mechanism SHOULD rather allow such discovery in a range of 60 seconds, and the operator should have the ability to configure the discovery delay.
注意，不要求实时检测PCE故障/失活；PCE发现机制应该允许在60秒的范围内进行此类发现，并且操作员应该能够配置发现延迟。
The PCE discovery mechanism MUST allow for policies to restrict the discovery scope to a set of authorized domains, to control and restrict the type and nature of the information to be disclosed, and also to filter and translate some information at domains borders. It MUST be possible to apply these policies on a per-PCE basis.
PCE发现机制必须允许策略将发现范围限制在一组授权域内，控制和限制要披露的信息的类型和性质，以及在域边界过滤和翻译某些信息。必须能够在每个PCE的基础上应用这些政策。
Note that the discovery mechanisms MUST allow disclosing policy information so as to control the disclosure policies at domain boundaries.
请注意，发现机制必须允许披露策略信息，以便在域边界控制披露策略。
Also, it MUST be possible to apply different policies when disclosing PCE information to different domains.
此外，在向不同领域披露PCE信息时，必须能够应用不同的政策。
The five major threats related to PCE discovery mechanisms are
与PCE发现机制相关的五大威胁是
- impersonation of PCE; - interception of PCE discovery information (sniffing); - falsification of PCE discovery information; - information disclosure to non-authorized PCCs (PCC spoofing); - Denial of Service (DoS) Attacks.
- 假冒四氯乙烯；-截取PCE发现信息（嗅探）；-伪造PCE发现信息；-向非授权PCC披露信息（PCC欺骗）；-拒绝服务（DoS）攻击。
Note that security of the PCE discovery procedures is of particular importance in an inter-AS context, where PCE discovery may increase the vulnerability to attacks and the consequences of these attacks.
请注意，PCE发现过程的安全性在AS间环境中特别重要，因为PCE发现可能会增加攻击的脆弱性以及这些攻击的后果。
Hence, mechanisms MUST be defined to ensure authenticity, integrity, confidentiality, and containment of PCE discovery information:
因此，必须定义机制以确保PCE发现信息的真实性、完整性、机密性和包容性：
- There MUST be a mechanism to authenticate discovery information. - There MUST be a mechanism to verify discovery information integrity. - There MUST be a mechanism to encrypt discovery information. - There MUST be a mechanism to restrict the scope of discovery to a set of authorized PCCs and to filter PCE information disclosed at domain boundaries (as per defined in Section 4.5).
- 必须有一种机制来验证发现信息。-必须有一种机制来验证发现信息的完整性。-必须有一种机制来加密发现信息。-必须有一种机制将发现范围限制在一组经授权的PCC上，并过滤在域边界披露的PCE信息（根据第4.5节中的定义）。
A PCE and PCC MUST be identified by a globally unique ID, which may be, for instance, a combination of AS number and IP address.
PCE和PCC必须由全局唯一ID标识，该ID可以是AS编号和IP地址的组合。
Mechanisms MUST be defined in order to limit the impact of a DoS attack on the PCE discovery procedure (e.g., filter out excessive PCE information change and flapping PCEs). Note also that DoS attacks may be either accidental (caused by a misbehaving PCE system) or intentional. As discussed in [RFC4657], such mechanisms may include
必须定义机制，以限制DoS攻击对PCE发现过程的影响（例如，过滤掉过多的PCE信息更改和扑动PCE）。还要注意，DoS攻击可能是偶然的（由行为不端的PCE系统引起）或故意的。如[RFC4657]中所述，此类机制可能包括
packet filtering, rate limiting, no promiscuous listening, and where applicable use of private addresses spaces.
数据包过滤、速率限制、无乱听，以及在适用的情况下使用私有地址空间。
Also, key consideration MUST be given in terms of how to establish a trust model for PCE discovery. The PCE discovery mechanism MUST explicitly support a specific set of one or more trust models.
此外，还必须考虑如何为PCE发现建立信任模型。PCE发现机制必须明确支持一组特定的一个或多个信任模型。
The PCE discovery mechanism MUST be flexible and extensible so as to easily allow for the inclusion of additional PCE information that could be defined in the future.
PCE发现机制必须具有灵活性和可扩展性，以便方便地包含将来可能定义的附加PCE信息。
The PCE discovery mechanism MUST be designed to scale well with an increase of any of the following parameters:
PCE发现机制必须设计为随着以下任何参数的增加而良好扩展：
- Number of PCCs discovering a given PCE. - Number of PCEs to be discovered by a given PCC. - Number of domains in the discovery scope.
- 发现给定PCE的PCC数。-给定PCC发现的PCE数。-发现范围中的域数。
The PCE discovery mechanism MUST NOT have an adverse effect in the performance of other protocols (especially routing and signaling) already operating in the network.
PCE发现机制不得对已经在网络中运行的其他协议（尤其是路由和信令）的性能产生不利影响。
Note that there is no scalability requirement with regards to the amount of information to be exchanged.
请注意，对于要交换的信息量没有可伸缩性要求。
Information disclosed in the PCE discovery mechanism is relatively static. Changes in PCE information may occur as a result of PCE configuration updates, PCE deployment/activation, or PCE deactivation/suppression, and should not occur as a result of the PCE activity itself. Hence, this information is quite stable and will not change frequently.
在PCE发现机制中公开的信息是相对静态的。PCE信息的变化可能是PCE配置更新、PCE部署/激活或PCE停用/抑制的结果，而不应是PCE活动本身的结果。因此，该信息相当稳定，不会频繁更改。
This section gives minimum order of magnitude estimates of what the PCE discovery mechanism should support.
本节给出了PCE发现机制应支持的最低数量级估计。
- Number of PCCs discovering a given PCE: 1000 - Number of PCEs to be discovered by a given PCC: 100
- 发现给定PCE的PCC数量：1000-给定PCC发现的PCE数量：100
Mechanisms are REQUIRED to manage PCE discovery operations. This includes the configuration of PCE discovery functions and policies, as well as the monitoring of the discovery protocol activity.
需要机制来管理PCE发现操作。这包括PCE发现功能和策略的配置，以及发现协议活动的监控。
It MUST be possible to enable and disable the PCE discovery function at a PCC and at a PCE.
必须能够在PCC和PCE上启用和禁用PCE发现功能。
On the PCC, it MUST be possible for an operator to activate/deactivate automatic PCE discovery. The activation of automatic discovery MUST not prevent static configuration of PCE information that may supplement discovered information.
在PCC上，操作员必须能够激活/停用PCE自动发现。自动发现的激活不得阻止PCE信息的静态配置，这可能会补充已发现的信息。
On the PCE, it MUST be possible for an operator to control the application of discovery policies by which the specific PCE is discovered. As described in Section 4.5, this control MUST include the ability to
在PCE上，操作员必须能够控制发现特定PCE的发现策略的应用。如第4.5节所述，该控制必须包括
- restrict the discovery scope to a set of authorized domains; - define the type and nature of the information disclosed; - specify the filtering and translation to be applied to the PCE information disclosed at domain borders.
- 将发现范围限制为一组授权域；-定义所披露信息的类型和性质；-指定要应用于在域边界公开的PCE信息的过滤和转换。
These configuration options MAY be supported through an implementation-specific local configuration interface, or MAY be supported via a standardised interface (such as a MIB module, as below).
这些配置选项可以通过特定于实现的本地配置接口来支持，也可以通过标准化接口（如MIB模块，如下所示）来支持。
PCE discovery MIB modules MUST be specified for the control of the function on PCCs and PCEs.
必须指定PCE发现MIB模块以控制PCC和PCE上的功能。
The MIB module that will run on PCCs MUST include at least the following:
将在PCC上运行的MIB模块必须至少包括以下内容：
- A control to disable automatic discovery by the PCC, - The set of known PCEs, - The number of known PCEs, and the number of discovered PCEs.
- 用于禁用PCC自动发现的控件，-已知PCE集，-已知PCE数和已发现PCE数。
For each PCE reported in the MIB module, the following information MUST be available:
对于MIB模块中报告的每个PCE，必须提供以下信息：
- Information advertised by the PCE (i.e., discovered information), - Information locally configured about the PCE, - The time since the PCE was discovered, - The time since any change to the discovered information for the PCE.
- PCE发布的信息（即发现的信息），-本地配置的PCE信息，-发现PCE后的时间，-发现的PCE信息发生任何更改后的时间。
Note that when a PCE is no longer alive (see Section 4.4), it SHOULD no longer be reported in the PCC MIB module.
请注意，当PCE不再处于活动状态时（参见第4.4节），不应再在PCC MIB模块中报告该PCE。
The MIB module SHOULD also provide the average and maximum rates of arrival, departure, and modification of PCE discovery to enable effective analysis of the operation of the protocols. Furthermore, the MIB module SHOULD report on the operation of the discovery protocol by counting the number of unacceptable and incomprehensible information exchanges.
MIB模块还应提供PCE发现的平均和最大到达、离开和修改速率，以便对协议的运行进行有效分析。此外，MIB模块应通过计算不可接受和不可理解的信息交换的数量来报告发现协议的操作。
The PCC MIB module SHOULD also be used to provide notifications when thresholds (e.g., on the maximum rate of change, on the number of unacceptable messages) are crossed, or when important events occur (e.g., the number of discovered PCEs decreases to zero).
PCC MIB模块还应用于在超过阈值（例如，最大变化率、不可接受消息数量）或发生重要事件（例如，发现的PCE数量降至零）时提供通知。
The MIB module that will run on PCEs MUST include at least
将在PCE上运行的MIB模块必须至少包括
- a control to disable automatic discovery announcements by the PCE; - information to be advertised by the PCE, although this information MAY be present as read-only; - the discovery policies active on the PCE, although this information MAY be present as read-only.
- 用于禁用PCE自动发现公告的控件；-PCE发布的信息，尽管该信息可能以只读形式呈现；-发现策略在PCE上处于活动状态，但此信息可能以只读形式显示。
The MIB module SHOULD also include
MIB模块还应包括
- the time since the last change to the advertised PCE information; - the time since the last change to the advertisement policies; - control of on which interfaces the PCE issues advertisements where this is applicable to the protocol solution selected.
- 自上次更改公布的PCE信息以来的时间；-自上次更改广告政策以来的时间；-控制PCE在适用于所选协议解决方案的接口上发布公告。
Note that a PCE MAY also be configured to discover other PCEs. In this case, it SHOULD operate the MIB module described in Section 4.10.2.1 as well as the module described here.
注意，PCE也可以被配置为发现其他PCE。在这种情况下，应操作第4.10.2.1节所述的MIB模块以及此处所述的模块。
It MUST be possible to monitor the operation of any PCE discovery protocol. Where an existing protocol is used to support the PCE discovery function, this monitoring SHOULD be achieved using the techniques already defined for that protocol, enhanced by the MIB
必须能够监控任何PCE发现协议的运行。如果使用现有协议来支持PCE发现功能，则应使用已经为该协议定义的技术（通过MIB增强）来实现该监控
modules described above. Where those techniques are inadequate, new techniques MUST be developed.
上述模块。如果这些技术不足，就必须开发新技术。
Monitoring of the protocol operation demands support for at least the following functions:
协议操作的监控要求至少支持以下功能：
- Correlation of information advertised against information received. - Counts of dropped, corrupt, and rejected information elements. - Detection of 'segmented' networks, that is, the ability to detect and diagnose the failure of a PCE advertisement to reach a PCC.
- 广告信息与收到信息的相关性。-丢弃、损坏和拒绝的信息元素计数。-检测“分段”网络，即检测和诊断PCE广告到达PCC的故障的能力。
Frequent changes in PCE information may have a significant impact on PCCs that receive the advertisements, might destabilize the operation of the network by causing the PCCs to swap between PCEs, and might harm the network through excessive advertisement traffic. Hence, it MUST be possible to apply at least the following controls:
PCE信息的频繁变化可能对接收广告的pcc产生重大影响，可能通过导致pcc在PCE之间交换而使网络的运行不稳定，并且可能通过过多的广告流量损害网络。因此，必须能够至少应用以下控制：
- Configurable limit on the rate of announcement of changed parameters at a PCE. - Control of the impact on PCCs such as through discovery messages rate-limiting. - Configurable control of triggers that cause a PCC to swap to another PCE.
- 在PCE上公布更改参数的速率的可配置限制。-通过发现消息速率限制等方式控制对PCC的影响。-可配置触发器控制，使PCC交换到另一个PCE。
This document is a requirement document and hence does not raise by itself any particular security issue.
本文件是一份需求文件，因此本身不会提出任何特定的安全问题。
A set of security requirements that MUST be addressed when considering the design and deployment of a PCE discovery mechanism has been identified in Section 4.6.
第4.6节确定了在考虑PCE发现机制的设计和部署时必须解决的一组安全要求。
We would like to thank, in chronological order, Benoit Fondeviole, Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil Bitar, and Kenji Kumaki.
我们要按照时间顺序感谢贝努伊特·丰德维奥尔、托马斯·莫林、埃米尔·斯蒂芬、让·菲利普·瓦修尔、程院长、阿德里安·法雷尔、张仁海、穆罕默德·布卡达尔、埃里克·格雷、伊戈尔·布莱斯金、迪米特里·帕帕迪米特里欧、阿尔西·艾扬加、安德鲁·多尔加诺、楼·伯杰、纳比尔·比塔尔和熊崎健二。
Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley and Sam Hartman for their review and constructive discussions during the final stages of publication.
还感谢罗斯·卡隆、特德·哈迪、丹·罗马斯坎努、罗斯·霍斯利和萨姆·哈特曼在出版的最后阶段所作的评论和建设性的讨论。
The following are the authors who contributed to the present document:
以下是对本文件作出贡献的作者：
Jean-Louis Le Roux (France Telecom) Paul Mabey (Qwest Communications) Eiji Oki (NTT) Richard Rabbat (Fujitsu) Ting Wo Chung (Bell Canada) Raymond Zhang (BT Infonet)
Jean-Louis Le Roux（法国电信）Paul Mabey（Qwest通信）Eiji Oki（NTT）Richard Rabbat（富士通）Ting Wo Chung（加拿大贝尔）Raymond Zhang（英国电信信息网）
[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月。
[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.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.和J.L.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
Contributors' Addresses
投稿人地址
Paul Mabey Qwest Communications 950 17th Street Denver, CO 80202 USA
美国科罗拉多州丹佛市第17街950号Paul Mabey Qwest Communications 80202
EMail: pmabey@qwest.com
EMail: pmabey@qwest.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585 JAPAN
日本东京武藏寺3-9-11-180-8585
EMail: oki.eiji@lab.ntt.co.jp
EMail: oki.eiji@lab.ntt.co.jp
Richard Rabbat Fujitsu Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 USA
理查德·拉巴特美国富士通实验室美国加利福尼亚州桑尼维尔市东阿克斯大道1240号345号，邮编94085
EMail: richard@us.fujitsu.com
EMail: richard@us.fujitsu.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, M5J 2T3 CANADA
加拿大安大略省多伦多市贝街181号丁和钟酒店350室，M5J 2T3加拿大
EMail: ting_wo.chung@bell.ca
EMail: ting_wo.chung@bell.ca
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
美国加利福尼亚州埃尔塞贡多大道东2160号雷蒙德·张BT信息网，邮编90025
EMail: raymond_zhang@infonet.com
EMail: raymond_zhang@infonet.com
Editor's Address
编辑地址
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE
Jean-Louis Le Roux（编辑）法国电信2号，Pierre Marzin大街22307 Lannion Cedex France
EMail: jeanlouis.leroux@orange-ft.com
EMail: jeanlouis.leroux@orange-ft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。