Policy-enabled QoS

QoS provides differentiation of traffic and the services provided to that traffic. This means that some traffic gets improved service and (inevitably) other traffic gets degraded service. Naturally, everyone would want the improved service for most of their traffic, but everyone can't have it (or at least not for free). Thus, QoS has a need for policy (the decision about which flows are entitled to which service) and policy creates a need for user authentication (to verify user identification).

Among the QoS protocols, only RSVP has explicit provisions for policy support, which we describe next. With other QoS protocols, policy is applied at network border location, which may be located either at a layer transition in a TCP/IP stack implementation (for example, as a layer 3 IP packet is passed to a layer 2 network driver) based on identifiable characteristics of the packet. We describe these border locations and their use of policies to define varying services in other QoS Forum papers on Policy.

RSVP policy object

The draft [RSVP Policy] describes the protocol mechanisms and algorithms for policy support in RSVP, and is meant to update the policy object description in RFC 2205 [RSVP]. Any policy-enabled RSVP router can generate, modify or remove POLICY_DATA objects.

Policy objects contain an option list and policy element list. The options are either a FILTER_SPEC object to preserve the original flow/policy association or a SCOPE object to prevent "policy loops". The policy elements are opaque and understood only by the RSVP routers that use them; the Internet Assigned Numbers Authority (IANA) will maintain a registry of policy element values and their meaning.

RSVP, multiple queues, and tagging can be valuable prioritization methods, but they aren't the only ways to address QoS.

A fairly new idea in the QoS realm is to make the network itself more intelligent by incorporating something called policy-based management. With this method, network managers could define policies that spelled out what levels of service certain types of traffic should have and what particular routing paths they should use. For example, with voice traffic, a path with a minimal number of hops would reduce delay and maintain the highest possible quality.

Policy-based management systems, which major networking vendors are starting to support, give IT managers and service providers a way to take a predefined policy and apply it across the board, rather than have to configure each network device with QoS support.

The Directory-Enabled Networks (DEN) initiative, which was launched in September 1997, is an interesting concept along these lines. Initially endorsed by Microsoft and Cisco, DEN allows network managers and service providers to create policy-based rules so that they can provide services based on users and applications. With DEN, directory services and networks are integrated, which means that network elements and services are represented in a directory. This scheme allows a centralized policy for network services to be associated with particular end-user stations and applications.

Because network devices and services are integrated with a directory, the network can be customized to provide a predictable level of service for users no matter where they are. For example, you might approve certain users for video conferencing applications, regardless of whether they log in to the network from their desktop or from a conference room with video conferencing equipment.

Wed, 23 July, 2003 13:07