summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3084.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3084.txt')
-rw-r--r--doc/rfc/rfc3084.txt1907
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc3084.txt b/doc/rfc/rfc3084.txt
new file mode 100644
index 0000000..7d229de
--- /dev/null
+++ b/doc/rfc/rfc3084.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+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 <Named ClientSI> or <Named Decision Data> 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 even when one party is using a
+ new version of the PIB while the other is using an old version.
+
+ Note that the SPPI [SPPI] provides the authoritative rules for
+ updating BER encoded PIBs. It is the purpose of the following
+ section to explain how such changes affect senders and receivers of
+ COPS messages.
+
+2.2. Adding PRCs to, or deprecating from, a PIB
+
+ A published PIB can be extended with new PRCs by simply revising the
+ document and adding additional PRCs. These additional PRCs are
+ easily identified with new PRIDs under the module's PRID Prefix.
+
+ In the event that a PEP implementing the new PIB is being configured
+ by a PDP implementing the old PIB, the PEP will simply not receive
+ any instances of the new PRC. In the event that the PEP is
+ implementing the old PIB and the PDP the new one, the PEP may receive
+ PRIs for the new PRC. Under such conditions, the PEP MUST return an
+ error to the PDP, and rollback to its previous (good) state.
+
+ Similarly, existing PRCs can be deprecated from a PIB. In this case,
+ the PEP ignores any PRIs sent to it by a PDP implementing the old
+ (non-deprecated) version of the PIB. A PDP implementing the new
+ version of the PIB simply does not send any instances of the
+ deprecated class.
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 7]
+
+RFC 3084 COPS-PR March 2001
+
+
+2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC
+
+ A PIB can be modified to deprecate existing attributes of a PRC or
+ add new ones.
+
+ When deprecating the attributes of a PRC, it must be remembered that,
+ with the COPS-PR protocol, the attributes of the PRC are identified
+ by their order in the sequence rather than an explicit label (or
+ attribute OID). Consequently, an ASN.1 value MUST be sent even for
+ deprecated attributes so that a PDP and PEP implementing different
+ versions of the PIB are inter-operable.
+
+ For a deprecated attribute, if the PDP is using a BER encoded PIB,
+ the PDP MUST send either an ASN.1 value of the correct type, or it
+ may send an ASN.1 NULL value. A PEP that receives an ASN.1 NULL for
+ an attribute that is not deprecated SHOULD substitute a default
+ value. If it has no default value to substitute it MUST return an
+ error to the PDP.
+
+ When adding new attributes to a PIB, these new attributes must be
+ added in sequence after the existing ones. A PEP that receives a PRI
+ with more attributes than it is expecting MUST ignore the additional
+ attributes and send a warning back to the PDP.
+
+ A PEP that receives a PRI with fewer attributes than it is expecting
+ SHOULD assume default values for the missing attributes. It MAY send
+ a warning back to the PDP. If the missing attributes are required
+ and there is no suitable default, the PEP MUST send an error back to
+ the PDP. In all cases the missing attributes are assumed to
+ correspond to the last attributes of the PRC.
+
+2.3. COPS Operations Supported for a Provisioning Instance
+
+ A Provisioning Instance (PRI) typically contains a value for each
+ attribute defined for the PRC of which it is an instance and is
+ identified uniquely, within the scope of a given COPS Client-Type and
+ Request-State on a PEP, by a Provisioning Instance Identifier (PRID).
+ The following COPS operations are supported on a PRI:
+
+ o Install - This operation creates or updates a named instance of a
+ PRC. It includes two parameters: a PRID object to name the PRI and
+ an Encoded Provisioning Instance Data (EPD) object with the
+ new/updated values. The PRID value MUST uniquely identify a single
+ PRI (i.e., PRID prefix or PRC values are illegal). Updates to an
+ existing PRI are achieved by simply reinstalling the same PRID with
+ the updated EPD data.
+
+
+
+
+
+Chan, et al. Standards Track [Page 8]
+
+RFC 3084 COPS-PR March 2001
+
+
+ o Remove - This operation is used to delete an instance of a PRC. It
+ includes one parameter, a PRID object, which names either the
+ individual PRI to be deleted or a PRID prefix naming one or more
+ complete classes of PRIs. Prefix-based deletion supports efficient
+ bulk policy removal. The removal of an unknown/non-existent PRID
+ SHOULD result in a warning to the PDP (no error).
+
+3. Message Content
+
+ The COPS protocol provides for different COPS clients to define their
+ own "named", i.e., client-specific, information for various messages.
+ This section describes the messages exchanged between a COPS server
+ (PDP) and COPS Policy Provisioning clients (PEP) that carry client-
+ specific data objects. All the COPS messages used by COPS-PR conform
+ to the message specifications defined in the COPS base protocol
+ [COPS].
+
+ Note: The use of the '*' character represented throughout this
+ document is consistent with the ABNF [RFC2234] and means 0 or more of
+ the following entities.
+
+3.1. Request (REQ) PEP -> PDP
+
+ The REQ message is sent by policy provisioning clients to issue a
+ 'configuration request' to the PDP as specified in the COPS Context
+ Object. The Client Handle associated with the REQ message originated
+ by a provisioning client MUST be unique for that client. The Client
+ Handle is used to identify a specific request state. Thus, one
+ client can potentially open several configuration request states,
+ each uniquely identified by its handle. Different request states are
+ used to isolate similarly named configuration information into non-
+ overlapping contexts (or logically isolated namespaces). Thus, an
+ instance of named information is unique relative to a particular
+ client-type and is unique relative to a particular request state for
+ that client-type, even if the information was similarly identified in
+ other request states (i.e., uses the same PRID). Thus, the Client
+ Handle is also part of the instance identification of the
+ communicated configuration information.
+
+ The configuration request message serves as a request from the PEP to
+ the PDP for provisioning policy data that the PDP may have for the
+ PEP, such as access control lists, etc. This includes policy the PDP
+ may have at the time the REQ is received as well as any future policy
+ data or updates to this data.
+
+ The configuration request message should include provisioning client
+ information to provide the PDP with client-specific configuration or
+ capability information about the PEP. The information provided by
+
+
+
+Chan, et al. Standards Track [Page 9]
+
+RFC 3084 COPS-PR March 2001
+
+
+ the PEP should include client resources (e.g., queuing capabilities)
+ and default policy configuration (e.g., default role combinations)
+ information as well as incarnation data on existing policy. This
+ information typically does not include all the information previously
+ installed by a PDP but rather should include checksums or shortened
+ references to previously installed information for synchronization
+ purposes. This information from the client assists the server in
+ deciding what types of policy the PEP can install and enforce. The
+ format of the information encapsulated in one or more of the COPS
+ Named ClientSI objects is described in section 5. Note that the
+ configuration request message(s) is generated and sent to the PDP in
+ response to the receipt of a Synchronize State Request (SSQ) message
+ from the PDP. Likewise, an updated configuration request message
+ (using the same Client Handle value as the original request now being
+ updated) may also be generated by the PEP and sent to the PDP at any
+ time due to local modifications of the PEP's internal state. In this
+ way, the PDP will be synchronized with the PEP's relevant internal
+ state at all times.
+
+ The policy information supplied by the PDP MUST be consistent with
+ the named decision data defined for the policy provisioning client.
+ The PDP responds to the configuration request with a DEC message
+ containing any available provisioning policy data.
+
+ The REQ message has the following format:
+
+ <Request> ::= <Common Header>
+ <Client Handle>
+ <Context = config request>
+ *(<Named ClientSI>)
+ [<Integrity>]
+
+ Note that the COPS objects IN-Int, OUT-Int and LPDPDecisions are not
+ included in a COPS-PR Request.
+
+3.2. Decision (DEC) PDP -> PEP
+
+ The DEC message is sent from the PDP to a policy provisioning client
+ in response to the REQ message received from the PEP. The Client
+ Handle MUST be the same Handle that was received in the corresponding
+ REQ message.
+
+ The DEC message is sent as an immediate response to a configuration
+ request with the solicited message flag set in the COPS message
+ header. Subsequent DEC messages may also be sent at any time after
+ the original DEC message to supply the PEP with additional/updated
+ policy information without the solicited message flag set in the COPS
+ message header (as they are unsolicited decisions).
+
+
+
+Chan, et al. Standards Track [Page 10]
+
+RFC 3084 COPS-PR March 2001
+
+
+ Each DEC message may contain multiple decisions. This means a single
+ message can install some policies and delete others. In general a
+ single COPS-PR DEC message MUST contain any required remove decisions
+ first, followed by any required install decisions. This is used to
+ solve a precedence issue, not a timing issue: the remove decision
+ deletes what it specifies, except those items that are installed in
+ the same message.
+
+ The DEC message can also be used by the PDP to command the PEP to
+ open a new Request State or Delete an existing Request-State as
+ identified by the Client-Handle. To accomplish this, COPS-PR defines
+ a new flag for the COPS Decision Flags object. The flag 0x02 is to
+ be used by COPS-PR client-types and is hereafter referred to as the
+ "Request-State" flag. An Install decision (Decision Flags: Command-
+ Code=Install) with the Request-State flag set in the COPS Decision
+ Flags object will cause the PEP to issue a new Request with a new
+ Client Handle or else specify the appropriate error in a COPS Report
+ message. A Remove decision (Decision Flags: Command-Code=Remove)
+ with the Request-State flag set in the COPS Decision Flags object
+ will cause the PEP to send a COPS Delete Request State (DRQ) message
+ for the Request-State identified by the Client Handle in the DEC
+ message. Whenever the Request-State flag is set in the COPS Decision
+ Flags object in the DEC message, no COPS Named Decision Data object
+ can be included in the corresponding decision (as it serves no
+ purpose for this decision flag). Note that only one decision with
+ the Request-State flag can be present per DEC message, and, if
+ present, this MUST be the only decision in that message. As
+ described below, the PEP MUST respond to each and every DEC with a
+ corresponding solicited RPT.
+
+ A COPS-PR DEC message MUST be treated as a single "transaction",
+ i.e., either all the decisions in a DEC message succeed or they all
+ fail. If they fail, the PEP will rollback to its previous good
+ state, which is the last successful DEC transaction, if any. This
+ allows the PDP to delete some policies only if other policies can be
+ installed in their place. The DEC message has the following format:
+
+ <Decision Message> ::= <Common Header>
+ <Client Handle>
+ *(<Decision>) | <Error>
+ [<Integrity>]
+
+ <Decision> ::= <Context>
+ <Decision: Flags>
+ [<Named Decision Data: Provisioning >]
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 11]
+
+RFC 3084 COPS-PR March 2001
+
+
+ Note that the Named Decision Data (Provisioning) object is included
+ in a COPS-PR Decision when it is an Install or Remove decision with
+ no Decision Flags set. Other types of COPS decision data objects
+ (e.g., Stateless, Replacement) are not supported by COPS-PR client-
+ types. The Named Decision Data object MUST NOT be included in the
+ decision if the Decision Flags object Command-Code is NULL (meaning
+ there is no configuration information to install at this time) or if
+ the Request-State flag is set in the Decision Flags object.
+
+ For each decision in the DEC message, the PEP performs the operation
+ specified in the Command-Code and Flags field in the Decision Flags
+ object on the Named Decision Data. For the policy provisioning
+ clients, the format for this data is defined in the context of the
+ Policy Information Base (see section 5). In response to a DEC
+ message, the policy provisioning client MUST send a RPT message, with
+ the solicited message flag set, back to the PDP to inform the PDP of
+ the action taken.
+
+3.3. Report State (RPT) PEP -> PDP
+
+ The RPT message is sent from the policy provisioning clients to the
+ PDP to report accounting information associated with the provisioned
+ policy, or to notify the PDP of changes in the PEP (Report-Type = '
+ Accounting') related to the provisioning client.
+
+ RPT is also used as a mechanism to inform the PDP about the action
+ taken at the PEP in response to a DEC message. For example, in
+ response to an 'Install' decision, the PEP informs the PDP if the
+ policy data is installed (Report-Type = 'Success') or not (Report-
+ Type = 'Failure'). Reports that are in response to a DEC message
+ MUST set the solicited message flag in their COPS message header.
+ Each solicited RTP MUST be sent for its corresponding DEC in the
+ order the DEC messages were received. In case of a solicited
+ failure, the PEP is expected to rollback to its previous (good) state
+ as if the erroneous DEC transaction did not occur. The PEP MUST
+ always respond to a DEC with a solicited RPT even in response to a
+ NULL DEC, in which case the Report-Type will be 'Success'.
+
+ Reports can also be unsolicited and all unsolicited Reports MUST NOT
+ set the solicited message flag in their COPS message header. Examples
+ of unsolicited reports include 'Accounting' Report-Types, which were
+ not triggered by a specific DEC messages, or 'Failure' Report-Types,
+ which indicate a failure in a previously successfully installed
+ configuration (note that, in the case of such unsolicited failures,
+ the PEP cannot rollback to a previous "good" state as it becomes
+ ambiguous under these asynchronous conditions what the correct state
+ might be).
+
+
+
+
+Chan, et al. Standards Track [Page 12]
+
+RFC 3084 COPS-PR March 2001
+
+
+ The RPT message may contain provisioning client information such as
+ accounting parameters or errors/warnings related to a decision. The
+ data format for this information is defined in the context of the
+ policy information base (see section 5). The RPT message has the
+ following format:
+
+ <Report State> ::= <Common Header>
+ <Client Handle>
+ <Report Type>
+ *(<Named ClientSI>)
+ [<Integrity>]
+
+4. COPS-PR Protocol Objects
+
+ The COPS Policy Provisioning clients encapsulate several new objects
+ within the existing COPS Named Client-specific information object and
+ Named Decision Data object. This section defines the format of these
+ new objects.
+
+ COPS-PR classifies policy data according to "bindings", where a
+ binding consists of a Provisioning Instance Identifier and the
+ Provisioning Instance data, encoded within the context of the
+ provisioning policy information base (see section 5).
+
+ The format for these new objects is as follows:
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num | S-Type |
+ +---------------+---------------+---------------+---------------+
+ | 32 bit unsigned integer |
+ +---------------+---------------+---------------+---------------+
+
+ S-Num and S-Type are similar to the C-Num and C-Type used in the base
+ COPS objects. The difference is that S-Num and S-Type are used only
+ for COPS-PR clients and are encapsulated within the existing COPS
+ Named ClientSI or Named Decision Data objects. The S-Num identifies
+ the general purpose of the object, and the S-Type describes the
+ specific encoding used for the object. All the object descriptions
+ and examples in this document use the Basic Encoding Rules as the
+ encoding type (S-Type = 1). Additional encodings can be defined for
+ the remaining S-Types in the future (for example, an additional S-
+ Type could be used to carry XML string based encodings [XML] as an
+ EPD of PRI instance data, where URNs identify PRCs [URN] and
+ XPointers would be used for PRIDs).
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 13]
+
+RFC 3084 COPS-PR March 2001
+
+
+ Length is a two-octet value that describes the number of octets
+ (including the header) that compose the object. If the length in
+ octets does not fall on a 32-bit word boundary, padding MUST be added
+ to the end of the object so that it is aligned to the next 32-bit
+ boundary before the object can be sent on the wire. On the receiving
+ side, a subsequent object boundary can be found by simply rounding up
+ the stated object length of the current object to the next 32-bit
+ boundary. The values for the padding MUST be all zeros.
+
+4.1. Complete Provisioning Instance Identifier (PRID)
+
+ S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable.
+
+ This object is used to carry the identifier, or PRID, of a
+ Provisioning Instance. The identifier is encoded following the rules
+ that have been defined for encoding SNMP Object Identifier (OID)
+ values. Specifically, PRID values are encoded using the
+ Type/Length/Value (TLV) format and initial sub-identifier packing
+ that is specified by the binary encoding rules [BER] used for Object
+ Identifiers in an SNMP PDU.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num = PRID | S-Type = BER |
+ +---------------+---------------+---------------+---------------+
+ | Instance Identifier |
+ +---------------+---------------+---------------+---------------+
+
+ For example, a (fictitious) PRID equal to 1.3.6.1.2.2.8.1 would be
+ encoded as follows (values in hex):
+
+ 06 07 2B 06 01 02 02 08 01
+
+ The entire PRID object would be encoded as follows:
+
+ 00 0D - Length
+ 01 - S-Num
+ 01 - S-Type (Complete PRID)
+ 06 07 2B 06 01 02 02 08 01 - Encoded PRID
+ 00 00 00 - Padding
+
+ NOTE: When encoding an xxxTable's xxxEntry Object-Type as defined by
+ the SMI [V2SMI] and SPPI [SPPI], the OID will contain all the sub-
+ identifiers up to and including the xxxEntry OID but not the columnar
+ identifiers for the attributes within the xxxEntry's SEQUENCE. The
+ last (suffix) identifier is the INDEX of an instance of an entire
+
+
+
+
+
+Chan, et al. Standards Track [Page 14]
+
+RFC 3084 COPS-PR March 2001
+
+
+ xxxEntry including its SEQUENCE of attributes encoded in the EPD
+ (defined below). This constitutes an instance (PRI) of a class (PRC)
+ in terms of the SMI.
+
+ A PRID for a scalar (non-columnar) value's OID is encoded directly as
+ the PRC where the instance identifier suffix is always zero as there
+ will be only one instance of a scalar value. The EPD will then be
+ used to convey the scalar value.
+
+4.2. Prefix PRID (PPRID)
+
+ Certain operations, such as decision removal, can be optimized by
+ specifying a PRID prefix with the intent that the requested operation
+ be applied to all PRIs matching the prefix (for example, all
+ instances of the same PRC). PRID prefix objects MUST only be used in
+ the COPS protocol <Remove Decision> operation where it may be more
+ optimal to perform bulk decision removal using class prefixes instead
+ of a sequence of individual <Remove Decision> operations. Other COPS
+ operations, e.g., <Install Decision> operations always require
+ individual PRID specification.
+
+ S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num = PPRID | S-Type = BER |
+ +---------------+---------------+---------------+---------------+
+ ... ...
+ | Prefix PRID |
+ ... ...
+ +---------------+---------------+---------------+---------------+
+
+ Continuing with the previous example, a prefix PRID that is equal to
+ 1.3.6.1.2.2 would be encoded as follows (values in hex):
+
+ 06 05 2B 06 01 02 02
+
+ The entire PPRID object would be encoded as follows:
+
+ 00 0B - Length
+ 02 - S-Num = Prefix PRID
+ 01 - S-Type = BER
+ 06 05 2B 06 01 02 02 - Encoded Prefix PRID
+ 00 - Padding
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 15]
+
+RFC 3084 COPS-PR March 2001
+
+
+4.3. Encoded Provisioning Instance Data (EPD)
+
+ S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable.
+
+ This object is used to carry the encoded value of a Provisioning
+ Instance. The PRI value, which contains all of the individual values
+ of the attributes that comprise the class (which corresponds to the
+ SMI's xxxEntry Object-Type defining the SEQUENCE of attributes
+ comprising a table [V2SMI][SPPI]), is encoded as a series of TLV
+ sub-components. Each sub-component represents the value of a single
+ attribute and is encoded following the BER. Note that the ordering
+ of non-scalar (multiple) attributes within the EPD is dictated by
+ their respective columnar OID suffix when defined in [V2SMI]. Thus,
+ the attribute with the smallest columnar OID suffix will appear first
+ and the attribute with the highest number columnar OID suffix will be
+ last.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num = EPD | S-Type = BER |
+ +---------------+---------------+---------------+---------------+
+ | BER Encoded PRI Value |
+ +---------------+---------------+---------------+---------------+
+
+ As an example, a fictional definition of an IPv4 packet filter class
+ could be described using the SMI as follows:
+
+ ipv4FilterIpFilter OBJECT IDENTIFIER ::= { someExampleOID 1 }
+
+ -- The IP Filter Table
+
+ ipv4FilterTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Ipv4FilterEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Filter definitions. A packet has to match all fields in
+ a filter. Wildcards may be specified for those fields
+ that are not relevant."
+
+ ::= { ipv4FilterIpFilter 1 }
+
+ ipv4FilterEntry OBJECT-TYPE
+ SYNTAX Ipv4FilterEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An instance of the filter class."
+
+
+
+Chan, et al. Standards Track [Page 16]
+
+RFC 3084 COPS-PR March 2001
+
+
+
+ INDEX { ipv4FilterIndex }
+
+ ::= { ipv4FilterTable 1 }
+
+ Ipv4FilterEntry ::= SEQUENCE {
+ ipv4FilterIndex Unsigned32,
+ ipv4FilterDstAddr IpAddress,
+ ipv4FilterDstAddrMask IpAddress,
+ ipv4FilterSrcAddr IpAddress,
+ ipv4FilterSrcAddrMask IpAddress,
+ ipv4FilterDscp Integer32,
+ ipv4FilterProtocol Integer32,
+ ipv4FilterDstL4PortMin Integer32,
+ ipv4FilterDstL4PortMax Integer32,
+ ipv4FilterSrcL4PortMin Integer32,
+ ipv4FilterSrcL4PortMax Integer32,
+ ipv4FilterPermit TruthValue
+ }
+
+ ipv4FilterIndex OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "An integer index to uniquely identify this filter among all
+ the filters."
+
+ ::= { ipv4FilterEntry 1 }
+
+ ipv4FilterDstAddr OBJECT-TYPE
+
+ SYNTAX IpAddress
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The IP address to match against the packet's destination IP
+ address."
+
+ ::= { ipv4FilterEntry 2 }
+
+ ipv4FilterDstAddrMask OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A mask for the matching of the destination IP address.
+ A zero bit in the mask means that the corresponding bit in
+
+
+
+Chan, et al. Standards Track [Page 17]
+
+RFC 3084 COPS-PR March 2001
+
+
+ the address always matches."
+
+ ::= { ipv4FilterEntry 3 }
+
+ ipv4FilterSrcAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The IP address to match against the packet's source IP
+ address."
+
+ ::= { ipv4FilterEntry 4 }
+
+ ipv4FilterSrcAddrMask OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A mask for the matching of the source IP address."
+
+ ::= { ipv4FilterEntry 5 }
+
+ ipv4FilterDscp OBJECT-TYPE
+ SYNTAX Integer32 (-1 | 0..63)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value that the DSCP in the packet can have and
+ match. A value of -1 indicates that a specific
+ DSCP value has not been defined and thus all DSCP values
+ are considered a match."
+
+ ::= { ipv4FilterEntry 6 }
+
+ ipv4FilterProtocol OBJECT-TYPE
+ SYNTAX Integer32 (0..255)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The IP protocol to match against the packet's protocol.
+ A value of zero means match all."
+
+ ::= { ipv4FilterEntry 7 }
+
+ ipv4FilterDstL4PortMin OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-write
+
+
+
+Chan, et al. Standards Track [Page 18]
+
+RFC 3084 COPS-PR March 2001
+
+
+ STATUS current
+ DESCRIPTION
+ "The minimum value that the packet's layer 4 destination
+ port number can have and match this filter."
+
+ ::= { ipv4FilterEntry 8 }
+
+ ipv4FilterDstL4PortMax OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The maximum value that the packet's layer 4 destination
+ port number can have and match this filter."
+
+ ::= { ipv4FilterEntry 9 }
+
+ ipv4FilterSrcL4PortMin OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The minimum value that the packet's layer 4 source port
+ number can have and match this filter."
+
+ ::= { ipv4FilterEntry 10 }
+
+ ipv4FilterSrcL4PortMax OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The maximum value that the packet's layer 4 source port
+ number can have and match this filter."
+
+ ::= { ipv4FilterEntry 11 }
+
+ ipv4FilterPermit OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "If false, the evaluation is negated. That is, a
+ valid match will be evaluated as not a match and vice
+ versa."
+
+ ::= { ipv4FilterEntry 12 }
+
+
+
+
+Chan, et al. Standards Track [Page 19]
+
+RFC 3084 COPS-PR March 2001
+
+
+ A fictional instance of the filter class defined above might then
+ be encoded as follows:
+
+ 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8
+ 40 04 C0 39 01 05 :ipv4FilterDstAddr/IpAddress/Value = 192.57.1.5
+ 40 04 FF FF FF FF :ipv4FilterDstMask/IpAddress/Value=255.255.255.255
+ 40 04 00 00 00 00 :ipv4FilterSrcAddr/IpAddress/Value = 0.0.0.0
+ 40 04 00 00 00 00 :ipv4FilterSrcMask/IpAddress/Value = 0.0.0.0
+ 02 01 FF :ipv4FilterDscp/Integer32/Value = -1 (not used)
+ 02 01 06 :ipv4FilterProtocol/Integer32/Value = 6 (TCP)
+ 05 00 :ipv4FilterDstL4PortMin/NULL/not supported
+ 05 00 :ipv4FilterDstL4PortMax/NULL/not supported
+ 05 00 :ipv4FilterSrcL4PortMin/NULL/not supported
+ 05 00 :ipv4FilterSrcL4PortMax/NULL/not supported
+ 02 01 01 :ipv4FilterPermit/TruthValue/Value = 1 (true)
+
+ The entire EPD object for this instance would then be encoded as
+ follows:
+
+ 00 30 - Length
+ 03 - S-Num = EPD
+ 01 - S-Type = BER
+ 02 01 08 - ipv4FilterIndex
+ 40 04 C0 39 01 05 - ipv4FilterDstAddr
+ 40 04 FF FF FF FF - ipv4FilterDstMask
+ 40 04 00 00 00 00 - ipv4FilterSrcAddr
+ 40 04 00 00 00 00 - ipv4FilterSrcMask
+ 02 01 FF - ipv4FilterDscp
+ 02 01 06 - ipv4FilterProtocol
+ 05 00 - ipv4FilterDstL4PortMin
+ 05 00 - ipv4FilterDstL4PortMax
+ 05 00 - ipv4FilterSrcL4PortMin
+ 05 00 - ipv4FilterSrcL4PortMax
+ 02 01 01 - ipv4FilterPermit
+
+ Note that attributes not supported within a class are still returned
+ in the EPD for a PRI. By convention, a NULL value is returned for
+ attributes that are not supported. In the previous example, source
+ and destination port number attributes are not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 20]
+
+RFC 3084 COPS-PR March 2001
+
+
+4.4. Global Provisioning Error Object (GPERR)
+
+ S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num = GPERR | S-Type = BER |
+ +---------------+---------------+---------------+---------------+
+ | Error-Code | Error Sub-code |
+ +---------------+---------------+---------------+---------------+
+
+ The global provisioning error object has the same format as the Error
+ object in COPS [COPS], except with C-Num and C-Type replaced by the
+ S-Num and S-Type values shown. The global provision error object is
+ used to communicate general errors that do not map to a specific PRC.
+
+ The following global error codes are defined:
+
+ availMemLow(1)
+ availMemExhausted(2)
+ unknownASN.1Tag(3) - The erroneous tag type SHOULD be
+ specified in the Error Sub-Code field.
+ maxMsgSizeExceeded(4) - COPS message (transaction) was too big.
+ unknownError(5)
+ maxRequestStatesOpen(6)- No more Request-States can be created
+ by the PEP (in response to a DEC
+ message attempting to open a new
+ Request-State).
+ invalidASN.1Length(7) - An ASN.1 object length was incorrect.
+ invalidObjectPad(8) - Object was not properly padded.
+ unknownPIBData(9) - Some of the data supplied by the PDP is
+ unknown/unsupported by the PEP (but
+ otherwise formatted correctly). PRC
+ specific error codes are to be used to
+ provide more information.
+ unknownCOPSPRObject(10)- Sub-code (octet 2) contains unknown
+ object's S-Num and (octet 3) contains
+ unknown object's S-Type.
+ malformedDecision(11) - Decision could not be parsed.
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 21]
+
+RFC 3084 COPS-PR March 2001
+
+
+4.5. PRC Class Provisioning Error Object (CPERR)
+
+ S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | S-Num = CPERR | S-Type = BER |
+ +---------------+---------------+---------------+---------------+
+ | Error-Code | Error Sub-code |
+ +---------------+---------------+---------------+---------------+
+
+ The class-specific provisioning error object has the same format as
+ the Error object in COPS [COPS], except with C-Num and C-Type
+ replaced by the S-Num and S-Type values shown. The class-specific
+ error object is used to communicate errors relating to specific PRCs
+ and MUST have an associated Error PRID Object.
+
+ The following Generic Class-Specific errors are defined:
+
+ priSpaceExhausted(1) - no more instances may currently be
+ installed in the given class.
+ priInstanceInvalid(2) - the specified class instance is
+ currently invalid prohibiting
+ installation or removal.
+ attrValueInvalid(3) - the specified value for identified
+ attribute is illegal.
+ attrValueSupLimited(4) - the specified value for the identified
+ attribute is legal but not currently
+ supported by the device.
+ attrEnumSupLimited(5) - the specified enumeration for the
+ identified attribute is legal but not
+ currently supported by the device.
+ attrMaxLengthExceeded(6) - the overall length of the specified
+ value for the identified attribute
+ exceeds device limitations.
+ attrReferenceUnknown(7) - the class instance specified by the
+ policy instance identifier does not
+ exist.
+ priNotifyOnly(8) - the class is currently only supported
+ for use by request or report messages
+ prohibiting decision installation.
+ unknownPrc(9) - attempt to install a PRI of a class not
+ supported by PEP.
+ tooFewAttrs(10) - recvd PRI has fewer attributes than
+ required.
+ invalidAttrType(11) - recvd PRI has an attribute of the wrong
+ type.
+
+
+
+
+Chan, et al. Standards Track [Page 22]
+
+RFC 3084 COPS-PR March 2001
+
+
+ deletedInRef(12) - deleted PRI is still referenced by
+ other (non) deleted PRIs
+ priSpecificError(13) - the Error Sub-code field contains the
+ PRC specific error code
+
+ Where appropriate (errors 3, 4, 5, 6, 7 above) the error sub-code
+ SHOULD identify the OID sub-identifier of the attribute
+ associated with the error.
+
+4.6. Error PRID Object (ErrorPRID)
+
+ S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable.
+
+ This object is used to carry the identifier, or PRID, of a
+ Provisioning Instance that caused an installation error or could not
+ be installed or removed. The identifier is encoded and formatted
+ exactly as in the PRID object as described in section 4.1.
+
+5. COPS-PR Client-Specific Data Formats
+
+ This section describes the format of the named client specific
+ information for the COPS policy provisioning client. ClientSI
+ formats are defined for Decision message's Named Decision Data
+ object, the Request message's Named ClientSI object and Report
+ message's Named ClientSI object. The actual content of the data is
+ defined by the policy information base for a specific provisioning
+ client-type (see below).
+
+5.1. Named Decision Data
+
+ The formats encapsulated by the Named Decision Data object for the
+ policy provisioning client-types depends on the type of decision.
+ Install and Remove are the two types of decisions that dictate the
+ internal format of the COPS Named Decision Data object and require
+ its presence. Install and Remove refer to the 'Install' and 'Remove'
+ Command-Code, respectively, specified in the COPS Decision Flags
+ Object when no Decision Flags are set. The data, in general, is
+ composed of one or more bindings. Each binding associates a PRID
+ object and a EPD object. The PRID object is always present in both
+ install and remove decisions, the EPD object MUST be present in the
+ case of an install decision and MUST NOT be present in the case of a
+ remove decision.
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 23]
+
+RFC 3084 COPS-PR March 2001
+
+
+ The format for this data is encapsulated within the COPS Named
+ Decision Data object as follows:
+ <Named Decision Data> ::= <<Install Decision> |
+ <Remove Decision>>
+
+ <Install Decision> ::= *(<PRID> <EPD>)
+
+ <Remove Decision> ::= *(<PRID>|<PPRID>)
+
+ Note that PRID objects in a Remove Decision may specify PRID prefix
+ values. Explicit and implicit deletion of installed policies is
+ supported by a client. Install Decision data MUST be explicit (i.e.,
+ PRID prefix values are illegal and MUST be rejected by a client).
+
+5.2. ClientSI Request Data
+
+ The provisioning client request data will use same bindings as
+ described above. The format for this data is encapsulated in the
+ COPS Named ClientSI object as follows:
+
+ <Named ClientSI: Request> ::= <*(<PRID> <EPD>)>
+
+5.3. Policy Provisioning Report Data
+
+ The COPS Named ClientSI object is used in the RPT message in
+ conjunction with the accompanying COPS Report Type object to
+ encapsulate COPS-PR report information from the PEP to the PDP.
+ Report types can be 'Success' or 'Failure', indicating to the PDP
+ that a particular set of provisioning policies has been either
+ successfully or unsuccessfully installed/removed on the PEP, or
+ 'Accounting'.
+
+5.3.1. Success and Failure Report-Type Data Format
+
+ Report-types can be 'Success' or 'Failure' indicating to the PDP that
+ a particular set of provisioning policies has been either
+ successfully or unsuccessfully installed/removed on the PEP. The
+ provisioning report data consists of the bindings described above and
+ global and specific error/warning information. Specific errors are
+ associated with a particular instance. For a 'Success' Report-Type,
+ a specific error is an indication of a warning related to a specific
+ policy that has been installed, but that is not fully implemented
+ (e.g., its parameters have been approximated) as identified by the
+ ErrorPRID object. For a 'Failure' Report-Type, this is an error code
+ specific to a binding, again, identified by the ErrorPRID object.
+ Specific errors may also include regular <PRID><EPD> bindings to
+
+
+
+
+
+Chan, et al. Standards Track [Page 24]
+
+RFC 3084 COPS-PR March 2001
+
+
+ carry additional information in a generic manner so that the specific
+ errors/warnings may be more verbosely described and associated with
+ the erroneous ErrorPRID object.
+
+ Global errors are not tied to a specific ErrorPRID. In a 'Success'
+ RPT message, a global error is an indication of a general warning at
+ the PEP level (e.g., memory low). In a 'Failure' RPT message, this
+ is an indication of a general error at the PEP level (e.g., memory
+ exhausted).
+
+ In the case of a 'Failure' Report-Type the PEP MUST report at least
+ the first error and SHOULD report as many errors as possible. In
+ this case the PEP MUST roll-back its configuration to the last good
+ transaction before the erroneous Decision message was received.
+
+ The format for this data is encapsulated in the COPS Named ClientSI
+ object as follows:
+
+ <Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
+
+ <report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
+
+5.3.2. Accounting Report-Type Data Format
+
+ Additionally, reports can be used to carry accounting information
+ when specifying the 'Accounting' Report-Type. This accounting report
+ message will typically carry statistical or event information related
+ to the installed configuration for use at the PDP. This information
+ is encoded as one or more <PRID><EPD> bindings that generally
+ describe the accounting information being reported from the PEP to
+ the PDP.
+
+ The format for this data is encapsulated in the COPS Named ClientSI
+ object as follows:
+
+ <Named ClientSI: Report> ::= <*(<PRID><EPD>)>
+
+ NOTE: RFC 2748 defines an optional Accounting-Timer (AcctTimer)
+ object for use in the COPS Client-Accept message. Periodic
+ accounting reports for COPS-PR clients are also obligated to be paced
+ by this timer. Periodic accounting reports SHOULD NOT be generated
+ by the PEP more frequently than the period specified by the COPS
+ AcctTimer. Thus, the period between new accounting reports SHOULD be
+ greater-than or equal-to the period specified (if specified) in the
+ AcctTimer. If no AcctTimer object is specified by the PDP, then
+ there are no constraints imposed on the PEP's accounting interval.
+
+
+
+
+
+Chan, et al. Standards Track [Page 25]
+
+RFC 3084 COPS-PR March 2001
+
+
+6. Common Operation
+
+ This section describes, in general, typical exchanges between a PDP
+ and Policy Provisioning COPS client.
+
+ First, a TCP connection is established between the client and server
+ and the PEP sends a Client-Open message specifying a COPS- PR
+ client-type (use of the ClientSI object within the Client-Open
+ message is currently undefined for COPS-PR clients). If the PDP
+ supports the specified provisioning client-type, the PDP responds
+ with a Client-Accept (CAT) message. If the client-type is not
+ supported, a Client-Close (CC) message is returned by the PDP to the
+ PEP, possibly identifying an alternate server that is known to
+ support the policy for the provisioning client-type specified.
+
+ After receiving the CAT message, the PEP can send requests to the
+ server. The REQ from a policy provisioning client contains a COPS
+ 'Configuration Request' context object and, optionally, any relevant
+ named client specific information from the PEP. The information
+ provided by the PEP should include available client resources (e.g.,
+ supported classes/attributes) and default policy configuration
+ information as well as incarnation data on existing policy. The
+ configuration request message from a provisioning client serves two
+ purposes. First, it is a request to the PDP for any provisioning
+ configuration data which the PDP may currently have that is suitable
+ for the PEP, such as access control filters, etc., given the
+ information the PEP specified in its REQ. Also, the configuration
+ request effectively opens a channel that will allow the PDP to
+ asynchronously send policy data to the PEP, as the PDP decides is
+ necessary, as long as the PEP keeps its request state open (i.e., as
+ long as the PEP does not send a DRQ with the request state's Client
+ Handle). This asynchronous data may be new policy data or an update
+ to policy data sent previously. Any relevant changes to the PEP's
+ internal state can be communicated to the PDP by the PEP sending an
+ updated REQ message. The PEP is free to send such updated REQ
+ messages at any time after a CAT message to communicate changes in
+ its local state.
+
+ After the PEP sends a REQ, if the PDP has Policy Provisioning policy
+ configuration information for the client, that information is
+ returned to the client in a DEC message containing the Policy
+ Provisioning client policy data within the COPS Named Decision Data
+ object and specifying an "Install" Command-Code in the Decision Flags
+ object. If no filters are defined, the DEC message will simply
+ specify that there are no filters using the "NULL Decision" Command-
+ Code in the Decision Flags object. As the PEP MUST specify a Client
+ Handle in the request message, the PDP MUST process the Client Handle
+ and copy it in the corresponding decision message. A DEC message
+
+
+
+Chan, et al. Standards Track [Page 26]
+
+RFC 3084 COPS-PR March 2001
+
+
+ MUST be issued by the PDP with the Solicited Message Flag set in the
+ COPS message header, regardless of whether or not the PDP has any
+ configuration information for the PEP at the time of the request.
+ This is to prevent the PEP from timing out the REQ and deleting the
+ Client Handle.
+
+ The PDP can then add new policy data or update/delete existing
+ configurations by sending subsequent unsolicited DEC message(s) to
+ the PEP, with the same Client Handle. Previous configurations
+ installed on the PEP are updated by the PDP by simply re-installing
+ the same instance of configuration information again (effectively
+ overwriting the old data). The PEP is responsible for removing the
+ Client handle when it is no longer needed, for example when an
+ interface goes down, and informing the PDP that the Client Handle is
+ to be deleted via the COPS DRQ message.
+
+ For Policy Provisioning purposes, access state, and access requests
+ to the policy server can be initiated by other sources besides the
+ PEP. Examples of other sources include attached users requesting
+ network services via a web interface into a central management
+ application, or H.323 servers requesting resources on behalf of a
+ user for a video conferencing application. When such a request is
+ accepted, the edge device affected by the decision (the point where
+ the flow is to enter the network) needs to be informed of the
+ decision. Since the PEP in the edge device did not initiate the
+ request, the specifics of the request, e.g., flowspec, packet filter,
+ and PHB to apply, needs to be communicated to the PEP by the PDP.
+ This information is sent to the PEP using the Decision message
+ containing Policy Provisioning Named Decision Data objects in the
+ COPS Decision object as specified. Any updates to the state
+ information, for example in the case of a policy change or call tear
+ down, is communicated to the PEP by subsequent unsolicited DEC
+ messages containing the same Client Handle and the updated Policy
+ Provisioning request state. Updates can specify that policy data is
+ to be installed, deleted, or updated (re-installed).
+
+ PDPs may also command the PEP to open a new Request State or delete
+ an exiting one by issuing a decision with the Decision Flags object's
+ Request-State flag set. If the command-code is "install", then the
+ PDP is commanding the PEP to create a new Request State, and
+ therefore issue a new REQ message specifying a new Client Handle or
+ otherwise issue a "Failure" RPT specifying the appropriate error
+ condition. Each request state represents an independent and
+ logically non-overlapping namespace, identified by the Client Handle,
+ on which transactions (a.k.a., configuration installations,
+ deletions, updates) may be performed. Other existing Request States
+ will be unaffected by the new request state as they are independent
+ (thus, no instances of configuration data within one Request State
+
+
+
+Chan, et al. Standards Track [Page 27]
+
+RFC 3084 COPS-PR March 2001
+
+
+ can be affected by DECs for another Request State as identified by
+ the Client Handle). If the command-code is "Remove", then the PDP is
+ commanding the PEP to delete the existing Request-State specified by
+ the DEC message's Client Handle, thereby causing the PEP to issue a
+ DRQ message for this Handle.
+
+ The PEP MUST acknowledge a DEC message and specify what action was
+ taken by sending a RPT message with a "Success" or "Failure" Report-
+ Type object with the Solicited Message Flag set in the COPS message
+ header. This serves as an indication to the PDP that the requestor
+ (e.g., H.323 server) can be notified whether the request has been
+ accepted by the network or not. If the PEP needs to reject the DEC
+ operation for any reason, a RPT message is sent with a Report-Type
+ with the value "Failure" and optionally a Client Specific Information
+ object specifying the policy data that was rejected. Under such
+ solicited report failure conditions, the PEP MUST always rollback to
+ its previously installed (good) state as if the DEC never occurred.
+ The PDP is then free to modify its decision and try again.
+
+ The PEP can report to the PDP the current status of any installed
+ request state when appropriate. This information is sent in a
+ Report-State (RPT) message with the "Accounting" flag set. The
+ request state that is being reported is identified via the associated
+ Client Handle in the report message.
+
+ Finally, Client-Close (CC) messages are used to cancel the
+ corresponding Client-Open message. The CC message informs the other
+ side that the client-type specified is no longer supported.
+
+7. Fault Tolerance
+
+ When communication is lost between PEP and PDP, the PEP attempts to
+ re-establish the TCP connection with the PDP it was last connected
+ to. If that server cannot be reached, then the PEP attempts to
+ connect to a secondary PDP, assumed to be manually configured (or
+ otherwise known) at the PEP.
+
+ When a connection is finally re-established with a PDP, the PEP sends
+ a OPN message with a <LastPDPAddr> object providing the address of
+ the most recent PDP for which it is still caching decisions. If no
+ decisions are being cached on the PEP (due to reboot or TTL timeout
+ of state) the PEP MUST NOT include the last PDP address information.
+ Based on this object, the PDP may request the PEP to re-synch its
+ current state information (by issuing a COPS SSQ message). If, after
+ re-connecting, the PDP does not request synchronization, the client
+ can assume the server recognizes it and the current state at the PEP
+ is correct, so a REQ message need not be sent. Still, any state
+ changes which occurred at the PEP that the PEP could not communicate
+
+
+
+Chan, et al. Standards Track [Page 28]
+
+RFC 3084 COPS-PR March 2001
+
+
+ to the PDP due to communication having been lost, MUST be reported to
+ the PDP via the PEP sending an updated REQ message. Whenever re-
+ synchronization is requested, the PEP MUST reissue any REQ messages
+ for all known Request-States and the PDP MUST issue DEC messages to
+ delete either individual PRIDs or prefixes as appropriate to ensure a
+ consistent known state at the PEP.
+
+ While the PEP is disconnected from the PDP, the active request-state
+ at the PEP is to be used for policy decisions. If the PEP cannot
+ re-connect in some pre-specified period of time, all installed
+ Request-States are to be deleted and their associated Handles
+ removed. The same holds true for the PDP; upon detecting a failed
+ TCP connection, the time-out timer is started for all Request-States
+ associated with the PEP and these states are removed after the
+ administratively specified period without a connection.
+
+8. Security Considerations
+
+ The COPS protocol [COPS], from which this document derives, describes
+ the mandatory security mechanisms that MUST be supported by all COPS
+ implementations. These mandatory security mechanisms are used by the
+ COPS protocol to transfer opaque information from PEP to PDP and vice
+ versa in an authenticated and secure manner. COPS for Policy
+ Provisioning simply defines a structure for this opaque information
+ already carried by the COPS protocol. As such, the security
+ mechanisms described for the COPS protocol will also be deployed in a
+ COPS-PR environment, thereby ensuring the integrity of the COPS-PR
+ information being communicated. Furthermore, in order to fully
+ describe a practical set of structured data for use with COPS-PR, a
+ PIB (Policy Information Base) will likely be written in a separate
+ document. The authors of such a PIB document need to be aware of the
+ security concerns associated with the specific data they have
+ defined. These concerns MUST be fully specified in the security
+ considerations section of the PIB document along with the required
+ security mechanisms for transporting this newly defined data.
+
+9. IANA Considerations
+
+ COPS for Policy Provisioning follows the same IANA considerations for
+ COPS objects as the base COPS protocol [COPS]. COPS-PR has defined
+ one additional Decision Flag value of 0x02, extending the COPS base
+ protocol only by this one value. No new COPS Client- Types are
+ defined by this document.
+
+ COPS-PR also introduces a new object number space with each object
+ being identified by its S-Num and S-Type value pair. These objects
+ are encapsulated within the existing COPS Named ClientSI or Named
+ Decision Data objects [COPS] and, therefore, do not conflict with any
+
+
+
+Chan, et al. Standards Track [Page 29]
+
+RFC 3084 COPS-PR March 2001
+
+
+ assigned numbers in the COPS base protocol. Additional S-Num and S-
+ Type pairs can only be added to COPS-PR using the IETF Consensus rule
+ as defined in [IANA]. These two numbers are always to be treated as
+ a pair, with one or more S-Types defined per each S-Num. This
+ document defines the S-Num values 1-6 and the S-Type 1 for each of
+ these six values (note that the S-Type value of 2 is reserved for
+ transport of XML encoded data). A listing of all the S-Num and S-
+ Type pairs defined by this document can be found in sections 4.1-4.6.
+
+ Likewise, additional Global Provisioning error codes and Class-
+ Specific Provisioning error codes defined for COPS-PR can only be
+ added with IETF Consensus. This document defines the Global
+ Provisioning error code values 1-11 in section 4.4 for the Global
+ Provisioning Error Object (GPERR). This document also defines the
+ Class-Specific error code values 1-13 in section 4.5 for the Class
+ Provisioning Error Object (CPERR).
+
+10. Acknowledgements
+
+ This document has been developed with active involvement from a
+ number of sources. The authors would specifically like to
+ acknowledge the valuable input given by Michael Fine, Scott Hahn, and
+ Carol Bell.
+
+11. References
+
+ [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
+ A. Sastry, "The COPS (Common Open Policy Service)
+ Protocol", RFC 2748, January 2000.
+
+ [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
+ for Policy Based Admission Control", RFC 2753, January
+ 2000.
+
+ [COPRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
+ A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
+
+ [ASN1] Information processing systems - Open Systems
+ Interconnection, "Specification of Abstract Syntax Notation
+ One (ASN.1)", International Organization for
+ Standardization, International Standard 8824, December
+ 1987.
+
+ [BER] Information processing systems - Open Systems
+ Interconnection - Specification of Basic Encoding Rules for
+ Abstract Syntax Notation One (ASN.1), International
+ Organization for Standardization. International Standard
+ 8825, (December, 1987).
+
+
+
+Chan, et al. Standards Track [Page 30]
+
+RFC 3084 COPS-PR March 2001
+
+
+ [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
+ W. Weiss, "An Architecture for Differentiated Service," RFC
+ 2475, December 1998.
+
+ [SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
+ Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
+ Policy Provisioning Information SPPI", Work in Progress.
+
+ [V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Structure of Management
+ Information Version 2(SMIv2)", STD 58, RFC 2578, April
+ 1999.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [IANA] Alvestrand, H. and T. Narten, "Guidelines for writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [URN] Moats, R., "Uniform Resource Names (URN) Syntax", RFC 2141,
+ May 1997.
+
+ [XML] World Wide Web Consortium (W3C), "Extensible Markup
+ Language (XML)," W3C Recommendation, February, 1998,
+ http://www.w3.org/TR/1998/REC-xml-19980210.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 31]
+
+RFC 3084 COPS-PR March 2001
+
+
+12. Authors' Addresses
+
+ Kwok Ho Chan
+ Nortel Networks, Inc.
+ 600 Technology Park Drive
+ Billerica, MA 01821
+
+ Phone: (978) 288-8175
+ EMail: khchan@nortelnetworks.com
+
+
+ David Durham
+ Intel
+ 2111 NE 25th Avenue
+ Hillsboro, OR 97124
+
+ Phone: (503) 264-6232
+ Email: david.durham@intel.com
+
+ Silvano Gai
+ Cisco Systems, Inc.
+ 170 Tasman Dr.
+ San Jose, CA 95134-1706
+
+ Phone: (408) 527-2690
+ EMail: sgai@cisco.com
+
+
+ Shai Herzog
+ IPHighway Inc.
+ 69 Milk Street, Suite 304
+ Westborough, MA 01581
+
+ Phone: (914) 654-4810
+ EMail: Herzog@iphighway.com
+
+
+ Keith McCloghrie
+
+ Phone: (408) 526-5260
+ EMail: kzm@cisco.com
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 32]
+
+RFC 3084 COPS-PR March 2001
+
+
+ Francis Reichmeyer
+ PFN, Inc.
+ University Park at MIT
+ 26 Landsdowne Street
+ Cambridge, MA 02139
+
+ Phone: (617) 494 9980
+ EMail: franr@pfn.com
+
+
+ John Seligson
+ Nortel Networks, Inc.
+ 4401 Great America Parkway
+ Santa Clara, CA 95054
+
+ Phone: (408) 495-2992
+ Email: jseligso@nortelnetworks.com
+
+
+ Raj Yavatkar
+
+ Phone: (503) 264-9077
+ EMail: raj.yavatkar@intel.com
+
+
+ Andrew Smith
+ Allegro Networks
+ 6399 San Ignacio Ave.
+ San Jose, CA 95119, USA
+
+ EMail: andrew@allegronetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 33]
+
+RFC 3084 COPS-PR March 2001
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chan, et al. Standards Track [Page 34]
+