Network Working Group K. Chan Request for Comments: 3084 J. Seligson Category: Standards Track Nortel Networks D. Durham Intel S. Gai K. McCloghrie Cisco S. Herzog IPHighway F. Reichmeyer PFN R. Yavatkar Intel A. Smith Allegro Networks March 2001 COPS Usage for Policy Provisioning (COPS-PR) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned (QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data. Chan, et al. Standards Track [Page 1] RFC 3084 COPS-PR March 2001 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Table of Contents Glossary........................................................... 3 1. Introduction.................................................... 3 1.1. Why COPS for Provisioning?.................................... 5 1.2. Interaction between the PEP and PDP........................... 5 2. Policy Information Base (PIB)................................... 6 2.1. Rules for Modifying and Extending PIBs........................ 7 2.2. Adding PRCs to, or deprecating from, a PIB.................... 7 2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC....... 8 2.3. COPS Operations Supported for a Provisioning Instance......... 8 3. Message Content................................................. 9 3.1. Request (REQ) PEP -> PDP..................................... 9 3.2. Decision (DEC) PDP -> PEP....................................10 3.3. Report State (RPT) PEP -> PDP................................12 4. COPS-PR Protocol Objects........................................13 4.1. Complete Provisioning Instance Identifier (PRID)..............14 4.2. Prefix PRID (PPRID)...........................................15 4.3. Encoded Provisioning Instance Data (EPD)......................16 4.4. Global Provisioning Error Object (GPERR)......................21 4.5. PRC Class Provisioning Error Object (CPERR)...................22 4.6. Error PRID Object (ErrorPRID).................................23 5. COPS-PR Client-Specific Data Formats............................23 5.1. Named Decision Data...........................................23 5.2. ClientSI Request Data.........................................24 5.3. Policy Provisioning Report Data...............................24 5.3.1. Success and Failure Report-Type Data Format.................24 5.3.2. Accounting Report-Type Data Format..........................25 6. Common Operation................................................26 7. Fault Tolerance.................................................28 8. Security Considerations.........................................29 9. IANA Considerations.............................................29 10. Acknowledgements...............................................30 11. References.....................................................30 12. Authors' Addresses.............................................32 13. Full Copyright Statement.......................................34 Chan, et al. Standards Track [Page 2] RFC 3084 COPS-PR March 2001 Glossary PRC Provisioning Class. A type of policy data. PRI Provisioning Instance. An instance of a PRC. PIB Policy Information Base. The database of policy information. PDP Policy Decision Point. See [RAP]. PEP Policy Enforcement Point. See [RAP]. PRID Provisioning Instance Identifier. Uniquely identifies an instance of a PRC. 1. Introduction The IETF Resource Allocation Protocol (RAP) WG has defined the COPS (Common Open Policy Service) protocol [COPS] as a scalable protocol that allows policy servers (PDPs) to communicate policy decisions to network devices (PEPs). COPS was designed to support multiple types of policy clients. COPS is a query/response protocol that supports two common models for policy control: Outsourcing and Configuration. The Outsourcing model addresses the kind of events at the PEP that require an instantaneous policy decision (authorization). In the outsourcing scenario, the PEP delegates responsibility to an external policy server (PDP) to make decisions on its behalf. For example, in COPS Usage for RSVP [COPRSVP] when a RSVP reservation message arrives, the PEP must decide whether to admit or reject the request. It can outsource this decision by sending a specific query to its PDP, waiting for its decision before admitting the outstanding reservation. The COPS Configuration model (herein described as the Provisioning model), on the other hand, makes no assumptions of such direct 1:1 correlation between PEP events and PDP decisions. The PDP may proactively provision the PEP reacting to external events (such as user input), PEP events, and any combination thereof (N:M correlation). Provisioning may be performed in bulk (e.g., entire router QoS configuration) or in portions (e.g., updating a DiffServ marking filter). Network resources are often provisioned based on relatively static SLAs (Service Level Agreements) at network boundaries. While the Outsourcing model is dynamically paced by the PEP in real-time, the Provisioning model is paced by the PDP in somewhat flexible timing over a wide range of configurable aspects of the PEP. Chan, et al. Standards Track [Page 3] RFC 3084 COPS-PR March 2001 Edge Device Policy Server +--------------+ +-----------+ +-----------+ | | | | | External | | | COPS | | | Events | | +-----+ | REQ() | +-----+ | +---+-------+ | | |----|----------|->| | | | | | PEP | | | | PDP |<-|---------+ | | |<---|----------|--| | | | +-----+ | COPS | +-----+ | | | DEC() | | +--------------+ +-----------+ Figure 1: COPS Provisioning Model In COPS-PR, policy requests describe the PEP and its configurable parameters (rather than an operational event). If a change occurs in these basic parameters, an updated request is sent. Hence, requests are issued quite infrequently. Decisions are not necessarily mapped directly to requests, and are issued mostly when the PDP responds to external events or PDP events (policy/SLA updates). This document describes the use of the COPS protocol [COPS] for support of policy provisioning. This specification is independent of the type of policy being provisioned (QoS, Security, etc.). Rather, it focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The data model assumed in this document is based on the concept of Policy Information Bases (PIBs) that define the policy data. There may be one or more PIBs for given area of policy and different areas of policy may have different sets of PIBs. In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (e.g., QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared. The examples used in this document are biased toward QoS Policy Provisioning in a Differentiated Services (DiffServ) environment. However, COPS-PR can be used for other types of provisioning policies under the same framework. Chan, et al. Standards Track [Page 4] RFC 3084 COPS-PR March 2001 1.1. Why COPS for Provisioning? COPS-PR has been designed within a framework that is optimized for efficiently provisioning policies across devices, based on the requirements defined in [RAP]. First, COPS-PR allows for efficient transport of attributes, large atomic transactions of data, and efficient and flexible error reporting. Second, as it has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS. COPS uses reliable TCP transport and, thus, uses a state sharing/synchronization mechanism and exchanges differential updates only. If either the server or client are rebooted (or restarted) the other would know about it quickly. Last, it is defined as a real-time event-driven communications mechanism, never requiring polling between the PEP and PDP. 1.2. Interaction between the PEP and PDP When a device boots, it opens a COPS connection to its Primary PDP. When the connection is established, the PEP sends information about itself to the PDP in the form of a configuration request. This information includes client specific information (e.g., hardware type, software release, configuration information). During this phase the client may also specify the maximum COPS-PR message size supported. In response, the PDP downloads all provisioned policies that are currently relevant to that device. On receiving the provisioned policies, the device maps them into its local QoS mechanisms, and installs them. If conditions change at the PDP such that the PDP detects that changes are required in the provisioned policies currently in effect, then the PDP sends the changes (installs, updates, and/or deletes) in policy to the PEP, and the PEP updates its local configuration appropriately. If, subsequently, the configuration of the device changes (board removed, board added, new software installed, etc.) in ways not covered by policies already known to the PEP, then the PEP asynchronously sends this unsolicited new information to the PDP in an updated configuration request. On receiving this new information, the PDP sends to the PEP any additional provisioned policies now needed by the PEP, or removes those policies that are no longer required. Chan, et al. Standards Track [Page 5] RFC 3084 COPS-PR March 2001 2. Policy Information Base (PIB) The data carried by COPS-PR is a set of policy data. The protocol assumes a named data structure, known as a Policy Information Base (PIB), to identify the type and purpose of unsolicited policy information that is "pushed" from the PDP to the PEP for provisioning policy or sent to the PDP from the PEP as a notification. The PIB name space is common to both the PEP and the PDP and data instances within this space are unique within the scope of a given Client-Type and Request-State per TCP connection between a PEP and PDP. Note that given a device might implement multiple COPS Client-Types, a unique instance space is to be provided for each separate Client-Type. There is no sharing of instance data across the Client-Types implemented by a PEP, even if the classes being instantiated are of the same type and share the same instance identifier. The PIB can be described as a conceptual tree namespace where the branches of the tree represent structures of data or Provisioning Classes (PRCs), while the leaves represent various instantiations of Provisioning Instances (PRIs). There may be multiple data instances (PRIs) for any given data structure (PRC). For example, if one wanted to install multiple access control filters, the PRC might represent a generic access control filter type and each PRI might represent an individual access control filter to be applied. The tree might be represented as follows: -------+-------+----------+---PRC--+--PRI | | | +--PRI | | | | | +---PRC-----PRI | | | +---PRC--+--PRI | +--PRI | +--PRI | +--PRI | +--PRI | +---PRC---PRI Figure 2: The PIB Tree Instances of the policy classes (PRIs) are each identified by a Provisioning Instance Identifier (PRID). A PRID is a name, carried in a COPS or object, which identifies a particular instance of a class. Chan, et al. Standards Track [Page 6] RFC 3084 COPS-PR March 2001 2.1. Rules for Modifying and Extending PIBs As experience is gained with policy based management, and as new requirements arise, it will be necessary to make changes to PIBs. Changes to an existing PIB can be made in several ways. (1) Additional PRCs can be added to a PIB or an existing one deprecated. (2) Attributes can be added to, or deprecated from, an existing PRC. (3) An existing PRC can be extended or augmented with a new PRC defined in another (perhaps enterprise specific) PIB. The rules for each of these extension mechanisms is described in this sub-section. All of these mechanisms for modifying a PIB allow for interoperability between PDPs and PEPs e