Network Working Group I. Bryskin
Request for Comments: 5394 Adva Optical
Category: Informational D. Papadimitriou
Alcatel
L. Berger
LabN Consulting
J. Ash
AT&T
December 2008
Network Working Group I. Bryskin
Request for Comments: 5394 Adva Optical
Category: Informational D. Papadimitriou
Alcatel
L. Berger
LabN Consulting
J. Ash
AT&T
December 2008
Policy-Enabled Path Computation Framework
基于策略的路径计算框架
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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy.
路径计算元素（PCE）体系结构在路径计算的上下文中引入了策略的概念。本文档提供了有关PCE体系结构中策略的其他详细信息，还提供了支持PCE策略的上下文。本文档介绍使用策略核心信息模型（PCIM）作为支持路径计算策略的框架。本文件还提供了支持PCE政策的代表性场景。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Background ......................................................4
2.1. Motivation .................................................4
2.2. Policy Attributes ..........................................6
2.3. Representative Policy Scenarios ............................7
2.3.1. Scenario: Policy Configured Paths ...................7
2.3.2. Scenario: Provider Selection Policy ................10
2.3.3. Scenario: Policy Based Constraints .................12
2.3.4. Scenario: Advanced Load Balancing (ALB) Example ....14
3. Requirements ...................................................16
4. Path Computation Policy Information Model (PCPIM) ..............18
5. Policy-Enabled Path Computation Framework Components ...........20
6. Policy Component Configurations ................................21
6.1. PCC-PCE Configurations ....................................21
6.2. Policy Repositories .......................................24
6.3. Cooperating PCE Configurations ............................25
6.4. Policy Configuration Management ...........................27
7. Inter-Component Communication ..................................27
7.1. Policy Communication ......................................27
7.2. PCE Discovery Policy Considerations .......................29
8. Path Computation Sequence of Events ............................29
8.1. Policy-Enabled PCC, Policy-Enabled PCE ....................29
8.2. Policy-Ignorant PCC, Policy-Enabled PCE ...................31
9. Introduction of New Constraints ................................32
10. Security Considerations .......................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................34
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Background ......................................................4
2.1. Motivation .................................................4
2.2. Policy Attributes ..........................................6
2.3. Representative Policy Scenarios ............................7
2.3.1. Scenario: Policy Configured Paths ...................7
2.3.2. Scenario: Provider Selection Policy ................10
2.3.3. Scenario: Policy Based Constraints .................12
2.3.4. Scenario: Advanced Load Balancing (ALB) Example ....14
3. Requirements ...................................................16
4. Path Computation Policy Information Model (PCPIM) ..............18
5. Policy-Enabled Path Computation Framework Components ...........20
6. Policy Component Configurations ................................21
6.1. PCC-PCE Configurations ....................................21
6.2. Policy Repositories .......................................24
6.3. Cooperating PCE Configurations ............................25
6.4. Policy Configuration Management ...........................27
7. Inter-Component Communication ..................................27
7.1. Policy Communication ......................................27
7.2. PCE Discovery Policy Considerations .......................29
8. Path Computation Sequence of Events ............................29
8.1. Policy-Enabled PCC, Policy-Enabled PCE ....................29
8.2. Policy-Ignorant PCC, Policy-Enabled PCE ...................31
9. Introduction of New Constraints ................................32
10. Security Considerations .......................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................34
The Path Computation Element (PCE) Architecture is introduced in [RFC4655]. This document describes the impact of policy-based decision making when incorporated into the PCE architecture and provides additional details on, and context for, applying policy within the PCE architecture.
[RFC4655]中介绍了路径计算元素（PCE）体系结构。本文档描述了基于策略的决策在纳入PCE体系结构时的影响，并提供了在PCE体系结构中应用策略的更多详细信息和上下文。
Policy-based Management (PBM), see [RFC3198], is a network management approach that enables a network to automatically perform actions in response to network events or conditions based on pre-established rules, also denoted as policies, from a network administrator. PBM enables network administrators to operate in a high-level manner through rule-based strategy (policies can be defined as a set of rules and actions); the latter are translated automatically (i.e.,
基于策略的管理（PBM），参见[RFC3198]，是一种网络管理方法，使网络能够根据预先建立的规则（也称为策略）自动执行操作，以响应网络管理员发出的网络事件或条件。PBM使网络管理员能够通过基于规则的策略（策略可以定义为一组规则和操作）以高级方式进行操作；后者是自动翻译的（即。，
dynamically, without human interference) into individual device configuration directives, aimed at controlling a network as a whole. Two IETF Working Groups have considered policy networking in the past: The Resource Allocation Protocol (RAP) working group and the Policy Framework working group.
动态地（无人为干扰）转换为单个设备配置指令，旨在控制整个网络。IETF的两个工作组过去曾考虑过策略联网：资源分配协议（RAP）工作组和策略框架工作组。
A framework for policy-based admission control [RFC2753] was defined and a protocol for use between Policy Enforcement Points (PEP) and Policy Decision Points (PDP) was specified: Common Open Policy Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to refer to the functions defined in the COPS context. This document makes no assumptions nor does it require that the actual COPS protocol be used. Any suitable policy exchange protocol (for example, Simple Object Access Protocol (SOAP) [W3CSOAP]) may be substituted.
定义了基于策略的准入控制框架[RFC2753]，并指定了策略实施点（PEP）和策略决策点（PDP）之间使用的协议：公共开放策略服务（COPS）[RFC2748]。本文件使用术语PEP和PDP来指COPS上下文中定义的功能。本文件不作任何假设，也不要求使用实际的COPS协议。可以替换任何合适的策略交换协议（例如，简单对象访问协议（SOAP）[W3CSOAP]）。
The IETF has also produced a general framework for representing, managing, sharing, and reusing policies in a vendor-independent, interoperable, and scalable manner. It has also defined an extensible information model for representing policies, called the Policy Core Information Model (PCIM) [RFC3060], and an extension to this model to address the need for QoS management, called the Quality of Service (QoS) Policy Information Model (QPIM) [RFC3644]. However, additional mechanisms are needed in order to specify policies related to the path computation logic as well as its control.
IETF还生成了一个通用框架，用于以独立于供应商、可互操作和可扩展的方式表示、管理、共享和重用策略。它还定义了用于表示策略的可扩展信息模型，称为策略核心信息模型（PCIM）[RFC3060]，以及对该模型的扩展，以满足QoS管理的需要，称为服务质量（QoS）策略信息模型（QPIM）[RFC3644]。然而，需要额外的机制来指定与路径计算逻辑及其控制相关的策略。
In Section 2, this document presents policy-related background and scenarios to provide a context for this work. Section 3 provides requirements that must be addressed by mechanisms and protocols that enable policy-based control over path computation requests and decisions. Section 4 introduces PCIM as a core component in a framework for providing policy-enabled path computation. Section 5 introduces a set of components that may be used to support policy-enabled path computation. Sections 6, 7, and 8 provide details on possible component configurations, communication, and events. Section 10 discusses the ability to introduce new constraints with minimal impact. It should be noted that this document, in Section 4, only introduces PCIM; specific PCIM definitions to support path computation will be discussed in a separate document.
在第2节中，本文档介绍了与策略相关的背景和场景，为这项工作提供了背景。第3节提供了必须通过能够对路径计算请求和决策进行基于策略的控制的机制和协议来解决的需求。第4节介绍了PCIM作为框架中的核心组件，用于提供策略启用的路径计算。第5节介绍了一组可用于支持策略启用的路径计算的组件。第6、7和8节详细介绍了可能的组件配置、通信和事件。第10节讨论了以最小影响引入新约束的能力。应注意，本文件第4节仅介绍了PCIM；支持路径计算的特定PCIM定义将在单独的文档中讨论。
The reader is assumed to be familiar with the following terms:
假定读者熟悉以下术语：
BEEP: Blocks Extensible Exchange Protocol, see [RFC3080]. CIM: Common Information Model, see [DMTF]. COPS: Common Open Policy Service, see [RFC2748]. CSPF: Constraint-based Shortest Path First, see [RFC3630].
BEEP：阻止可扩展交换协议，请参阅[RFC3080]。CIM：公共信息模型，请参见[DMTF]。COPS：公共开放政策服务，参见[RFC2748]。CSPF：首先是基于约束的最短路径，请参见[RFC3630]。
LSP: Label Switched Path, see [RFC3031]. LSR: Label Switching Router, see [RFC3031]. PBM: Policy-Based Management, see [RFC3198]. PC: Path Computation. PCC: Path Computation Client, see [RFC4655]. PCCIM: Path Computation Core Information Model. PCE: Path Computation Element, see [RFC4655]. PCEP: Path Computation Element Communication Protocol, see [PCEP]. PCIM: Policy Core Information Model, see [RFC3060]. PDP: Policy Decision Point, see [RFC2753]. PEP: Policy Enforcement Point, see [RFC2753]. QPIM: QoS Policy Information Model, see [RFC3644]. SLA: Service Level Agreement. SOAP: Simple Object Access Protocol, see [W3CSOAP]. TE: Traffic Engineering, see [RFC3209] and [RFC3473]. TED: Traffic Engineering Database, see [RFC3209] and [RFC3473]. TE LSP: Traffic Engineering MPLS Label Switched Path, see [RFC3209] and [RFC3473]. WDM: Wavelength Division Multiplexing
LSP：标记交换路径，请参阅[RFC3031]。LSR：标签交换路由器，参见[RFC3031]。PBM：基于策略的管理，请参见[RFC3198]。路径计算。PCC：路径计算客户端，请参阅[RFC4655]。PCCIM：路径计算核心信息模型。PCE：路径计算元素，请参见[RFC4655]。PCEP：路径计算元件通信协议，参见[PCEP]。PCIM：策略核心信息模型，请参阅[RFC3060]。PDP：政策决策点，参见[RFC2753]。政治公众人物：政策实施点，请参见[RFC2753]。QPIM:QoS策略信息模型，请参阅[RFC3644]。SLA：服务级别协议。SOAP：简单对象访问协议，请参见[W3CSOAP]。TE：交通工程，见[RFC3209]和[RFC3473]。TED：交通工程数据库，见[RFC3209]和[RFC3473]。TE LSP：流量工程MPLS标签交换路径，请参阅[RFC3209]和[RFC3473]。波分复用
This section provides some general background on the use of policies within the PCE architecture. It presents the rationale behind the use of policies in the TE path computation process, as well as representative policies usage scenarios. This information is intended to provide context for the presented PCE policy framework. This section does not attempt to present an exhaustive list of rationales or scenarios.
本节提供了PCE体系结构中策略使用的一般背景。它介绍了在TE路径计算过程中使用策略的基本原理，以及具有代表性的策略使用场景。本信息旨在为所提出的PCE政策框架提供背景。本节不试图提供详尽的理由或场景列表。
The PCE architecture as introduced in [RFC4655] includes policy as an integral part of the PCE architecture. This section presents some of the rationale for this inclusion.
[RFC4655]中介绍的PCE体系结构包括作为PCE体系结构组成部分的策略。本节介绍了包含此内容的一些基本原理。
Network operators require a certain level of flexibility to shape the TE path computation process, so that the process can be aligned with their business and operational needs. Many aspects of the path computation may be governed by policies. For example, a PCC may use policies configured by the operator to decide which optimization criteria, constraints, diversities and their relaxation strategies to request while computing path(s) for a particular service. Depending on SLAs, TE and cost/performance ratio goals, path computation requests may be issued differently for different services. A given Service A, for instance, may require two Shared Risk Link Group (SRLG)-disjoint paths for building end-to-end recovery scheme, while
网络运营商需要一定程度的灵活性来塑造TE路径计算过程，以便该过程能够与其业务和运营需求相一致。路径计算的许多方面可能由策略控制。例如，PCC可以使用由运营商配置的策略来决定在计算特定服务的路径时要请求哪些优化标准、约束、多样性及其放松策略。根据SLA、TE和成本/性能比目标，针对不同服务发出的路径计算请求可能不同。例如，给定的服务A可能需要两条共享风险链接组（SRLG）-不相交的路径来构建端到端恢复方案，而
for a Service B link-disjoint paths may be sufficient. Service A may need paths with minimal end-to-end delay, while Service B may be looking for shortest (minimal-cost) paths. Different constraint relaxation strategies may be applied while computing paths for Service A and for Service B, and so forth. So, based on distinct service requirements, distinct or similar policies may be adopted when issuing/handling path computation requests.
对于服务B，链路不相交路径可能就足够了。服务A可能需要具有最小端到端延迟的路径，而服务B可能需要最短（最小成本）的路径。在计算服务A和服务B等的路径时，可以应用不同的约束松弛策略。因此，基于不同的服务需求，在发出/处理路径计算请求时可以采用不同或类似的策略。
Likewise, a PCE may apply policies to decide which algorithm(s) to use while performing path computations requested from a particular PCC or for a particular domain, see [RFC4927]; whether to seek the cooperation of other PCEs to satisfy a particular request or to handle a request on its own (possibly responding with non-explicit paths), or how the request should be modified before being sent to other member(s) of a group of cooperating PCEs, etc.
类似地，PCE可以应用策略来决定在执行从特定PCC或特定域请求的路径计算时使用哪些算法，请参见[RFC4927]；是否寻求其他PCE的合作以满足特定请求或自行处理请求（可能以非显式路径响应），或者在将请求发送给合作PCE组的其他成员之前应如何修改请求，等等。
Additional motivation for supporting policies within the PCE architecture can be described as follows. Historically, a path computation entity was an intrinsic part of an LSR's control plane and always co-located with the LSR's signaling and routing subsystems. This approach allowed for unlimited flexibility in providing various path computation enhancements, such as: adding new types of constraints, diversities and their relaxation strategies, adopting new objective functions and optimization criteria, etc. All that had to be done to support an enhancement was to upgrade the control plane software of a particular LSR (and no other LSRs or any other network elements).
在PCE体系结构中支持策略的其他动机可以描述如下。历史上，路径计算实体是LSR控制平面的固有部分，并且始终与LSR的信令和路由子系统位于同一位置。这种方法允许在提供各种路径计算增强方面具有无限的灵活性，例如：添加新类型的约束、多样性及其松弛策略，采用新的目标函数和优化标准，等等。为了支持增强，所要做的就是升级特定LSR的控制平面软件（没有其他LSR或任何其他网络元素）。
With the introduction of the PCE architecture, the introduction of new PCE capabilities becomes more complicated: it isn't enough for a PCE to upgrade its own software. In order to take advantage of a PCE's new capabilities, new advertising and signaling objects may need to be standardized, all PCCs may need to be upgraded with new software, and new interoperability problems may need to be resolved, etc.
随着PCE体系结构的引入，新PCE功能的引入变得更加复杂：PCE升级自己的软件是不够的。为了利用PCE的新功能，可能需要标准化新的广告和信令对象，可能需要使用新软件升级所有PCC，可能需要解决新的互操作性问题，等等。
Within the context of the PCE architecture, it is therefore highly desirable to find a way to introduce new path computation capabilities without requiring modifying either the discovery/communication protocols or the PCC software. One way to achieve this objective is to consider path selection constraints, their relaxations, and objective functions, as path computation request-specific policies. Furthermore, such policies may be configured and managed by a network operator as any other policies and may be interpreted in real time by PCCs and PCEs.
因此，在PCE架构的上下文中，非常希望找到一种在不需要修改发现/通信协议或PCC软件的情况下引入新路径计算能力的方法。实现这一目标的一种方法是考虑路径选择约束、它们的松弛和目标函数，作为路径计算请求特定策略。此外，这种策略可以由网络运营商作为任何其他策略来配置和管理，并且可以由pcc和pce实时解释。
There are a number of advantages and useful by-products of such an approach:
这种方法有许多优点和有用的副产品：
- New path computation capabilities may be introduced without changing PCE-PCC communication and discovery protocols or PCC software. Only the PCE module providing the path computation capabilities (referred to in this document as a path computation engine) needs to be updated.
- 在不改变PCE-PCC通信和发现协议或PCC软件的情况下，可以引入新的路径计算能力。只有提供路径计算功能的PCE模块（在本文档中称为路径计算引擎）需要更新。
- Existing constraints, objective functions and their relaxations may be aggregated and otherwise associated, thus producing new, more complex objective functions that do not require a change of code even on the PCEs supporting the functions.
- 现有的约束条件、目标函数及其松弛可以聚合或以其他方式关联，从而产生新的、更复杂的目标函数，即使在支持这些函数的PCE上也不需要更改代码。
- Different elements such as conditions, actions, variables, etc., may be reused by multiple constraints, diversities, and optimizations.
- 多种约束、多样性和优化可以重用不同的元素，如条件、操作、变量等。
- PCCs and PCEs need to handle other (that is, not request-specific) policies. Path computation-related policies of all types can be placed within the same policy repositories, managed by the same policy management tools, and interpreted using the same mechanisms. Also, policies need to be supported by PCCs and PCEs independent of the peculiarities of a specific PCC-PCE communication protocol, see [PCEP]. Thus, introducing a new (request-specific) type of policy describing constraints and other elements of a path computation request will be a natural and relatively inexpensive addition to the policy-enabled path computation architecture.
- PCC和PCE需要处理其他（即，不是特定于请求的）策略。所有类型的与路径计算相关的策略都可以放在相同的策略存储库中，由相同的策略管理工具进行管理，并使用相同的机制进行解释。此外，政策需要由PCC和PCE支持，独立于特定PCC-PCE通信协议的特性，参见[PCEP]。因此，引入一种新的（特定于请求的）策略类型来描述路径计算请求的约束和其他元素，将是对启用策略的路径计算体系结构的自然且相对便宜的补充。
This section provides a summary listing of the policy attributes that may be included in the policy exchanges described in the scenarios that follow. This list is provided for guidance and is not intended to be exclusive. Implementation of this framework might include additional policy attributes not listed here.
本节提供可能包含在以下场景中描述的策略交换中的策略属性的摘要列表。本清单仅供参考，并非排他性的。此框架的实现可能包括此处未列出的其他策略属性。
Identities
身份
- LSP head-end - LSP destination - PCC - PCE
- LSP前端-LSP目的地-PCC-PCE
LSP identifiers
LSP标识符
- LSP head-end - LSP destination - Tunnel identifier - Extended tunnel identifier - LSP ID - Tunnel name
- LSP头端-LSP目的地-隧道标识符-扩展隧道标识符-LSP ID-隧道名称
Requested LSP qualities
请求的LSP质量
- bandwidth - traffic parameters - LSP attributes - explicit path inclusions - explicit path exclusions - link protection level - setup priority - holding priority - preexisting LSP route
- 带宽-流量参数-LSP属性-显式路径包含-显式路径排除-链路保护级别-设置优先级-保持优先级-先前存在的LSP路由
Requested path computation behavior
请求路径计算行为
- objective function - other LSPs to be considered
- 目标函数-需要考虑的其他LSP
Additional policy information
其他政策信息
- Transparent policy information as received in Resource Reservation Protocol (RSVP)-TE
- 在资源保留协议（RSVP）-TE中接收的透明策略信息
This section provides example scenarios of how policies may be applied using the PCE policy framework within the PCE architecture context. Actual networks may deploy one of the scenarios discussed, some combination of the presented scenarios, or other scenarios (not discussed). This section should not be viewed as limiting other applications of policies within the PCE architecture.
本节提供了如何在PCE体系结构上下文中使用PCE策略框架应用策略的示例场景。实际网络可能部署所讨论的场景之一、所呈现场景的某些组合或其他场景（未讨论）。本节不应被视为限制PCE体系结构中策略的其他应用。
A very simple usage scenario for PCE policy would be to use PCE to centrally administer configured paths. Configured paths are composed of strict and loose hops in the form of Explicit Route Objects (EROs), see [RFC3209], and are used by one or more LSPs. Typically, such paths are configured at the LSP ingress. In the context of policy-enabled path computation, an alternate approach is possible.
PCE策略的一个非常简单的使用场景是使用PCE集中管理配置的路径。配置的路径由显式路由对象（ERO）形式的严格跃点和松散跃点组成，请参见[RFC3209]，并由一个或多个LSP使用。通常，在LSP入口处配置这样的路径。在启用策略的路径计算的上下文中，可以使用另一种方法。
In particular, service-specific policies can be installed that will provide configured path(s) for a specific service request. The request may be identified based on service parameters such as endpoints, requested QoS, or even a token that identifies the initiator of a service request. The configured path(s) would then be used as input to the path computation process, which would return explicit routes by expanding of all specified loose hops.
特别是，可以安装特定于服务的策略，这些策略将为特定的服务请求提供配置的路径。该请求可以基于诸如端点、所请求的QoS或甚至标识服务请求的发起方的令牌的服务参数来标识。然后将配置的路径用作路径计算过程的输入，路径计算过程将通过扩展所有指定的松散跃点返回显式路由。
Example of policy: if(service_destination matches 10.132.12.0/24) Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1. else Compute path dynamically.
策略示例：如果（服务目标匹配10.132.12.0/24）使用路径：10.125.13.1=>10.125.15.1=>10.132.12.1。否则动态计算路径。
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g., routing protocol)
| | |
| v |
| ------ ----- | Inter-PCE Request/Response
| |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ------------- Signaling
Request |[PCC][Policy]| Protocol
<------>| Node |<------->
or Signaling -------------
Protocol
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g., routing protocol)
| | |
| v |
| ------ ----- | Inter-PCE Request/Response
| |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ------------- Signaling
Request |[PCC][Policy]| Protocol
<------>| Node |<------->
or Signaling -------------
Protocol
Figure 1: Policy Enabled PCC and PCE
图1：启用策略的PCC和PCE
Path computation policies may be applied at either a PCC or a PCE, see Figure 1. In the PCC case, the configured path would be processed at the PCC and then passed to the PCE along with the PCE request, probably in the form of (inclusion) constraints. When applied at the PCE, the configured path would be used locally. Both cases require some method to configure and manage policies. In the PCC case, the real benefit would come when there is an automated policy distribution mechanism.
路径计算策略可以应用于PCC或PCE，见图1。在PCC的情况下，配置的路径将在PCC处处理，然后与PCE请求一起传递给PCE，可能以（包含）约束的形式。在PCE上应用时，配置的路径将在本地使用。这两种情况都需要一些方法来配置和管理策略。在PCC案例中，当有一个自动化的策略分发机制时，真正的好处就会出现。
------------------ -------------------
| | | |
| PCE | | PCE |
| | | |
| ------ ----- | | ----- ------ |
| |Policy| | TED | | | | TED | |Policy| |
| ------ ----- | | ----- ------ |
------------------ -------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
------------------ -------------------
| | | |
| PCE | | PCE |
| | | |
| ------ ----- | | ----- ------ |
| |Policy| | TED | | | | TED | |Policy| |
| ------ ----- | | ----- ------ |
------------------ -------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 2: Multiple PCE Path Computation
图2：多PCE路径计算
------------------ ------------------
| | Inter-PCE Request/Response | |
| PCE |<-------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
------------------ ------------------
| | Inter-PCE Request/Response | |
| PCE |<-------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 3: Multiple PCE Path Computation with Inter-PCE Communication
图3：具有PCE间通信的多PCE路径计算
Policy-configured paths may also be used in environments with multiple (more than one) cooperating PCEs (see Figures 2 and 3). For example, consider the case when there is limited TE visibility and independent PCEs are used to determine path(s) within each area of the TE visibility. In such a case, it may not be possible (or desirable) to configure entire explicit path(s) on a single PCE. However, it is possible to configure explicit path(s) for each area of the TE visibility and each responsible PCE. One by one, the PCEs would then map an incoming signaling request to appropriate configured path(s). Note that to make such a scenario work, it would
策略配置的路径也可用于具有多个（多个）协作PCE的环境中（见图2和图3）。例如，考虑TE能见度有限的情况，并且使用独立的PCE来确定TE能见度的每个区域内的路径。在这种情况下，可能不可能（或不希望）在单个PCE上配置整个显式路径。但是，可以为TE可见性的每个区域和每个负责PCE配置显式路径。然后，pce将一个接一个地将传入信令请求映射到适当的配置路径。请注意，要使这样的场景工作，它将
likely be necessary to start and finish the configured paths on TE domain boundary nodes. Clearly, consistent PCE Policy Repositories are also critical in this example.
可能需要启动和完成TE域边界节点上的配置路径。显然，在本例中，一致的PCE策略存储库也很重要。
A potentially more interesting scenario is applying PC policies in multi-provider topologies. There are numerous interesting policy applications in such topologies. A rudimentary example is simple access control, that is, deciding which PCCs are permitted to request inter-domain path computation.
一个可能更有趣的场景是在多提供商拓扑中应用PC策略。在这种拓扑中有许多有趣的策略应用。一个基本的例子是简单的访问控制，即决定允许哪些PCC请求域间路径计算。
A more complicated example is applying policy to determine which domain or network provider will be used to support a particular PCE request. Consider the topology presented in Figure 4. In this example, there are multiple transit domains available to provide a path from a source domain to a destination domain. Furthermore, each transit domain may have one or more options for reaching a particular domain. Each domain will need to select which of the multiple available paths will be used to satisfy a particular PCE request.
一个更复杂的例子是应用策略来确定将使用哪个域或网络提供商来支持特定的PCE请求。考虑图4所示的拓扑结构。在此示例中，有多个传输域可用于提供从源域到目标域的路径。此外，每个中转域可以有一个或多个到达特定域的选项。每个域将需要选择多个可用路径中的哪一个用于满足特定PCE请求。
In today's typical path computation process, TE reachability, availability, and metric are the basic criteria for path selection. However, policies can provide an important added consideration in the decision process. For example, transit domain A may be more expensive and provide lower delay or loss than transit domain B. Likewise, a transit domain may wish to treat PCE requests from its own customers differently than requests from other providers. In both cases, computation based on traffic engineering databases will result in multiple transit domains that provide reachability, and policies can be used to govern which PCE requests get better service.
在当今典型的路径计算过程中，可达性、可用性和度量是路径选择的基本标准。然而，政策可以在决策过程中提供重要的附加考虑因素。例如，传输域A可能比传输域B更昂贵，并且提供更低的延迟或损失。同样，传输域可能希望以不同于其他提供商的方式处理来自其自身客户的PCE请求。在这两种情况下，基于流量工程数据库的计算将导致提供可达性的多个传输域，并且可以使用策略来控制哪些PCE请求获得更好的服务。
+-------+
+----------+Transit+----------+
+---+---+ | Domain| +---+---+
|Transit| | C | |Transit|
+--------+ Domain| +---+---+ | Domain+--------+
| | A +--+ | +--+ F | |
+--+---+ +---+---+ | | | +---+---+ +--+---+
|Source| | | +---+---+ | | |Target|
|Domain| | +---+Transit+---+ | |Domain|
+--+---+ | +---+ Domain|---+ | +--+---+
| +---+---+ | | D | | +---+---+ |
| |Transit| | +---+---+ | |Transit| |
+--------+ Domain+--+ | +--+ Domain+--------+
| B | | | G |
+---+---+ +---+---+ +---+---+
| |Transit| |
+----------+ Domain+----------+
| E |
+-------+
+-------+
+----------+Transit+----------+
+---+---+ | Domain| +---+---+
|Transit| | C | |Transit|
+--------+ Domain| +---+---+ | Domain+--------+
| | A +--+ | +--+ F | |
+--+---+ +---+---+ | | | +---+---+ +--+---+
|Source| | | +---+---+ | | |Target|
|Domain| | +---+Transit+---+ | |Domain|
+--+---+ | +---+ Domain|---+ | +--+---+
| +---+---+ | | D | | +---+---+ |
| |Transit| | +---+---+ | |Transit| |
+--------+ Domain+--+ | +--+ Domain+--------+
| B | | | G |
+---+---+ +---+---+ +---+---+
| |Transit| |
+----------+ Domain+----------+
| E |
+-------+
Figure 4: Multi-Domain Network with Multiple Transit Options
图4：具有多个传输选项的多域网络
There are multiple options for differentiating which PCE requests use a particular transit domain and get a particular (better or worse) level of service. For example, a PCE in the source domain may use user- and request-specific policies to determine the level of service to provide. A PCE in the source domain may also use domain-specific policies to choose which transit domains are acceptable. A PCE in a transit domain may use request-specific policies to determine if a request is from a direct customer or another provider, and then use domain-specific policies to identify how the request should be processed.
有多种选择可以区分哪些PCE请求使用特定的传输域并获得特定（更好或更差）的服务级别。例如，源域中的PCE可以使用特定于用户和请求的策略来确定要提供的服务级别。源域中的PCE还可以使用特定于域的策略来选择可接受的传输域。传输域中的PCE可以使用特定于请求的策略来确定请求是来自直接客户还是其他提供商，然后使用特定于域的策略来确定应如何处理请求。
Example of policy: if(path computation request issued by a PCC within Source Domain) Route the path through Transit Domain A. else Route the path through Transit Domain B.
策略示例：if（源域内PCC发出的路径计算请求）通过传输域a路由路径。else通过传输域B路由路径。
Another usage scenario is the use of policy to provide constraints in a PCE request. Consider an LSR with a policy enabled PCC, as shown in Figure 1, which receives a service request via signaling, including over a Network-Network Interface (NNI) or User Network Interface (UNI) reference point, or receives a configuration request over a management interface to establish a service. In either case, the path(s) needed to support the service are not explicitly specified in the message/request, and hence path computation is needed.
另一个使用场景是使用策略在PCE请求中提供约束。考虑具有策略启用的PCC的LSR，如图1所示，它通过信令接收服务请求，包括通过网络网络接口（NNI）或用户网络接口（UNI）参考点，或通过管理接口接收配置请求以建立服务。在这两种情况下，支持服务所需的路径都没有在消息/请求中明确指定，因此需要进行路径计算。
In this case, the PCC may apply user- or service-specific policies to decide how the path selection process should be constrained, that is, which constraints, diversities, optimization criterion, and constraint relaxation strategies should be applied in order for the service LSP(s) to have a likelihood to be successfully established and provide necessary QoS and resilience against network failures. When deciding on the set of constraints, the PCC uses as an input all information it knows about the user and service, such as the contents of the received message, port ID over which message was received, associated VPN ID, signaling/reference point type, request time, etc. Once the constraints and other parameters of the required path computation are determined, the PCC generates a path computation request that includes the request-specific policies that describe the determined set of constraints, optimizations, and other parameters that indicate how the request is to be considered in the path computation process.
在这种情况下，PCC可以应用用户或特定于服务的策略来决定应该如何约束路径选择过程，即，为了服务LSP，应该应用哪些约束、多样性、优化标准和约束放松策略有可能成功建立并提供必要的QoS和网络故障恢复能力。当决定约束集时，PCC使用其知道的关于用户和服务的所有信息作为输入，例如接收消息的内容、接收消息的端口ID、相关联的VPN ID、信令/参考点类型、请求时间、，等。一旦确定了所需路径计算的约束和其他参数，PCC将生成一个路径计算请求，该请求包括描述所确定的约束集、优化、，以及指示在路径计算过程中如何考虑请求的其他参数。
Example of policy: if(LSP belongs to a WDM layer network) Compute the path with wavelength continuity constraint with the maximum Optical Signal Noise Ratio (OSNR) at the path end optimization. else if(LSP belongs to a connection oriented Ethernet layer network) Compute the path with minimum end-to-end delay. else Compute the shortest path.
策略示例：如果（LSP属于WDM层网络），则在路径端优化时以最大光信噪比（OSNR）计算具有波长连续性约束的路径。else if（LSP属于面向连接的以太网层网络）以最小的端到端延迟计算路径。否则计算最短路径。
The PCC may also apply server-specific policies in order to select which PCE to use from the set of known (i.e., discovered or configured) PCEs. The PCC may also use server-specific policies to form the request to match the PCE's capabilities so that the request will not be rejected and has a higher likelihood of being satisfied in an efficient way. An example of a request modification as the result of a server-specific policy is removing a constraint not supported by the PCE. Once the policy processing is completed at the
PCC还可以应用特定于服务器的策略，以便从已知（即，发现的或配置的）PCE集合中选择要使用的PCE。PCC还可以使用特定于服务器的策略来形成与PCE的能力相匹配的请求，以便该请求不会被拒绝，并且具有以有效方式被满足的更高可能性。由于特定于服务器的策略而导致的请求修改的一个示例是删除PCE不支持的约束。一旦策略处理在
PCC, and the path computation request resulting from the original service request is updated by the policy processing, the request is sent to the PCE.
PCC，并且由原始服务请求产生的路径计算请求由策略处理更新，该请求被发送到PCE。
Example of policy:
if(LSP belongs to a WDM layer network)
Identify a PCE supporting wavelength continuity and optical
impairment constraints;
Send a request to such PCE, requesting path computation with the
following constraints:
a) wavelength continuity;
b) maximum Polarization Mode Dispersion (PMD) at the path end.
if(the path computation fails) remove the maximum PMD constraint
and try the computation again.
Example of policy:
if(LSP belongs to a WDM layer network)
Identify a PCE supporting wavelength continuity and optical
impairment constraints;
Send a request to such PCE, requesting path computation with the
following constraints:
a) wavelength continuity;
b) maximum Polarization Mode Dispersion (PMD) at the path end.
if(the path computation fails) remove the maximum PMD constraint
and try the computation again.
The PCE that receives the request validates and otherwise processes the request, applying the policies found in the request as well as any policies that are available at the PCE, e.g., client- and domain-specific policies. As a result of the policy processing, the PCE may decide to reject the request.
接收请求的PCE验证并以其他方式处理请求，应用请求中找到的策略以及PCE上可用的任何策略，例如，特定于客户端和域的策略。作为策略处理的结果，PCE可以决定拒绝该请求。
Example of policy: Authenticate the PCC requesting the path computation using the PCC ID found in the path computation request; Reject the request if the authentication fails.
策略示例：使用路径计算请求中找到的PCC ID对请求路径计算的PCC进行身份验证；如果身份验证失败，则拒绝请求。
The PCE also may decide to respond with one or several pre-computed paths if user- or client-specific policies instruct the PCE to do so. If the PCE decides to satisfy the request by performing a path computation, it determines if it needs the cooperation of other PCEs and defines parameters for path computations to be performed locally and remotely. After that, the PCE instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends path computation requests to one or more other PCEs. It then waits for the responses from the local path computation engine and, when used, the remote PCE. It then combines the resulting paths and sends the result back to the requesting PCC. The response may indicate policies describing the resulting paths, their characteristics (summary cost, expected end-to-end delay, etc.), as well as additional information related to the request, e.g., which constraints were honored, which were dismissed, and which were relaxed and in what way.
如果特定于用户或客户端的策略指示PCE这样做，则PCE还可以决定使用一个或多个预先计算的路径进行响应。如果PCE决定通过执行路径计算来满足请求，则它确定是否需要其他PCE的合作，并为本地和远程执行的路径计算定义参数。之后，PCE指示同一位置的路径计算引擎执行本地路径计算，并且如果需要，向一个或多个其他PCE发送路径计算请求。然后，它等待来自本地路径计算引擎和远程PCE（使用时）的响应。然后，它组合结果路径并将结果发送回请求PCC。响应可以指示描述结果路径的策略、其特征（汇总成本、预期端到端延迟等）以及与请求相关的附加信息，例如，哪些约束得到遵守，哪些被取消，哪些被放松以及以何种方式放松。
Example of policy:
if(the path destination belongs to domain A)
Instruct local path computation engine to perform the path
computation;
else
Identify the PCE supporting the destination domain;
Send path computation request to such PCE;
Wait for and process the response.
Send the path computation response to the requesting PCC.
Example of policy:
if(the path destination belongs to domain A)
Instruct local path computation engine to perform the path
computation;
else
Identify the PCE supporting the destination domain;
Send path computation request to such PCE;
Wait for and process the response.
Send the path computation response to the requesting PCC.
The PCC processes the response and instructs the LSR to encode the received path(s) into the outgoing signaling message(s).
PCC处理该响应并指示LSR将接收到的路径编码到传出信令消息中。
Figure 5 illustrates a problem that stems from the coupling between BGP and IGP in the BGP decision process. If a significant portion of the traffic destined for the data center (or customer network) enters a PCE-enabled network from AS 1 and all IGP links' weights are the same, then both PE3 and PE4 will prefer to reach the data center using the routes advertised by PE2. PE5 will use the router-IDs of PE1 and PE2 to break the tie and might therefore also select to use the path through PE2 (if the router ID of PE2 is smaller than that of PE1). Either way, the net result is that the link between PE2 and CE will carry most of the traffic while the link between PE1 and the Customer Edge (CE) will be mostly idle.
图5说明了BGP决策过程中BGP和IGP之间的耦合产生的问题。如果目的地为数据中心（或客户网络）的通信量的很大一部分从AS 1进入启用PCE的网络，并且所有IGP链路的权重相同，则PE3和PE4都希望使用PE2公布的路由到达数据中心。PE5将使用PE1和PE2的路由器ID打破联系，因此也可能选择使用通过PE2的路径（如果PE2的路由器ID小于PE1的路由器ID）。无论哪种方式，最终结果都是PE2和CE之间的链路将承载大部分流量，而PE1和客户边缘（CE）之间的链路将大部分空闲。
..............................
. AS 1 .
. .
. +---+ +---+ +----+ .
....|PE8|...|PE9|...|PE10|....
+---+ +---+ +----+
| | |
+---+ +---+ +---+
......|PE3|...|PE4|...|PE5|......
. +---+ +---+ +---+ .
.............. +---+ \ / ___/ +---+
. . _|PE2|_____+--+__/ / _|PE6|
. +--+ / +---+ |P1|_____+--+_______/ +---+
. Customer |CE|= . +--+ |P2| .
. Network +--+ \_+---+ \ +--+ .
. . |PE1|________+--+___/| x===x . PCE used
.............. +---+ |P3| | |PCE| . by all
. +--+ | x===x . AS0 nodes
. AS 0 +---+ .
..................|PE7|..........
+---+
..............................
. AS 1 .
. .
. +---+ +---+ +----+ .
....|PE8|...|PE9|...|PE10|....
+---+ +---+ +----+
| | |
+---+ +---+ +---+
......|PE3|...|PE4|...|PE5|......
. +---+ +---+ +---+ .
.............. +---+ \ / ___/ +---+
. . _|PE2|_____+--+__/ / _|PE6|
. +--+ / +---+ |P1|_____+--+_______/ +---+
. Customer |CE|= . +--+ |P2| .
. Network +--+ \_+---+ \ +--+ .
. . |PE1|________+--+___/| x===x . PCE used
.............. +---+ |P3| | |PCE| . by all
. +--+ | x===x . AS0 nodes
. AS 0 +---+ .
..................|PE7|..........
+---+
Figure 5: Advanced Load Balancing
图5：高级负载平衡
This is a common problem for providers and customers alike. Analysis of Netflow records, see [IRSCP], for a large ISP network on a typical day has shown that for 71.8% of multi-homed customers, there is a complete imbalance, where the most loaded link carries all the traffic and the least loaded link carries none.
这是提供商和客户共同面临的问题。对Netflow记录的分析（见[IRSCP]）表明，对于一个大型ISP网络来说，在一个典型的日子里，71.8%的多宿用户存在完全不平衡的情况，负载最大的链路承载所有流量，而负载最小的链路不承载任何流量。
PCE policies can address this problem by basing the routing decision at the ingress routers on the offered load towards the multi-homed customer. For example, in Figure 5, PCE policies could be configured such that traffic load is monitored (e.g., based on Netflow data) at ingress routers PE3 to PE7 towards the data center prefixes served by egress routers PE1 and PE2. Using this offered load information, the path computations returned by PCE, based on the enabled PCE policies, can direct traffic to the appropriate egress router, on a per-ingress router basis. For example, the PCE path computation might direct traffic from both PE4 and PE5 to egress PE1, thus overriding the default IGP based selection. Alternatively, traffic from each ingress router to each egress link could be split 50-50.
PCE策略可以通过基于向多宿客户提供的负载的入口路由器的路由决策来解决这个问题。例如，在图5中，可以配置PCE策略，以便在入口路由器PE3到PE7处向由出口路由器PE1和PE2服务的数据中心前缀监控流量负载（例如，基于网络流数据）。使用此提供的负载信息，PCE基于启用的PCE策略返回的路径计算可以基于每个入口路由器将流量引导到适当的出口路由器。例如，PCE路径计算可以将来自PE4和PE5的流量引导到出口PE1，从而覆盖默认的基于IGP的选择。或者，从每个入口路由器到每个出口链路的流量可以50-50分开。
This scenario is a good example of how a policy-governed PCE can account for some information that was not or cannot be advertised as TE link/node attributes, and, therefore, cannot be subject for explicit path computation constraints. More generally, such information can be pretty much anything. For example, traffic demand
此场景是一个很好的示例，说明了受策略管理的PCE如何解释一些信息，这些信息不是或不能作为TE链路/节点属性发布，因此不能受到显式路径计算约束。更一般地说，这样的信息几乎可以是任何东西。例如，交通需求
forecasts, flow monitoring feedback, any administrative policies, etc. Further examples are described in [IRSCP] of how PCE policies might address certain network routing problems, such as selective distributed denial-of-service (DDoS) blackholing, planned maintenance, and VPN gateway selection.
预测、流量监控反馈、任何管理策略等。[IRSCP]中描述了PCE策略如何解决某些网络路由问题的更多示例，如选择性分布式拒绝服务（DDoS）黑洞、计划维护和VPN网关选择。
Example of policy: for(all traffic flows destined to Customer Network) if(flow ingresses on PE3, PE4, or PE5) Route the flow over PE1. else Route the flow over PE2.
策略示例：对于（所有目的地为客户网络的流量）if（PE3、PE4或PE5上的流量入口）将流量路由至PE1。否则，通过PE2对流量进行布线。
The following requirements must be addressed by mechanisms and protocols that enable policy-based control over path computation requests and decisions:
必须通过能够对路径计算请求和决策进行基于策略的控制的机制和协议来满足以下要求：
- (G)MPLS path computation-specific The mechanisms must meet the policy-based control requirements specific to the problem of path computation using RSVP-TE as the signaling protocol on MPLS and GMPLS LSRs.
- （G） 特定于MPLS路径计算的机制必须满足特定于使用RSVP-TE作为MPLS和GMPLS LSR上的信令协议的路径计算问题的基于策略的控制要求。
- Support for non-(G)MPLS PCCs The mechanisms must be sufficiently generic to support non-(G)MPLS (LSR) clients such as a Network Management System (NMS), or network planner, etc.
- 支持非（G）MPLS PCC机制必须足够通用，以支持非（G）MPLS（LSR）客户端，如网络管理系统（NMS）或网络规划器等。
- Support for many policies The mechanisms must include support for many policies and policy configurations. In general, the determination and configuration of viable policies are the responsibility of the service provider.
- 对许多策略的支持机制必须包括对许多策略和策略配置的支持。一般来说，确定和配置可行的策略是服务提供商的责任。
- Provision for monitoring and accounting information The mechanisms must include support for monitoring policy state and provide access information. In particular, mechanisms must provide usage and access information that may be used for accounting purposes.
- 提供监控和会计信息机制必须包括支持监控政策状态并提供访问信息。特别是，机制必须提供可用于记帐目的的使用和访问信息。
- Fault tolerance and recovery The mechanisms must include provisions for fault tolerance and recovery from failure cases such as failure of PCC/PCE PDPs, disruption in communication that separate a PCC/PCE PDP from its associated PCC/PCE PEPs.
- 容错和恢复机制必须包括故障情况下的容错和恢复规定，例如PCC/PCE PDP故障、将PCC/PCE PDP与其相关PCC/PCE PEP分离的通信中断。
- Support for policy-ignorant nodes The mechanisms should not be mandatory for every node in a network. Policy-based path computation control may be enforced at a subset of nodes, for example, on boundary nodes within an administrative domain. These policy-capable nodes will function as trusted nodes from the point of view of the policy-ignorant nodes in that administrative domain. Alternatively, policy may be applied solely on PCEs with all PCCs being policy-ignorant nodes.
- 对策略无关节点的支持网络中的每个节点都不应强制使用这些机制。基于策略的路径计算控制可以在节点子集上实施，例如，在管理域内的边界节点上。从该管理域中策略无关节点的角度来看，这些具有策略能力的节点将充当受信任节点。或者，策略可以仅应用于pce，而所有pcc都是策略无关节点。
- Scalability One of the important requirements for the mechanisms is scalability. The mechanisms must scale at least to the same extent that RSVP-TE signaling scales in terms of accommodating multiple LSPs and network nodes in the path of an LSP. There are several sensitive areas in terms of scalability of policy-based path computation control. First, not every policy-aware node in an infrastructure should be expected to contact a remote PDP. This would cause potentially long delays in verifying requests. Additionally, the policy control architecture must scale at least as well as RSVP-TE protocol based on factors such as the size of RSVP-TE messages, the time required for the network to service an RSVP-TE request, local processing time required per node, and local memory consumed per node. These scaling considerations are of particular importance during re-routing of a set of LSPs.
- 可伸缩性机制的一个重要要求是可伸缩性。这些机制的扩展必须至少与RSVP-TE信令在适应LSP路径中的多个LSP和网络节点方面的扩展程度相同。在基于策略的路径计算控制的可伸缩性方面有几个敏感领域。首先，不应期望基础结构中的每个策略感知节点都联系远程PDP。这将导致验证请求的潜在长时间延迟。此外，策略控制体系结构必须根据诸如RSVP-TE消息的大小、网络服务RSVP-TE请求所需的时间、每个节点所需的本地处理时间以及每个节点消耗的本地内存等因素，至少扩展RSVP-TE协议。在一组LSP的重新路由过程中，这些缩放注意事项特别重要。
- Security and denial-of-service considerations The policy control architecture, protocols, and mechanisms must be secure as far as the following aspects are concerned:
- 安全和拒绝服务注意事项就以下方面而言，策略控制体系结构、协议和机制必须是安全的：
o First, the mechanisms proposed must minimize theft and denial-of-service threats.
o 首先，提出的机制必须将盗窃和拒绝服务威胁降至最低。
o Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating.
o 其次，必须确保参与策略控制的实体（如政治公众人物和政策制定者）能够在通信之前验证彼此的身份并建立必要的信任。
- Inter-AS and inter-area requirements There are several inter-AS policy-related requirements discussed in [RFC4216] and [RFC5376], and inter-area policy-related requirements discussed in [RFC4927]. These requirements must be addressed by policy-enabled PCE mechanisms and protocols.
- AS间和区域间需求[RFC4216]和[RFC5376]中讨论了几个AS间策略相关需求，以及[RFC4927]中讨论的区域间策略相关需求。这些要求必须通过政策支持的PCE机制和协议来解决。
It should be noted that this document only outlines the communication elements and mechanisms needed to allow a wide variety of possible policies to be applied for path computation control. It does not include any discussion of any specific policy behavior, nor does it define or require use of specific policies.
应该注意的是，本文件仅概述了允许对路径计算控制应用多种可能策略所需的通信元素和机制。它不包括任何特定策略行为的讨论，也不定义或要求使用特定策略。
The Policy Core Information Model (PCIM) introduced in [RFC3060] and expanded in [RFC3460] presents the object-oriented information model for representing general policy information.
[RFC3060]中介绍并在[RFC3460]中扩展的策略核心信息模型（PCIM）提供了用于表示一般策略信息的面向对象信息模型。
This model defines two hierarchies of object classes:
此模型定义了对象类的两个层次结构：
- Structural classes representing policy information and control of policies.
- 表示策略信息和策略控制的结构类。
- Association classes that indicate how instances of the structural classes are related to each other.
- 指示结构类的实例如何相互关联的关联类。
These classes can be mapped to various concrete implementations, for example, to a directory that uses Lightweight Directory Access Protocol version 3 (LDAPv3) as its access protocol.
这些类可以映射到各种具体实现，例如，映射到使用轻量级目录访问协议版本3（LDAPv3）作为其访问协议的目录。
Figure 6 shows an abstract from the class inheritance hierarchy for PCIM.
图6显示了PCIM类继承层次结构的抽象。
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract)
| | |
| | +---PolicyGroup
| | |
| | +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition
| | |
| | +---CompoundPolicyCondition
| | |
| | +---CompoundFilterCondition
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction
| | |
| | +---CompoundPolicyAction
| |
| +---PolicyVariable (abstract)
| | |
| | +---PolicyExplicitVariable
| | |
| | +---PolicyImplicitVariable
| | |
| | +---(subtree of more specific classes)
| |
| +---PolicyValue (abstract)
| |
| +---(subtree of more specific classes)
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract)
| | |
| | +---PolicyGroup
| | |
| | +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition
| | |
| | +---CompoundPolicyCondition
| | |
| | +---CompoundFilterCondition
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction
| | |
| | +---CompoundPolicyAction
| |
| +---PolicyVariable (abstract)
| | |
| | +---PolicyExplicitVariable
| | |
| | +---PolicyImplicitVariable
| | |
| | +---(subtree of more specific classes)
| |
| +---PolicyValue (abstract)
| |
| +---(subtree of more specific classes)
Figure 6: PCIM Class Inheritance
图6:PCIM类继承
The policy classes and associations defined in PCIM are sufficiently generic to allow them to represent policies related to anything.
PCIM中定义的策略类和关联具有足够的通用性，允许它们表示与任何内容相关的策略。
Policy models for application-specific areas such as the Path Computation Service may extend the PCIM in several ways. The preferred way is to use the PolicyGroup, PolicyRule, and PolicyTimePeriodCondition classes directly as a foundation for representing and communicating policy information. Then, specific subclasses derived from PolicyCondition and PolicyAction can capture application-specific definitions of conditions and actions of policies.
特定于应用程序的策略模型（如路径计算服务）可以通过多种方式扩展PCIM。首选的方法是将策略组、策略规则和策略时间周期条件类直接用作表示和传递策略信息的基础。然后，从PolicyCondition和PolicyAction派生的特定子类可以捕获策略的条件和操作的特定于应用程序的定义。
The Policy Quality of Service Information Model [RFC3644] further extends the PCIM to represent QoS policy information for large-scale policy domains. New classes introduced in this document describing QoS- and RSVP-related variables, conditions, and actions can be used as a foundation for the PCPIM.
策略服务质量信息模型[RFC3644]进一步扩展了PCIM，以表示大规模策略域的QoS策略信息。本文档中介绍的描述QoS和RSVP相关变量、条件和动作的新类可以用作PCPIM的基础。
Detailed description of the PCPIM will be provided in a separate document.
PCPIM的详细说明将在单独的文件中提供。
The following components are defined as part of the framework to support policy-enabled path computation:
以下组件被定义为框架的一部分，以支持策略启用的路径计算：
- PCE Policy Repository A database from which PCE policies are available in the form of instances of PCPIM classes. PCE Policies are configured and managed by PCE Policy Management Tools;
- PCE策略存储库PCE策略以PCPIM类实例的形式从中可用的数据库。PCE策略由PCE策略管理工具配置和管理；
- PCE Policy Decision Point (PCE-PDP) A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCE-PEP(s);
- PCE策略决策点（PCE-PDP）一个逻辑实体，能够从一个或多个策略存储库检索相关路径计算策略，并将信息传递给相关PCE-PEP；
- PCE Policy Enforcement Point (PCE-PEP) A logical entity capable of issuing device-specific Path Computation Engine configuration requests for the purpose of enforcing the policies;
- PCE策略实施点（PCE-PEP）：能够发出设备特定路径计算引擎配置请求以实施策略的逻辑实体；
- PCC Policy Decision Point (PCC-PDP) A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCC-PEP(s);
- PCC策略决策点（PCC-PDP）一个逻辑实体，能够从一个或多个策略存储库检索相关路径计算策略，并将信息传递给相关的PCC-PEP；
- PCC Policy Enforcement Point (PCC-PEP) A logical entity capable of issuing device-specific Path Computation Service User configuration requests for the purpose of enforcing the policies.
- PCC策略实施点（PCC-PEP）能够发出设备特定路径计算服务用户配置请求以实施策略的逻辑实体。
From the policy perspective a PCC is logically decomposed into two parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located with a Path Computation Service User entity that requires remote path computation (for example, the GMPLS control plane of an LSR). The PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) or separated. In the latter case, they talk to each other via such protocols as SOAP [W3CSOAP] or BEEP [RFC3080].
从政策角度来看，PCC在逻辑上分为两部分：PCC-PDP和PCC-PEP。当存在时，PCC-PEP与需要远程路径计算的路径计算服务用户实体（例如，LSR的GMPLS控制平面）位于同一位置。PCC-PEP和PCC-PDP可以物理上位于同一位置（根据[RFC2748]）或分开。在后一种情况下，它们通过SOAP[W3CSOAP]或BEEP[RFC3080]等协议相互通信。
Likewise, a PCE is logically decomposed into two parts: PCE-PEP and PCE-PDP. When present, PCE-PEP is co-located with a Path Computation Engine entity that actually provides the Path Computation Service (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may be physically co-located or separated. In the later case, they communicate using such protocols as SOAP and/or BEEP.
同样，PCE在逻辑上被分解为两部分：PCE-PEP和PCE-PDP。当存在时，PCE-PEP与实际提供路径计算服务（即运行路径计算算法）的路径计算引擎实体位于同一位置。PCE-PEP和PCE-PDP可以物理上共存或分离。在后一种情况下，它们使用SOAP和/或BEEP等协议进行通信。
PCC-PDP/PCE-PDP may be co-located with, or separated from, an associated PCE Policy Repository. In the latter case, the PDPs use some access protocol (for example, LDAPv3 or SNMP). The task of PDPs is to retrieve policies from the repository (or repositories) and convey them to respective PEPs either in an unsolicited way or upon the PEP's requests.
PCC-PDP/PCE-PDP可与相关PCE策略存储库位于同一位置或与之分离。在后一种情况下，PDP使用一些访问协议（例如，LDAPv3或SNMP）。PDP的任务是从存储库（或多个存储库）中检索策略，并以未经请求的方式或应政治公众人物的请求将其传达给相应的政治公众人物。
A PCC-PEP may receive policy information not only from PCC-PDP(s) but also from PCE-PEP(s) via PCC-PCE communication and/or PCE discovery protocols. Likewise, a PCE-PEP may receive policy information not only from PCE-PDP(s) but also from PCC-PEP(s), via the PCC-PCE communication protocol [PCEP].
PCC-PEP不仅可以从PCC-PDP接收策略信息，还可以通过PCC-PCE通信和/或PCE发现协议从PCC-PEP接收策略信息。同样，PCE-PEP不仅可以通过PCC-PCE通信协议[PCEP]从PCE-PDP接收策略信息，还可以通过PCC-PCE通信协议[PCEP]从PCC-PEP接收策略信息。
Any given policy can be interpreted (that is, translated into a sequence of concrete device specific configuration requests) either on a PDP or on the associated PEP or partly on the PDP and partly on the PEP.
任何给定的策略都可以在PDP或相关PEP上解释（即，转换为具体设备特定的配置请求序列），或者部分在PDP上，部分在PEP上解释。
Generally speaking, the task of the PCC-PEP is to select the PCE and build path computation requests applying service-specific policies provided by the PCC-PDP. The task of the PCE-PEP is to control path computations by applying request-specific policies found in the requests as well as client-specific and domain-specific policies supplied by the PCE-PDP.
一般来说，PCC-PEP的任务是选择PCE并应用PCC-PDP提供的特定于服务的策略构建路径计算请求。PCE-PEP的任务是通过应用请求中发现的特定于请求的策略以及PCE-PDP提供的特定于客户端和特定于域的策略来控制路径计算。
The PCE policy architecture supports policy being applied at a PCC and at a PCE. While the architecture supports policy being applied at both, there is no requirement for policy to always be applied at both, or even at either. The use of policy in a network, on PCCs,
PCE策略体系结构支持在PCC和PCE上应用策略。虽然体系结构支持在两个位置都应用策略，但不要求始终在两个位置都应用策略，甚至在两个位置都应用策略。在PCC上的网络中使用策略，
and on PCEs, is a specific network design choice. Some networks may choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 8), and others at both PCCs and PCEs (Figure 9). Regardless of where policy is applied, it must be applied in a consistent fashion in order to achieve the intended results.
而在PCE上，则是一种特定的网络设计选择。一些网络可能选择仅在PCC（图7）、一些PCE（图8）和其他PCC和PCE（图9）上应用策略。无论政策应用于何处，都必须以一致的方式应用，以实现预期的结果。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy -----------------------
| PCC-PDP |<--------- | PCE Policy Repository |
--------- -----------------------
^
| e.g., SOAP
v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy -----------------------
| PCC-PDP |<--------- | PCE Policy Repository |
--------- -----------------------
^
| e.g., SOAP
v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
Figure 7: Policies Applied on PCC Only
图7：仅适用于PCC的政策
Along with supporting flexibility in where policy may be applied, the PCE architecture is also flexible in terms of where specific types of policies may be applied. Also, the PCE architecture allows for the application of only a subset of policy types. [RFC4655] defines several PC policy types. Each of these may be applied at either a PCC or a PCE or both. Clearly, when policy is only applied at PCCs or at PCEs, all PCE policy types used in the network must be applied at those locations.
除了支持在何处应用策略的灵活性外，PCE体系结构在何处应用特定类型的策略方面也具有灵活性。此外，PCE体系结构只允许应用策略类型的子集。[RFC4655]定义了几种PC策略类型。其中每一个都可以应用于PCC或PCE或两者。显然，当策略仅应用于PCC或PCE时，网络中使用的所有PCE策略类型都必须应用于这些位置。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
----------------------- Policy ---------
| PCE Policy Repository | -------->| PCE-PDP |
----------------------- ---------
^
e.g., SOAP |
v
--------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
----------------------- Policy ---------
| PCE Policy Repository | -------->| PCE-PDP |
----------------------- ---------
^
e.g., SOAP |
v
--------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 8: Policies Applied on Only
图8：仅在上应用的策略
In the case where policy is only applied at a PCE, it is expected that the PCC will pass to the PCE all information about the service that it can gather in the path computation request (most likely in the form of PCPIM policy variables). The PCE is expected to understand this information and apply appropriate policies while defining the actual parameters of the path computation to be performed. Note that in this scenario, the PCC cannot apply server-specific or any other policies, and PCE selection is static.
在策略仅应用于PCE的情况下，预期PCC将向PCE传递其可在路径计算请求中收集的关于服务的所有信息（最有可能以PCPIM策略变量的形式）。PCE在定义要执行的路径计算的实际参数时，应理解此信息并应用适当的策略。请注意，在此场景中，PCC不能应用特定于服务器的策略或任何其他策略，并且PCE选择是静态的。
When applying policy at both the PCC and PCE, it is necessary to select which types of policies are applied at each. In such configurations, it is likely that the application of policy types will be distributed across the PCC and PCE rather than applying all of them at both. For example, user-specific and server-specific policies may be applied at a PCC, request- and client-specific policies may be applied at a PCE, while domain-specific policies may be applied at both the PCC and PCE.
在PCC和PCE上应用策略时，需要选择在每个位置应用哪些类型的策略。在这种配置中，策略类型的应用可能会分布在PCC和PCE之间，而不是同时应用所有策略类型。例如，特定于用户和特定于服务器的策略可以应用于PCC，特定于请求和客户端的策略可以应用于PCE，而特定于域的策略可以应用于PCC和PCE。
In the case when policy is only applied at a PCC, the PCC must apply all the types of required policies, for example user-, service-, server-, and domain-specific policies. The PCC uses the policies to construct a path computation request that appropriately represents the applied policies. The request will necessarily be limited to the set of "basic" (that is, non-policy capable) constraints explicitly defined by the PCC-PCE communication protocol.
如果策略仅应用于PCC，则PCC必须应用所有类型的必需策略，例如用户、服务、服务器和特定于域的策略。PCC使用策略来构造适当表示应用策略的路径计算请求。该请求必须限制在PCC-PCE通信协议明确定义的一组“基本”（即，不支持策略）约束内。
Within the policy-enabled path computation framework policy repositories may be used in a single or multiple PCE policy repository configuration:
在策略启用的路径计算框架内，策略存储库可用于单个或多个PCE策略存储库配置：
o) Single PCE Policy Repository
o) 单个PCE策略存储库
In this configuration, there is a single PCE Policy Repository shared between PCCs and PCEs.
在此配置中，PCC和PCE之间共享一个PCE策略存储库。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 9: Single PCC/PCE Policy Repository
图9：单个PCC/PCE策略存储库
o) Multiple PCE Policy Repositories
o) 多个PCE策略存储库
The repositories in this case may be fully or partially synchronized by some discovery/synchronization management protocol or may be completely independent. Note that the situation when PCE Policy Repository A exactly matches PC Policy Repository B, results in the single PCE Policy Repository configuration case.
在这种情况下，存储库可以通过某些发现/同步管理协议完全或部分同步，也可以完全独立。请注意，如果PCE策略存储库A与PC策略存储库B完全匹配，则会导致出现单个PCE策略存储库配置情况。
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCC-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCC-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 10: Multiple PCE/PCC Policy Repositories
图10：多个PCE/PCC策略存储库
The previous section shows the relationship between PCCs and PCEs. A parallel relationship exists between cooperating PCEs, and, in fact, this relationship can be viewed as the same as the relationship between PCCs and PCEs. The one notable difference is that there will be cases where having a shared PCE Policy Repository will not be desirable, for example, when the PCEs are managed by different entities. Note that in this case, it still remains necessary for the policies to be consistent across the domains in order to identify usable paths. The other notable difference is that a PCE, while processing a path computation request, may need to apply requester-specific (that is, client-specific) policies in order to modify the request before sending it to other cooperating PCE(s). This relationship is particularly important as the PCE architecture allows for configuration where all PCCs are not policy-enabled.
上一节显示了PCC和PCE之间的关系。合作的PCE之间存在平行关系，事实上，这种关系可以被视为与PCC和PCE之间的关系相同。一个显著的区别是，在某些情况下，不需要共享PCE策略存储库，例如，当PCE由不同的实体管理时。请注意，在这种情况下，仍然需要跨域保持策略一致，以便识别可用路径。另一个显著的区别是，PCE在处理路径计算请求时，可能需要应用特定于请求者（即特定于客户端）的策略，以便在将请求发送到其他协作PCE之前修改该请求。这种关系尤其重要，因为PCE体系结构允许在所有PCC均未启用策略的情况下进行配置。
The following are example configurations. These examples do not represent an exhaustive list and other configurations are expected.
以下是示例配置。这些示例并不代表一个详尽的列表，预期会有其他配置。
o) Single Policy Repository
o) 单一策略存储库
In this configuration, there is a single PCE Policy Repository shared between PCEs. This configuration is likely to be useful within a single administrative domain where multiple PCEs are provided for redundancy or load distribution purposes.
在此配置中，PCE之间共享一个PCE策略存储库。此配置在单个管理域中可能很有用，其中提供多个PCE用于冗余或负载分配目的。
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol ---------
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol ---------
Figure 11: Single PCC Policy Repository
图11：单个PCC策略存储库
o) Multiple Policy Repositories
o) 多个策略存储库
The repositories in this case may be fully or partially synchronized by some discovery/synchronization management protocol(s) or may be completely independent. In the multi-domain case, it is expected that the repositories will be distinct, providing, however, consistent policies.
在这种情况下，存储库可以通过某些发现/同步管理协议完全或部分同步，也可以完全独立。在多域情况下，预期存储库将是不同的，但提供一致的策略。
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCE-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCE-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 12: Multiple PCC Policy Repositories
图12：多个PCC策略存储库
The management of path computation policy information used by PCCs and PCEs is largely out of scope of the described framework. The framework assumes that such information is installed, removed, and otherwise managed using typical policy management techniques. Policy Repositories may be populated and managed via static configuration, standard and proprietary policy management tools, or even dynamically via policy management/discovery protocols and applications.
PCC和PCE使用的路径计算策略信息的管理在很大程度上超出了所述框架的范围。该框架假定使用典型的策略管理技术安装、删除和管理此类信息。策略存储库可以通过静态配置、标准和专有策略管理工具填充和管理，甚至可以通过策略管理/发现协议和应用程序动态填充和管理。
Flexibility in the application of policy types is imperative from the architecture perspective. However, this commodity implies added complexity on the part of the PCE-related communication protocols.
从体系结构的角度来看，策略类型应用的灵活性是必不可少的。然而，这种商品意味着PCE相关通信协议的复杂性增加。
One added complexity is that PCE communication protocols must carry certain information to support various policy types that may be applied. For example, in the case where policy is only applied at a PCE, a PCC-PCE request must carry sufficient information for the PCE to apply service- or user-specific policies. This does imply that a PCC must have sufficient understanding of what policies can be applied at the PCE. Such information may be obtained via local configuration, static coding, or even via a PCE discovery mechanism. The PCC must also have sufficient understanding to properly encode the required information for each policy type.
一个额外的复杂性是，PCE通信协议必须携带某些信息，以支持可能应用的各种策略类型。例如，在策略仅应用于PCE的情况下，PCC-PCE请求必须包含足够的信息，以便PCE应用特定于服务或用户的策略。这确实意味着PCC必须充分了解什么样的政策可以适用于PCE。此类信息可通过本地配置、静态编码或甚至通过PCE发现机制获得。PCC还必须有足够的理解，以正确编码每种保单类型所需的信息。
Another added complexity is that PCE communication protocols must also be able to carry information that may result from a policy decision. For example, user- or service-specific policy applied at a PCC may result in policy-related information that must be carried along with the request for use by a PCE. This complexity is particularly important as it may be used to introduce new path computation parameters (e.g., constraints, objection functions, etc.) without modification of the core PCC and PCE. This communication will likely simply require the PCE communication protocols to support opaque policy-related information elements.
另一个增加的复杂性是，PCE通信协议还必须能够承载可能由策略决策产生的信息。例如，在PCC应用的特定于用户或服务的策略可能导致与策略相关的信息必须与PCE使用的请求一起携带。这种复杂性尤其重要，因为它可用于引入新的路径计算参数（例如，约束、目标函数等），而无需修改核心PCC和PCE。这种通信可能只需要PCE通信协议来支持不透明的策略相关信息元素。
A final added complexity is that PCE communication protocols must also be able to support updated or unsolicited responses from a PCE. For example, changes in PCE policy may force a change to a previously provided path. Such updated or unsolicited responses may contain information that the PCC must act on, and may contain policy information that must be provided to a PCC.
最后增加的复杂性是，PCE通信协议还必须能够支持来自PCE的更新或未经请求的响应。例如，PCE策略的更改可能会强制更改先前提供的路径。此类更新或未经请求的回复可能包含PCC必须采取行动的信息，也可能包含必须提供给PCC的政策信息。
PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request-response type PCC-PCE Communication Protocol, i.e., [PCEP]. This document makes no assumptions as to what exact protocol is used to support this communication. This document does assume that the semantics of a path computation request are sufficiently abstract and general, and support both PCE-PCC and PCE-PCE communication.
PCC-PEP和PCE-PEP或一对PCE-PEP通过请求-响应型PCC-PCE通信协议进行通信，即[PCEP]。本文件未对支持此通信所使用的确切协议做出任何假设。本文档假定路径计算请求的语义足够抽象和通用，并且支持PCE-PCC和PCE-PCE通信。
From a policy perspective, a path computation request should include at a minimum:
从策略的角度来看，路径计算请求至少应包括：
o One or more source addresses; o One or more destination addresses; o Computation type (P2P (point to point), P2MP (point to multipoint), MP2P (multipoint to point), etc.); o Number of required paths; o Zero or more policy descriptors in the following format: <policy name>, <policy variable1 name>, <param11>, <param12>,...,<param1N> <policy variable2 name>, <param21>, <param12>,...,<param2N> ... <policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
o 一个或多个源地址；o一个或多个目的地地址；o计算类型（P2P（点对点）、P2MP（点对多点）、MP2P（多点对点）等）；o所需路径的数量；o以下格式的零个或多个策略描述符：<policy name>、<policy variable1 name>、<param11>、<param12>、<param1N>、<policy variable2 name>、<param21>、<param12>、<param2N><策略变量名称>，<paramM1>，<paramM2>，…，<paramMN>
A successful path computation response, at minimum, should include the list of computed paths and may include policies (in the form of policy descriptors as in path computation request, see above) for use in evaluating and otherwise applying the computed paths.
成功的路径计算响应至少应包括计算路径的列表，并可包括用于评估和应用计算路径的策略（如路径计算请求中的策略描述符形式，见上文）。
PCC-PCE Communication Protocol provides transport for policy information and should not understand nor make any assumptions about the semantics of policies specified in path computation requests and responses.
PCC-PCE通信协议为策略信息提供传输，不应理解或假设路径计算请求和响应中指定的策略语义。
Note: This document explicitly allows for (but does not require) the PCC to decide that all necessary constraints, objective functions, etc. pertinent to the computation of paths for the service in question are to be determined by the PCE performing the computation. In this case, the PCC will use a set of policies (more precisely, PCPIM policy variables) describing the service-specific information. These policies may be placed within the path computation request and delivered to the PCE via a PCC-PCE communication protocol such as [PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand this information and use it to determine the constraints and optimization functions applying local policies (that is, policies locally configured or provided by the associated PCE-PDP(s)).
注：本文件明确允许（但不要求）PCC决定由执行计算的PCE确定与所述服务路径计算相关的所有必要约束、目标函数等。在这种情况下，PCC将使用一组策略（更准确地说，PCPIM策略变量）来描述特定于服务的信息。这些策略可以放置在路径计算请求中，并通过诸如[PCEP]的PCC-PCE通信协议传送到PCE。PCE（更准确地说，PCE-PEP）应理解该信息，并使用该信息确定应用本地策略（即，本地配置或由相关PCE-PDP提供的策略）的约束和优化功能。
Dynamic PCE discovery allows for PCCs and PCEs to automatically discover a set of PCEs (including information required for the PCE selection). It also allows for PCCs and PCEs to dynamically detect new PCEs or any modification of PCEs status. Policy can be applied in two ways in this context:
动态PCE发现允许PCC和PCE自动发现一组PCE（包括PCE选择所需的信息）。它还允许PCC和PCE动态检测新PCE或PCE状态的任何修改。在这种情况下，可以通过两种方式应用策略：
1. Restricting the scope of information distribution for the mandatory set of information (in particular the PCE presence and location).
1. 限制强制性信息集的信息分发范围（尤其是PCE的存在和位置）。
2. Restricting the type and nature of the optional information distributed by the discovery protocol. The latter is also subject to policy since the PCE architecture allows for distributing this information using either PCE discovery protocol(s) or PCC-PCE communication protocol(s). One important policy decision in this context is the nature of the information to be distributed, especially, when this information is not strictly speaking "discovery" information, rather, the PCE state changes. Client-specific and domain-specific policies may be applied when deciding whether this information should be distributed and to which clients of the path computation service (that is, which PCCs and/or PCEs).
2. 限制由发现协议分发的可选信息的类型和性质。后者也受政策约束，因为PCE体系结构允许使用PCE发现协议或PCC-PCE通信协议分发此信息。在这种情况下，一个重要的决策是要分发的信息的性质，特别是当这些信息严格来说不是“发现”信息，而是PCE状态发生变化时。在决定是否应将此信息分发给路径计算服务的哪些客户端（即，哪些PCC和/或PCE）时，可以应用特定于客户端和特定于域的策略。
Another place where policy applies is at the administrative boundaries. In multi-domain networks, multiple PCEs will communicate with each other and across administrative boundaries. In such cases, domain-specific policies would be applied to 1) filter the information exchanged between peering PCEs during the discovery process (to the bare minimum in most cases if at all allowed by the security policy) and 2) limit the content of information being passed in path computation request and responses.
政策适用的另一个地方是行政边界。在多域网络中，多个PCE将相互通信并跨越管理边界。在这种情况下，特定于域的策略将应用于1）过滤发现过程中对等PCE之间交换的信息（在大多数情况下，如果安全策略允许的话，达到最低限度）和2）限制路径计算请求和响应中传递的信息内容。
This section presents a non-exhaustive list of representative scenarios.
本节提供了一个非详尽的代表性场景列表。
When a GMPLS LSR receives a Setup (RSVP Path) message from an upstream LSR, the LSR may decide to use a remote Path Computation Entity. The following sequence of events occurs in this case:
当GMPLS LSR从上游LSR接收到设置（RSVP Path）消息时，LSR可以决定使用远程路径计算实体。在这种情况下，会发生以下事件序列：
- A PCC-PEP co-located with the LSR applies the service-specific policies to select a PCE for the service path computation as well as to build the path computation request (that is, to select a list
- 与LSR共存的PCC-PEP应用特定于服务的策略来选择用于服务路径计算的PCE以及构建路径计算请求（即，选择列表）
of policies, their variables, conditions and actions expressing constraints, diversities, objective functions and relaxation strategies appropriate for the service path computation). The policies may be:
策略，其变量、条件和动作表示适用于服务路径计算的约束、多样性、目标函数和松弛策略）。这些政策可以是：
a) Statically configured on the PCC-PEP;
a) 在PCC-PEP上静态配置；
b) Communicated to the PCC-PEP by a remote or local PCC-PDP via protocol such as SOAP either proactively (most of the cases) or upon an explicit request by the PCC-PEP in cases when some specifics of the new service have not been covered yet by the policies so far known to the PCC-PEP).
b) 由远程或本地PCC-PDP通过协议（如SOAP）主动（大多数情况下）或在PCC-PEP明确请求的情况下（在PCC-PEP目前已知的政策尚未涵盖新服务的某些细节的情况下）与PCC-PEP通信。
The input for the decision process on the PCC-PEP is the information found in the signaling message as well as any other service-specific information such as port ID over which the message was received, associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so forth. After the path computation request is built, it is sent directly to the PCE-PEP using the PCC-PCE Communication Protocol, e.g., [PCEP].
PCC-PEP上的决策过程的输入是在信令消息中找到的信息以及任何其他特定于服务的信息，例如通过其接收消息的端口ID、相关联的VPN ID、参考点类型（UNI、E-NNI等）等。构建路径计算请求后，使用PCC-PCE通信协议（例如，[PCEP]）将其直接发送到PCE-PEP。
- PCE-PEP validates and otherwise processes the request applying the policies found in the request- as well as client- and domain-specific policies. The latter, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is the following information:
- PCE-PEP应用请求中的策略以及特定于客户端和域的策略来验证和处理请求。后者也可以在PCE-PEP上静态配置，或者由相关联的本地或远程PCE-PDP通过诸如SOAP的协议提供。决策过程的结果是以下信息：
a) Whether the request should be satisfied, rejected, or dismissed.
a) 是否应满足、拒绝或驳回请求。
b) The sets of sources and destinations for which paths should be locally computed.
b) 应本地计算其路径的源和目标集。
c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of locally performed path computation.
c) 在每个局部执行的路径计算中要考虑的约束集、多样性、优化函数和松弛。
d) The address of the next-in-chain PCE.
d) 链中下一个PCE的地址。
e) The path computation request to be sent to the next-in-chain PCE.
e) 要发送到下一个链内PCE的路径计算请求。
The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using a PCC-PCE Communication Protocol. Then, it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC-
PCE-PEP指示同一位置的路径计算引擎执行本地路径计算，并在必要时使用PCC-PCE通信协议将路径计算请求发送到下一个链内PCE。然后，它等待来自本地路径计算引擎和远程PCE的响应，组合产生的路径，并使用PCC将它们发送回PCC-PEP-
PCE Communication Protocol. The response contains the resulting paths as well as policies describing some additional information (for example, which of constraints were honored, which were dismissed, and which were relaxed and in what way).
PCE通信协议。响应包含结果路径以及描述一些附加信息的策略（例如，哪些约束得到遵守，哪些约束被取消，哪些约束被放松，以及以何种方式放松）。
- PCC-PEP instructs the signaling subsystem of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s).
- PCC-PEP指示GMPLS LSR的信令子系统将接收到的路径编码到传出设置消息中。
This case parallels the previous example, but the user- and service-specific policies should be applied at the PCE as the PCC is policy ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) message from an upstream LSR, the LSR may decide to use a non-co-located Path Computation Entity. The following sequence of events occurs in this case:
这种情况与前面的示例类似，但是用户和服务特定的策略应该应用于PCE，因为PCC不知道策略。同样，当GMPLS LSR已经从上游LSR接收到设置（RSVP Path）消息时，LSR可以决定使用非共址路径计算实体。在这种情况下，会发生以下事件序列：
- The PCC constructs a PCE request using information found in the signaling/provisioning message as well as any other service-specific information such as port ID over which the message was received, associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so forth. This information is encoded in the request in the form of policy variables. After the request is built, it is sent directly to the PCE-PEP using a PCC-PCE Communication Protocol.
- PCC使用在信令/供应消息中找到的信息以及任何其他特定于服务的信息（例如通过其接收消息的端口ID、相关联的VPN ID、参考点类型（UNI、E-NNI等））来构造PCE请求。该信息以策略变量的形式编码在请求中。构建请求后，使用PCC-PCE通信协议将其直接发送到PCE-PEP。
- PCE-PEP validates and otherwise processes the request interpreting the policy variables found in the request and applying user-, service-, client-, and domain-specific policies to build the actual path computation request. The policies, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is the following information:
- PCE-PEP验证并以其他方式处理请求，解释在请求中找到的策略变量，并应用用户、服务、客户端和域特定的策略来构建实际的路径计算请求。策略也可以在PCE-PEP上静态配置，或者由相关联的本地或远程PCE-PDP通过诸如SOAP的协议提供。决策过程的结果是以下信息：
a) Whether the request should be satisfied, rejected, or dismissed.
a) 是否应满足、拒绝或驳回请求。
b) The sets of sources and destinations for which paths should be locally computed.
b) 应本地计算其路径的源和目标集。
c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of locally performed path computation.
c) 在每个局部执行的路径计算中要考虑的约束集、多样性、优化函数和松弛。
d) The address of the next-in-chain PCE.
d) 链中下一个PCE的地址。
e) The path computation request to be sent to the next-in-chain PCE.
e) 要发送到下一个链内PCE的路径计算请求。
The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using the PCC-PCE Communication Protocol. Then, it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains the resulting paths as well as policies describing some additional information (for example, which of constraints were honored, which were dismissed, and which were relaxed and in what way)
PCE-PEP指示同一位置的路径计算引擎执行本地路径计算，并在必要时使用PCC-PCE通信协议将路径计算请求发送到下一个链内PCE。然后，它等待来自本地路径计算引擎和远程PCE的响应，组合产生的路径，并使用PCC-PCE通信协议将它们发送回PCC-PEP。响应包含结果路径以及描述一些附加信息的策略（例如，哪些约束得到遵守，哪些约束被取消，哪些约束被放松，以及以何种方式放松）
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s).
- PCC-PEP指示GMPLS LSR的信令子系统将接收到的路径编码到传出设置消息中。
An important aspect of the policy-enabled path computation framework discussed above is the ability to introduce new constraints with minimal impact. In particular, only those components and mechanisms that will use a new constraint need to be updated in order to support the new constraint. Importantly, those components and mechanisms that will not use the new constraint must not require any change in order for the new constraint to be utilized. For example, the PCE communication protocols must not require any changes to support new constraints. Likewise, PCC and PCEs that will not process new constraints must not require any modification.
上面讨论的基于策略的路径计算框架的一个重要方面是能够以最小的影响引入新的约束。特别是，只有那些将使用新约束的组件和机制需要更新以支持新约束。重要的是，那些不使用新约束的组件和机制不得需要任何更改才能使用新约束。例如，PCE通信协议不得要求任何更改以支持新的约束。同样，不会处理新约束的PCC和PCE不得要求任何修改。
Consider the case where a PCE has been upgraded with software supporting optical physical impairment constraint, such as Polarization Mode Dispersion (PMD), that previously was not supported in the domain. In this case, one or more new policies will be installed in the PCE Policy Repository (associated with the PCE) defining the constraint (rules that determine application criteria, set of policy variables, conditions, actions, etc.) and its relaxation strategy (or strategies). The new policies will be also propagated into other PCE Policy Repositories within the domain via discovery and synchronization protocols or via local configuration. PCE-PDPs and PCC-PDPs will then retrieve the corresponding policies from the repository (or repositories). From then on, PCC-PDPs will instruct associated PCC-PEPs to add the new policy information into path computation requests for services with certain parameters (for example, for services provisioned in the optical channel (OCh) layer).
考虑PCE已被升级的软件支持光学物理损伤约束，如偏振模色散（PMD），先前在域中不支持。在这种情况下，将在PCE策略库（与PCE关联）中安装一个或多个新策略，以定义约束（确定应用标准、策略变量集、条件、操作等的规则）及其放松策略（或策略）。新策略还将通过发现和同步协议或本地配置传播到域内的其他PCE策略存储库中。然后，PCE PDP和PCC PDP将从存储库中检索相应的策略。从那时起，PCC-pdp将指示相关的PCC-pep将新的策略信息添加到具有特定参数的服务（例如，对于在光信道（OCh）层中提供的服务）的路径计算请求中。
It is important to note that policy-enabled path computation model naturally solves the PCE capability discovery issues. Suppose a PCE working in a single PCE Policy Repository configuration starts to support a new constraint. Once a corresponding policy installed in
需要注意的是，策略启用的路径计算模型自然地解决了PCE能力发现问题。假设在单个PCE策略存储库配置中工作的PCE开始支持新的约束。一旦在中安装了相应的策略
the repository, it automatically becomes available for all repository users, that is, PCCs. In the multi-repository case some policy synchronization must be provided; however, this problem is one of the management plane which is solved already.
在存储库中，它将自动对所有存储库用户（即PCC）可用。在多存储库的情况下，必须提供一些策略同步；然而，这个问题是已经解决的管理层面之一。
This document adds to the policy security considerations mentioned in [RFC4655]. In particular, it is now necessary to consider the security issues related to policy information maintained in PCE Policy Repositories and policy-related transactions. The most notable issues, some of which are also listed in [RFC4655], are:
本文档增加了[RFC4655]中提到的策略安全注意事项。特别是，现在需要考虑与PCE策略库和策略相关事务中维护的策略信息相关的安全问题。[RFC4655]中列出了最值得注意的问题，其中一些问题包括：
- Unauthorized access to the PCE Policy Repositories;
- 未经授权访问PCE策略存储库；
- Interception of policy information when it is retrieved from the repositories and/or transported from PDPs to PEPs;
- 从存储库检索和/或从PDP传输到PEP时拦截策略信息；
- Interception of policy-related information in path computation requests and responses;
- 拦截路径计算请求和响应中的策略相关信息；
o Impersonation of user and client identities;
o 模拟用户和客户身份；
o Falsification of policy information and/or PCE capabilities;
o 伪造政策信息和/或PCE能力；
o Denial-of-service attacks on policy-related communication mechanisms.
o 对策略相关通信机制的拒绝服务攻击。
As with [RFC4655], it is expected that PCE solutions will address the PCE aspects of these issues in detail.
与[RFC4655]一样，预计PCE解决方案将详细解决这些问题的PCE方面。
Adrian Farrel contributed significantly to this document. We would like to thank Bela Berde for fruitful discussions on PBM and policy-driven path computation. We would also like to thank Kobus Van der Merwe for providing insights and examples regarding PCE policy applications.
阿德里安·法雷尔对这份文件做出了重大贡献。我们要感谢Bela Berde就PBM和政策驱动路径计算进行了富有成效的讨论。我们还要感谢Kobus Van der Merwe就PCE政策应用提供的见解和示例。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3060]Moore，B.，Ellesson，E.，Strassner，J.，和A.Westerinen，“政策核心信息模型——版本1规范”，RFC 3060，2001年2月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460]Moore，B.，Ed.，“政策核心信息模型（PCIM）扩展”，RFC 3460，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644]Snir，Y.，Ramberg，Y.，Strassner，J.，Cohen，R.，和B.Moore，“政策服务质量（QoS）信息模型”，RFC 36442003年11月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年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月。
[RFC4927] Le Roux, J.-L., Ed., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4927]Le Roux，J.-L.，编辑，“区域间MPLS和GMPLS流量工程的路径计算元素通信协议（PCECP）特定要求”，RFC 4927，2007年6月。
[DMTF] Common Information Model (CIM) Schema, version 2.x. Distributed Management Task Force, Inc. The components of the CIM v2.x schema are available via links on the following DMTF web page: http://www.dmtf.org/standards/standard_cim.php.
[DMTF]公共信息模型（CIM）模式，版本2.x。Distributed Management Task Force，Inc.。CIM v2.x模式的组件可通过以下DMTF网页上的链接获得：http://www.dmtf.org/standards/standard_cim.php.
[IRSCP] Van der Merwe, J., et al., "Dynamic Connectivity Management with an Intelligent Route Service Control Point," ACM SIGCOMM Workshop on Internet Network Management (INM), Pisa, Italy, September 11, 2006.
[IRSCP]Van der Merwe，J.等人，“具有智能路由服务控制点的动态连接管理”，ACM SIGCOMM互联网网络管理（INM）研讨会，意大利比萨，2006年9月11日。
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, November 2008.
[PCEP]Vasseur，JP.，Ed.和JL。Le Roux，Ed.，“路径计算元素（PCE）通信协议（PCEP）”，正在进行的工作，2008年11月。
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]Durham，D.，Ed.，Boyle，J.，Cohen，R.，Herzog，S.，Rajan，R.，和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 2748，2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198]威斯特林，A.，施尼兹莱因，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[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月。
[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月。
[W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and Gudgin, M., "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003.
[W3CSOAP]Hadley，M.，Mendelsohn，N.，Moreau，J.，Nielsen，H.，和Gudgin，M.，“SOAP版本1.2第1部分：消息传递框架”，W3C REC-soap12-part1-20030624，2003年6月。
Authors' Addresses
作者地址
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean，弗吉尼亚州22102电子邮件：ibryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
Dimitri Papadimitriou Alcatel Fr.Wellesplein 1，B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。papadimitriou@alcatel.be
Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，LLC电话：+1 301 468 9228电子邮件：lberger@labn.net
Jerry Ash AT&T EMail: gash5107@yahoo.com
Jerry Ash AT&T电子邮件：gash5107@yahoo.com