COPS lays down policy-management law

Policy-enabled networks promise to help net executives more effectively allocate network resources and reduce management overhead. Turning these promises to reality, however, will require several key infrastructure elements.

These elements include policy servers and policy-aware switches, routers and end stations. According to the Internet Engineering Task Force (IETF), policy servers, called Policy Decision Points (PDP), will make most policy decisions. Policy-aware switches and other devices, called Policy Enforcement Points (PEP), will be charged with controlling application access to network resources.

Helping PDPs and PEPs coordinate their policy undertakings - and helping them interoperate, even though they may come from different vendors - will be a protocol, known as the Common Open Policy Service (COPS), now in draft form at the IETF.

COPS will be charged with maintaining communications between the various policy servers and enforcement devices used in LANs. COPS' chief virtue is its ability to maintain "state" between PDPs and PEPs. That ability means that COPS is able to give a policy server an ongoing awareness of PDP and PEP activities; any change in operating environments or in specific policies can be implemented quickly and efficiently.

Other network management protocols such as SNMP can be programmed to do the same, but they would demand greater administrative overhead - and would introduce greater complexity - than the simple, straightforward COPS.

COPS is a query-and-response protocol that relies on TCP/IP as its transport mechanism. COPS' essential function is to carry messages between a policy server and its various clients, the PEPs.

For instance, a local Layer 3 switch or router receives a Resource Reservation Protocol (RSVP) request to initiate a session with another network node. The switch - a PEP device in policy terms - needs to perform admission control, a function that determines if sufficient resources exist to fulfill the request. Second, the switch needs to ensure the requesting user is authorized to make the request.

Typically, the switch can make the admission control decision locally. But the device most likely will need to consult a policy server - a PDP - for a policy control decision. Without this consultation, a situation could occur in which the first RSVP request gains all the switch's available bandwidth, and subsequent requests are denied until the first requestor's session ends.

Here's where COPS makes a real difference. Through the already-open TCP connection - COPS opens a connection as soon as a PDP or PEP device boots up - the switch consults the server through a COPS message. Each COPS message includes client-specific information along with the actions the requestor is asking the target device to perform.

Carried within these messages are objects of variable lengths that carry the necessary information to complete the message. In the first Request message, for instance, one or more COPS-encapsulated objects might be used to identify the client and define the type of event that triggered the query. And in the Response message, a "decision object" would carry the actual policy decision.

In all, the COPS protocol allows for 10 message types, from Request and Response to Report State, Synchronize State, Client-Accept and Client-Close. Upon device start up, for instance, a newly booted switch typically issues a COPS request to begin tracking the state of this particular PEP. Another message, Keep-Alive, is issued periodically in order to determine if a PEP or PDP has become inactive.

Through the combination of this simple message set and the encapsulated, client-specific objects, COPS is thus able to track and update the states of numerous PEPs and PDPs, without requiring undue administrative overhead.

Network vendors and users expect COPS to play a key role within the evolving industry framework for policy-enabled networks.

Such a framework will make use of several protocols - including but not limited to Lightweight Directory Access Protocol for directory access; Remote Authentication Dial-In User Service and DIAMETER for user authentication; SNMP for client/server communications in older networks; 802.1p for LAN priority; and Differentiated Services for WAN priority.

Cookish is director of marketing for the Network Management Division of 3Com. He can be reached at Michael_Cookish@3Com.com.

Feedback

Tell us your thoughts on this article or the issues raised in it. We'll cc: the author and editors on all comments.

Comments:

Name:
E-mail address:

Can we post your comments in an online forum on the topic?
Yes No

What did you think of this article?
Very useful Somewhat useful Not at all useful

Would you want to see:
More articles on this topic
Fewer articles on this topic

Thank you! When you click Submit, you'll be taken back to this article.