On this page
|
| SUMMARY | |
| Protocol |
: |
Common Open Policy Service |
| Protocol suite |
: |
TCP/IP |
| Layer |
: |
Application Layer |
| SNMP MIBs |
: |
iso.org.dod.internet.mgmt.mib-2.copsClientMIB (1.3.6.1.2.1.89). |
| Ports |
: |
3288 (TCP) |
| Related protocols |
: |
TCP,
RSVP |
| Working groups |
: |
RAP, Resource Allocation Protocol |
|
| DESCRIPTION |
The Common Open Policy Service (COPS) Protocol is part of the internet protocol suite as defined by the IETF RFC 2748.
COPS specifies a simple client/server model for supporting policy control over Quality of Service (QoS) signaling protocols (e.g. RSVP). Policies are stored on servers, also known as Policy Decision Points (PDP), and are enforced on clients, also known as Policy Enforcement Points (PEP).
There are two "flavors", or models of COPS: The Outsourcing Model and the Provisioning Model. The Outsourcing Model is the simplest flavor of COPS. In this model, all policies are stored at the PDP. Whenever the PEP needs to make a decision, it sends all relevant information to the PDP. The PDP analyzes the information, takes the decision, and relays it to the PEP. The PEP then simply enforces the decision.
In the Provisioning Model, the PEP reports its decision-making capabilities to the PDP. The PDP then downloads relevant policies on to the PEP. The PEP can then make its own decisions based on these policies. The Provisioning Model uses the Policy Information Base as a repository of the policies.
Common header
Each COPS message consists of the COPS header followed by a number of typed objects.
| 4 |
8 | 16 |
32 | | Version |
Flags | Opcode |
Client type |
| Message length |
| Data |
- Version
COPS version number. Current version is 1.
- Flags
Defined flag values (all other flags must be set to 0): 0x1 Solicited Message Flag Bit. This flag is set when the message is solicited by another COPS message. This flag is NOT to be set (value=0) unless otherwise specified in section 3.
- Op Code
| Opcode | Description | | 1 | REQ, Request. | | 2 | DEC, Decision. | | 3 | RPT, Report State. | | 4 | DRQ, Delete Request State. | | 5 | SSQ, Synchronize State Req. | | 6 | OPN, Client-Open. | | 7 | CAT, Client-Accept. | | 8 | CC, Client-Close. | | 9 | KA, Keep-Alive. | | 10 | SSC, Synchronize Complete. |
- Client-type
The Client-type identifies the policy client. Interpretation of all encapsulated objects is relative to the client-type. Client-types that set the most significant bit in the client-type field are enterprise specific (these are client-types 0x8000 - 0xFFFF). For KA Messages, the client-type in the header must always be set to 0 as the KA is used for connection verification (not per client session verification).
- Message Length
Size of message in octets, which includes the standard COPS header and all encapsulated objects. Messages must be aligned on 4 octet intervals.
| Client type | Description | | 0x0001 | RSVP. | | 0x0002 | DiffServ QoS. | | 0x8001-0x8004 | IP Highway. | | 0x8005 | Fujitsu Application Server Software Division. | | 0x8006 | HP OpenView PolicyXpert. | | 0x8007 | HP OpenView PolicyXpert COPS-PR PXPIB. | | 0x8008 | PacketCable Dynamic Quality of Service. | | 0x8009 | COPS usage for 3GPP GO interface. |
COPS Specific Object Formats
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 following format:
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 next 32-bit boundary.
Typically, C-Num identifies the class of information contained in the object, and the C-Type identifies the subtype or version of the information contained in the object.
Communication
The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP implementation per server must listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP is responsible for initiating the TCP connection to a PDP. 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.
If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client-type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform.
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 the following figure.
Multiple PDPs illustration
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it should explicitly send a Client-Close message for each opened client-type containing an object indicating the "Communication Failure" Error-Code. Additionally, the PEP should continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a message containing a object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
Client Handle Usage
The client handle is used to identify a unique request state for a single PEP per client-type. 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 for a particular Client-Type over a particular TCP connection 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 by the PEP to identify a new request state. Handles referring to different request states must be unique within the context of a particular TCP connection and client-type.
Synchronization Behavior
When disconnected from a PDP, 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 have passed local admission control. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message.
After a failure and before a new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some appropriate length of time. Specific rules for such behavior are to be defined in the appropriate COPS client-type extension specifications.
A PEP that caches state from a previous exchange with a disconnected PDP must communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. The object will only be included for the last PDP with which the PEP was completely in sync. If the service interruption was temporary and the PDP still contains the complete state for the PEP, the PDP may choose not to synchronize all states. It is still the responsibility of the PEP to update the PDP of all state changes that occurred during the disruption of service including any states communicated to the previous PDP that had been deleted after the connection was lost. These must be explicitly deleted after a connection is reestablished. If the PDP issues a synchronize request the PEP must pass all current states to the PDP followed by a Synchronize State Complete message (thus completing the synchronization process). If the PEP crashes and loses all cached state for a client-type, it will simply not include a in its Client-Open message.
COPS for RSVP
Common Open Policy Service (COPS) is a protocol for communicating network traffic policy information to network devices. Resource ReSerVation Protocol (RSVP) is a means for reserving network resources！primarily bandwidth！to guarantee that applications transmitting end-to-end across the Internet will perform at the desired speed and quality.
Combined, COPS with RSVP gives network managers centralized monitoring and control of RSVP, including the ability to:
- Ensure adequate bandwidth and jitter & delay bounds for time-sensitive traffic such as voice transmission.
- Ensure adequate bandwidth for multimedia applications such as videoconferencing and distance learning.
- Prevent bandwidth-hungry applications from delaying top priority flows or harming the performance of other applications customarily run over the same network.
In so doing, COPS for RSVP supports the following crucial RSVP features:
- Admission control！The RSVP reservation is accepted or rejected based on end-to-end available network resources.
- Bandwidth guarantee！The RSVP reservation, if accepted, will guarantee that those reserved resources will continue to be available while the reservation is in place.
- Media-independent reservation！An end-to-end RSVP reservation can span arbitrary lower layer media types.
- Data classification！While a reservation is in place, data packets belonging to that RSVP flow are separated from other packets and forwarded as part of the reserved flow.
- Data policing！Data packets belonging to an RSVP flow that exceed the reserved bandwidth size are marked with a lower packet precedence.
|
 Top of Page
