Networking / Beginners

Choosing to Apply Policy

When resources in a network are reserved to support service management for integrated services or the Resource Reservation Protocol (RSVP) they are removed from general availability and are held for exclusive use by a specific datastream. This happens solely on the say-so of the requesting node-usually the node that will be sending or receiving the data. This requesting node knows the characteristics of the data being transferred and what network resources will be required to support them, so the reservation request asks for what is needed.

A node in the network receives many such requests but has only limited resources available. It must decide which requests should be satisfied and which rejected. These decisions obviously take into account the available bandwidth, and may consider authentication data (e.g., whether or not the request is from a valid neighbor or not) and request priority (as in RSVP-TE for MPLS). However, in a large network additional policy-based decisions need to be made to determine whether precious resources should be tied up for use by data flows between particular applications at the source and destination nodes.

It is not necessary to make these policy decisions at each node in the network. It is sufficient to consider the requests as they pass into and out of policy administrative domains. Once a request has entered such a domain, the nodes within the network may consider that the local domain policy has been satisfied and can reserve the resources as requested. Policy checking on departure from an administrative domain may not be necessary, but network operators may want to distinguish between reservation requests that are satisfied entirely within their network and the financial cost of resources reserved outside their network.

The points of policy control may be configured with sufficient information to make policy decisions on their own. This would certainly be the case for simple policies, but for more complex decisions based on detailed information about the topology and players in the network-and possibly a frequently changing network-wide policy-the points of policy control must consult an external policy server.

Figure shows how a router that makes policy decisions might be constructed. When a reservation request is received by the signaling component of the router (step 1) it consults the local policy component (step 2). If the policy control component on the router cannot make a decision, it consults a remote policy server (step 3). The policy decision (step 4) is relayed by the local policy component to the signaling component (step 5), which is able to make the required resource reservations (step 6) before signaling to the next node in the network (step 7). Finally, the data can fl ow, making use of the reserved resources (steps 8 and 9).

Policy is the responsibility of a distinct component

Figure below shows the full architecture for policy-based decision making. The IETF has named a point of policy control a policy enforcement point (PEP). The PEP receives a policy request and consults its local policy decision point (LPDP), which may involve examination of a cache of locally stored policy information. If the LPDP is unable to make a decision, the PEP consults a remote policy decision point (PDP) on another node in the network. Since the PDP is remote from the PEP, the two nodes must use a protocol to communicate; although the IETF specified the COPS protocol for this purpose, this protocol never gained much momentum and has been replaced by other mechanisms such as the exchange of XML-encoded policy information using SOAP or Blocks Extensible Exchange Protocol (BEEP). The PEP fills the role of a client, making policy inquiries or requests to the PDP server.

Policy architecture

The PDP has much more information available to it and can apply the full policy rules to produce an answer for the PEP. However, as the size of networks grows it may be infeasible for a single PDP server to retain all of the information necessary to make proper policy decisions about all possible traffic flows. The architecture handles this by allowing both the LDPD and PDP to read additional policy data from a full (and probably distributed) policy database using whatever protocol is suitable (perhaps LDAP, the Lightweight Directory Access Protocol, or maybe SNMP).

[Previous] [Contents] [Next]

In this tutorial:

  1. IP Network Management
  2. Choosing to Manage your Network
  3. Choosing a Configuration Method
  4. Command Line Interfaces
  5. Graphical User Interfaces
  6. Standardized Data Representations and Access
  7. Making the Choice
  8. Management Information Base
  9. Representing Managed Objects
  10. Simple Network Management Protocol
  11. Requests, Responses, and Notifications
  12. SNMP Versions and Security
  13. Choosing an SNMP Version
  14. Extensible Markup Language
  15. Extensibility and Domains of Applicability
  16. XML Remote Procedure Calls
  17. Simple Object Access Protocol
  18. XML Applicability to Network Management
  19. Common Object Request Broker Architecture
  20. Interface Definition Language
  21. The Architecture
  22. CORBA Communications
  23. Choosing a Configuration Protocol
  24. Choosing to Collect Statistics
  25. Policy Control
  26. Choosing to Apply Policy
  27. Policy Information Base