Network Working Group R. Yavatkar
Request for Comments: 2753 Intel
Category: Informational D. Pendarakis
IBM
R. Guerin
U. Of Pennsylvania
January 2000
Network Working Group R. Yavatkar
Request for Comments: 2753 Intel
Category: Informational D. Pendarakis
IBM
R. Guerin
U. Of Pennsylvania
January 2000
A Framework for Policy-based Admission Control
基于策略的接纳控制框架
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
The IETF working groups such as Integrated Services (called "int-serv") and RSVP [1] have developed extensions to the IP architecture and the best-effort service model so that applications or end users can request specific quality (or levels) of service from an internetwork in addition to the current IP best-effort service. Recent efforts in the Differentiated Services Working Group are also directed at the definition of mechanisms that support aggregate QoS services. The int-serv model for these new services requires explicit signaling of the QoS (Quality of Service) requirements from the end points and provision of admission and traffic control at Integrated Services routers. The proposed standards for RSVP [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a new reservation setup protocol and new service definitions respectively. Under the int-serv model, certain data flows receive preferential treatment over other flows; the admission control component only takes into account the requester's resource reservation request and available capacity to determine whether or not to accept a QoS request. However, the int-serv mechanisms do not include an important aspect of admission control: network managers and service providers must be able to monitor, control, and enforce use of network resources and services based on policies derived from criteria such as the identity of users and applications, traffic/bandwidth requirements, security considerations, and time-
IETF工作组，如综合服务（称为“int serv”）和RSVP[1]已经开发了对IP架构和尽力而为服务模型的扩展，以便应用程序或最终用户可以在当前IP尽力而为服务的基础上，从互联网请求特定质量（或级别）的服务。区分服务工作组最近的工作还针对支持聚合QoS服务的机制的定义。这些新服务的int-serv模型需要从端点发出QoS（服务质量）要求的明确信号，并在综合服务路由器上提供准入和流量控制。RSVP[RFC 2205]和集成服务[RFC 2211，RFC 2212]的拟议标准分别是新的预约设置协议和新的服务定义的示例。在int-serv模型下，某些数据流比其他数据流受到优先处理；接纳控制组件仅考虑请求者的资源保留请求和可用容量，以确定是否接受QoS请求。但是，int serv机制不包括准入控制的一个重要方面：网络管理者和服务提供商必须能够根据从用户和应用程序的身份、流量/带宽要求等标准派生的策略来监控、控制和强制使用网络资源和服务，安全考虑因素和时间-
of-day/week. Similarly, diff-serv mechanisms also need to take into account policies that involve various criteria such as customer identity, ingress points, and so on.
一天/一周。类似地，diff-serv机制还需要考虑涉及各种标准（如客户身份、入口点等）的策略。
This document is concerned with specifying a framework for providing policy-based control over admission control decisions. In particular, it focuses on policy-based control over admission control using RSVP as an example of the QoS signaling mechanism. Even though the focus of the work is on RSVP-based admission control, the document outlines a framework that can provide policy-based admission control in other QoS contexts. We argue that policy-based control must be applicable to different kinds and qualities of services offered in the same network and our goal is to consider such extensions whenever possible.
本文件旨在指定一个框架，用于对准入控制决策提供基于策略的控制。特别地，它关注使用RSVP作为QoS信令机制的示例的基于策略的对准入控制的控制。尽管工作的重点是基于RSVP的接纳控制，但本文概述了一个框架，该框架可以在其他QoS上下文中提供基于策略的接纳控制。我们认为，基于策略的控制必须适用于在同一网络中提供的不同种类和质量的服务，并且我们的目标是尽可能考虑这种扩展。
We begin with a list of definitions in Section 2. Section 3 lists the requirements and goals of the mechanisms used to control and enforce access to better QoS. We then outline the architectural elements of the framework in Section 4 and describe the functionality assumed for each component. Section 5 discusses example policies, possible scenarios, and policy support needed for those scenarios. Section 6 specifies the requirements for a client-server protocol for communication between a policy server (PDP) and its client (PEP) and evaluates the suitability of some existing protocols for this purpose.
我们从第2节中的定义列表开始。第3节列出了用于控制和强制访问更好QoS的机制的要求和目标。然后，我们在第4节中概述了框架的体系结构元素，并描述了为每个组件假定的功能。第5节讨论了示例策略、可能的场景以及这些场景所需的策略支持。第6节规定了用于策略服务器（PDP）及其客户端（PEP）之间通信的客户端-服务器协议的要求，并评估了某些现有协议的适用性。
The following is a list of terms used in this document.
以下是本文件中使用的术语列表。
- Administrative Domain: A collection of networks under the same administrative control and grouped together for administrative purposes.
- 管理域：在同一管理控制下，为管理目的而分组在一起的网络集合。
- Network Element or Node: Routers, switches, hubs are examples of network nodes. They are the entities where resource allocation decisions have to be made and the decisions have to be enforced. A RSVP router which allocates part of a link capacity (or buffers) to a particular flow and ensures that only the admitted flows have access to their reserved resources is an example of a network element of interest in our context.
- 网元或节点：路由器、交换机、集线器是网络节点的示例。它们是必须做出资源分配决策和执行决策的实体。RSVP路由器将链路容量（或缓冲区）的一部分分配给特定流，并确保只有允许的流才能访问其保留资源，这是我们上下文中感兴趣的网络元素的一个示例。
In this document, we use the terms router, network element, and network node interchangeably, but the should all be interpreted as references to a network element.
在本文档中，我们可以互换地使用术语路由器、网元和网络节点，但都应解释为对网元的引用。
- QoS Signaling Protocol: A signaling protocol that carries an admission control request for a resource, e.g., RSVP.
- QoS信令协议：承载资源（如RSVP）准入控制请求的信令协议。
- Policy: The combination of rules and services where rules define the criteria for resource access and usage.
- 策略：规则和服务的组合，其中规则定义了资源访问和使用的标准。
- Policy control: The application of rules to determine whether or not access to a particular resource should be granted.
- 策略控制：应用规则来确定是否应授予对特定资源的访问权。
- Policy Object: Contains policy-related information such as policy elements and is carried in a request or response related to a resource allocation decision.
- 策略对象：包含与策略相关的信息，如策略元素，并包含在与资源分配决策相关的请求或响应中。
- Policy Element: Subdivision of policy objects; contains single units of information necessary for the evaluation of policy rules. A single policy element may carry an user or application identification whereas another policy element may carry user credentials or credit card information. The policy elements themselves are expected to be independent of which QoS signaling protocol is used.
- 政策要素：政策对象的细分；包含评估策略规则所需的单个信息单元。单个策略元素可以携带用户或应用程序标识，而另一个策略元素可以携带用户凭证或信用卡信息。策略元素本身预期独立于所使用的QoS信令协议。
- Policy Decision Point (PDP): The point where policy decisions are made.
- 政策决策点（PDP）：作出政策决策的点。
- Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced.
- 策略执行点（PEP）：实际执行策略决策的点。
- Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in this document.
- 策略无知节点（PIN）：不使用本文档中定义的机制显式支持策略控制的网络元素。
- Resource: Something of value in a network infrastructure to which rules or policy criteria are first applied before access is granted. Examples of resources include the buffers in a router and bandwidth on an interface.
- 资源：网络基础设施中有价值的东西，在授予访问权之前，首先应用规则或策略标准。资源的示例包括路由器中的缓冲区和接口上的带宽。
- Service Provider: Controls the network infrastructure and may be responsible for the charging and accounting of services.
- 服务提供商：控制网络基础设施，并可能负责服务的收费和记帐。
- Soft State Model - Soft state is a form of the stateful model that times out installed state at a PEP or PDP. It is an automatic way to erase state in the presence of communication or network element failures. For example, RSVP uses the soft state model for installing reservation state at network elements along the path of a data flow.
- 软状态模型-软状态是有状态模型的一种形式，在PEP或PDP上超时安装状态。它是在存在通信或网元故障时自动擦除状态的一种方法。例如，RSVP使用软状态模型在数据流路径上的网络元素上安装保留状态。
- Installed State: A new and unique request made from a PEP to a PDP that must be explicitly deleted.
- 已安装状态：PEP向PDP发出的新的唯一请求，必须明确删除。
- Trusted Node: A node that is within the boundaries of an administrative domain (AD) and is trusted in the sense that the admission control requests from such a node do not necessarily need a PDP decision.
- 受信任节点：位于管理域（AD）边界内的节点，在来自此类节点的准入控制请求不一定需要PDP决策的意义上受信任。
In this section, we describe the goals and requirements of mechanisms and protocols designed to provide policy-based control over admission control decisions.
在本节中，我们描述了旨在对准入控制决策提供基于策略的控制的机制和协议的目标和要求。
- Policies vs Mechanisms: An important point to note is that the framework does not include any discussion of any specific policy behavior or does not require use of specific policies. Instead, the framework only outlines the architectural elements and mechanisms needed to allow a wide variety of possible policies to be carried out.
- 策略与机制：需要注意的一点是，该框架不包括任何特定策略行为的讨论，也不需要使用特定策略。相反，该框架仅概述了允许执行各种可能的政策所需的体系结构要素和机制。
- RSVP-specific: The mechanisms must be designed to meet the policy-based control requirements specific to the problem of bandwidth reservation using RSVP as the signaling protocol. However, our goal is to allow for the application of this framework for admission control involving other types of resources and QoS services (e.g., Diff-Serv) as long as we do not diverge from our central goal.
- 特定于RSVP：这些机制必须设计为满足特定于使用RSVP作为信令协议的带宽预留问题的基于策略的控制要求。然而，我们的目标是，只要我们不偏离我们的中心目标，就允许将此框架应用于涉及其他类型资源和QoS服务（例如，区分服务）的准入控制。
- Support for preemption: The mechanisms designed must include support for preemption. By preemption, we mean an ability to remove a previously installed state in favor of accepting a new admission control request. For example, in the case of RSVP, preemption involves the ability to remove one or more currently installed reservations to make room for a new resource reservation request.
- 支持抢占：设计的机制必须包括对抢占的支持。所谓抢占，我们指的是能够删除先前安装的状态，以接受新的准入控制请求。例如，在RSVP的情况下，抢占涉及到删除一个或多个当前安装的预订以为新的资源预订请求腾出空间的能力。
- Support for many styles of policies: The mechanisms designed must include support for many policies and policy configurations including bi-lateral and multi-lateral service agreements and policies based on the notion of relative priority. 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, resource usage, and provide access information. In particular, mechanisms must be included to provide usage and access information that may be used for accounting and billing purposes.
- 提供监控和记帐信息：这些机制必须包括对监控策略状态、资源使用和提供访问信息的支持。特别是，必须包括提供使用和访问信息的机制，这些信息可用于记帐和计费目的。
- Fault tolerance and recovery: The mechanisms designed on the basis of this framework must include provisions for fault tolerance and recovery from failure cases such as failure of PDPs, disruption in communication including network partitions (and subsequent merging) that separate a PDP from its associated PEPs.
- 容错和恢复：基于此框架设计的机制必须包括容错和故障情况下恢复的规定，如PDP故障、通信中断，包括将PDP与其相关PEP分离的网络分区（以及后续合并）。
- Support for Policy-Ignorant Nodes (PINs): Support for the mechanisms described in this document should not be mandatory for every node in a network. Policy based admission control could be enforced at a subset of nodes, for example the boundary nodes within an administrative domain. These policy capable nodes would function as trusted nodes from the point of view of the policy-ignorant nodes in that administrative domain.
- 对策略无关节点（PIN）的支持：对本文档中描述的机制的支持不应强制用于网络中的每个节点。基于策略的准入控制可以在节点子集上实施，例如管理域内的边界节点。从该管理域中策略无关节点的角度来看，这些具有策略能力的节点将充当受信任节点。
- Scalability: One of the important requirements for the mechanisms designed for policy control is scalability. The mechanisms must scale at least to the same extent that RSVP scales in terms of accommodating multiple flows and network nodes in the path of a flow. In particular, scalability must be considered when specifying default behavior for merging policy data objects and merging should not result in duplicate policy elements or objects. There are several sensitive areas in terms of scalability for policy control over RSVP. 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 that must travel up hop by hop. Secondly, RSVP is capable of setting up resource reservations for multicast flows. This implies that the policy control model must be capable of servicing the special requirements of large multicast flows. Thus, the policy control architecture must scale at least as well as RSVP based on factors such as the size of RSVP messages, the time required for the network to service an RSVP request, local processing time required per node, and local memory consumed per node.
- 可伸缩性：为策略控制设计的机制的一个重要要求是可伸缩性。这些机制的扩展程度必须至少与RSVP在适应多个流和流路径中的网络节点方面的扩展程度相同。特别是，在指定合并策略数据对象的默认行为时，必须考虑可伸缩性，并且合并不应导致重复的策略元素或对象。就RSVP策略控制的可伸缩性而言，存在几个敏感领域。首先，不应期望基础结构中的每个策略感知节点都联系远程PDP。这将在验证必须逐跳向上的请求时造成潜在的长时间延迟。其次，RSVP能够为多播流设置资源预留。这意味着策略控制模型必须能够满足大型多播流的特殊需求。因此，策略控制体系结构必须根据诸如RSVP消息的大小、网络服务RSVP请求所需的时间、每个节点所需的本地处理时间以及每个节点所消耗的本地内存等因素至少扩展RSVP。
- Security and denial of service considerations: The policy control architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed under the framework must minimize theft and denial of service threats. 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.
- 安全和拒绝服务注意事项：就以下方面而言，策略控制体系结构必须是安全的。首先，该框架下提出的机制必须将盗窃和拒绝服务威胁降至最低。其次，必须确保参与策略控制的实体（如政治公众人物和政策制定者）能够在通信之前验证彼此的身份并建立必要的信任。
The two main architectural elements for policy control are the PEP (Policy Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a simple configuration involving these two elements; PEP is a component at a network node and PDP is a remote entity that
策略控制的两个主要架构元素是PEP（策略实施点）和PDP（策略决策点）。图1显示了涉及这两个元素的简单配置；PEP是网络节点上的一个组件，PDP是一个远程实体
may reside at a policy server. The PEP represents the component that always runs on the policy aware node. It is the point at which policy decisions are actually enforced. Policy decisions are made primarily at the PDP. The PDP itself may make use of additional mechanisms and protocols to achieve additional functionality such as user authentication, accounting, policy information storage, etc. For example, the PDP is likely to use an LDAP-based directory service for storage and retrieval of policy information[6]. This document does not include discussion of these additional mechanisms and protocols and how they are used.
可以驻留在策略服务器上。PEP表示始终在策略感知节点上运行的组件。这是政策决定实际执行的点。政策决策主要由PDP做出。PDP本身可以使用附加机制和协议来实现附加功能，例如用户身份验证、记帐、策略信息存储等。例如，PDP可能使用基于LDAP的目录服务来存储和检索策略信息[6]。本文件不包括对这些附加机制和协议及其使用方式的讨论。
The basic interaction between the components begins with the PEP. The PEP will receive a notification or a message that requires a policy decision. Given such an event, the PEP then formulates a request for a policy decision and sends it to the PDP. The request for policy control from a PEP to the PDP may contain one or more policy elements (encapsulated into one or more policy objects) in addition to the admission control information (such as a flowspec or amount of bandwidth requested) in the original message or event that triggered the policy decision request. The PDP returns the policy decision and the PEP then enforces the policy decision by appropriately accepting or denying the request. The PDP may also return additional information to the PEP which includes one or more policy elements. This information need not be associated with an admission control decision. Rather, it can be used to formulate an error message or outgoing/forwarded message.
组件之间的基本交互从PEP开始。政治公众人物将收到需要政策决策的通知或消息。如果发生此类事件，政治公众人物随后制定政策决策请求，并将其发送给PDP。除了触发策略决策请求的原始消息或事件中的准入控制信息（例如，所请求的流量规格或带宽量）之外，从PEP到PDP的策略控制请求还可以包含一个或多个策略元素（封装到一个或多个策略对象中）。PDP返回策略决策，然后政治公众人物通过适当地接受或拒绝请求来执行策略决策。PDP还可以向政治公众人物返回包括一个或多个政策要素的附加信息。该信息不需要与接纳控制决策相关联。相反，它可以用来表示错误消息或传出/转发消息。
________________ Policy server
| | ______
| Network Node | | |------------->
| _____ | | | May use LDAP,SNMP,.. for accessing
| | | | | | policy database, authentication,etc.
| | PEP |<-----|------->| PDP |------------->
| |_____| | |_____|
| |
|________________|
________________ Policy server
| | ______
| Network Node | | |------------->
| _____ | | | May use LDAP,SNMP,.. for accessing
| | | | | | policy database, authentication,etc.
| | PEP |<-----|------->| PDP |------------->
| |_____| | |_____|
| |
|________________|
Figure 1: A simple configuration with the primary policy control architecture components. PDP may use additional mechanisms and protocols for the purpose of accounting, authentication, policy storage, etc.
图1：主要策略控制体系结构组件的简单配置。PDP可使用额外的机制和协议进行记帐、身份验证、策略存储等。
The PDP might optionally contact other external servers, e.g., for accessing configuration, user authentication, accounting and billing databases. Protocols defined for network management (SNMP) or directory access (LDAP) might be used for this communication. While the specific type of access and the protocols used may vary among
PDP可选择性地联系其他外部服务器，例如，用于访问配置、用户身份验证、记帐和计费数据库。为网络管理（SNMP）或目录访问（LDAP）定义的协议可用于此通信。然而，访问的具体类型和使用的协议可能因客户而异
different implementations, some of these interactions will have network-wide implications and could impact the interoperability of different devices.
在不同的实现中，其中一些交互将具有网络范围的影响，并可能影响不同设备的互操作性。
Of particular importance is the "language" used to specify the policies implemented by the PDP. The number of policies applicable at a network node might potentially be quite large. At the same time, these policies will exhibit high complexity, in terms of number of fields used to arrive at a decision, and the wide range of decisions. Furthermore, it is likely that several policies could be applicable to the same request profile. For example, a policy may prescribe the treatment of requests from a general user group (e.g., employees of a company) as well as the treatment of requests from specific members of that group (e.g., managers of the company). In this example, the user profile "managers" falls within the specification of two policies, one general and one more specific.
特别重要的是用于指定PDP实施的政策的“语言”。适用于网络节点的策略数量可能相当大。同时，这些策略在用于达成决策的字段数量和决策范围方面将表现出高度复杂性。此外，可能有多个策略可适用于同一请求配置文件。例如，政策可以规定对一般用户组（例如，公司员工）请求的处理以及对该组特定成员（例如，公司经理）请求的处理。在本例中，用户配置文件“managers”属于两个策略的规范范围，一个是常规策略，另一个是特定策略。
In order to handle the complexity of policy decisions and to ensure a coherent and consistent application of policies network-wide, the policy specification language should ensure unambiguous mapping of a request profile to a policy action. It should also permit the specification of the sequence in which different policy rules should be applied and/or the priority associated with each one. Some of these issues are addressed in [6].
为了处理策略决策的复杂性，并确保在网络范围内连贯一致地应用策略，策略规范语言应确保请求配置文件与策略操作的明确映射。它还应允许指定应用不同策略规则的顺序和/或与每个规则相关的优先级。[6]中讨论了其中一些问题。
In some cases, the simple configuration shown in Figure 1 may not be sufficient as it might be necessary to apply local policies (e.g., policies specified in access control lists) in addition to the policies applied at the remote PDP. In addition, it is possible for the PDP to be co-located with the PEP at the same network node. Figure 2 shows the possible configurations.
在某些情况下，图1所示的简单配置可能不够，因为除了在远程PDP上应用的策略之外，可能还需要应用本地策略（例如，在访问控制列表中指定的策略）。此外，PDP可能与PEP位于同一网络节点处。图2显示了可能的配置。
The configurations shown in Figures 1 and 2 illustrate the flexibility in division of labor. On one hand, a centralized policy server, which could be responsible for policy decisions on behalf of multiple network nodes in an administrative domain, might be implementing policies of a wide scope, common across the AD. On the other hand, policies which depend on information and conditions local to a particular router and which are more dynamic, might be better implemented locally, at the router.
图1和图2中所示的配置说明了分工的灵活性。一方面，可以代表管理域中的多个网络节点负责策略决策的集中式策略服务器可能正在实施在整个AD中通用的大范围策略。另一方面，依赖于特定路由器本地信息和条件且更具动态性的策略可能更好地在路由器本地实现。
________________ ____________________
| | | |
| Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
________________ ____________________
| | | |
| Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
Figure 2: Two other possible configurations of policy control architecture components. The configuration on the left shows a local decision point at a network node and the configuration on the right shows PEP and PDP co-located at the same node.
图2：策略控制体系结构组件的另外两种可能的配置。左侧的配置显示网络节点的本地决策点，右侧的配置显示位于同一节点的PEP和PDP。
If it is available, the PEP will first use the LPDP to reach a local decision. This partial decision and the original policy request are next sent to the PDP which renders a final decision (possibly, overriding the LPDP). It must be noted that the PDP acts as the final authority for the decision returned to the PEP and the PEP must enforce the decision rendered by the PDP. Finally, if a shared state has been established for the request and response between the PEP and PDP, it is the responsibility of the PEP to notify the PDP that the original request is no longer in use.
如果可行，政治公众人物将首先使用LPDP达成本地决策。该部分决策和原始策略请求随后发送给PDP，PDP将给出最终决策（可能会覆盖LPDP）。必须注意的是，PDP作为返回给政治公众人物的决定的最终权威，政治公众人物必须执行PDP作出的决定。最后，如果已经为PEP和PDP之间的请求和响应建立了共享状态，则PEP有责任通知PDP原始请求不再使用。
Unless otherwise specified, we will assume the configuration shown on the left in Figure 2 in the rest of this document.
除非另有规定，否则我们将采用本文档其余部分图2中左侧所示的配置。
Under this policy control model, the PEP module at a network node must use the following steps to reach a policy decision:
在此策略控制模型下，网络节点上的PEP模块必须使用以下步骤来达成策略决策：
1. When a local event or message invokes PEP for a policy decision, the PEP creates a request that includes information from the message (or local state) that describes the admission control request. In addition, the request includes appropriate policy elements as described below.
1. 当本地事件或消息调用PEP进行策略决策时，PEP将创建一个请求，其中包含来自描述准入控制请求的消息（或本地状态）的信息。此外，请求还包括如下所述的适当策略元素。
2. The PEP may consult a local configuration database to identify a set of policy elements (called set A) that are to be evaluated locally. The local configuration specifies the types of policy elements that are evaluated locally. The PEP passes the request
2. 政治公众人物可查阅本地配置数据库，以确定将在本地评估的一组策略元素（称为集合a）。本地配置指定本地评估的策略元素的类型。政治公众人物通过了请求
with the set A to the Local Decision point (LPDP) and collects the result of the LPDP (called "partial result" and referred to as D(A) ).
将A设置为本地决策点（LPDP），并收集LPDP的结果（称为“部分结果”，称为D（A））。
3. The PEP then passes the request with ALL the policy elements and D(A) to the PDP. The PDP applies policies based on all the policy elements and the request and reaches a decision (let us call it D(Q)). It then combines its result with the partial result D(A) using a combination operation to reach a final decision.
3. 然后，PEP将包含所有策略元素和D（A）的请求传递给PDP。PDP基于所有策略元素和请求应用策略，并做出决策（我们称之为D（Q））。然后使用组合运算将其结果与部分结果D（A）组合，以达到最终决策。
4. The PDP returns the final policy decision (obtained from the combination operation) to the PEP.
4. PDP将最终策略决策（从组合操作中获得）返回给政治公众人物。
Note that in the above model, the PEP MUST contact the PDP even if no (or NULL) policy objects are received in the admission control request. This requirement helps ensure that a request cannot bypass policy control by omitting policy elements in a reservation request. However, "short circuit" processing is permitted, i.e., if the result of D(A), above, is "no", then there is no need to proceed with further policy processing at the PDP. Still, the PDP must be informed of the failure of local policy processing. The same applies to the case when policy processing is successful but admission control (at the resource management level due to unavailable capacity) fails; again the PDP has to be informed of the failure.
注意，在上述模型中，即使在准入控制请求中未收到（或空）策略对象，PEP也必须联系PDP。此要求有助于确保请求不能通过省略保留请求中的策略元素而绕过策略控制。但是，允许进行“短路”处理，即，如果上述D（A）的结果为“否”，则无需在PDP上继续进行进一步的策略处理。但是，必须将本地策略处理失败通知PDP。这同样适用于策略处理成功但准入控制（由于容量不可用而在资源管理级别）失败的情况；同样，必须将故障通知PDP。
It must also be noted that the PDP may, at any time, send an asynchronous notification to the PEP to change an earlier decision or to generate a policy error/warning message.
还必须注意，PDP可随时向政治公众人物发送异步通知，以更改早期决策或生成策略错误/警告消息。
In the case of a RSVP router, Figure 3 shows the interaction between a PEP and other int-serv components within the router. For the purpose of this discussion, we represent all the components of RSVP-related processing by a single RSVP module, but a more detailed discussion of the exact interaction and interfaces between RSVP and the PEP is provided in a separate document [3].
在RSVP路由器的情况下，图3显示了PEP和路由器内其他int serv组件之间的交互。在本讨论中，我们通过一个RSVP模块来表示RSVP相关处理的所有组件，但RSVP和PEP之间的确切交互和接口的更详细讨论在单独的文档中提供[3]。
______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
Figure 3: Relationship between PEP and other int-serv components within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler
图3:RSVP路由器中PEP和其他int serv组件之间的关系。PC—数据包分类器，PS—数据包调度器
When a RSVP message arrives at the router (or an RSVP related event requires a policy decision), the RSVP module is expected to hand off the request (corresponding to the event or message) to its PEP module. The PEP will use the PDP (and LPDP) to obtain the policy decision and communicate it back to the RSVP module.
当RSVP消息到达路由器（或RSVP相关事件需要策略决策）时，RSVP模块应将请求（对应于事件或消息）移交给其PEP模块。政治公众人物将使用PDP（和LPDP）获取政策决策，并将其传回RSVP模块。
Typically, PDP returns the final policy decision based on an admission control request and the associated policy elements. However, it should be possible for the PDP to sometimes ask the PEP (or the admission control module at the network element where PEP resides) to generate policy-related error messages. For example, in the case of RSVP, the PDP may accept a request and allow installation and forwarding of a reservation to a previous hop, but, at the same time, may wish to generate a warning/error message to a downstream node (NHOP) to warn about conditions such as "your request may have to be torn down in 10 mins, etc." Basically, an ability to create policy-related errors and/or warnings and to propagate them using the native QoS signaling protocol (such as RSVP) is needed. Such a policy error returned by the PDP must be able to also specify whether the
通常，PDP基于许可控制请求和相关策略元素返回最终策略决策。然而，PDP有时可能会要求PEP（或PEP所在网元的准入控制模块）生成与策略相关的错误消息。例如，在RSVP的情况下，PDP可以接受请求并允许安装保留并将其转发到前一跳，但同时，可能希望向下游节点（NHOP）生成警告/错误消息，以警告诸如“您的请求可能必须在10分钟内被删除等”之类的情况，需要能够创建与策略相关的错误和/或警告，并使用本机QoS信令协议（如RSVP）传播它们。PDP返回的此类策略错误还必须能够指定
reservation request should still be accepted, installed, and forwarded to allow continued normal RSVP processing. In particular, when a PDP sends back an error, it specifies that:
保留请求仍应被接受、安装和转发，以允许继续正常的RSVP处理。特别是，当PDP发回错误时，它指定：
1. the message that generated the admission control request should be processed further as usual, but an error message (or warning) be sent in the other direction and include the policy objects supplied in that error message
1. 生成许可控制请求的消息应该像往常一样进行进一步处理，但错误消息（或警告）将以另一个方向发送，并包括该错误消息中提供的策略对象
2. or, specifies that an error be returned, but the RSVP message should not be forwarded as usual.
2. 或者，指定返回错误，但不应像往常一样转发RSVP消息。
All the details of RSVP message processing and associated interactions between different elements at an RSVP router (PEP, LPDP) and PDP are included in separate documents [3,8]. In the following, a few, salient points related to the framework are listed:
RSVP路由器（PEP、LPDP）和PDP上不同元件之间的RSVP消息处理和相关交互的所有细节均包含在单独的文件中[3,8]。以下列出了与框架相关的几个要点：
* LPDP is optional and may be used for making decisions based on policy elements handled locally. The LPDP, in turn, may have to go to external entities (such as a directory server or an authentication server, etc.) for making its decisions.
* LPDP是可选的，可用于根据本地处理的策略元素做出决策。反过来，LPDP可能必须求助于外部实体（如目录服务器或身份验证服务器等）来做出决策。
* PDP is stateful and may make decisions even if no policy objects are received (e.g., make decisions based on information such as flowspecs and session object in the RSVP messages). The PDP may consult other PDPs, but discussion of inter-PDP communication and coordination is outside the scope of this document.
* PDP是有状态的，即使未收到任何策略对象，也可能做出决策（例如，根据RSVP消息中的流规范和会话对象等信息做出决策）。PDP可咨询其他PDP，但PDP间通信和协调的讨论不在本文件范围内。
* PDP sends asynchronous notifications to PEP whenever necessary to change earlier decisions, generate errors etc.
* PDP在必要时向PEP发送异步通知，以更改早期决策、生成错误等。
* PDP exports the information useful for usage monitoring and accounting purposes. An example of a useful mechanism for this purpose is a MIB or a relational database. However, this document does not specify any particular mechanism for this purpose and discussion of such mechanisms is out of the scope of this document.
* PDP导出对使用情况监控和记帐有用的信息。用于此目的的有用机制的一个示例是MIB或关系数据库。然而，本文件并未为此目的规定任何特定机制，对此类机制的讨论不在本文件范围内。
By allowing division of labor between an LPDP and a PDP, the policy control architecture allows staged deployment by enabling routers of varying degrees of sophistication, as far as policy control is concerned, to communicate with policy servers. Figure 4 depicts an example set of nodes belonging to three different administrative domains (AD) (Each AD could correspond to a different service
通过允许LPDP和PDP之间的分工，策略控制体系结构通过允许不同复杂度的路由器（就策略控制而言）与策略服务器通信，允许分阶段部署。图4描述了一组属于三个不同管理域（AD）的节点示例（每个AD可以对应于不同的服务）
provider in this case). Nodes A, B and C belong to administrative domain AD-1, advised by PDP PS-1, while D and E belong to AD-2 and AD-3, respectively. E communicates with PDP PS-2. In general, it is expected that there will be at least one PDP per administrative domain.
提供程序（在本例中为）。节点A、B和C属于管理域AD-1，由PDP PS-1建议，而D和E分别属于AD-2和AD-3。E与PDP PS-2通信。通常，每个管理域至少有一个PDP。
Policy capable network nodes could range from very unsophisticated, such as E, which have no LPDP, and thus have to rely on an external PDP for every policy processing operation, to self-sufficient, such as D, which essentially encompasses both an LPDP and a PDP locally, at the router.
具有策略能力的网络节点可以是非常简单的，例如E，它没有LPDP，因此必须依赖外部PDP进行每个策略处理操作，也可以是自给自足的，例如D，它基本上在路由器上同时包含LPDP和本地PDP。
AD-1 AD-2 AD-3
________________/\_______________ __/\___ __/\___
{ } { } { }
A B C D E
+-------+ +-----+ +-------+ +-------+ +-------+
| RSVP | | RSVP| | RSVP | | RSVP | | RSVP |
+----+ |-------| |-----| |-------| |-------| |-------|
| S1 |--| P | L |--| |----| P | L |----| P | P |----| P | +----+
+----+ | E | D | +-----+ | E | D | | E | D | | E |-| R1 |
| P | P | | P | P | | P | P | | P | +----+
+-------+ +-------+ +-------+ +-------+
^ ^ ^
| | |
| | |
| | +-------+
| | | PDP |
| +------+ | |-------|
+-------->| PDP |<------+ | |
|------| +-------+
| | PS-2
+------+
PS-1
AD-1 AD-2 AD-3
________________/\_______________ __/\___ __/\___
{ } { } { }
A B C D E
+-------+ +-----+ +-------+ +-------+ +-------+
| RSVP | | RSVP| | RSVP | | RSVP | | RSVP |
+----+ |-------| |-----| |-------| |-------| |-------|
| S1 |--| P | L |--| |----| P | L |----| P | P |----| P | +----+
+----+ | E | D | +-----+ | E | D | | E | D | | E |-| R1 |
| P | P | | P | P | | P | P | | P | +----+
+-------+ +-------+ +-------+ +-------+
^ ^ ^
| | |
| | |
| | +-------+
| | | PDP |
| +------+ | |-------|
+-------->| PDP |<------+ | |
|------| +-------+
| | PS-2
+------+
PS-1
Figure 4: Placement of Policy Elements in an internet
图4：策略元素在internet中的位置
In the following, we present examples of desired policies and scenarios requiring policy control that the policy control framework should be able to support. In some cases, possible approach(es) for achieving the desired goals are also outlined with a list of open issues to be resolved.
在下文中，我们将举例说明需要策略控制的期望策略和场景，策略控制框架应该能够支持这些策略和场景。在某些情况下，还列出了实现预期目标的可能方法以及有待解决的未决问题清单。
5.1. Admission control policies based on factors such as Time-of-Day, User Identity, or credentials.
5.1. 基于时间、用户身份或凭据等因素的准入控制策略。
Policy control must be able to express and enforce rules with temporal dependencies. For example, a group of users might be allowed to make reservations at certain levels only during off-peak hours. In addition, the policy control must also support policies that take into account identity or credentials of users requesting a particular service or resource. For example, an RSVP reservation request may be denied or accepted based on the credentials or identity supplied in the request.
策略控制必须能够表达和实施具有时间依赖性的规则。例如，可能只允许一组用户在非高峰时间进行特定级别的预订。此外，策略控件还必须支持考虑请求特定服务或资源的用户的身份或凭据的策略。例如，可以基于请求中提供的凭据或标识拒绝或接受RSVP保留请求。
Until recently, usage agreements between service providers for traffic crossing their boundaries have been quite simple. For example, two ISPs might agree to accept all traffic from each other, often without performing any accounting or billing for the "foreign" traffic carried. However, with the availability of QoS mechanisms based on Integrated and Differentiated Services, traffic differentiation and quality of service guarantees are being phased into the Internet. As ISPs start to sell their customers different grades of service and can differentiate among different sources of traffic, they will also seek mechanisms for charging each other for traffic (and reservations) transiting their networks. One additional incentive in establishing such mechanisms is the potential asymmetry in terms of the customer base that different providers will exhibit: ISPs focused on servicing corporate traffic are likely to experience much higher demand for reserved services than those that service the consumer market. Lack of sophisticated accounting schemes for inter-ISP traffic could lead to inefficient allocation of costs among different service providers.
直到最近，服务提供商之间关于跨越其边界的流量的使用协议都非常简单。例如，两个ISP可能会同意接受彼此的所有流量，通常不会对所携带的“国外”流量进行任何记帐或计费。然而，随着基于集成和区分服务的QoS机制的可用性，流量区分和服务质量保证正逐步进入互联网。随着互联网服务提供商开始向其客户销售不同等级的服务，并能够区分不同的流量来源，他们还将寻求机制，为通过其网络的流量（和预订）相互收费。建立这类机制的另一个激励因素是，不同提供商在客户基础方面可能会表现出不对称性：专注于为公司流量提供服务的ISP对预订服务的需求可能比为消费者市场提供服务的ISP要高得多。缺乏复杂的ISP间通信计费方案可能导致不同服务提供商之间的成本分配效率低下。
Bilateral agreements could fall into two broad categories; local or global. Due to the complexity of the problem, it is expected that initially only the former will be deployed. In these, providers which manage a network cloud or administrative domain contract with their closest point of contact (neighbor) to establish ground rules and arrangements for access control and accounting. These contracts are mostly local and do not rely on global agreements; consequently, a policy node maintains information about its neighboring nodes only. Referring to Figure 4, this model implies that provider AD-1 has established arrangements with AD-2, but not with AD-3, for usage of each other's network. Provider AD-2, in turn, has in place agreements with AD-3 and so on. Thus, when forwarding a reservation request to AD-2, provider AD-2 will charge AD-1 for use of all resources beyond AD-1's network. This information is obtained by recursively applying the bilateral agreements at every boundary between (neighboring) providers, until the recipient of the reservation request is reached. To implement this scheme under the policy control architecture, boundary nodes have to add an appropriate policy object to the RSVP
双边协定可分为两大类；本地或全球。由于问题的复杂性，预计最初只部署前者。其中，管理网络云或管理域的提供商与其最近的联系点（邻居）签订合同，以建立访问控制和计费的基本规则和安排。这些合同大多是本地合同，不依赖全球协议；因此，策略节点仅维护其相邻节点的信息。参考图4，该模型意味着提供商AD-1已经与AD-2（而不是AD-3）建立了使用彼此网络的安排。提供商AD-2与AD-3签订了相应的协议，以此类推。因此，当向AD-2转发预订请求时，提供商AD-2将向AD-1收取使用AD-1网络以外所有资源的费用。该信息是通过在（相邻）提供商之间的每个边界递归应用双边协议获得的，直到到达保留请求的接收者。为了在策略控制体系结构下实现此方案，边界节点必须向RSVP添加适当的策略对象
message before forwarding it to a neighboring provider's network. This policy object will contain information such as the identity of the provider that generated them and the equivalent of an account number where charges can be accumulated. Since agreements only hold among neighboring nodes, policy objects have to be rewritten as RSVP messages cross the boundaries of administrative domains or provider's networks.
将消息转发到相邻提供商的网络之前。此策略对象将包含信息，例如生成它们的提供商的身份以及可以累积费用的等效帐号。由于协议仅在相邻节点之间有效，因此必须将策略对象重写为跨越管理域或提供商网络边界的RSVP消息。
In many settings, it is useful to distinguish between reservations on the basis of some level of "importance". For example, this can be useful to avoid that the first reservation being granted the use of some resources, be able to hog those resources for some indefinite period of time. Similarly, this may be useful to allow emergency calls to go through even during periods of congestion. Such functionality can be supported by associating priorities with reservation requests, and conveying this priority information together with other policy information.
在许多情况下，根据某种程度的“重要性”区分保留是有益的。例如，这有助于避免被授予使用某些资源的第一个保留能够无限期占用这些资源。类似地，这可能有助于允许紧急呼叫通过，即使在拥堵期间也是如此。通过将优先级与预订请求关联，并将此优先级信息与其他策略信息一起传递，可以支持此类功能。
In its basic form, the priority associated with a reservation directly determines a reservation's rights to the resources it requests. For example, assuming that priorities are expressed through integers in the range 0 to 32 with 32 being the highest priority, a reservation of priority, say, 10, will always be accepted, if the amount of resources held by lower priority reservations is sufficient to satisfy its requirements. In other words, in case there are not enough free resources (bandwidth, buffers, etc.) at a node to accommodate the priority 10 request, the node will attempt to free up the necessary resources by preempting existing lower priority reservations.
在其基本形式中，与保留相关联的优先级直接决定了保留对其请求的资源的权利。例如，假设优先级通过0到32之间的整数表示，其中32是最高优先级，如果低优先级保留所持有的资源量足以满足其要求，则始终接受优先级保留，例如10。换句话说，如果节点上没有足够的可用资源（带宽、缓冲区等）来容纳优先级为10的请求，则节点将尝试通过抢占现有的低优先级保留来释放必要的资源。
There are a number of requirements associated with the support of priority and their proper operation. First, traffic control in the router needs to be aware of priorities, i.e., classify existing reservations according to their priority, so that it is capable of determining how many and which ones to preempt, when required to accommodate a higher priority reservation request. Second, it is important that preemption be made consistently at different nodes, in order to avoid transient instabilities. Third and possibly most important, merging of priorities needs to be carefully architected and its impact clearly understood as part of the associated policy definition.
有许多与支持优先级及其正确操作相关的要求。首先，路由器中的流量控制需要了解优先级，即，根据优先级对现有保留进行分类，以便在需要满足更高优先级的保留请求时，能够确定要抢占多少和哪些保留。其次，重要的是在不同的节点上一致地进行抢占，以避免瞬态不稳定性。第三，也可能是最重要的一点，需要仔细设计优先事项的合并，并将其影响清楚地理解为相关政策定义的一部分。
Of the three above requirements, merging of priority information is the more complex and deserves additional discussions. The complexity of merging priority information arises from the fact that this merging is to be performed in addition to the merging of reservation
在上述三项要求中，合并优先权信息更为复杂，值得进一步讨论。合并优先级信息的复杂性源于这样一个事实，即除了保留的合并之外，还要执行此合并
information. When reservation (FLOWSPEC) information is identical, i.e., homogeneous reservations, merging only needs to consider priority information, and the simple rule of keeping the highest priority provides an adequate answer. However, in the case of heterogeneous reservations, the *two-dimensional nature* of the (FLOWSPEC, priority) pair makes their ordering, and therefore merging, difficult. A description of the handling of different cases of RSVP priority objects is presented in [7].
信息当保留（FuffSPEC）信息是相同的，即同质保留时，合并只需要考虑优先级信息，并且保持最高优先级的简单规则提供了适当的答案。然而，在异构保留的情况下，（FLOWSPEC，priority）对的*二维性质*使得它们的排序变得困难，因此难以合并。[7]中描述了RSVP优先级对象不同情况下的处理。
A model of increasing popularity in the telephone network is that of the pre-paid calling card. This concept could also be applied to the Internet; users purchase "tokens" which can be redeemed at a later time for access to network services. When a user makes a reservation request through, say, an RSVP RESV message, the user supplies a unique identification number of the "token", embedded in a policy object. Processing of this object at policy capable routers results in decrementing the value, or number of remaining units of service, of this token.
电话网络中越来越流行的一种模式是预付费电话卡。这一概念也可以应用于互联网；用户购买“代币”，可在以后兑换以访问网络服务。当用户通过RSVP RESV消息发出预订请求时，用户提供嵌入在策略对象中的“令牌”的唯一标识号。在支持策略的路由器上处理此对象会导致此令牌的值或剩余服务单元的数量减少。
Referring to Figure 4, suppose receiver R1 in the administrative domain AD3 wants to request a reservation for a service originating in AD1. R1 generates a policy data object of type PD(prc, CID), where "prc" denotes pre-paid card and CID is the card identification number. Along with other policy objects carried in the RESV message, this object is received by node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains locally, or has remote access to, a database of pre-paid card numbers. If the amount of remaining credit in CID is sufficient, the PDP accepts the reservation and the policy object is returned to PEP_E. Two issues have to be resolved here:
参考图4，假设管理域AD3中的接收器R1想要为源自AD1的服务请求保留。R1生成PD（prc，CID）类型的策略数据对象，其中“prc”表示预付卡，CID表示卡标识号。与RESV消息中携带的其他策略对象一起，该对象由节点E接收，节点E将其转发给其PEP，PEP_E，后者依次联系PDP PS-3。PS-3在本地维护或远程访问预付卡号码数据库。如果CID中的剩余信用额足够，PDP接受保留并将保单对象返回给PEP_E。此处必须解决两个问题：
* What is the scope of these charges?
* 这些费用的范围是什么？
* When are charges (in the form of decrementing the remaining credit) first applied?
* 什么时候开始使用费用（以递减剩余信用的形式）？
The answer to the first question is related to the bilateral agreement model in place. If, on the one hand, provider AD-3 has established agreements with both AD-2 and AD-1, it could charge for the cost of the complete reservation up to sender S1. In this case PS-2 removes the PD(prc,CID) object from the outgoing RESV message.
第一个问题的答案与现有的双边协定模式有关。一方面，如果提供商AD-3与AD-2和AD-1都建立了协议，则它可以向发送方S1收取完整预订的费用。在这种情况下，PS-2从传出的RESV消息中删除PD（prc，CID）对象。
On the other hand, if AD-3 has no bilateral agreements in place, it will simply charge CID for the cost of the reservation within AD-3 and then forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other administrative domains will charge CID for their
另一方面，如果AD-3没有双边协议，它只需向CID收取AD-3内的预订费用，然后在传出的RESV消息中转发PD（prc，CID）。其他管理域中的后续PDP将收取CID的费用
respective reservations. Since multiple entities are both reading (remaining credit) and writing (decrementing credit) to the same database, some coordination and concurrency control might be needed. The issues related to location, management, coordination of credit card (or similar) databases is outside the scope of this document.
各自的保留。由于多个实体同时向同一数据库读取（剩余信用）和写入（递减信用），因此可能需要一些协调和并发控制。与信用卡（或类似）数据库的位置、管理和协调相关的问题不在本文件范围内。
Another problem in this scenario is determining when the credit is exhausted. The PDPs should contact the database periodically to submit a charge against the CID; if the remaining credit reaches zero, there must be a mechanism to detect that and to cause revocation or termination of privileges granted based on the credit.
这种情况下的另一个问题是确定信贷何时耗尽。PDP应定期联系数据库，以提交针对CID的费用；如果剩余信用达到零，则必须有一种机制来检测该情况，并导致撤销或终止基于该信用授予的特权。
Regarding the issue of when to initiate charging, ideally that should happen only after the reservation request has succeeded. In the case of local charges, that could be communicated by the router to the PDP.
关于何时开始充电的问题，理想情况下，只有在预订请求成功后才能开始充电。在本地收费的情况下，路由器可以将其传送给PDP。
The ability of senders to specify restrictions on reservations, based on receiver identity, number of receivers or reservation cost might be useful in future network applications. An example could be any application in which the sender pays for service delivered to receivers. In such a case, the sender might be willing to assume the cost of a reservation, as long as it satisfies certain criteria, for example, it originates from a receiver who belongs to an access control list (ACL) and satisfies a limit on cost. (Notice that this could allow formation of "closed" multicast groups).
发送方根据接收方身份、接收方数量或预约成本指定预约限制的能力在未来的网络应用中可能很有用。一个例子可以是发送方为交付给接收方的服务付费的任何应用程序。在这种情况下，发送方可能愿意承担保留的成本，只要它满足某些标准，例如，它来自属于访问控制列表（ACL）并满足成本限制的接收方。（请注意，这可能允许形成“封闭”多播组）。
In the policy based admission control framework such a scheme could be achieved by having the sender generate appropriate policy objects, carried in a PATH message, which install state in routers on the path to receivers. In accepting reservations, the routers would have to compare the RESV requests to the installed state.
在基于策略的接纳控制框架中，可以通过让发送方生成路径消息中携带的适当策略对象来实现这种方案，该策略对象将状态安装在到接收方的路径上的路由器中。在接受预订时，路由器必须将RESV请求与已安装状态进行比较。
A number of different solutions can be built to address this scenario; precise description of a solution is beyond the scope of this document.
可以构建许多不同的解决方案来解决此场景；对解决方案的精确描述超出了本文档的范围。
6. Interaction Between the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP)
6. 策略实施点（PEP）和策略决策点（PDP）之间的交互
In the case of an external PDP, the need for a communication protocol between the PEP and PDP arises. In order to allow for interoperability between different vendors networking elements and (external) policy servers, this protocol should be standardized.
在外部PDP的情况下，需要PEP和PDP之间的通信协议。为了实现不同供应商网络元素和（外部）策略服务器之间的互操作性，应将该协议标准化。
This section describes a set of general requirements for the communication protocol between the PEP and an external PDP.
本节描述了PEP和外部PDP之间通信协议的一组一般要求。
* Reliability: The sensitivity of policy control information necessitates reliable operation. Undetected loss of policy queries or responses may lead to inconsistent network control operation and are clearly unacceptable for actions such as billing and accounting. One option for providing reliability is the re-use of the TCP as the transport protocol.
* 可靠性：策略控制信息的敏感性要求可靠操作。未检测到的策略查询或响应丢失可能会导致网络控制操作不一致，并且对于计费和记帐等操作来说显然是不可接受的。提供可靠性的一个选择是重新使用TCP作为传输协议。
* Small delays: The timing requirements of policy decisions related to QoS signaling protocols are expected to be quite strict. The PEP to PDP protocol should add small amount of delay to the response delay experienced by queries placed by the PEP to the PDP.
* 小延迟：与QoS信令协议相关的策略决策的时间要求预计将非常严格。PEP-to-PDP协议应在PEP向PDP发出的查询所经历的响应延迟上增加少量延迟。
* Ability to carry opaque objects: The protocol should allow for delivery of self-identifying, opaque objects, of variable length, such as RSVP messages, RSVP policy objects and other objects that might be defined as new policies are introduced. The protocol should not have to be changed every time a new object has to be exchanged.
* 携带不透明对象的能力：协议应允许传递长度可变的自识别不透明对象，如RSVP消息、RSVP策略对象和其他可能定义为新策略的对象。协议不应在每次交换新对象时都进行更改。
* Support for PEP-initiated, two-way Transactions: The protocol must allow for two-way transactions (request-response exchanges) between a PEP and a PDP. In particular, PEPs must be able to initiate requests for policy decision, re-negotiation of previously made policy decision, and exchange of policy information. To some extent, this requirement is closely tied to the goal of meeting the requirements of RSVP-specific, policy-based admission control. RSVP signaling events such as arrival of RESV refresh messages, state timeout, and merging of reservations require that a PEP (such as an RSVP router) request a policy decision from PDP at any time. Similarly, PEP must be able to report monitoring information and policy state changes to PDP at any time.
* 支持PEP发起的双向事务：协议必须允许PEP和PDP之间的双向事务（请求-响应交换）。特别是，政治公众人物必须能够发起政策决策请求、重新协商先前作出的政策决策以及交换政策信息。在某种程度上，这一要求与满足特定于RSVP、基于策略的准入控制要求的目标密切相关。RSVP信令事件（如RESV刷新消息到达、状态超时和保留合并）要求PEP（如RSVP路由器）随时向PDP请求策略决策。同样，政治公众人物必须能够随时向PDP报告监控信息和政策状态变化。
* Support for asynchronous notification: This is required in order to allow both the policy server and client to notify each other in the case of an asynchronous change in state, i.e., a change that is not triggered by a signaling message. For example, the server would need to notify the client if a particular reservation has to be terminated due to expiration of a user's credentials or account balance. Likewise, the client has to inform the server of a reservation rejection which is due to admission control failure.
* 支持异步通知：这是必需的，以便允许策略服务器和客户端在状态发生异步更改时相互通知，即，不由信令消息触发的更改。例如，如果由于用户的凭据或帐户余额过期而必须终止特定的保留，服务器将需要通知客户端。同样，客户端必须通知服务器由于准入控制失败而导致的预订拒绝。
* Handling of multicast groups: The protocol should provision for handling of policy decisions related to multicast groups.
* 多播组的处理：协议应规定处理与多播组相关的策略决策。
* QoS Specification: The protocol should allow for precise specification of level of service requirements in the PEP requests forwarded to the PDP.
* QoS规范：协议应允许在转发给PDP的PEP请求中精确规范服务级别要求。
The communication tunnel between policy clients and policy servers should be secured by the use of an IPSEC [4] channel. It is advisable that this tunnel makes use of both the AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols, in order to provide confidentiality, data origin authentication, integrity and replay prevention.
策略客户端和策略服务器之间的通信隧道应通过使用IPSEC[4]通道进行保护。建议此隧道同时使用AH（身份验证头）和ESP（封装安全负载）协议，以提供机密性、数据源身份验证、完整性和重播预防。
In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authentication can be used to secure communications between network elements.
在RSVP信令机制的情况下，RSVP MD5[2]消息认证可用于保护网元之间的通信。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[2] Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[3] Herzog，S.，“政策控制的RSVP扩展”，RFC 2750，2000年1月。
[4] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[4] 阿特金森，R.，“互联网协议的安全架构”，RFC 18251995年8月。
[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[5] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[6] Rajan, R., et al., "Schema for Differentiated Services and Integrated Services in Networks", Work in Progress.
[6] Rajan，R.等人，“网络中区分服务和综合服务的模式”，正在进行中。
[7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress.
[7] Herzog，S.，“RSVP优先权政策”，正在进行中。
[8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.
[8] Herzog，S.，“警察对RSVP的使用”，RFC 2749，2000年1月。
This is a result of an ongoing discussion among many members of the RAP group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.
这是说唱乐团许多成员持续讨论的结果，包括吉姆·博伊尔、罗恩·科恩、劳拉·坎宁安、戴夫·达勒姆、谢·赫尔佐格、蒂姆·奥马利、拉朱·拉詹和阿伦·萨斯特里。
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
拉吉·雅瓦卡尔英特尔公司2111美国希尔斯伯勒第25大道东北部，邮编：97124
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Dimitrios Pendarakis IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights NY 10598
Dimitrios Pendarakis IBM T.J.Watson研究中心纽约约克敦高地704号邮政信箱10598
Phone: +1 914-784-7536
EMail: dimitris@watson.ibm.com
Phone: +1 914-784-7536
EMail: dimitris@watson.ibm.com
Roch Guerin University of Pennsylvania Dept. of Electrical Engineering 200 South 33rd Street Philadelphia, PA 19104
宾夕法尼亚大学电气工程系，费城南第三十三街200号，19104
Phone: +1 215 898-9351
EMail: guerin@ee.upenn.edu
Phone: +1 215 898-9351
EMail: guerin@ee.upenn.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。