|
| EXAMPLES |
|
|
Top of Page
|
| PROTOCOL RELATIONS |
■ Parent layer
■ Child layer
TCP
| | COPS | |
Top of Page
|
| GLOSSARY |
|
COPS
COPS (Common Open Policy Service ) is a protocol for communicating network traffic policy information to network devices. COPS specifies a simple client/server model for supporting policy control over Quality of Service (QoS) signaling protocols.
IETF
IETF (Internet Engineering Task Force) is the main standards organization for the Internet. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.
QoS
QoS (Quality of Service) refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies.
RSVP
RSVP (Resource Reservation Setup Protocol) is a new Internet protocol being developed to enable the Internet to support specified Qualities-of-Service (QoS's). Using RSVP, an application will be able to reserve resources along a route from source to destination.
|
Top of Page
|
| REFERENCES |
RFCs:
[ RFC 2748] The COPS (Common Open Policy Service) Protocol.
Updated by: RFC 4261.
[ RFC 2749] COPS usage for RSVP.
[ RFC 2940] Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients.
Defines SNMP MIB iso.org.dod.internet.mgmt.mib-2.copsClientMIB (1.3.6.1.2.1.89).
[ RFC 3084] COPS Usage for Policy Provisioning (COPS-PR).
[ RFC 3127] Authentication, Authorization, and Accounting: Protocol Evaluation.
[ RFC 3159] Structure of Policy Provisioning Information (SPPI).
[ RFC 3317] Differentiated Services Quality of Service Policy Information Base.
[ RFC 3535] Overview of the 2002 IAB Network Management Workshop.
[ RFC 3571] Framework Policy Information Base for Usage Feedback.
[ RFC 4261] Common Open Policy Service (COPS) Over Transport Layer Security (TLS).
Defines COPS object class = 16, type = 2 (Integrity-TLS).
Updates: RFC 2748.
|
Top of Page
|
| OTHER PROTOCOLS OF TCP/IP SUITE |
|
|
|
|
|
