draft-ietf-rap-pr-02.txt   draft-ietf-rap-pr-03.txt 
Internet Draft Kwok Ho Chan Internet Draft Kwok Ho Chan
Expiration: September 2000 Nortel Networks Expiration: January 2001 Nortel Networks
File: draft-ietf-rap-pr-02.txt David Durham File: draft-ietf-rap-pr-03.txt David Durham
Intel Intel
Silvano Gai Silvano Gai
Cisco Cisco
Shai Herzog Shai Herzog
IPHighway IPHighway
Keith McCloghrie Keith McCloghrie
Cisco Cisco
Francis Reichmeyer Francis Reichmeyer
IPHighway IPHighway
John Seligson John Seligson
Nortel Networks Nortel Networks
Andrew Smith Andrew Smith
Extreme Networks No Affiliation
Raj Yavatkar Raj Yavatkar
Intel Intel
COPS Usage for Policy Provisioning COPS Usage for Policy Provisioning
March 10, 2000 July 14, 2000
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 9 skipping to change at page 2, line 9
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This draft describes the use of the COPS protocol [COPS] for This draft describes the use of the COPS protocol [COPS] for
support of policy provisioning. This specification is independent support of policy provisioning. This specification is independent
of type of policy being provisioned (QoS, Security, etc.) but of the type of policy being provisioned (QoS, Security, etc.) but
focuses on the mechanisms and conventions used to communicate focuses on the mechanisms and conventions used to communicate
provisioned information between PDPs and PEPs. The protocol provisioned information between PDPs and PEPs. The protocol
extensions described in this document do not make any assumptions extensions described in this document do not make any assumptions
about the policy data being communicated, but describe the message about the policy data being communicated, but describe the message
formats and objects that carry policy data. formats and objects that carry policy data.
Table of Contents Table of Contents
Abstract..............................................................3 Abstract..............................................................2
Table of Contents.....................................................4 Table of Contents.....................................................3
Glossary..............................................................5 Glossary..............................................................4
1. Introduction.....................................................5 1. Introduction.....................................................4
1.1. Why not SNMP?..................................................6 1.1. Why not SNMP?..................................................5
1.2. Interaction between the PEP and PDP............................7 1.2. Interaction between the PEP and PDP............................6
2. Policy Information Base (PIB)....................................8 2. Policy Information Base (PIB)....................................7
2.1. Rules for Modifying and Extending PIBs.........................9 2.1. Rules for Modifying and Extending PIBs.........................8
2.2. Adding PRCs to, or deprecating from, a PIB.....................9 2.2. Adding PRCs to, or deprecating from, a PIB.....................8
2.2.1. Adding or Deprecating Attributes of a PRC......................9 2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC..........8
2.2.2. Augmenting a PRC with another PRC.............................10 2.3. COPS Operations Supported for a Policy Rule Instance...........9
2.3. COPS Operations Supported for a Policy Rule Instance..........10 3. Message Content.................................................10
3. Message Content.................................................11 3.1. Request (REQ) PEP -> PDP.....................................10
3.1. Request (REQ) PEP -> PDP.....................................11 3.2. Decision (DEC) PDP -> PEP....................................11
3.2. Decision (DEC) PDP -> PEP....................................12 3.3. Report State (RPT) PEP -> PDP................................13
3.3. Report State (RPT) PEP -> PDP................................14 4. COPS-PR Protocol Objects........................................13
4. COPS-PR Protocol Objects........................................14 4.1. Complete Policy Rule Identifier (PRID)........................14
4.1. Complete Policy Rule Identifier (PRID)........................15 4.2. PRID Prefix(PPRID)............................................15
4.2. Prefix PRID (PPRID)...........................................16
4.3. Encoded Policy Instance Data (EPD)............................16 4.3. Encoded Policy Instance Data (EPD)............................16
4.4. Provisioning Error Object (PERR)..............................18 4.4. Global Provisioning Error Object (GPERR)......................17
4.5. Error PRID Object (ErrorPRID).................................19 4.5. PRC Class Provisioning Error Object (CPERR)...................18
4.6. Error PRID Object (ErrorPRID).................................19
5. COPS-PR Client-Specific Data Formats............................19 5. COPS-PR Client-Specific Data Formats............................19
5.1. Named Decision Data...........................................20 5.1. Named Decision Data...........................................20
5.2. ClientSI Request Data.........................................20 5.2. ClientSI Request Data.........................................20
5.3. Policy Provisioning Report Data...............................20 5.3. Policy Provisioning Report Data...............................20
5.3.1. Success and Failure Report-Type Data Format...................21 5.3.1. Success and Failure Report-Type Data Format...................21
5.3.2. Accounting Report-Type Data Format............................21 5.3.2. Accounting Report-Type Data Format............................21
6. Common Operations...............................................22 6. Common Operation................................................22
7. Fault Tolerance.................................................24 7. Fault Tolerance.................................................24
7.1. Security Considerations.......................................25 7.1. Security Considerations.......................................25
8. Acknowledgements................................................25 8. Acknowledgements................................................25
9. References......................................................26 9. References......................................................26
10. Author Information..............................................27 10. Author Information..............................................27
11. Full Copyright Notice...........................................28 11. Full Copyright Notice...........................................28
Glossary Glossary
PRC Policy Rule Class. A type of policy data. PRC Policy Rule Class. A type of policy data.
skipping to change at page 5, line 21 skipping to change at page 4, line 21
PDP Policy Decision Point. See [RAP-FRAMEWORK]. PDP Policy Decision Point. See [RAP-FRAMEWORK].
PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. PEP Policy Enforcement Point. See [RAP-FRAMEWORK].
PRID Policy Rule Instance Identifier. Uniquely identifies an PRID Policy Rule Instance Identifier. Uniquely identifies an
instance of a PRC. instance of a PRC.
1. Introduction 1. Introduction
The IETF Resource Allocation Protocol (RAP) WG has defined the The IETF Resource Allocation Protocol (RAP) WG has defined the
COPS (Common Open Policy Service) protocol [COPS] as a scalable COPS (Common Open Policy Service) protocol [COPS] as a scalable
protocol that allows policy servers (PDPs) to communicate policy protocol that allows policy servers (PDPs) to communicate policy
decisions to network devices (PEP). COPS was designed to support decisions to network devices (PEPs). COPS was designed to support
multiple types of policy clients. multiple types of policy clients.
COPS is a query/response protocol that supports two common models COPS is a query/response protocol that supports two common models
for policy control: Outsourcing and Configuration. for policy control: Outsourcing and Configuration.
The Outsourcing model addresses the kind of events at the PEP that The Outsourcing model addresses the kind of events at the PEP that
require instantaneous policy decision (authorization). The PEP, require instantaneous policy decision (authorization). In the
being aware that it must perform a policy decision. However, being outsourcing scenario, the PEP delegates responsibility to an
unable to carry the task itself, the PEP delegates responsibility external policy server (PDP) to make decision on its behalf. For
to an external policy server (PDP). For example, in [COPS-RSVP] example, in [COPS-RSVP] when a RSVP reservation message arrives,
when a reservation message arrives, the PEP is aware that it must the PEP must decide whether to admit or reject the request. It can
decide whether to admit or reject the request. It sends a specific outsource this decision by sending a specific query to its PDP,
query to the PDP, and in most case, waits for a decision before waiting for its decision before admitting the outstanding
admitting the outstanding reservation. reservation.
The COPS Configuration model (herein described as the Provisioning The COPS Configuration model (herein described as the Provisioning
model), on the other hand, makes no assumptions of such direct 1:1 model), on the other hand, makes no assumptions of such direct 1:1
correlation between PEP events and PDP decisions. The PDP may correlation between PEP events and PDP decisions. The PDP may
proactively provision the PEP reacting to external events (such as proactively provision the PEP reacting to external events (such as
user input), PEP events, and any combination thereof (N:M user input), PEP events, and any combination thereof (N:M
correlation). Provisioning may be performed in bulk (e.g., entire correlation). Provisioning may be performed in bulk (e.g., entire
router QoS configuration) or in portions (e.g., updating a router QoS configuration) or in portions (e.g., updating a
DiffServ marking filter). DiffServ marking filter).
skipping to change at page 6, line 39 skipping to change at page 5, line 39
of the type of policy being provisioned (QoS, Security, etc.) but, of the type of policy being provisioned (QoS, Security, etc.) but,
rather, focuses on the mechanisms and conventions used to rather, focuses on the mechanisms and conventions used to
communicate provisioned information between PDPs and PEPs. The communicate provisioned information between PDPs and PEPs. The
model described in this document is based on the concept of Policy model described in this document is based on the concept of Policy
Information Bases (PIBs) that define the policy data. There may be Information Bases (PIBs) that define the policy data. There may be
one or more PIBs for given area of policy and different areas of one or more PIBs for given area of policy and different areas of
policy will have different sets of PIBs. policy will have different sets of PIBs.
In order to support a model that includes multiple PDPs In order to support a model that includes multiple PDPs
controlling non-overlapping areas of policy on a single PEP, the 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 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 of policy being managed. A single client-type for a given area of
policy (eg. QoS) will be used for all PIBs that exist in that policy (eg. QoS) will be used for all PIBs that exist in that
area. The client should treat all the COPS-PR client-types it area. The client should treat all the COPS-PR client-types it
supports as non-overlapping and independent namespaces where supports as non-overlapping and independent namespaces where
instances MUST NOT be shared. instances MUST NOT be shared.
The Examples used in this document are biased toward QoS Policy The Examples used in this document are biased toward QoS Policy
Provisioning in a Differentiated Services (DiffServ) environment. Provisioning in a Differentiated Services (DiffServ) environment.
However, COPS-PR can be used for other types of provisioning However, COPS-PR can be used for other types of provisioning
policies under the same framework. policies under the same framework.
skipping to change at page 7, line 51 skipping to change at page 6, line 51
This information includes client specific information (e.g., This information includes client specific information (e.g.,
hardware type, software release, configuration information). hardware type, software release, configuration information).
During this phase the client may also specify the maximum COPS-PR During this phase the client may also specify the maximum COPS-PR
message size supported. message size supported.
In response, the PDP downloads all provisioned policies that are In response, the PDP downloads all provisioned policies that are
currently relevant to that device. On receiving the provisioned currently relevant to that device. On receiving the provisioned
policies, the device maps them into its local QoS mechanisms, and policies, the device maps them into its local QoS mechanisms, and
installs them. If conditions change at the PDP such that the PDP installs them. If conditions change at the PDP such that the PDP
detects that changes are required in the provisioned policies detects that changes are required in the provisioned policies
currently in effect, then the PDP sends the changes (installs currently in effect, then the PDP sends the changes (installs,
and/or deletes) in policy to the PEP, and the PEP updates its updates, and/or deletes) in policy to the PEP, and the PEP updates
local QoS mechanisms appropriately. its local configuration appropriately.
If, subsequently, the configuration of the device changes (board If, subsequently, the configuration of the device changes (board
removed, board added, new software installed, etc.) in ways not removed, board added, new software installed, etc.) in ways not
covered by policies already known to the PEP, then the PEP sends covered by policies already known to the PEP, then the PEP
this unsolicited new information to the PDP. On receiving this new asynchronously sends this unsolicited new information to the PDP.
information, the PDP sends to the PEP any additional provisioned On receiving this new information, the PDP sends to the PEP any
policies now needed by the PEP. additional provisioned policies now needed by the PEP.
2. Policy Information Base (PIB) 2. Policy Information Base (PIB)
The data carried by COPS-PR is a set of policy rules. The protocol The data carried by COPS-PR is a set of policy rules. The protocol
uses a named data structure, known as a Policy Information Base uses a named data structure, known as a Policy Information Base
(PIB), to identify the type and purpose of unsolicited policy (PIB), to identify the type and purpose of unsolicited policy
information that is "pushed" from the PDP to the PEP for information that is "pushed" from the PDP to the PEP for
provisioning policy. The PIB name space is common to both the PEP provisioning policy. The PIB name space is common to both the PEP
and the PDP and data instances within this space are unique within and the PDP and data instances within this space are unique within
the scope of a given PDP/PEP/Client-Type communication channel. the scope of a given Client-Type and Request-State per TCP
Note that a given device might implement multiple PEPs or multiple connection between a PEP and PDP. Note that given a device might
Client-Types and the name space is then only relevant within each implement multiple COPS Client-Types, a unique namespace is to be
separate channel (there is no sharing of instance data across the provided for each separate Client-Type (there is no sharing of
PDP/PEP/Client-Types). instance data across the Client-Types implemented by a PEP even if
the types of classes being instantiated are the same).
The PIB can be described as a conceptual tree data structure where The PIB can be described as a conceptual tree namespace where the
the branches of the tree represent types of rules or Policy Rule branches of the tree represent types of rules or Policy Rule
Classes (PRCs), while the leaves represent the contents of Policy Classes (PRCs), while the leaves represent various instantiations
Rule Instances (PRIs). There may be multiple instances of rules of Policy Rule Instances (PRIs). There may be multiple instances
(PRIs) for any given rule type (PRC). For example, if one wanted of rules (PRIs) for any given rule type (PRC). For example, if one
to install multiple access control filters, the PRC might wanted to install multiple access control filters, the PRC might
represent a generic access control filter type and each PRI might represent a generic access control filter type and each PRI might
represent an individual access control filter to be applied. The represent an individual access control filter to be applied. The
tree might be represented as follows: tree might be represented as follows:
-------+-------+----------+---PRC--+--PRI -------+-------+----------+---PRC--+--PRI
| | | +--PRI | | | +--PRI
| | | | | |
| | +---PRC-----PRI | | +---PRC-----PRI
| | | |
| +---PRC--+--PRI | +---PRC--+--PRI
skipping to change at page 9, line 19 skipping to change at page 8, line 19
As experience is gained with policy management, and as new As experience is gained with policy management, and as new
requirements arise, it will be necessary to make changes to PIBs. requirements arise, it will be necessary to make changes to PIBs.
Changes to an existing PIB can be made in several ways. Changes to an existing PIB can be made in several ways.
(1) Additional PRCs can be added to a PIB or an existing one (1) Additional PRCs can be added to a PIB or an existing one
deprecated. deprecated.
(2) Attributes can be added to, or deprecated from an existing (2) Attributes can be added to, or deprecated from an existing
PRC. PRC.
(3) An existing PRC can be extended by "augmenting" it with a new (3) An existing PRC can be extended or augmented with a new PRC
PRC defined in another (perhaps enterprise specific) PIB. defined in another (perhaps enterprise specific) PIB.
The rules for each of these extension mechanisms is described in The rules for each of these extension mechanisms is described in
this sub-section. All of these mechanisms for modifying a PIB this sub-section. All of these mechanisms for modifying a PIB
allow for interoperability between PDPs and PEPs even when one allow for interoperability between PDPs and PEPs even when one
party is using a new version of the PIB while the other is using party is using a new version of the PIB while the other is using
an old version. an old version.
2.2. Adding PRCs to, or deprecating from, a PIB 2.2. Adding PRCs to, or deprecating from, a PIB
A published PIB can be extended with new PRCs by simply revising A published PIB can be extended with new PRCs by simply revising
the document and adding additional PRCs. These additional PRCs the document and adding additional PRCs. These additional PRCs
are easily identified with new PRIDs under the module's PRID are easily identified with new PRIDs under the module's PRID
Prefix. Prefix.
In the event that a PEP implementing the new PIB is being In the event that a PEP implementing the new PIB is being
configured by a PDP implementing the old PIB, the PEP will simply 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 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 PEP is implementing the old PIB and the PDP the new one, the PEP
may receive PRIs for the new PRC. The PEP SHOULD ignore these may receive PRIs for the new PRC. Under such conditions, the PEP
unsupported PRI. However, it MAY return and error to the PDP. In MUST return an error to the PDP, and rollback to its previous
the latter case, the PDP must restructure its policy decisions to (good) state.
exclude the unsupported PRCs.
Similarly, existing PRCs can be deprecated from a PIB. In this Similarly, existing PRCs can be deprecated from a PIB. In this
case, the PEP ignores any PRIs sent it by a PDP implementing the case, the PEP ignores any PRIs sent it by a PDP implementing the
old (non- deprecated) version of the PIB. 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 new version of the PIB simply does not send any instances of the
deprecated class. deprecated class.
2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC 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 A PIB can be modified to deprecate existing attributes of a PRC or
add new ones. add new ones.
When deprecating the attributes of a PRC, it must be remembered When deprecating the attributes of a PRC, it must be remembered
that, with the COPS-PR protocol, the attributes of the PRC are that, with the COPS-PR protocol, the attributes of the PRC are
identified by their order in the sequence rather than an explicit identified by their order in the sequence rather than an explicit
label (or attribute OID). Consequently, an ASN.1 value MUST be label (or attribute OID). Consequently, an ASN.1 value MUST be
sent even for deprecated attributes so that a PDP and PEP sent even for deprecated attributes so that a PDP and PEP
implementing different versions of the PIB are inter-operable. implementing different versions of the PIB are inter-operable.
skipping to change at page 10, line 24 skipping to change at page 9, line 22
For a deprecated attribute, if the PDP is using a BER encoded PIB, 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 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 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 for an attribute that is not deprecated SHOULD substitute a
default value. If it has no default value to substitute it MUST default value. If it has no default value to substitute it MUST
return an error to the PDP. return an error to the PDP.
When adding new attributes to a PIB, these new attributes must be When adding new attributes to a PIB, these new attributes must be
added in sequence after the existing ones. A PEP that receives a added in sequence after the existing ones. A PEP that receives a
PRI with more attributes than it is expecting MUST ignore the PRI with more attributes than it is expecting MUST ignore the
additional attributes. It MAY send a warning back to the PDP. additional attributes and send a warning back to the PDP.
A PEP that receives a PRI with fewer attributes than it is A PEP that receives a PRI with fewer attributes than it is
expecting SHOULD assume default values for the missing attributes. expecting SHOULD assume default values for the missing attributes.
It MAY send a warning back to the PDP. If 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 are required and there is no suitable default, the PEP MUST send
and error back to the PDP. In all cases the missing attributes and error back to the PDP. In all cases the missing attributes
are assumed to correspond to the last attributes of the PRC. are assumed to correspond to the last attributes of the PRC.
2.3. COPS Operations Supported for a Policy Rule Instance 2.3. COPS Operations Supported for a Policy Rule Instance
A Policy Rule Instance (PRI) typically contains a value for each A Policy Rule Instance (PRI) typically contains a value for each
attribute defined for the PRC of which it an instance and is attribute defined for the PRC of which it is an instance and is
identified uniquely, within the scope of a given COPS Client-Type on identified uniquely, within the scope of a given COPS Client-Type
a PEP, by a Policy Rule Identifier (PRID). The following COPS and Request-State on a PEP, by a Policy Rule Identifier (PRID). The
operations are supported on a PRI: following COPS operations are supported on a PRI:
o Install - This operation creates or updates a named instance of o Install - This operation creates or updates a named instance of
a PRC. It includes two parameters: a PRID object to name the PRI a PRC. It includes two parameters: a PRID object to name the PRI
and an Encoded Policy Instance Data (EPD) object with the and an Encoded Policy Instance Data (EPD) object with the
new/updated values. The PRID value MUST uniquely identify a new/updated values. The PRID value MUST uniquely identify a
single PRI (i.e. PRID/PRC prefix values are illegal). single PRI (i.e. PRID/PRC prefix values are illegal). Updates to
an existing PRI are achieved by simply reinstalling the same
PRID with the updated EPD data.
o Remove - This operation is used to delete an instance of a PRC. o Remove - This operation is used to delete an instance of a PRC.
It includes one parameter, a PRID object, which names either the It includes one parameter, a PRID object, which names either the
individual PRI to be deleted or a PRID prefix naming one or more individual PRI to be deleted or a PRID prefix naming one or more
complete classes of PRIs. Prefix-based deletion supports complete classes of PRIs. Prefix-based deletion supports
efficient bulk policy removal. efficient bulk policy removal.
3. Message Content 3. Message Content
The COPS protocol provides for different COPS clients to define The COPS protocol provides for different COPS clients to define
skipping to change at page 11, line 33 skipping to change at page 10, line 33
Context Object. The Client Handle associated with the REQ message Context Object. The Client Handle associated with the REQ message
originated by a provisioning client must be unique for that originated by a provisioning client must be unique for that
client. The Client Handle is used to identify a specific request client. The Client Handle is used to identify a specific request
state. Thus, one client can potentially open several configuration state. Thus, one client can potentially open several configuration
request states, each uniquely identified by its handle. Different request states, each uniquely identified by its handle. Different
request states are used to isolate similarly named configuration request states are used to isolate similarly named configuration
information into non-overlapping contexts (or logically isolated information into non-overlapping contexts (or logically isolated
namespaces). Thus, a piece of named information is unique relative namespaces). Thus, a piece of named information is unique relative
to a particular client-type and is unique relative to a particular to a particular client-type and is unique relative to a particular
request state for that client-type, even if the information was request state for that client-type, even if the information was
similarly identified in other request states. Thus, the Client similarly identified in other request states (i.e. uses the same
Handle is part of the instance identification of the communicated PRID). Thus, the Client Handle is also part of the instance
configuration information. identification of the communicated configuration information.
The config request message serves as a request from the PEP to the
PDP for provisioning policy data which 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 config request message should include provisioning client The configuration request message serves as a request from the PEP
information to provide the PDP with client-specific configuration to the PDP for provisioning policy data that the PDP may have for
or capability information about the PEP. The information provided the PEP, such as access control lists, etc. This includes policy
by the PEP should include client resource (e.g. queuing the PDP may have at the time the REQ is received as well as any
capabilities) and default policy configuration (e.g. default role future policy data or updates to this data.
combinations) information as well as references to existing policy
(i.e. PIB) incarnation data. 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 The configuration request message should include provisioning
what types of policy the PEP can install and enforce. The format client information to provide the PDP with client-specific
of the information encapsulated in the provisioning Named ClientSI configuration or capability information about the PEP. The
data is described in section 5. Note that the config request information provided by the PEP should include client resources
message is regenerated and sent to the PDP in response to the (e.g. queuing capabilities) and default policy configuration (e.g.
receipt of a Synchronize State Request (SSQ) message. default role combinations) information as well as references to
existing policy (i.e. PIB) incarnation data. 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 the
provisioning Named ClientSI data is described in section 5. Note
that the configuration request message 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 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 policy information supplied by the PDP must be consistent with
the named decision data defined for the policy provisioning the named decision data defined for the policy provisioning
client. The PDP responds to the config request with a DEC message client. The PDP responds to the configuration request with a DEC
containing any available provisioning policy data. message containing any available provisioning policy data.
The REQ message has the following format: The REQ message has the following format:
<Request> ::= <Common Header> <Request> ::= <Common Header>
<Client Handle> <Client Handle>
<Context = config request> <Context = config request>
[<Named ClientSI: Provisioning >] [<Named ClientSI: Provisioning >]
[<Integrity>] [<Integrity>]
Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are
skipping to change at page 12, line 52 skipping to change at page 12, line 8
Each DEC message may contain multiple decisions. This means a Each DEC message may contain multiple decisions. This means a
single message can install some policies and delete others. In single message can install some policies and delete others. In
general a COPS-PR decision message should contain at most one or general a COPS-PR decision message should contain at most one or
more deletes followed by one or more install decisions. This is more deletes followed by one or more install decisions. This is
used to solve a precedence issue, not a timing issue: the delete used to solve a precedence issue, not a timing issue: the delete
decision deletes what it specifies, except those items that are decision deletes what it specifies, except those items that are
installed in the same message. installed in the same message.
The DEC message can also be used by the PDP to command the PEP to 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 open a new Request State or Delete an existing Request-State as
identified by the Client-Handle. To accomplish this, COPS-PR identified by the Client-Handle. To accomplish this, COPS-PR
defines a new flag for the COPS Decision Flags object. The flag 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 0x02 is to be used by COPS-PR client-types and is hereafter
referred to as the "Request-State" flag. An Install decision referred to as the "Request-State" flag. An Install decision
(Decision Flags: Command-Code=Install) with the Request-State flag (Decision Flags: Command-Code=Install) with the Request-State flag
set in the COPS Decision Flags object will cause the PEP to issue 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 a new Request with a new Client Handle or else specify the
appropriate error in a COPS Report message. A Remove decision appropriate error in a COPS Report message. A Remove decision
(Decision Flags: Command-Code=Remove) with the Request-State flag (Decision Flags: Command-Code=Remove) with the Request-State flag
set in the COPS Decision Flags object will cause the PEP to send a set in the COPS Decision Flags object will cause the PEP to send a
COPS Delete Request State (DRQ) message for the request state COPS Delete Request State (DRQ) message for the Request-State
identified by the Client Handle in the DEC message. Whenever the identified by the Client Handle in the DEC message. Whenever the
Request-State flag is set in the COPS Decision Flags object in 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 DEC message, no COPS Named Decision Data object can be included in
the corresponding decision (as it serves no purpose for this the corresponding decision (as it serves no purpose for this
decision flag). decision flag).
A COPS-PR DEC message must be treated as a single "transaction", 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 i.e. either all the decisions in a DEC message succeed or they all
fail. This allows the PDP to delete some policies only if other fail. This allows the PDP to delete some policies only if other
policies can be installed in their place. The DEC message has the policies can be installed in their place. The DEC message has the
skipping to change at page 14, line 18 skipping to change at page 13, line 24
the PDP to report accounting information associated with the the PDP to report accounting information associated with the
provisioned policy, or to notify the PDP of changes in the PEP provisioned policy, or to notify the PDP of changes in the PEP
(Report-Type = 'Accounting') related to the provisioning client. (Report-Type = 'Accounting') related to the provisioning client.
RPT is also used as a mechanism to inform the PDP about the action 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 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 response to an 'Install' decision, the PEP informs the PDP if the
policy data is installed (Report-Type = 'Success') or not (Report- policy data is installed (Report-Type = 'Success') or not (Report-
Type = 'Failure'). Reports that are in response to a DEC message Type = 'Failure'). Reports that are in response to a DEC message
MUST set the solicited message flag in their COPS message header. MUST set the solicited message flag in their COPS message header.
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.
Reports can also be unsolicited and all unsolicited Reports MUST Reports can also be unsolicited and all unsolicited Reports MUST
NOT set the solicited message flag in their COPS message header. NOT set the solicited message flag in their COPS message header.
Examples of unsolicited reports include 'Accounting' Report-Types, Examples of unsolicited reports include 'Accounting' Report-Types,
that were not triggered by a specific DEC messages, or 'Failure' that were not triggered by a specific DEC messages, or 'Failure'
Report-Types that indicate a change of state in a previously Report-Types that indicate a failure in a previously successfully
successfully installed configuration. installed configuration (Note that in the case of such unsolicited
failures, the PEP cannot rollback to a previous "good" state as
such becomes ambiguous under such asynchronous conditions).
The RPT message may contain provisioning client information such The RPT message may contain provisioning client information such
as accounting parameters or errors/warnings related to a decision. as accounting parameters or errors/warnings related to a decision.
The data format for this information is defined in the context of The data format for this information is defined in the context of
the policy information base (see section 5). The RPT message has the policy information base (see section 5). The RPT message has
the following format: the following format:
<Report State> ::= <Common Header> <Report State> ::= <Common Header>
<Client Handle> <Client Handle>
<Report Type> <Report Type>
skipping to change at page 16, line 17 skipping to change at page 15, line 29
06 07 2B 06 01 02 02 08 01 06 07 2B 06 01 02 02 08 01
The entire PRID object would be encoded as follows: The entire PRID object would be encoded as follows:
00 0D - Length 00 0D - Length
01 - S-Num 01 - S-Num
01 - S-Type (Complete PRID) 01 - S-Type (Complete PRID)
06 07 2B 06 01 02 02 08 01 - Encoded PRID 06 07 2B 06 01 02 02 08 01 - Encoded PRID
00 00 00 - Padding 00 00 00 - Padding
NOTE: When encoding an xxxTable's xxxEntry Object-Type as defined
by the SMI [V2SMI], 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
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. PRID Prefix(PPRID) 4.2. PRID Prefix(PPRID)
Certain operations, such as decision removal, can be optimized by Certain operations, such as decision removal, can be optimized by
specifying a PRID prefix with the intent that the requested specifying a PRID prefix with the intent that the requested
operation be applied to all PRIs matching the prefix. PRID prefix operation be applied to all PRIs matching the prefix. PRID prefix
objects MUST only be used in the COPS protocol <Remove Decision> objects MUST only be used in the COPS protocol <Remove Decision>
operation where it may be more optimal to perform bulk decision operation where it may be more optimal to perform bulk decision
removal using class prefixes instead of a sequence of individual removal using class prefixes instead of a sequence of individual
<Remove Decision> operations. Other COPS operations, e.g. <Install <Remove Decision> operations. Other COPS operations, e.g. <Install
Decision> operations always require individual PRID specification. Decision> operations always require individual PRID specification.
skipping to change at page 17, line 4 skipping to change at page 16, line 30
The entire PRID object would be encoded as follows: The entire PRID object would be encoded as follows:
00 0B - Length 00 0B - Length
02 - S-Num = PRID Prefix 02 - S-Num = PRID Prefix
01 - S-Type = BER 01 - S-Type = BER
06 05 2B 06 01 02 02 - Encoded PRID Prefix 06 05 2B 06 01 02 02 - Encoded PRID Prefix
00 - Padding 00 - Padding
4.3. Encoded Policy Instance Data (EPD) 4.3. Encoded Policy Instance Data (EPD)
S-Num = 3, S-Type = 1, Length = variable. S-Num = 3, S-Type = 1, Length = variable.
This object is used to carry the encoded value of a Policy Rule This object is used to carry the encoded value of a Policy Rule
Instance. The PRI value, which contains all of the individual Instance. The PRI value, which contains all of the individual
values of the attributes that comprise the class, is encoded as a values of the attributes that comprise the class (which
series of TLV sub-components. Each sub-component represents the corresponds to the SMI xxxEntry Object-Type defining the SEQUENCE
value of a single attribute and is encoded following the BER. of attributes comprising a table [V2SMI]), 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.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | S-Num = EPD | S-Type = BER | | Length | S-Num = EPD | S-Type = BER |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
... ... ... ...
| BER Encoded PRI Value | | BER Encoded PRI Value |
... ... ... ...
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
As an example, an instance of the filter class, defined in the QoS As an example, an instance of the filter class, defined in the
Policy IP PIB [PIB], would be encoded as follows: Framework PIB [PIB], would be encoded as follows:
02 01 08 :filterIndex/INTEGER/Value = 8 02 01 08 :filterIndex/INTEGER/Value = 8
40 04 C0 39 01 05 :filterDstAddr/IpAddress/Value = 192.57.1.5 40 04 C0 39 01 05 :filterDstAddr/IpAddress/Value = 192.57.1.5
40 04 FF FF FF FF :filterDstMask/IpAddress/Value = 255.255.255.255 40 04 FF FF FF FF :filterDstMask/IpAddress/Value = 255.255.255.255
40 04 00 00 00 00 :filterSrcAddr/IpAddress/Value = 0.0.0.0 40 04 00 00 00 00 :filterSrcAddr/IpAddress/Value = 0.0.0.0
40 04 00 00 00 00 :filterSrcMask/IpAddress/Value = 0.0.0.0 40 04 00 00 00 00 :filterSrcMask/IpAddress/Value = 0.0.0.0
02 01 FF :filterDscp/Integer32/Value = -1 (not used) 02 01 FF :filterDscp/Integer32/Value = -1 (not used)
02 01 06 :filterProtocol/INTEGER/Value = 6 (TCP) 02 01 06 :filterProtocol/INTEGER/Value = 6 (TCP)
05 00 :filterDstL4PortMin/NULL/not supported 05 00 :filterDstL4PortMin/NULL/not supported
05 00 :filterDstL4PortMax/NULL/not supported 05 00 :filterDstL4PortMax/NULL/not supported
skipping to change at page 18, line 24 skipping to change at page 18, line 4
4.4. Global Provisioning Error Object (GPERR) 4.4. Global Provisioning Error Object (GPERR)
S-Num = 4, S-Type = 1, Length = 8. S-Num = 4, S-Type = 1, Length = 8.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | S-Num = GPERR | S-Type = BER | | Length | S-Num = GPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
The global provisioning error object has the same format as the The global provisioning error object has the same format as the
Error object in COPS [COPS], except with C-Num and C-Type replaced 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 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 object is used to communicate general errors that do not map to a
specific PRC. specific PRC.
The following global error codes are defined: The following global error codes are defined:
availMemLow(1), availMemLow(1)
availMemExhausted(2), availMemExhausted(2)
unknownASN.1Tag(3), unknownASN.1Tag(3) - The erroneous tag type MUST be
maxMsgSizeExceeded(4), specified in the Error Sub-Code field.
maxMsgSizeExceeded(4) - COPS message (transaction) was too big.
unknownError(5) unknownError(5)
maxRequestStatesOpen(6)- No more Request-States can be created
Note: For the unknownASN.1Tag, the erroneous tag type by the PEP (in response to a DEC
MUST be specified in the Error Sub-Code field 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 PEP (but
otherwise formatted correctly). PRC
specific error codes are to be used to
provide more information.
4.5. PRC Class Provisioning Error Object (CPERR) 4.5. PRC Class Provisioning Error Object (CPERR)
S-Num = 5, S-Type = 1, Length = 8. S-Num = 5, S-Type = 1, Length = 8.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | S-Num = CPERR | S-Type = BER | | Length | S-Num = CPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
skipping to change at page 19, line 4 skipping to change at page 18, line 40
4.5. PRC Class Provisioning Error Object (CPERR) 4.5. PRC Class Provisioning Error Object (CPERR)
S-Num = 5, S-Type = 1, Length = 8. S-Num = 5, S-Type = 1, Length = 8.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | S-Num = CPERR | S-Type = BER | | Length | S-Num = CPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
The class-specific provisioning error object has the same format The class-specific provisioning error object has the same format
as the Error object in COPS [COPS], except with C-Num and C-Type 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 replaced by the S-Num and S-Type values shown. The class-specific
error object is used to communicate errors relating to specific error object is used to communicate errors relating to specific
PRCs and MUST have an associated Error PRID Object. PRCs and MUST have an associated Error PRID Object.
The following Generic Class-Specific errors are defined: The following Generic Class-Specific errors are defined:
priSpaceExhausted(1), priSpaceExhausted(1) - no more instances may currently be
priInstanceInvalid(2), installed in the given class.
attrValueInvalid(3),
attrValueSupLimited(4), priInstanceInvalid(2) - the specified class instance is
attrEnumSupLimited(5), currently invalid prohibiting
attrMaxLengthExceeded(6), installation.
attrReferenceUnknown(7), attrValueInvalid(3) - the specified value for identified
priNotifyOnly(8), attribute is illegal.
unknownPrc(9), -- install a PRI of a class not supported by PEP attrValueSupLimited(4) - the specified value for the identified
noAccess(10), -- install a PRI of a class whose access is notify attribute is legal but not currently
tooFewAttrs(11), -- recvd PRI has fewer attributes than required. supported by the device.
invalidAttrType(12), -- recvd PRI has an attribute of the wrong 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 implemented as a
'notify' 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. type.
deletedInRef(13), -- deleted PRI is still referenced by other deletedInRef(12) - deleted PRI is still referenced by
(non) deleted PRIs other (non) deleted PRIs
priSpecificError(14) priSpecificError(13) - the Error Sub-code field contains the
PRC specific error code
Note: For the priSpecificError code the Error Sub-code field Where appropriate (errors 3, 4, 5, 6, 7 above) the error sub-code
contains the PRC specific error code should identify the OID sub-identifier of the attribute
associated with the error.
4.6. Error PRID Object (ErrorPRID) 4.6. Error PRID Object (ErrorPRID)
S-Num = 6, S-Type = 1 (BER ErrorPRID), Length = variable. S-Num = 6, S-Type = 1 (BER ErrorPRID), Length = variable.
This object is used to carry the identifier, or PRID, of a Policy This object is used to carry the identifier, or PRID, of a Policy
Rule Instance that caused an installation error or could not be Rule Instance that caused an installation error or could not be
installed or removed. The identifier is encoded and formatted installed or removed. The identifier is encoded and formatted
exactly as in the PRID object as described in section 4.1. exactly as in the PRID object as described in section 4.1.
5. COPS-PR Client-Specific Data Formats 5. COPS-PR Client-Specific Data Formats
This section describes the format of the named client specific This section describes the format of the named client specific
information for the COPS policy provisioning client. ClientSI information for the COPS policy provisioning client. ClientSI
formats are defined for Decision message's Named Decision Data formats are defined for Decision message's Named Decision Data
object, the Request message's Named ClientSI object and Report object, the Request message's Named ClientSI object and Report
message's Named ClientSI object. The actual content of the data is message's Named ClientSI object. The actual content of the data is
defined by the policy information base for a specific provisioning defined by the policy information base for a specific provisioning
client type (see below). client-type (see below).
5.1. Named Decision Data 5.1. Named Decision Data
The formats encapsulated by the Named Decision Data object for the The formats encapsulated by the Named Decision Data object for the
policy provisioning client-types depends on the type of decision. policy provisioning client-types depends on the type of decision.
Install and Remove are the two types of decisions that dictate the Install and Remove are the two types of decisions that dictate the
internal format of the COPS Named Decision Data object and require internal format of the COPS Named Decision Data object and require
its presence. Install and Remove refer to the 'Install' and its presence. Install and Remove refer to the 'Install' and
'Remove' Command-Code, respectively, specified in the COPS 'Remove' Command-Code, respectively, specified in the COPS
Decision Flags Object when no Decision Flags are set. The data, Decision Flags Object when no Decision Flags are set. The data,
skipping to change at page 22, line 10 skipping to change at page 22, line 14
related to the installed configuration for use at the PDP. This related to the installed configuration for use at the PDP. This
information is encoded as one or more <PRID><EPD> bindings that information is encoded as one or more <PRID><EPD> bindings that
generally describe the accounting information being reported from generally describe the accounting information being reported from
the PEP to the PDP. the PEP to the PDP.
The format for this data is encapsulated in the COPS Named ClientSI The format for this data is encapsulated in the COPS Named ClientSI
object as follows: object as follows:
<ClientSI: Named Report> ::= <*(<PRID><EPD>)> <ClientSI: Named Report> ::= <*(<PRID><EPD>)>
6. Common Operations 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.
6. Common Operation
This section describes, in general, typical exchanges between a This section describes, in general, typical exchanges between a
PDP and Policy Provisioning COPS client. PDP and Policy Provisioning COPS client.
First, a TCP connection is established between the client and First, a TCP connection is established between the client and
server and the PEP sends a Client-Open message specifying a COPS- server and the PEP sends a Client-Open message specifying a COPS-
PR client-type, Policy Provisioning client. If the PDP supports PR client-type (use of the ClientSI object within the Client-Open
the specified provisioning client type, the PDP responds with a message is currently undefined for COPS-PR clients). If the PDP
Client-Accept (CAT) message. If the client-type is not supported, supports the specified provisioning client-type, the PDP responds
a Client-Close (CC) message is returned by the PDP to the PEP, with a Client-Accept (CAT) message. If the client-type is not
possibly identifying an alternate server that is known to support supported, a Client-Close (CC) message is returned by the PDP to
the policy for the provisioning client-type specified. 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 After receiving the CAT message, the PEP can send requests to the
server. The REQ from a policy provisioning client contains a COPS server. The REQ from a policy provisioning client contains a COPS
'Configuration Request' context object and, optionally, any 'Configuration Request' context object and, optionally, any
relevant named client specific information from the PEP. The relevant named client specific information from the PEP. The
information provided by the PEP should include available client information provided by the PEP should include available client
resources (e.g., supported classes/attributes) and default policy resources (e.g., supported classes/attributes) and default policy
configuration information as well as references to existing policy configuration information as well as references to existing policy
(i.e., PIB) incarnation data. The configuration request message (i.e., PIB) incarnation data. The configuration request message
from a provisioning client serves two purposes. First, it is a from a provisioning client serves two purposes. First, it is a
request to the PDP for any provisioning configuration data which request to the PDP for any provisioning configuration data which
the PDP may currently have that is suitable for the PEP, such as the PDP may currently have that is suitable for the PEP, such as
access control filters, etc., given the information the PEP access control filters, etc., given the information the PEP
specified in its REQ. Also, the configuration request effectively specified in its REQ. Also, the configuration request effectively
opens a channel that will allow the PDP to asynchronously send opens a channel that will allow the PDP to asynchronously send
policy data to the PEP, as the PDP decides is necessary, as long policy data to the PEP, as the PDP decides is necessary, as long
as the PEP keeps its request state open (ie. As long as the PEP as the PEP keeps its request state open (ie. As long as the PEP
does not send a DRQ with the request state's Client Handle). This 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 asynchronous data may be new policy data or an update to policy
data sent previously. 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 to its local
state.
After the PEP sends a REQ, if the PDP has Policy Provisioning After the PEP sends a REQ, if the PDP has Policy Provisioning
policy configuration information for the client, that information policy configuration information for the client, that information
is returned to the client in a DEC message containing the Policy is returned to the client in a DEC message containing the Policy
Provisioning client policy data within the COPS Named Decision Provisioning client policy data within the COPS Named Decision
Data object and specifying an "Install" Command-Code in the Data object and specifying an "Install" Command-Code in the
Decision Flags object. If no filters are defined, the DEC message Decision Flags object. If no filters are defined, the DEC message
will simply specify that there are no filters using the "NULL will simply specify that there are no filters using the "NULL
Decision" Command-Code in the Decision Flags object. As the PEP Decision" Command-Code in the Decision Flags object. As the PEP
MUST specify a Client Handle in the request message, the PDP MUST MUST specify a Client Handle in the request message, the PDP MUST
process the Client Handle and copy it in the corresponding process the Client Handle and copy it in the corresponding
decision message. A DEC message must be issued by the PDP with the decision message. A DEC message must be issued by the PDP with the
Solicited Message Flag set in the COPS message header, regardless Solicited Message Flag set in the COPS message header, regardless
of whether or not the PDP has any configuration information for 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 the PEP at the time of the request. This is to prevent the PEP
from timing out the REQ and deleting the Client Handle. from timing out the REQ and deleting the Client Handle.
The PDP can then add new policy data or update/delete existing The PDP can then add new policy data or update/delete existing
state by sending subsequent unsolicited DEC message(s) to the PEP, state by sending subsequent unsolicited DEC message(s) to the PEP,
with the same Client Handle. The PEP is responsible for removing with the same Client Handle. Previous configurations installed on
the Client handle when it is no longer needed, for example when the PEP are updated by the PDP by simply re-installing the same
the interface goes down, and informing the PDP that the Client instance of configuration information again (effectively
Handle is to be deleted via the COPS DRQ message. 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 For Policy Provisioning purposes, access state, and access
requests to the policy server can be initiated by other sources requests to the policy server can be initiated by other sources
besides the PEP. Examples of other sources include attached users besides the PEP. Examples of other sources include attached users
requesting network services via a web interface into a central requesting network services via a web interface into a central
management application, or H.323 servers requesting resources on management application, or H.323 servers requesting resources on
behalf of a user for a video conferencing application. When such a behalf of a user for a video conferencing application. When such a
request is accepted, the edge device affected by the decision (the request is accepted, the edge device affected by the decision (the
point where the flow is to enter the network) must be informed of point where the flow is to enter the network) must be informed of
the decision. Since the PEP in the edge device did not initiate the decision. Since the PEP in the edge device did not initiate
the request, the specifics of the request, e.g. flowspec, packet the request, the specifics of the request, e.g. flowspec, packet
filter, and PHB to apply, must be communicated to the PEP by the filter, and PHB to apply, must be communicated to the PEP by the
PDP. This information is sent to the PEP using the Decision PDP. This information is sent to the PEP using the Decision
message containing Policy Provisioning Named Decision Data objects message containing Policy Provisioning Named Decision Data objects
in the COPS Decision object as specified. Any updates to the state in the COPS Decision object as specified. Any updates to the state
information, for example in the case of a policy change or call information, for example in the case of a policy change or call
tear down, is communicated to the PEP by subsequent DEC messages tear down, is communicated to the PEP by subsequent unsolicited
containing the same Client Handle and the updated Policy DEC messages containing the same Client Handle and the updated
Provisioning request state. Updates can specify that policy data Policy Provisioning request state. Updates can specify that policy
is to be deleted or installed. data is to be installed, deleted, or updated (re-installed).
PDPs may also command the PEP to open a new Request State or PDPs may also command the PEP to open a new Request State or
delete an exiting one by issuing a decision with the Decision delete an exiting one by issuing a decision with the Decision
Flags object's Request-State flag set. If the command-code is Flags object's Request-State flag set. If the command-code is
"install", then the PDP is commanding the PEP to create a new "install", then the PDP is commanding the PEP to create a new
Request State, and therefore issue a new REQ message specifying a Request State, and therefore issue a new REQ message specifying a
new Client Handle or otherwise issue a "Failure" RPT specifying an new Client Handle or otherwise issue a "Failure" RPT specifying
error condition. Each request state represents an independent and the appropriate error condition. Each request state represents an
logically non-overlapping namespace, identified by the Client independent and logically non-overlapping namespace, identified by
Handle, on which transactions may be performed. Other existing the Client Handle, on which transactions (a.k.a. configuration
Request States will be unaffected by the new request state as they installations, deletions, updates) may be performed. Other
are independent (thus, no instances of configuration data within existing Request States will be unaffected by the new request
one Request State can be affected by DECs for another Request state as they are independent (thus, no instances of configuration
State as identified by the Client Handle). If the command-code is data within one Request State can be affected by DECs for another
"Remove", then the PDP is commanding the PEP to delete the 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 existing Request-State specified by the DEC message's Client
Handle, thereby causing the PEP to issue a DRQ message for this Handle, thereby causing the PEP to issue a DRQ message for this
Handle. Handle.
The PEP acknowledges the DEC message and action taken by sending a The PEP acknowledges a DEC message and action taken by sending a
RPT message with a "Success" or "Failure" Report-Type object with RPT message with a "Success" or "Failure" Report-Type object with
the Solicited Message Flag set in the COPS message header. This 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 serves as an indication to the PDP that the requestor (e.g. H.323
server) can be notified that the request has been accepted by the server) can be notified that the request has been accepted by the
network. If the PEP needs to reject the DEC operation for any network. If the PEP needs to reject the DEC operation for any
reason, a RPT message is sent with a Report-Type of value reason, a RPT message is sent with a Report-Type of value
"Failure" and optionally a Client Specific Information object "Failure" and optionally a Client Specific Information object
specifying the policy data that was rejected. The PDP can then specifying the policy data that was rejected. Under such failure
respond to the requestor accordingly. 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 local status of any installed The PEP can report to the PDP the local status of any installed
request state when appropriate. This information is sent in a request state when appropriate. This information is sent in a
Report-State (RPT) message with the "Accounting" flag set. The Report-State (RPT) message with the "Accounting" flag set. The
request state being reported is referenced by the Client Handle request state that is being reported is identified via the
associated with the request state and the client specific data associated Client Handle in the report message.
identifier.
Finally, Client-Close (CC) messages are used to cancel the Finally, Client-Close (CC) messages are used to cancel the
corresponding Client-Open message. The CC message informs the corresponding Client-Open message. The CC message informs the
other side that the client type specified is no longer supported. other side that the client-type specified is no longer supported.
7. Fault Tolerance 7. Fault Tolerance
When communication is lost between PEP and PDP, the PEP attempts When communication is lost between PEP and PDP, the PEP attempts
to re-establish the TCP connection with the PDP it was last to re-establish the TCP connection with the PDP it was last
connected to. If that server cannot be reached, then the PEP connected to. If that server cannot be reached, then the PEP
attempts to connect to a secondary PDP, assumed at this time to be attempts to connect to a secondary PDP, assumed to be manually
manually configured at the PEP. configured (or otherwise known) at the PEP.
When a connection is finally re-established with a PDP, the PEP When a connection is finally re-established with a PDP, the PEP
sends a OPN message with a <LastPDPAddr> object providing the sends a OPN message with a <LastPDPAddr> object providing the
address of the most recent PDP for which it is still caching address of the most recent PDP for which it is still caching
decisions. If no decisions are being cached on the PEP (due to 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 reboot or TTL timeout of state) the PEP must not include the last
PDP address information. Based on this information, the PDP may PDP address information. Based on this object, the PDP may request
request the PEP to re-synch its current state information (by the PEP to re-synch its current state information (by issuing a
issuing a COPS SSQ message). If, after re-connecting, the PDP does COPS SSQ message). If, after re-connecting, the PDP does not
not request the synchronization, the client can assume the server request synchronization, the client can assume the server
recognizes it and the current state at the PEP is correct. Any recognizes it and the current state at the PEP is correct, so a
state changes which occurred at the PEP while the connection was REQ message need not be sent. Still, any state changes which
lost must be reported to the PDP via the PEP sending an updated occurred at the PEP that the PEP could not communicate to the PDP
REQ message. On the other hand, if re-synchronization is due to communication having been lost, must be reported to the PDP
requested, the PEP MUST reissue any REQ messages it generated via the PEP sending an updated REQ message. Whenever re-
during initial connection establishment and the PDP MUST issue DEC 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 messages to delete either individual PRIDs or prefixes as
appropriate to ensure a consistent known state at the PEP. appropriate to ensure a consistent known state at the PEP.
While the PEP is disconnected from the PDP, the request state at While the PEP is disconnected from the PDP, the active request-
the PEP is to be used for policy decisions. If the PEP cannot re- state at the PEP is to be used for policy decisions. If the PEP
connect in some pre-specified period of time, the request state is cannot re-connect in some pre-specified period of time, all
to be deleted and the associated Handles removed. The same holds installed Request-States are to be deleted and their associated
true for the PDP; upon detecting a failed TCP connection, the Handles removed. The same holds true for the PDP; upon detecting a
time-out timer is started for the request state associated with failed TCP connection, the time-out timer is started for all
the PEP and the state is removed after the specified period Request-States associated with the PEP and these states are
without a connection. removed after the administratively specified period without a
connection.
7.1. Security Considerations 7.1. Security Considerations
The use of COPS for Policy Provisioning introduces no new security The use of COPS for Policy Provisioning introduces no new security
issues over the base COPS protocol [COPS]. The security mechanism issues over the base COPS protocol [COPS]. The security mechanism
described in that document should be deployed in a COPS-PR described in that document should be deployed in a COPS-PR
environment. environment.
8. Acknowledgements 8. Acknowledgements
This document has been developed with active involvement This document has been developed with active involvement from a
from a number of sources. The authors would specifically like to number of sources. The authors would specifically like to
acknowledge the valuable input given by Michael Fine and Scott Hahn. acknowledge the valuable input given by Michael Fine, Scott Hahn,
and Carol Bell.
9. References 9. References
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.,
Sastry, A., "The COPS (Common Open Policy Service) Sastry, A., "The COPS (Common Open Policy Service)
Protocol", IETF RFC 2748, Proposed Standard, January 2000. Protocol", IETF RFC 2748, Proposed Standard, January 2000.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based [RAP] Yavatkar, R., et al., "A Framework for Policy Based
Admission Control",IETF RFC 2753, January 2000. Admission Control",IETF RFC 2753, January 2000.
skipping to change at page 26, line 35 skipping to change at page 26, line 35
[BER] Information processing systems - Open Systems [BER] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1), International Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard Organization for Standardization. International Standard
8825, (December, 1987). 8825, (December, 1987).
[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Service," RFC Weiss, "An Architecture for Differentiated Service," RFC
2475, December 1998. 2475, December 1998.
[PIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, A. Smith, "An [PIB] M. Fine, K. McCloghrie, R. Sahita, S. Hahn, K. Chan, A.
Initial Quality of Service Policy Information Base for Smith, J. Seligson, "Framework Policy Information Base",
COPS-PR Clients and Servers", draft-mfine-cops-pib-02.txt, draft-ietf-rap-frameworkpib-00.txt, July 2000.
October 1999.
V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2(SMIv2)", STD 58, RFC 2578, April Information Version 2(SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[RFC2234] D. Crocker, P. Overell, " Augmented BNF for Syntax [RFC2234] D. Crocker, P. Overell, " Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
10. Author Information 10. Author Information
Francis Reichmeyer IPHighway Inc. Francis Reichmeyer IPHighway Inc.
Phone: (201) 585-0800 Parker Plaza, 16th Floor Phone: (201) 585-0800 Parker Plaza, 16th Floor
Email: FranR@iphighway.com 400 Kelby St. Email: FranR@iphighway.com 400 Kelby St.
Fort-Lee, NJ 07024 Fort-Lee, NJ 07024
Shai Herzog Shai Herzog
Phone: (201) 585-0800 Phone: (201) 585-0800
Email: Herzog@iphighway.com Email: Herzog@iphighway.com
Kwok Ho Chan Nortel Networks, Inc. Kwok Ho Chan Nortel Networks, Inc.
Phone: (978) 916-8175 600 Technology Park Drive Phone: (978) 288-8175 600 Technology Park Drive
Email: kchan@nortelnetworks.com Billerica, MA 01821 EMail: khchan@nortelnetworks.com Billerica, MA 01821
David Durham Intel David Durham Intel
Phone: (503) 264-6232 2111 NE 25th Avenue Phone: (503) 264-6232 2111 NE 25th Avenue
Email: david.durham@intel.com Hillsboro, OR 97124 Email: david.durham@intel.com Hillsboro, OR 97124
Raj Yavatkar Raj Yavatkar
Phone: (503) 264-9077 Phone: (503) 264-9077
Email: raj.yavatkar@intel.com Email: raj.yavatkar@intel.com
Silvano Gai Cisco Systems, Inc. Silvano Gai Cisco Systems, Inc.
Phone: (408) 527-2690 170 Tasman Dr. Phone: (408) 527-2690 170 Tasman Dr.
Email: sgai@cisco.com San Jose, CA 95134-1706 Email: sgai@cisco.com San Jose, CA 95134-1706
Keith McCloghrie Keith McCloghrie
Phone: (408) 526-5260 Phone: (408) 526-5260
Email: kzm@cisco.com Email: kzm@cisco.com
Andrew Smith Extreme Networks Andrew Smith
Phone: +1 408 579 2821 3585 Monroe St. 415 345 1827 fax
Email: andrew@extremenetworks.com Santa Clara CA 95051 ah_smith@pacbell.net
USA
John Seligson Nortel Networks, Inc. John Seligson Nortel Networks, Inc.
Phone: (408) 495-2992 4401 Great America Parkway Phone: (408) 495-2992 4401 Great America Parkway
Email:jseligso@nortelnetworks.com Santa Clara, CA 95054 Email:jseligso@nortelnetworks.com Santa Clara, CA 95054
11. Full Copyright Notice 11. Full Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/