draft-ietf-rap-cops-01.txt   draft-ietf-rap-cops-02.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: September 1998 MCI Expiration: February 1999 Level 3
File: draft-ietf-rap-cops-01.txt Ron Cohen File: draft-ietf-rap-cops-02.txt Ron Cohen
Class Data Systems Cisco
David Durham David Durham
Intel Intel
Shai Herzog Shai Herzog
IPHighway IPHighway
Raju Rajan Raju Rajan
IBM IBM
Arun Sastry Arun Sastry
Cisco Cisco
The COPS (Common Open Policy Service) Protocol The COPS (Common Open Policy Service) Protocol
Last Updated: March 12, 1998 Last Updated: August 6, 1998
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
"working draft" or "work in progress". "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before September 1998. Distribution of this document will expire before February 1999. Distribution of this
draft is unlimited. draft is unlimited.
Abstract Abstract
This document describes a simple client/server model for supporting This document describes a simple client/server model for supporting
policy control over QoS Signaling Protocols with similar properties policy control over QoS Signaling Protocols and provisioned QoS
as ReSerVation Protocol (RSVP). It is designed to be extensible so resource management. It is designed to be extensible so that other
that other kinds of policy clients may be supported in the future. kinds of policy clients may be supported in the future. The model
The model does not make any assumptions about the decision methods does not make any assumptions about the methods of the policy
of the policy server, but is based on the server returning responses server, but is based on the server returning decisions to policy
to policy requests. requests.
1. Introduction 1. Introduction
This document describes a simple query and response protocol that This document describes a simple query and response protocol that
can be used to exchange policy information between a policy server can be used to exchange policy information between a policy server
(Policy Decision Point or PDP) and its clients (Policy Enforcement (Policy Decision Point or PDP) and its clients (Policy Enforcement
Points or PEPs). One policy client is expected to be RSVP routers Points or PEPs). One example of a policy client is RSVP routers
that must exercise policy-based admission control over RSVP usage that must exercise policy-based admission control over RSVP usage
[RSVP]. We assume that at least one policy server exists in each [RSVP]. We assume that at least one policy server exists in each
controlled administrative domain. The basic model of interaction controlled administrative domain. The basic model of interaction
between a policy server and its clients is compatible with between a policy server and its clients is compatible with
the framework document for policy based admission control [WRK]. the framework document for policy based admission control [WRK].
A chief objective of our proposal is to begin with a simple but A chief objective of policy control protocol is to begin with a
extensible design. The main characteristics of the proposed protocol simple but extensible design. The main characteristics of the COPS
include: protocol include:
1. The protocol employs a client/server model where the PEP 1. The protocol employs a client/server model where the PEP
sends requests, updates, and deletes to the remote PDP and the sends requests, updates, and deletes to the remote PDP and the
PDP returns decisions back to the PEP. PDP returns decisions back to the PEP.
2. The protocol uses TCP as its transport protocol for reliable 2. The protocol uses TCP as its transport protocol for reliable
exchange of messages between policy clients and a server. exchange of messages between policy clients and a server.
Therefore, no additional mechanisms are necessary for reliable Therefore, no additional mechanisms are necessary for reliable
communication between a server and its clients. communication between a server and its clients.
3. The protocol is extensible in that it is designed to leverage 3. The protocol is extensible in that it is designed to leverage
off self-identifying objects and can support diverse client off self-identifying objects and can support diverse client
specific information. Thus, even though the protocol was created specific information without requiring modifications to the COPS
for the administration and enforcement of policies in protocol itself. The protocol was created for the general
conjunction with RSVP, the protocol may be extended for administration, configuration, and enforcement of policies
administration of other (signaling) protocols such as multicast whether signaled or provisioned. The protocol may be extended
access and network security. for the administration of a variety of signaling protocols as
well as policy configuration on a device.
4. The protocol relies on existing protocols for security. 4. The protocol relies on existing protocols for security.
Namely IPSEC [IPSEC] can be used to authenticate and secure the Namely IPSEC [IPSEC] can be used to authenticate and secure the
channel between the PEP and the server. channel between the PEP and the server.
5. The protocol is stateful in two main aspects: 5. The protocol is stateful in two main aspects:
(1) Request/Response state is shared between client and server (1) Request/Decision state is shared between client and server
and (2) State from various events (Request/Response pairs) may and (2) State from various events (Request/Decision pairs) may
be inter-associated. By (1) we mean that requests from the be inter-associated. By (1) we mean that requests from the
client PEP are installed or remembered by the remote PDP until client PEP are installed or remembered by the remote PDP until
they are explicitly deleted by the PEP. At the same time, they are explicitly deleted by the PEP. At the same time,
Responses from the remote PDP can be generated asynchronously at Decisions from the remote PDP can be generated asynchronously at
any time for a currently installed request state. By (2) we mean any time for a currently installed request state. By (2) we mean
that the server may respond to new queries differently because that the server may respond to new queries differently because
of previously installed, related Request/Response state (e.g., of previously installed Request/Decision state(s) that are
for RSVP, the server may associate state from incoming Path and related.
Resv requests).
6. Additionally, the protocol is stateful in that it allows the
server to push configuration information to the client, and then
allows the server to remove such state from the client when it
is no longer applicable.
1.1. Basic Model 1.1. Basic Model
+----------------+ +----------------+
| | | |
| Network Node | Policy Server | Network Node | Policy Server
| | | |
| +-----+ | COPS +-----+ | +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP | | | PEP |<-----|-------------->| PDP |
| |+----+ | +-----+ | +-----+ | +-----+
| ^ | | ^ |
| | | | | |
| \-->+-----+ | | \-->+-----+ |
| | LDP | | | | LDP | |
| +-----+ | | +-----+ |
| | | |
+----------------+ +----------------+
Figure 1: A COPS illustration. Figure 1: A COPS illustration.
Figure 1 Illustrates the layout of various policy components in a Figure 1 Illustrates the layout of various policy components in a
typical COPS example (taken from [WRK]). Here, COPS is used to typical COPS example (taken from [WRK]). Here, COPS is used to
communicate policy information between a Policy Enforcement Point communicate policy information between a Policy Enforcement Point
(PEP) and a remote Policy Decision Point (PDP). (PEP) and a remote Policy Decision Point (PDP) within the context of
a particular type of client.
It is assumed that each participating policy client is functionally It is assumed that each participating policy client is functionally
consistent with a PEP [WRK]. The PEP may communicate with a policy consistent with a PEP [WRK]. The PEP may communicate with a policy
server (herein referred to as a remote PDP [WRK]) to obtain policy server (herein referred to as a remote PDP [WRK]) to obtain policy
decisions or directives. decisions or directives.
The COPS protocol uses a single persistent TCP connection between The PEP uses a TCP connection to send requests to and receive
the PEP and a remote PDP. The remote PDP listens on a well-known decisions from the remote PDP. Communication between the PEP and
port number (COPS=3288), and the PEP is responsible for initiating remote PDP is mainly in the form of a stateful request/decision
the connection. The location of the remote PDP can either be exchange, though the remote PDP may occasionally send unsolicited
configured, or obtained via a service location mechanism [SRVLOC]. decisions to the PEP to force changes in previously approved request
Service discovery is outside the scope of this protocol, however. states. The PEP also has the capacity to report to the remote PDP
that it has committed to an accepted request state for purposes of
accounting and monitoring. The PEP is responsible for notifying the
PDP when a request state has changed on the PEP. Finally, the PEP is
responsible for the deletion of any state that is no longer
applicable due to events at the client or decisions issued by the
server.
The PEP uses the TCP connection to send requests to and receive When the PEP sends a configuration request, it expects the PDP to
responses from the remote PDP. Communication between the PEP and continuously send named units of configuration data to the PEP via
remote PDP is mainly in the form of a stateful request/response decision messages as applicable for the configuration request. When
exchange, though the remote PDP may occasionally send an unsolicited a unit of named configuration data is successfully installed on the
response to the PEP to force a change in a previously approved PEP, the PEP should send a report message to the PDP confirming the
request state. The PEP also has the capacity to report to the remote installation. The server may then update or remove the named
PDP that it has committed to an accepted request state for purposes configuration information via a new decision message. When the PDP
of accounting and monitoring. Finally, the PEP is responsible for sends a decision to remove named configuration data from the PEP,
the deletion of a request state that is no longer applicable or the PEP will delete the specified configuration and send a report
updating a request state on the PDP when it likewise changes at the message to the PDP as confirmation.
PEP.
The policy protocol is designed to communicate self-identifying The policy protocol is designed to communicate self-identifying
objects which contain the data necessary for identifying request objects which contain the data necessary for identifying request
states, establishing the context for a request, identifying the type states, establishing the context for a request, identifying the type
of request, referencing previously installed requests, relaying of request, referencing previously installed requests, relaying
policy decisions, reporting errors, and transferring client specific policy decisions, reporting errors, and transferring client
information. specific/name space information.
To distinguish between different kinds of clients, the type of To distinguish between different kinds of clients, the type of
client is identified in each message. Different types of clients may client is identified in each message. Different types of clients may
have different client specific data and may require different kinds have different client specific data and may require different kinds
of policy decisions. It is expected that each new client type will of policy decisions. It is expected that each new client-type will
have a corresponding extensions draft specifying the specifics of have a corresponding usage draft specifying the specifics of its
its interaction with this policy protocol. interaction with this policy protocol.
The context of each request corresponds to the policy event that The context of each request corresponds to the type of event that
triggered it. COPS identifies three types of controlled events: (1) triggered it. COPS identifies three types of outsourcing events: (1)
the arrival of an incoming message (2) allocation of local the arrival of an incoming message (2) allocation of local
resources, and (3) the forwarding of an outgoing message. resources, and (3) the forwarding of an outgoing message. Each of
Each of these events may require different decisions to be made. these events may require different decisions to be made. Context sub
Context sub types are also defined according to the type of message types are also available to describe the type of message that
that triggered the policy event. In RSVP, this subtype is used to triggered the policy event. The content of a COPS request/decision
define the RSVP signaling message type (e.g., Path, Resv, etc.). The message depends on the context. A forth type of request is useful
content of a COPS request/response message depends on the context. for types of clients that wish to receive configuration information
from the PDP. This allows a PEP to issue a configuration request for
a specific named device or module that requires configuration
information to be installed.
The PEP may also have the capability to make a local policy decision The PEP may also have the capability to make a local policy decision
via its Local Decision Point (LDP) [WRK], however, the PDP remains via its Local Decision Point (LDP) [WRK], however, the PDP remains
the authoritative decision point at all times. This means that the authoritative decision point at all times. This means that the
any local decision information must always be relayed to the PDP. relevant local decision information must be relayed to the PDP. That
That is, the PDP must be granted access to all relevant information is, the PDP must be granted access to all relevant information to
to make a final policy decision. To facilitate this functionality, make a final policy decision. To facilitate this functionality, the
the PEP must send its local decision information to the remote PDP PEP must send its local decision information to the remote PDP via a
via a LDP decision object. The PEP must then abide by the PDP's LDP decision object. The PEP must then abide by the PDP's decision
decision as it is absolute. as it is absolute.
Finally, fault tolerance is a required capability for this protocol, Finally, fault tolerance is a required capability for this protocol,
particularly due to the fact it is associated with the security and particularly due to the fact it is associated with the security and
service management of distributed network devices. Fault tolerance service management of distributed network devices. Fault tolerance
is achieved by having both the PEP and remote PDP constantly verify is achieved by having both the PEP and remote PDP constantly verify
their connection to each other via keep-alive messages. When a their connection to each other via keep-alive messages. When a
failure is detected, the PEP must try to reconnect to the remote PDP failure is detected, the PEP must try to reconnect to the remote PDP
or attempt to connect to a new/alternative PDP. Once a connection is or attempt to connect to a new/alternative PDP. While disconnected,
reestablished, the remote PDP may request that all the PEP's the PEP should revert to making local decisions. Once a connection
is reestablished, the PEP is expected to notify the PDP of any
events that passed local admission control after the connection was
lost. Additionally, the remote PDP may request that all the PEP's
internal state be resynchronized (all previously installed requests internal state be resynchronized (all previously installed requests
are to be reissued). After failure and before the new connection is are to be reissued). After failure and before the new connection is
fully functional, disruption of service can be minimized if the PEP fully functional, disruption of service can be minimized if the PEP
caches previously communicated decisions and continues to use them caches previously communicated decisions and continues to use them
for some limited amount of time. (Discussions of specific provisions for some limited amount of time, typically in the order of minutes.
for such a mechanism are outside of the scope of this draft, and are (Discussions of specific provisions for such a mechanism are outside
left to client specific implementations). of the scope of this draft, and are left to client specific
implementations).
2. The Protocol 2. The Protocol
This section describes the message formats and objects exchanged This section describes the message formats and objects exchanged
between the PEP and remote PDP. between the PEP and remote PDP.
2.1 Common Header 2.1 Common Header
Each COPS message consists of the COPS header followed by a number Each COPS message consists of the COPS header followed by a number
of typed objects. of typed objects.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
|Version| //// | Op Code | Client Type | |Version| //// | Op Code | Client-type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Message Length | | Message Length |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0. Global note: //// implies field is reserved, set to 0.
The fields in the header are: The fields in the header are:
Version: 4 bits Version: 4 bits
COPS version number. Current version is 1. COPS version number. Current version is 1.
Op Code: 8 bits Op Code: 8 bits
The COPS operations: The COPS operations:
1 = Request (REQ) 1 = Request (REQ)
2 = Response (RES) 2 = Decision (DEC)
3 = Unsolicited Response (USR)
4 = Report State (RPT) 4 = Report State (RPT)
5 = Delete Request State (DRQ) 5 = Delete Request State (DRQ)
6 = Synchronize State Req (SSQ) 6 = Synchronize State Req (SSQ)
7 = Client-Open (OPN) 7 = Client-Open (OPN)
8 = Client-Accept (CAT) 8 = Client-Accept (CAT)
9 = Keep-Alive (KA) 9 = Keep-Alive (KA)
10= Client-Close (CC) 10= Client-Close (CC)
11= Synchronize Complete (SSC)
Client Type: 16 bits Client-type: 16 bits
The Client Type identifies the policy client. Interpretation of The Client-type identifies the policy client. Interpretation of
all encapsulated objects is relative to the client type. all encapsulated objects is relative to the client-type. Client-
(See Appendix A for the RSVPv1 client type ID). types that set the most significant bit in the client-type field
are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for particular
client-type IDs).
Message Length: 32 bits Message Length: 32 bits
Size of message in octets, which includes the standard COPS Size of message in octets, which includes the standard COPS
header and all encapsulated objects. Messages must be aligned on header and all encapsulated objects. Messages must be aligned on
4 octet intervals. 4 octet intervals.
2.2 COPS Specific Object Formats 2.2 COPS Specific Object Formats
All the objects follow the same object format; each object consists All the objects follow the same object format; each object consists
of one or more 32-bit words with a four octet header, using the of one or more 32-bit words with a four-octet header, using the
following format: following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type | | Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The 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 previous stated object length to the first 32-bit
boundary.
Typically, C-Num identifies the class of information contained in Typically, C-Num identifies the class of information contained in
the object, and the C-Type identifies the subtype or version of the the object, and the C-Type identifies the subtype or version of the
information contained in the object. information contained in the object.
C-num: 8 bits C-num: 8 bits
1 = Handle 1 = Handle
2 = Handle Reference.
3 = Context 3 = Context
4 = In Interface 4 = In Interface
5 = Out Interface 5 = Out Interface
6 = Reason code 6 = Reason code
7 = Decision 7 = Decision
8 = LDP Decision 8 = LDP Decision
9 = Protocol Error 9 = Protocol Error
10 = Client Specific Info 10 = Client Specific Info
11 = Timer 11 = Timer
12 = PEP Identification 12 = PEP Identification
13 = Report Type 13 = Report Type
14 = PDP Address 14 = PDP Address
C-type: 8 bits C-type: 8 bits
Values defined per C-num. Values defined per C-num.
2.2.1 Handle Object (Handle) 2.2.1 Handle Object (Handle)
Unique value that identifies an installed request state. This The Handle Object encapsulates a unique value that identifies an
identification is used by most COPS operations. The request state installed state. This identification is used by most COPS
corresponding to this handle must be explicitly deleted by the operations. A state corresponding to a handle must be explicitly
client when no longer applicable. deleted when it is no longer applicable.
The handle value is set by the PEP and is opaque to the PDP. The PDP
performs a byte-wise comparison on the value in this object with
respect to the handle object values for other currently installed
requests.
C-Num = 1, C-Type = 1
Variable-length field, no implied format. C-Num = 1
2.2.2 Handle Reference Object (HandleRef) C-Type = 1, Client Handle.
Same C-Type formats as the handle object. This object may appear in Variable-length field, no implied format other than it is unique
requests and is used to associate the current request to previously from other client handles. It is always initially chosen by the PEP
installed request states. The presence of a reference handle in a and then deleted by the PEP when no longer applicable. The client
request message tells the PDP that it should also consider handle is used to refer to a request state initiated by the PEP and
information in the referenced installed state when making a policy installed at the PDP. A PEP will specify a client handle in its
decision for the current request. Handle References are only used Request messages, Report messages and Delete messages sent to the
for the specific client types that mandate them. PDP. In all cases, the client handle is used to uniquely identify
the PEP request.
C-num = 2, C-Type = (same as handle object) The client handle value is set by the PEP and is opaque to the PDP.
The PDP simply performs a byte-wise comparison on the value in this
object with respect to the handle object values of other currently
installed requests.
2.2.3 Context Object (Context) 2.2.2 Context Object (Context)
Specifies the type of event(s) that triggered the query. Required Specifies the type of event(s) that triggered the query. Required
for request messages. for request messages. Admission control, resource allocation, and
forwarding requests are all amenable to client-types that outsource
their decision making facility to the PDP. For applicable client-
types a PEP can also make a request to receive named configuration
information from the PDP. This named configuration data may be in a
form useful for setting system attributes on a PEP, or it may be in
the form of policy rules that are to be directly verified by the
PEP.
Multiple flags can be set for the same request. This is only
allowed, however, if the set of client specific information in the
combined request is identical to the client specific information
that would be specified if individual requests were made for each
specified flag.
C-num = 3, C-Type = 1 C-num = 3, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| R-Type | M-Type | | R-Type | M-Type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
R-Type (Request Type Flag) R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request 0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request 0x02 = Resource-Allocation request
0x04 = Outgoing-Message request 0x04 = Outgoing-Message request
skipping to change at page 8, line 38 skipping to change at page 9, line 4
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| R-Type | M-Type | | R-Type | M-Type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
R-Type (Request Type Flag) R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request 0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request 0x02 = Resource-Allocation request
0x04 = Outgoing-Message request 0x04 = Outgoing-Message request
0x08 = Configuration request 0x08 = Configuration request
M-Type (Message Type) M-Type (Message Type)
Client Specific 16 bit values of protocol message types Client Specific 16 bit values of protocol message types
2.2.4 In-Interface Object (IN-Int) 2.2.3 In-Interface Object (IN-Int)
The In-Interface Object is used to identify the incoming interface The In-Interface Object is used to identify the incoming interface
on which a particular request/response applies. For flows or on which a particular request/decision applies. For flows or
messages generated from the PEP's local host, the loop back address messages generated from the PEP's local host, the loop back address
is used. is used.
Note: In-Interface is typically relative to the flow of the Note: In-Interface is typically relative to the flow of the
underlying protocol messages. That is, the In-Interface is the underlying protocol messages. That is, the In-Interface is the
interface on which the protocol message was received. interface on which the protocol message was received.
C-Num = 4 C-Num = 4
C-Type = 1, IPv4 Address C-Type = 1, IPv4 Address
skipping to change at page 9, line 36 skipping to change at page 9, line 50
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ifindex | | ifindex |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Ifindex may be used to differ between sub-interfaces and unnumbered Ifindex may be used to differ between sub-interfaces and unnumbered
interfaces (see RSVP's LIH for an example). When appropriate, this interfaces (see RSVP's LIH for an example). When appropriate, this
ifindex integer should correspond to the same integer value for the ifindex integer should correspond to the same integer value for the
interface in the SNMP MIB-II interface index table. interface in the SNMP MIB-II interface index table.
2.2.5 Out-Interface Object (OUT-Int) 2.2.4 Out-Interface Object (OUT-Int)
The Out-Interface is used to identify the outgoing interface to The Out-Interface is used to identify the outgoing interface to
which a specific request/response applies. It has the same format as which a specific request/decision applies. It has the same format as
the In-Interface Object. the In-Interface Object.
C-Num = 5, C-Type = (same C-Type as for In-Interface) C-Num = 5, C-Type = (same C-Type as for In-Interface)
Note: In-Interface is typically relative to the flow of the Note: Out-Interface is typically relative to the flow of the
underlying protocol messages. That is, the Out-Interface is the one underlying protocol messages. That is, the Out-Interface is the one
on which a protocol message is about to be forwarded. on which a protocol message is about to be forwarded.
2.2.6 Reason Object (Reason) 2.2.5 Reason Object (Reason)
This object specifies the reason why the request state was deleted. This object specifies the reason why the request state was deleted.
It should appear in the delete request (DRQ) message. It should appear in the delete request (DRQ) message. The Reason
Sub-code field is reserved for more detailed client-specific reason
codes defined in the corresponding documents.
C-Num = 6, C-Type = 1 C-Num = 6, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code | | Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Reason Code: Reason Code:
1 = Unknown 1 = Unspecified
2 = Management 2 = Management
3 = Preempted 3 = Preempted
4 = Tear 4 = Tear
5 = Timeout 5 = Timeout
6 = Route Change 6 = Route Change
7 = Insufficient Resources 7 = Insufficient Resources
8 = PDP's Directive 8 = PDP's Directive
9 = Client Specific (details in sub-code) 9 = Unsupported decision
10= Synchronize Handle Unknown 10= Synchronize Handle Unknown
11= Transient Handle (stateless event)
2.2.7 Decision Object (Decision) 2.2.6 Decision Object (Decision)
Decision made by the PDP. Must appear in replies. The specific non-
mandatory decision objects required in a decision to a particular
request depend on the type of client.
Decision made by the PDP. Must appear in replies. The specific
decision objects required in a response to a particular request
depend on the type of client.
C-Num = 7 C-Num = 7
CType = 1, Decision Flags (mandatory!) CType = 1, Decision Flags (Mandatory)
A flag bit set to 1 implies a negative decision for that flag. A flag bit set to 1 implies a negative decision for that flag.
Flags not applicable to a given request type should be ignored. Not setting any flags generally implies a positive decision.
Flag values not applicable to a given request type MUST be
ignored by the PEP.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Flags | | Flags |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Flags: Flags:
0x01 = Reject Incoming (Reject if set) 0x01 = Allow Incoming (Reject if set)
0x02 = Do Not Allocate Resources (Reject if set) 0x02 = Allocate Resources (Reject if set)
0x04 = Drop Outgoing (do not forward message if set) 0x04 = Forward Outgoing (do not forward if set)
0x08 = Trigger Error (Trigger error message if set) 0x08 = Trigger Error (Trigger error message if set)
0x10 = NULL Configuration (No configuration data if set)
0x20 = Install Configuration (Nothing to install if set)
0x40 = Remove Configuration (Nothing to remove if set)
0x80 = Enable Configuration (Nothing to enable if set)
0x100= Disable Configuration (Nothing to disable if set)
0x200= Solicited Decision
(Initial decision after a new/updated request if set)
Ctype = 2, Resource Allocation Data (optional) Ctype = 2, Resource Allocation Data
It is expected that PEPs would be able to configure simple
stateless policy information to be processed locally in their
LDP. As this set is well known and implemented ubiquitously,
PDPs are aware of it as well (either universally, through
configuration, or using the Client-Open message). The PDP may
also include this information in its response, and the PEP
should apply it to the resource allocation event that generated
the request.
Examples of resource allocation information that can be found in
other documents are:
Preemption Priority It is expected that even outsourcing PEPs will be able to make
some simple stateless policy decisions locally in their LDP. As
this set is well known and implemented ubiquitously, PDPs are
aware of it as well (either universally, through configuration,
or using the Client-Open message). The PDP may also include this
information in its decision, and the PEP should apply it to the
resource allocation event that generated the request.
Priority is used by PEP to decide which of the flows should be As an example, reservations may be admitted by a PDP contingent
preempted, when not enough resources are available on the on some type of per-session preemption priority. A RSVP PEP
interface. For RSVP, when preemption is supported, a higher could have a set of stateless policy rules for when to preempt
priority reservation can preempt an installed reservation with other reservations in favor of a new one (e.g. higher-priority
lower priority. pre-empts any of lower priority). The PDP would need to include
appropriate priority information for each reservation in its
decisions that the PEP can use to apply its rules.
CType = 3, Replacement Data (Optional) CType = 3, Replacement Data
This object is typically applicable as a response for an This object is typically applicable as a decision for an
outgoing request. Format includes a list of client specific data outgoing request. Format includes a list of client specific data
that is to be used in place of information specified in the that is to be used in place of information specified in the
request. Use of this decision type is optional. For RSVP, this request. Use of this decision type is optional. For RSVP, this
decision is used to change objects carried in RSVP messages. For decision is used to change objects carried in RSVP messages. For
example, replacing the policy data objects when forwarding a example, replacing the policy data objects when forwarding a
Resv message upstream is possible due to this decision type. If Resv message upstream is possible due to this decision type. If
this decision doesn't appear in a response, all objects are this decision doesn't appear in a decision message, all signaled
passed as if the PDP was not there. To remove an object the objects are passed as if the PDP was not there. To remove an
decision should carry an empty object of length 4 (header only). object the decision should carry an empty object of length 4
Appendix A specifies the list of RSVP objects that can be (header only).
replaced.
CType = 4, Client Specific Decision Data (Optional) CType = 4, Client Specific Decision Data
Proprietary decision types can be introduced using the Client Additional decision types can be introduced using the Client
Data Decision Object. Like the Replacement Data object, client Specific Decision Data Object. Like the Replacement Data object,
specific information is encapsulated within the Client Data client specific information is encapsulated within the Client
Object. Data Object.
2.2.8 LDP Decision Object (LDPDecision) Ctype = 5, Named Decision Data
Named configuration information should be encapsulated in this
version of the decision object in response to configuration
requests.
2.2.7 LDP Decision Object (LDPDecision)
Decision made by the PEP's local decision point (LDP). May appear in Decision made by the PEP's local decision point (LDP). May appear in
requests. These objects correspond to and are formatted the same as requests. These objects correspond to and are formatted the same as
the client specific decision objects defined above. the client specific decision objects defined above.
C-Num = 8 C-Num = 8
CType = (same C-Type as for Decision object) CType = (same C-Type as for Decision objects)
2.2.9 Error Object (Error) 2.2.8 Error Object (Error)
This object is used to identify a particular COPS protocol error. This object is used to identify a particular COPS protocol error.
The error sub-code field contains additional detailed client
specific error codes.
C-Num 9, C-Type = 1 C-Num 9, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Error-Code: Error-Code:
1 = Bad handle 1 = Bad handle
2 = Invalid handle reference 2 = Invalid handle reference
3 = Bad message format 3 = Bad message format
4 = Unable to process (server gives up on query) 4 = Unable to process (server gives up on query)
5 = Mandatory client-specific info missing 5 = Mandatory client-specific info missing
6 = Unsupported client type 6 = Unsupported client-type
7 = Mandatory COPS object missing 7 = Mandatory COPS object missing
8 = Client Failure 8 = Client Failure
9 = Communication Failure 9 = Communication Failure
10= Client Specific (details in sub-code) 10= Unspecified
11= Shutting down
2.2.10 Client Specific Information Object (ClientSI) 2.2.9 Client Specific Information Object (ClientSI)
All objects/attributes specific to a client's signaling protocol
must be encapsulated within one or more Client Information Objects.
The various types of this object are required for requests, and used The various types of this object are required for requests, and used
in reports and opens when required. Additional ClientSI encapsulated in reports and opens when required. It contains client-related
data unknown to the PDP can be safely ignored by the PDP. information.
Class-Num = 10, C-Num = 10,
C-Type = 1, Request ClientSI. C-Type = 1, Signaled ClientSI.
Variable-length field. The format of the data encapsulated in the Variable-length field. All objects/attributes specific to a client's
ClientSI object is determined by the client type. Used in request signaling protocol or internal state must be encapsulated within one
queries. or more signaled Client Specific Information Objects. The format of
the data encapsulated in the ClientSI object is determined by the
client-type.
C-Type = 2, Report ClientSI. C-Type = 2, Named ClientSI.
Variable-length field. The format of the data encapsulated in the Variable-length field. Contains named configuration information
ClientSI object is determined by the client type. Used in COPS useful for relaying specific information about the PEP, a request,
report messages when required. or configured state to the server.
C-Type = 3, Client-Open ClientSI. 2.2.10 Timer Object (Timer)
Variable-length field. The format of the data encapsulated in the Times are encoded as 2 octet integer values and are in units of
ClientSI object is determined by the client type. Used in COPS seconds. The timer value is treated as a delta.
clientSI messages for feature negotiation, etc. when required.
2.2.11 Timer Object (Timer) C-Num = 11,
Times are encoded as 2 octet integer values and are in units of C-Type = 1, Keep-alive timer value
seconds. The time value is treated as a delta.
Class-Num = 11, C-Type = 1, Keep-alive timer value Timer object used to specify the maximum time interval over which a
COPS message must be sent or received. The value of zero implies
infinity.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value | | ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.12 PEP Identification Object (PEPID) C-Type = 2, Accounting timer value
Optional timer value used to determine the minimum interval between
periodic accounting type reports. The value of zero implies
infinity.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to The PEP Identification Object is used to identify the PEP client to
the remote PDP. It is required for Client-Open messages. the remote PDP. It is required for Client-Open messages.
C-Num = 12, C-Type = 1 C-Num = 12, C-Type = 1
Variable-length field (zero padded ASCII symbolic name) configured Variable-length field (zero padded ASCII symbolic name) configured
by local administrators for the PEP. For example, it can be the by local administrators for the PEP. For example, it can be the
PEP's main IP address (not to be confused with the actual IP address PEP's main IP address (not to be confused with the actual IP address
used in the persistent TCP connection). It may also be the PEP's DNS used in the persistent TCP connection). It may also be the PEP's DNS
name, or any other symbol that uniquely identifies each PEP within name, or any other symbol that uniquely identifies each PEP within
the policy domain. The choice of configuration bears no significance the policy domain. The choice of configuration bears no significance
to the COPS protocol. By default, at least the primary IP address of for the COPS protocol, but does for policy at the PDP that may need
the PEP represented as a string is expected in the PEPID. to uniquely identify individual PEPs. By default, at least the
primary IP address of the PEP represented as a string is expected in
the PEPID.
2.2.13 Report-Type Object (Report-Type) 2.2.12 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle: The Type of Report on the request state associated with a handle:
C-Num = 13, C-Type = 1 C-Num = 13, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | ///////////// | | Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Report-Type: Report-Type:
1 = Commit : PEP's local resources now allocated 1 = Commit : PEP's local resources now allocated
2 = Accounting: Accounting update for an installed state 2 = Accounting: Accounting update for an installed state
3 = No Commit : PEP's resource allocation failure 3 = No Commit : PEP's resource allocation failure
4 = Installed : Named configuration installed
5 = Removed : Named configuration removed
6 = Enabled : Named configuration enabled
7 = Disabled : Named configuration disabled
8 = Inst&Enab : Named config. installed and enabled
2.2.14 PDP Address (PDPAddr) 2.2.13 PDP Address (PDPAddr)
A PDP when closing a PEP session for a particular client type may A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to another PDP server optionally use this object to redirect the PEP to another PDP server
via this object: via this object:
C-Num = 14, C-Num = 14,
C-Type = 1, IPv4 Address C-Type = 1, IPv4 Address (4 octets, as shown for In-interface)
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
C-Type = 2, IPv6 Address (16 octets, as shown for In-interface) C-Type = 2, IPv6 Address (16 octets, as shown for In-interface)
2.3 Communication
The COPS protocol uses a single persistent TCP connection between
the PEP and a remote PDP. The remote PDP listens on a well-known
port number (COPS=3288), and the PEP is responsible for initiating
the connection. The location of the remote PDP can either be
configured, or obtained via a service location mechanism [SRVLOC].
Service discovery is outside the scope of this protocol, however.
It is possible a single PEP may have open connections to multiple
PDPs. This is the case when there are physically different PDPs
supporting different client-types as shown in figure 2.
+----------------+
| |
| Network Node | Policy Server
| |
| +-----+ | COPS Client Type 1 +-----+
| |PEP1 |<-----|-------------------->| PDP1|
| +-----+ | | COPS Client Type 2 +-----+
| ^ | PEP2|<--|---------\ +-----+
| | +-----+ | \----------| PDP2|
| \-->+-----+ | +-----+
| | LDP | |
| +-----+ |
| |
+----------------+
Figure 2: Multiple PDPs illustration.
When a TCP connection is torn down or is lost, both the PEP and PDP
is expected to clean up any outstanding state related to any
pervious request/decision exchanges. Additionally, the PEP should
continuously attempt to contact the primary PDP or, if unsuccessful,
any known backup PDPs. If a PEP is in communication with a backup
PDP and the primary PDP becomes available, the backup PDP should
redirect the PEP back to the primary PDP (via a close/redirect
message for the affected client-type).
2.4 Client Handle Usage
The client handle is used to identify a unique request state. Client
handles are chosen by the PEP and are opaque to the PDP. The PDP
simply uses the request handle to uniquely identify the request
state and generically tie its decisions to a corresponding request.
Client handles are initiated in request messages and are then used
by subsequent request, decision, and report messages to reference
the same request state. When the PEP is ready to remove a local
request state, it will issue a delete message to the PDP for the
corresponding client handle. A handle MUST be explicitly deleted by
the PEP before it can be used to identify a new request state.
Handles referring to different request states must be unique.
3. Message Content 3. Message Content
This section describes the basic messages exchanged between a PEP This section describes the basic messages exchanged between a PEP
and a remote PDP as well as their contents. and a remote PDP as well as their contents.
3.1 Request (REQ) PEP -> PDP 3.1 Request (REQ) PEP -> PDP
The PEP establishes a request state handle for which the remote PDP The PEP establishes a request state client handle for which the
may maintain a state. The remote PDP then uses this handle to refer remote PDP may maintain a state. The remote PDP then uses this
to the exchanged information and decisions. handle to refer to the exchanged information and decisions.
Once a stateful handle is established for a new request, any Once a stateful handle is established for a new request, any
subsequent modifications of the request can be made using the REQ subsequent modifications of the request can be made using the REQ
message specifying the previously installed handle. The PEP is message specifying the previously installed handle. The PEP is
responsible for notifying the PDP whenever its local state changes responsible for notifying the PDP whenever its local state changes
so the PDP's state will mirror the PEP's state. so the PDP's state will be able to accurately mirror the PEP's
state.
The format of the Request message is as follows: The format of the Request message is as follows:
<Request> ::= <Common Header> <Request> ::= <Common Header>
<Handle> <Client Handle>
<Context> <Context>
[<IN-Int>] [<IN-Int>]
[<OUT-Int>] [<OUT-Int>]
<ClientSI> <ClientSI(s)>
[<list of HandleRefs>]
[<LDPDecision>] [<LDPDecision>]
The context object is used to determine the context within which all The context object is used to determine the context within which all
the other objects are to be interpreted. It also is used to the other objects are to be interpreted. It also is used to
determine the kind of response to be returned from the policy determine the kind of decision to be returned from the policy
server. This response might be related to admission control, server. This decision might be related to admission control,
resource allocation, or object forwarding and substitution. resource allocation, object forwarding and substitution, or
configuration.
The interface objects are used to determine the corresponding The interface objects are used to determine the corresponding
interface on which a signaling protocol message was received or is interface on which a signaling protocol message was received or is
about to be sent. They are only used if the client is participating about to be sent. They are typically used if the client is
along the path of a signaling protocol. participating along the path of a signaling protocol or if the
client is requesting configuration data for a particular interface.
ClientSI (C-Type = 1), the client specific information object holds
the client type specific data for which a policy decision needs to
be made.
The handle reference objects are used to refer to state information ClientSI, the client specific information object holds the client-
currently installed on the PDP that is associated with the current type specific data for which a policy decision needs to be made. In
request. the case of configuration, the named clientSI may include named
information about the module, interface, or functionality to be
configured.
Finally, LDPDecision object holds information regarding the local Finally, LDPDecision object holds information regarding the local
decision made by the LDP. decision made by the LDP.
3.2 Response (RES) PDP -> PEP 3.2 Decision (DEC) PDP -> PEP
The PDP responds to the REQ with a RES message that includes the The PDP responds to the REQ with a DEC message that includes the
associated handle and the decision. If there was a protocol error an associated client handle and one or more decision objects. If there
error object is returned instead. was a protocol error an error object is returned instead.
In order to avoid the issue of keeping track of which Request a It is assumed that the first decision for a new/updated request will
particular response belongs to, it is important that, for a given set the solicited decision flag. This avoids the issue of keeping
handle, there be at most one outstanding response per query. This track of which updated request (that is, a request reissued for the
essentially means that the PEP should not issue more than one same handle) a particular decision corresponds. It is important
REQ(for a given handle) before it receives a corresponding RES. To that, for a given handle, there be at most one outstanding solicited
avoid deadlock, the client can always timeout after issuing a decision per request. This essentially means that the PEP should not
request. It can then delete the timed-out handle, and try again issue more than one REQ (for a given handle) before it receives a
using a different (new) handle. corresponding DEC with the solicited decision flag set.
The format of the Response message is as follows: To avoid deadlock, the client can always timeout after issuing a
request. It must then delete the timed-out handle, and possibly try
again using a different (new) handle.
<Response> ::= <Common Header> The format of the Decision message is as follows:
<Handle>
<Decision> ::= <Common Header>
<Client Handle>
<Context>
<Decision(s)> || <Error> <Decision(s)> || <Error>
The response may include either an Error object or one or more The decision may include either an Error object or one or more
decision objects. COPS protocol problems are reported in the Error decision objects. COPS protocol problems are reported in the Error
object (e.g. an error with the format of the original request). object (e.g. an error with the format of the original request).
Decision object(s) depend on the context of the associated request Decision object(s) depend on the context and the type of client.
and the type of client.
3.3 Unsolicited Response (USR) PDP -> PEP
The remote PDP can also send an unsolicited response to a PEP to
report a different response than the one previously communicated.
For example, the PDP may admit a new flow and change its mind to
reject it sometime later. The change of mind is communicated using
the USR message.
The format for an USR is the same as that for a RES and similarly,
it dependents on the context of the original request.
3.4 Report State (RPT) PEP -> PDP 3.3 Report State (RPT) PEP -> PDP
This message is used by the PEP to communicate a change in the This message is used by the PEP to communicate a change in the
status of a previously installed request state to the server. A status of a previously installed state to the PDP. A commit or no-
commit or no commit report indicates to the PDP that a particular commit report-type indicates to the PDP that a particular policy
policy directive has or has not been acted upon as is relevant for directive has or has not been acted upon as is relevant for
accounting purposes. (In RSVP this would mean that a reservation accounting purposes. (In RSVP this would mean that a reservation
passed or failed local capacity admission control). passed or failed local capacity admission control. For a
configuration decision, it would mean the decision data either could
or could not be installed by the PEP).
The Report State may also be used to provide periodic updates of The Report State may also be used to provide periodic updates of
client specific information for accounting and state monitoring client specific information for accounting and state monitoring
purposes depending on the type of the client. In such cases the purposes depending on the type of the client. In such cases the
accounting report type should be specified utilizing the client accounting report type should be specified utilizing the client
specific information object (C-Type = 2). specific information object.
<Report State> ::== <Common Header> <Report State> ::== <Common Header>
<Handle> <Client Handle>
<Report-Type> <Report-Type>
[ <Client Specific Information> ] [<ClientSI(s)>]
3.5 Delete Request State (DRQ) PEP -> PDP 3.4 Delete Request State (DRQ) PEP -> PDP
This message indicates to the remote PDP that the request state is When sent from the PEP this message indicates to the remote PDP that
no longer available in the PEP and must be deleted. This will be the state identified by the client handle is no longer
used by the remote PDP to initiate the appropriate housekeeping available/relevant. This information will then be used by the remote
actions. The reason code object is interpreted with respect to the PDP to initiate the appropriate housekeeping actions. The reason
client type. code object is interpreted with respect to the client-type and
signifies the reason for the removal.
The format of the Delete Request State message is as follows: The format of the Delete Request State message is as follows:
<Delete Request> ::= <Common Header> <Delete Request> ::= <Common Header>
<Handle> <Client Handle>
<Reason> <Reason>
Given the stateful nature of COPS, it is important that when a Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for request state is finally removed from the PEP, a DRQ message for
this request state is sent to the PDP so the corresponding state may this request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly likewise be removed on the PDP. Request states not explicitly
deleted by the PEP will be maintained by the PDP until either the deleted by the PEP will be maintained by the PDP until either the
client session is closed or the connection is terminated. client session is closed or the connection is terminated.
3.6 Synchronize State Request (SSQ) PDP -> PEP 3.5 Synchronize State Request (SSQ) PDP -> PEP
The format of the Synchronize State Query message is as follows: The format of the Synchronize State Query message is as follows:
<Synchronize State> ::= <Common Header> <Synchronize State> ::= <Common Header>
[<Handle>] [<Client Handle>]
This message indicates that the remote PDP wishes the client (which This message indicates that the remote PDP wishes the client (which
appears in the common header) to re-send its state. If the optional appears in the common header) to re-send its state. If the optional
Handle is present, only the state associated with this handle is Client Handle is present, only the state associated with this handle
synchronized. If the client does not recognize the requested handle, is synchronized. If the PEP does not recognize the requested handle,
it should immediately send a DRQ message to the PDP for the handle it should immediately send a DRQ message to the PDP for the handle
that was specified in the SSQ message. If no handle is specified in that was specified in the SSQ message. If no handle is specified in
the SSQ message, all the active client state should be synchronized the SSQ message, all the active client state should be synchronized
with the PDP. with the PDP.
The client performs state synchronization by re-issuing request The client performs state synchronization by re-issuing request
queries of the specified client type for the existing state in the queries of the specified client-type for the existing state in the
PEP. PEP. When synchronization is complete, the PEP must issue a
synchronize state complete message to the PDP.
3.7 Client-Open (OPN) PEP -> PDP 3.6 Client-Open (OPN) PEP -> PDP
The Client-Open message can be used by the PEP to specify to the PDP The Client-Open message can be used by the PEP to specify to the PDP
the client types the PEP can support, a *suggested* time interval the client-types the PEP can support, a *suggested* time interval
for keep-alive messages, or client specific feature negotiation. A for keep-alive messages, and/or minimum time intervals for
accounting updates, and/or client specific feature negotiation. A
Client-Open message can be sent to the PDP at any time and multiple Client-Open message can be sent to the PDP at any time and multiple
Client-Open messages for the same client type are allowed (in case Client-Open messages for the same client-type are allowed (in case
of global state changes). of global state changes).
<Client-Open> ::= <Common Header> <Client-Open> ::= <Common Header>
<PEPID> <PEPID>
[<Timer>] [<KA Timer>]
[<ClientSI>] [<ACCT Timer>]
[<Client ClientSI>]
The PEPID is a symbolic, variable length name that identifies the The PEPID is a symbolic, variable length name that identifies the
specific client to the PDP. Values for the PEPID are configurable by specific client to the PDP. Values for the PEPID are configurable by
administrators of administrative domains and are of direct administrators of administrative domains and are of direct
significance to the COPS protocol. By default, the PEPID specifies significance to the COPS protocol. By default, the PEPID specifies
the primary IP address in the form of a string for the PEP in the primary IP address in the form of a string for the PEP in
question. question.
If included, the timer corresponds to PEP's preference for the If included, the timer corresponds to PEP's preference for the
maximum intermediate time between the generation of messages for maximum intermediate time between the generation of messages for
connection verification. connection verification and/or the minimum time interval between
periodic accounting reports.
Finally, a ClientSI (C-Type = 3) object can be included for relaying Finally, a named ClientSI object can be included for relaying
global information about the PEP to the PDP when required (as additional global information about the PEP to the PDP when required
specified in the appropriate extensions document). (as specified in the appropriate extensions document for the client-
type).
3.8 Client-Accept (CAT) PDP -> PEP 3.7 Client-Accept (CAT) PDP -> PEP
The Client-Accept message is used to positively respond to the The Client-Accept message is used to positively respond to the
Client-Open message. This message will return to the PEP a timer Client-Open message. This message will return to the PEP a timer
object indicating the expected time interval between keep-alive object indicating the maximum time interval between keep-alive
messages. messages. Optionally, a timer specifying the minimum allowed
interval between accounting report messages may be included when
applicable.
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
<Timer> <KA Timer>
[<ACCT Timer>]
If the PDP refuses the client, it will instead issue a Client-Close If the PDP refuses the client, it will instead issue a Client-Close
message. message.
The timer corresponds to maximum acceptable intermediate time The KA Timer corresponds to maximum acceptable intermediate time
between the generation of messages by the PDP and PEP. The timer between the generation of messages by the PDP and PEP. The timer
value is determined by the PDP taking into account the client's value is determined by the PDP taking into account the client's
preference established with the OPN message. A timer value of 0 preference established with the OPN message. A timer value of 0
implies no secondary connection verification is necessary. implies no secondary connection verification is necessary.
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP The optional accounting timer allows the PDP to indicate to the PEP
that periodic accounting reports should not exceed the specified
timer interval. This allows the PDP to control the rate at which
accounting reports are sent by the PEP (when applicable).
3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message only needs to be transmitted when there has The keep-alive message only needs to be transmitted when there has
been no activity between the client and server for a period been no activity between the client and server for a period
approaching half that of the minimum of all timer values negotiated approaching half that of the minimum of all timer values negotiated
with the OPN & CAT messages. It is a validation for each side that with the OPN & CAT messages. It is a validation for each side that
the connection is still functioning. the connection is still functioning.
Note: The client type in the header should always be set to 0 as the Note: The client-type in the header should always be set to 0 as the
KA is used for connection verification (not per client session KA is used for connection verification (not per client session
verification). verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
Both client and server may assume the connection is insufficient for Both client and server may assume the connection is insufficient for
the client type with the minimum time value (specified in the CAT the client-type with the minimum time value (specified in the CAT
message) if no communication activity is detected for a period message) if no communication activity is detected for a period
exceeding the timer period. For the PEP, such detection implies the exceeding the timer period. For the PEP, such detection implies the
remote PDP or connection is down and the PEP should now attempt to remote PDP or connection is down and the PEP should now attempt to
use an alternative/backup PDP. use an alternative/backup PDP.
3.10 Client-Close (CC) PEP -> PDP, PDP -> PEP 3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being notify the other that a particular type of client is no longer being
supported. supported.
<Client-Close> ::= <Common Header> <Client-Close> ::= <Common Header>
[<Error>] [<Error>]
[<PDPAddr>] [<PDPAddr>]
An Error object is optionally included to describe the reason for An Error object is optionally included to describe the reason for
the close due to an error condition (e.g. requested client type is the close due to an error condition (e.g. requested client-type is
not supported by the remote PDP or client failure). not supported by the remote PDP or client failure).
A PDP may optionally include a PDP-Address object in order to inform A PDP may optionally include a PDP-Address object in order to inform
the PEP of the alternate PDP it should use for the client type the PEP of the alternate PDP it should use for the client-type
specified in the common header. specified in the common header.
3.10 Synchronize State Complete (SSC) PEP -> PDP
The Synchronize State Complete is sent by the PEP to the PDP after
the PDP sends a synchronize state request to the PEP and the PEP has
finished synchronization. It is useful so that the PDP will know
when all the old client state has been successfully re-requested
and, thus, the PEP and PDP are completely synchronized.
<Synchronize State Complete> ::= <Common Header>
4. Common Operation 4. Common Operation
This section describes the typical exchanges between remote PDP This section describes the typical exchanges between remote PDP
servers and PEP clients. servers and PEP clients.
Sometime after a connection is established between the PEP and a Sometime after a connection is established between the PEP and a
remote PDP, the PEP will send one or more Client-Open messages to remote PDP, the PEP will send one or more Client-Open messages to
the remote PDP, at least one for each client type supported by the the remote PDP, at least one for each client-type supported by the
PEP. The open message should contain the common header noting one PEP. The open message should contain the common header noting one
client type supported by the PEP. The remote PDP will then respond client-type supported by the PEP. The remote PDP will then respond
with a Client-Accept message echoing back each of the client types with a Client-Accept message echoing back each of the client-types
the PEP supports that it can support as well. If a specific client the PEP supports that it can support as well. If a specific client-
type is not supported by the PDP, the PDP will instead respond with type is not supported by the PDP, the PDP will instead respond with
a Client-Close specifying the client type is not supported, and a Client-Close specifying the client-type is not supported and will
possibly suggesting an alternate PDP address. Otherwise, the PDP possibly suggest an alternate PDP address. Otherwise, the PDP will
will specify the timer interval between keep-alive messages in its specify the timer interval between keep-alive messages in its
Client-Accept and the PEP can begin issuing requests to the PDP. Client-Accept and the PEP can begin issuing its requests to the PDP.
When the PEP receives an event that requires a new policy decision In the outsourcing scenario, when the PEP receives an event that
it sends a request message to the remote PDP. The remote PDP then requires a new policy decision it sends a request message to the
makes a decision and sends a response back to the PEP. Since the remote PDP. What specifically qualifies as an event for a particular
request is stateful, the request will be remembered, or installed, client-type should be specified in the specific document for that
on the remote PDP. The unique handle, specified in both the request client-type. The remote PDP then makes a decision and sends a
and its corresponding response identifies this request state. The decision message back to the PEP. Since the request is stateful, the
PEP is responsible for deleting this request state once the request request will be remembered, or installed, on the remote PDP. The
is no longer applicable. unique handle, specified in both the request and its corresponding
decision identifies this request state. The PEP is responsible for
deleting this request state once the request is no longer
applicable.
The PEP can update a previously installed request state by reissuing The PEP can update a previously installed request state by reissuing
a request for the previously installed handle. The remote PDP is a request for the previously installed handle. The remote PDP is
then expected to make new decisions and send a response back to the then expected to make new decisions and send a decision message back
PEP. Likewise, the server may change a previously issued decision on to the PEP. Likewise, the server may change a previously issued
any currently installed request state at any time by issuing an decision on any currently installed request state at any time by
asynchronous response. At all times the PEP module is expected to issuing another decision message. At all times the PEP module is
abide by the PDP's decisions and notify the PDP on state changes. expected to abide by the PDP's decisions and notify the PDP of any
state changes.
The PEP may also notify the remote PDP of the local status of an Likewise, in the configuration scenario, the PEP will make a
installed request using the report message where appropriate. The configuration request to the PDP for a particular interface, module,
report message is to be used to signify when billing should or functionality that may be specified in the named client specific
effectively begin, or to produce periodic updates for monitoring and information object. The PDP will then send potentially several
accounting purposes depending on the client. This message can carry decisions containing named units of configuration data to the PEP.
client specific information when needed. The PEP is expected to install and use the configuration locally. A
particular named configuration can be updated by simply sending
additional decision messages for the same named configuration. When
the PDP no longer wishes the PEP to use a piece of configuration
information, it will send a decision message specifying the named
configuration and a decision flags object with the remove
configuration flag set. The PEP should then proceed to remove the
corresponding configuration and send a report message to the PDP
that specifies it has been deleted.
To validate the connection between the client and server is still In all cases, the PEP may notify the remote PDP of the local status
functioning, the keep-alive message is used. If no COPS message is of an installed state using the report message where appropriate.
generated within one half the minimum timer value interval, a keep- The report message is to be used to signify when billing should
alive message needs to be generated. Both the PEP and remote PDP are begin, what actions were taken, or to produce periodic updates for
expected to follow this procedure. monitoring and accounting purposes depending on the client. This
message can carry client specific information when needed.
Finally, Client-Close messages are used to negate the affects of the The keep-alive message is used to validate the connection between
the client and server is still functioning when there is no other
messaging between the PEP and PDP. The PEP must generate a COPS
message within one half the negotiated minimum timer interval or
else a keep-alive message must be generated. Likewise, the PDP must
either have sent a COPS message to every connected PEP within half
the negotiated minimum timer interval or a keep-alive must be
issued. If either side does not receive a keep-alive or any other
COPS message within the negotiated timer interval from the other,
the connection should be considered lost.
Finally, Client-Close messages are used to negate the effects of the
corresponding Client-Open messages, notifying the other side that corresponding Client-Open messages, notifying the other side that
the specified client type is no longer supported/active. the specified client-type is no longer supported/active.
5. Security 5. Security
The security of RSVP messages is provided by inter-router MD5 The security of RSVP messages is provided by inter-router MD5
authentication [MD5]. This assumes a chain-of-trust model for inter authentication [MD5]. This assumes a chain-of-trust model for inter
PEP authentication. Security between the client (PEP) and server PEP authentication. Security between the client (PEP) and server
(PDP) is provided by IPSEC [IPSEC]. (PDP) is provided by IPSEC [IPSEC].
To ensure the client (PEP) is communicating with the correct policy To ensure the client (PEP) is communicating with the correct policy
server (PDP) involves two issues: authentication of the policy server (PDP) involves two issues: authentication of the policy
client and server using a shared secret, and consistent proof that client and server using a shared secret, and consistent proof that
the connection remains valid. The shared secret requires manual the connection remains valid. The shared secret requires manual
configuration of keys, which is a maintenance issue. IPSEC AH may be configuration of keys, which is a maintenance issue. IPSEC AH may be
used for the validation of the connection; IPSEC ESP may be used to used for the validation of the connection; IPSEC ESP may be used to
provide both validation and secrecy. provide both validation and secrecy.
6. Open issues 6. Open issues
6.1 Bi-directional Connection Establishment:
Currently, only the PEP is supposed to connect with the PDP. It
might be useful to have the PDP proactive in establishing
connections with its PEPs (via a separate COPS PEP port). Such would
potentially simplify PEP configuration and allow a primary PDP that
has failed to notify its clients that it is functional again. Such
functionality will be specified in the appropriate COPS Extensions
document. In the meantime, PEPs should at least be locally
configured to connect to their appropriate Primary PDP/Backup PDP.
6.2 RSVP Object Replacement:
Should the PDP be capable of directing the RSVP PEP to replace other
objects than the Policy Data object (e.g. FlowSpec)? If so, which
RSVP objects and for which request types?
6.3 RSVP Policy Data Priority Element Definition.
The object format of the Policy Data Element for Priority
representation will be described in another document.
7. References 7. References
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September Version 1 - Functional Specification", RFC 2205, September
1997. 1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission
Control", Internet-Draft, draft-ietf-rap-framework-00.txt, Control", Internet-Draft, draft-ietf-rap-framework-00.txt,
November 1997. November 1997.
skipping to change at page 23, line 12 skipping to change at page 26, line 12
Representation for RSVP", Internet-Draft, draft-ietf-rap- Representation for RSVP", Internet-Draft, draft-ietf-rap-
user-identity-00.txt, March 1998. user-identity-00.txt, March 1998.
8. Author Information and Acknowledgments 8. Author Information and Acknowledgments
Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar,
Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan,
and Dimitrios Pendarakis for their valuable contributions. and Dimitrios Pendarakis for their valuable contributions.
Jim Boyle Ron Cohen Jim Boyle Ron Cohen
MCI Class Data Systems Level 3 Communications Cisco Systems
2100 Reston Parkway 13 Hasadna St. 1450 Infinite Drive13 Hasadna St.
Reston, VA 20191 Ra'anana 43650 Israel Louisville, CO 80027 Ra'anana 43650 Israel
703.715.7006 972.9.7462020 303.926.3100 972.9.7462020
jboyle@mci.net ronc@classdata.com email: jboyle@l3.net ronc@classdata.com
David Durham Raju Rajan David Durham Raju Rajan
Intel IBM T.J. Watson Research Cntr Intel IBM T.J. Watson Research Cntr
2111 NE 25th Avenue P.O. Box 704 2111 NE 25th Avenue P.O. Box 704
Hillsboro, OR 97124 Yorktown Heights, NY 10598 Hillsboro, OR 97124 Yorktown Heights, NY 10598
503.264.6232 914.784.7260 503.264.6232 914.784.7260
David_Durham@mail.intel.com raju@watson.ibm.com David_Durham@mail.intel.com raju@watson.ibm.com
Shai Herzog Arun Sastry Shai Herzog Arun Sastry
IPHighway Cisco Systems IPHighway Cisco Systems
2055 Gateway Pl., Suite 400 506210 W Tasman Drive 2055 Gateway Pl., Suite 400 506210 W Tasman Drive
San Jose, CA 95110 San Jose, CA 95134 San Jose, CA 95110 San Jose, CA 95134
408.390.3045 408.526.7685 408.390.3045 408.526.7685
herzog@iphighway.com asastry@cisco.com herzog@iphighway.com asastry@cisco.com
Appendix A. COPS Extensions for Use with RSVP
A.1 Overview of COPS extensions for RSVP
Building on the foundations described in the previous sections this
section describes the specific functionality required for this
protocol to support policy control over RSVP.
Setting the client type in the COPS common header to 1 indicates an
RSVP client capable of performing admission control and policy data
substitution using RSVP V1 objects.
A.2 COPS objects for use with RSVP
The COPS objects defined in section 2.2 are applicable to RSVP
policy control, and their use is described in the text that follows.
The message type information found in the RSVP message header is
represented by the M-Type in the COPS Context Object.
All objects contained within RSVP messaging are expected to be
encapsulated in the Client Specific Information Object without
alteration. Multiple RSVP objects may be contained within a single
Client Specific Information Object exchanged between the PEP and
remote PDP.
In support of the verification integrity of incoming RSVP messages,
the COPS protocol may optionally return a security key in the Client
Specific Decision Data object (C-Type = 4) useful for future
integrity checks by the PEP. Refer to the document on User Identity
Representation for RSVP [UserID] for details on the format and
application of this security key when supported by the PEP.
Finally, for the COPS outgoing message responses, RSVP objects may
be returned to the PEP from the remote PDP via the Replacement Data
Decision Object. This object may contain multiple RSVP objects, but
is primarily concerned with returning the Policy Data object.
Objects included in the Replace Data Decision Object are to replace
their corresponding object in the RSVP message (typically for
outgoing RSVP messages).
A.3. Operation of COPS for Policy Control Over RSVP
A.3.1 RSVP values for the Context Object (Context)
The semantics of the Context object for RSVP is as follows:
R-Type (Request Type Flag)
0x01 = Incoming-Message request
The arrival of an incoming RSVP message
Allows processing of incoming policy information as well as
the decision whether to accept an incoming message. If It is
rejected, the message is treated as if it never Arrived.
0x02 = Resource-Allocation request
Applies only for Resv messages.
The decision whether to admit a reservation and commit local
resources to it is performed for the merge of all
reservations that arrived on a particular interface
(potentially from several Previous Hops).
0x04 = Outgoing-Message request
The forwarding of an outgoing RSVP message.
The Decision whether to allow the forwarding of an outgoing
RSVP message as well as providing the relevant outgoing
policy information.
M-Type (Message Type)
The M-Type field in the Context Object may have one of the
Following values that correspond to supported RSVP messages
In COPS:
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
Note: The PathTear, ResvTear, and the Resv Confirm message types are
not supported.
A.3.2 RSVP flows
Policy Control is performed per RSVP flow. An RSVP flow corresponds
to an atomic unit of reservation as identified by RSVP (TC
reservation). It should be noted that RSVP allows multiple flows to
be packed (which is different from merged) into a single FF Resv
message. To support such messages a separate COPS request must be
issued for each of the packed flows as if they were individual RSVP
messages.
A.3.4 Expected Associations for RSVP Requests
RSVP signaling requires the participation of both senders and
receivers. RSVP processing rules define what is the subset of the
Path state that matches each Resv state. In the common unicast case,
the RSVP session includes one Path state and one Resv state. In
multicast cases the correspondence might be many to many. Since the
decision to admit a reservation for a session may depend on
information carried both in Path and Resv messages, we term the Path
States that match with a single Resv state as its associated states.
It is assumed that the PDP is capable of determining these
associations based on the RSVP message processing rules given the
RSVP objects expressed in the COPS Client Specific Information
Object.
A.3.5 RSVP's Capacity Admission Control: Commit and Delete
In RSVP, the admission of a new reservation requires both an
administrative approval (policy control) and capacity admission
control. Once local admission control accepts the reservation, the
PEP notifies the remote PDP by sending a report message specifying
the Commit type. The Commit type report message is to be used to
signify when billing should effectively begin, and performing
heavier operations (e.g., debiting a credit card) is permissible.
If instead a reservation approved by the PDP fails admission due to
lack of resources, the PEP must notify the PDP by issuing a delete
message.
A.3.6 Policy Control Over Path and Resv Tear
Path and Resv Tear messages are not controlled by this policy
architecture. This relies on two assumptions: First, that MD-5
authentication verifies that the Tear is received from the same node
that sent the initial reservation, and second, that it is
functionally equivalent to that node holding-off refreshes for this
reservation. When a Resv or Path Tear is received at the PEP, all
affected states installed on the PDP should either be deleted or
updated by the PEP.
A.3.7 PEP Caching COPS Decisions
Because COPS is a stateful protocol, refreshes for RSVP Path and
Resv messages need not be constantly sent to the remote PDP. Once a
decision has been returned for a request, the PEP can cache that
decision and apply it to future refreshes. The PEP is only
responsible for updating a request state if there is a change
detected in the corresponding Resv or Path message.
A.3.8 Data Expected in Request Messages for RSVP Support
The information required in a RSVP request for each applicable
message type and request type combination is outlined below:
In, Path -
<handle><context: in, Path><in-interface>
<client info: all objects in Path message>
Out, Path -
<handle><context: out, Path><out-interface>
<client info: all objects in outgoing Path message>
In & Out (unicast combined request), Path -
<handle><context: in & out, Path><in-interface>
<out-interface>
<client info: all objects in Path message>
In, Resv -
<handle><context: in, Resv><in-interface>
<client info: all objects in Resv message>
Merge, Resv -
<handle><context: merge, Resv><in-interface>
<client info: all objects in merged Resv message including
the merged FLOWSPEC object>
Out, Resv -
<handle><context: out, Resv><out-interface>
<client info: all objects in outgoing Resv message>
In & Merge (combined request, PEP can merge), Resv -
<handle><context: in & merge, Resv><in-interface>
<client info: all objects in Resv message>
In & Merge & Out (unicast combined request), Resv -
<handle><context: in & merge & out, Resv><in-interface>
<out-interface>
<client info: all objects in Resv message>
In, PathErr -
<handle><context: in, PathErr><in-interface>
<client info: all objects in PathErr message>
Out, PathErr -
<handle><context: out, PathErr><out-interface>
<client info: all objects in outgoing PathErr message>
In & Out (unicast combined request), PathErr -
<handle><context: in & out, PathErr><in-interface>
<out-interface>
<client info: all objects in PathErr message>
In, ResvErr -
<handle><context: in, ResvErr><in-interface>
<client info: all objects in ResvErr message>
Out, ResvErr -
<handle><context: out, ResvErr><out-interface>
<client info: all objects in outgoing ResvErr message>
In & Out (unicast combined request), ResvErr
<handle><context: in & out, ResvErr><in-interface>
<out-interface>
<client info: all objects in ResvErr message>
A.3.9 Expected Decisions for RSVP Requests
The expected decision information relative to a request for each
applicable message type and request type combination is outlined
below ([optional]):
In, Path -
<handle><Decision Flags>[<Decision Data: Security Key>]
Out, Path -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), Path -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
[<Decision Data: Security Key>]
In, Resv -
<handle><Decision Flags>[<Decision Data: Security Key>]
Merge, Resv -
<handle><Decision Flags>[<Decision Priority>]
Out, Resv -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Merge (combined request, PEP can merge), Resv -
<handle><Decision Flags>[<Decision Priority>][<Decision
Data: Security Key>]
In & Merge & Out (unicast combined request), Resv -
<handle><Decision Flags>[<Decision Priority>]
[<DecisionReplacement: policy data>][<Decision Data:
Security Key>]
In, PathErr -
<handle><Decision Flags>
Out, PathErr -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), PathErr -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
In, ResvErr -
<handle><Decision Flags>
Out, ResvErr -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), ResvErr -
<handle><Decision Flags>[<DecisionReplacement: policy data>]
A.4 Illustrative Examples, Using COPS for RSVP
A.4.1 Unicast Flow Example
This section details the steps in using COPS for controlling a
Unicast RSVP flow. It details the contents of the COPS messages
with respect to the following figure.
PEP (router)
+-----------------+
| |
R1 ------------+if1 if3+------------ S1
| if2 |
+--------+--------+
|
|
PDP (server)
figure 1: Unicast Example: a single router view
The PEP router has three interfaces (1,2,3). Sender S1 sends to
receiver R1.
A Path message arrives from S1:
PEP --> PDP REQ := <Handle A><Context in&out, Path>
<In-Interface if3> <Out-Interface if1>
<ClientSI: all objects in Path message>
PDP --> PEP RES := <Handle A><Decision accept>
A Resv message arrives from R1:
PEP --> PDP REQ := <Handle B><Context in&merge&out, Resv>
<In-Interface if1> <Out-Interface if3>
<ClientSI: all objects in Resv message>
PDP --> PEP RES := <Handle B>
<Decisions: accept, Priority=7,
Replace: POLICY.DATA1>
PEP --> PDP RPT := <Handle B>
<Report type: commit>
Time Passes, the PDP changes its decision:
PDP --> PEP USR := <Handle B>
<Decisions: accept, Priority=3,
Replace: POLICY.DATA2>
Because the priority is too low, the PEP preempts the flow:
PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted>
Time Passes, the sender S1 ceases to send Path messages:
PEP --> PDP DRQ := <Handle A>
<Reason: Timeout>
A.4.2 Shared Multicast Flows
This section details the steps in using COPS for controlling a
multicast RSVP flow. It details the contents of the COPS messages
with respect to the following figure.
-----------------
r1 | |
H1-------------|i1 | r4
| o1 |---------------- S1
r2 | Router |
H2 ------------|i2 |
| | o2 |---------------- S2
| r3 | |
| -----------------
H3
figure 1: 2 senders and 3 receivers
Figure 1 shows an RSVP router which has two senders and three
receivers for the same multicast session. Interface i2 is connected
to a shared media.
First detailed is the request message content for a Path sent by
sender S1, assuming that both receivers have already joined the
multicast session, but haven't sent a Resv message as yet. Assume
sender S2 has not yet sent a path message. The Path message arrives
on interface o1:
PEP -----> PDP REQ := <handle A><context in, Path>
<in-interface o1><client info: all
objects in Path message>
PDP -----> PEP RES := <handle A><Decision accept>
Here the PDP decides to allow the Path message. Next, the Router
consults its forwarding table, and finds two outgoing interfaces,
i1 and i2, for the path. The exchange below is for interface i1,
another exchange would likewise be completed for i2 using the new
handle B2.
PEP -----> PDP REQ := <handle B1><context out, Path>
<out-interface i1><client info: all
objects in outgoing Path message>
PDP -----> PEP RES := <handle B1><Decision forward>
<Decision replacement object:
policy object>
Here, the PDP decided to allow the forwarding of the Path message
via interface i1, and determined the appropriate policy objects for
the message going out on this interface.
Next, the receiver r2 sends a Resv message of WF style. The Resv
arrives on interface i2. Here the PEP queries the PDP which decides
to accept this reservation with priority 5 as shown below.
PEP -----> PDP REQ := <handle C><context in, Resv>
<in-interface i2><client info: all
objects in Resv message>
PDP -----> PEP RES := <handle C><Decision accept>
This assumes the PEP is not itself capable of merging priority
information, and, thus, must make another query for the incoming
interface merge.
PEP -----> PDP REQ := <handle D><context merge, Resv>
<in-interface i2><client info: all
objects in merged Resv message>
PDP -----> PEP RES := <handle D><Decision Priority: 5>
After PEP successfully admitted the reservation it sends a report
message that signals to the PDP that it can start an accounting log
for this reservation.
PEP -----> PDP RPT := <handle D>
<commit>
The reservation r2 needs to be sent upstream towards sender S1 out
interface o1. An outgoing Resv request is made which carries the
associated handle of the Path message for which this Resv is being
forwarded.
PEP -----> PDP REQ := <handle E><context out,Resv>
<out-interface o1><client info: all
objects in outgoing Resv message>
PDP -----> PEP RES := <handle E><Decision forward><Decision
replacement object: policy object>
Next, receiver H3 sends the Resv message r3. The PEP sends an
incoming request for handle F and the PDP decides to accept the Resv
(as before). The new reservation also requires the PEP to update the
merged request (handle D) due to the modified flowspec. The PDP now
gives this request priority 7. If accepted by local admission
control, a report is again sent.
PEP -----> PDP REQ := <handle D><context merge, Resv>
<in-interface i2><client info: all
objects in merged Resv message w/
new merged FLOWSPEC>
PDP -----> PEP RES := <handle D><Decision priority 7>
PEP -----> PDP RPT := <handle D>
<commit>
Now the outgoing request for handle E is reissued for the merged (R2
& R3) outgoing Resv to be sent towards sender S1 due to a modified
flowspec.
PEP -----> PDP REQ := <handle E><context out,Resv>
<out-interface o1><client info: all
objects in outgoing Resv message w/
new merged FLOWSPEC>
PDP -----> PEP RES := <handle E><Decision forward><Decision
replacement object: policy object>
When S2 joins the session by sending a Path message, incoming and
outgoing Path requests are issued for the new Path. The two incoming
Resv requests may then be reissued for handle C and handle E if
there is a change in their shared sender filter list (for SE
filters) specifying the new sender. A new outgoing Resv request
would then be issued for the Resv to be sent to s2 out interface o2.
 End of changes. 

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