The QOS Quagmire

Convergence will live or die depending on how easy it is to implement IP-based QoS through policy-based networking. Unfortunately, policy-based networking is still a work in progress. By Tom Stenson
Network World, 09/06/99

Do you believe in convergence? More specifically, do you believe in a new world order in which voice, data and video all travel in harmony on high-speed IP networks?

If so, you also believe in policy-based networking. Convergence will ultimately succeed or fail based on the IP community 's ability to implement quality of service (QoS) in a manageable, scalable fashion - and that 's what policy-based networking is all about.

A quick reality check indicates that the standards are still evolving, the protocols are untested and the products are immature. Policy-based networking won 't be ready for prime time for another year or two. But it 's not too early to start learning the basics of policy-based networking.

Policy: The basics

A policy defines how network resources are to be provisioned among network clients. Clients may be users, applications or hosts, and resources may be provisioned statically or dynamically based on factors such as time of day, resource utilization and client authorization rights.

A high-level policy statement, such as: "Provide Expedited Forwarding for all voice-over-IP traffic," is translated into a structured set of "if <condition(s)> then <action(s)>" rules so the policy can be stored, retrieved and interpreted by the various network components.

Unfortunately, first-generation systems generally will not interpret high-level policy statements. Instead, the systems will require the network manager to enter policies as rules, such as: "if Port = HTTP (80) then set IP Precedence = 4".

Framework under construction

One of the most promising aspects of policy-based networking is the work in progress at the Internet Engineering Task Force (IETF) to define a standard policy framework and a related set of protocols and schemas.

What has emerged is, at least on the surface, a relatively simple and elegant framework. The typical policy-based network will include:

Policy entry console: a management tool through which the network manager defines and edits policies.
Policy decision point (PDP): a policy server that retrieves policies from a repository and makes decisions on behalf of a Policy Enforcement Point (PEP).
PEP: network devices, such as routers, switches and firewalls, that enforce policy decisions via access lists, queue management algorithms and other means.
Policy repository: a Lightweight Directory Access Protocol (LDAP)-compliant directory server that stores policies.

PDPs and PEPs will talk to each other via a simple query/response protocol called Common Open Policy Service (COPS). COPS is preferred over SNMP because it is connection-oriented and reliable, and includes locking mechanisms to prevent multiple PDPs from simultaneously attempting to update the same PEP.

The framework does not specify how implementation will occur; several components could exist on a single physical server, or each may reside on its own server.

Policy rules must be represented as data structures so they can be stored and retrieved. To address this issue, the IETF 's Policy Framework Working Group has defined the Policy Framework Core Information Model, which defines a high-level set of object-oriented classes that can be used for general policy representation. Object classes in the core model can be extended with subclasses to represent specific types of policies - for example, QoS or network security policies.

There is general agreement within the vendor community that policy information should be stored in an LDAP-compliant directory, so the Policy Framework Working Group has also defined a mapping of the Core Information Model into an LDAP directory schema.

The framework concepts enjoy widespread vendor support and are defined in Internet drafts in the IETF. Although none have reached request for comments (RFC) status, taken together these ideas provide a clear roadmap for how policy network systems are to be built in the future.

QoS standards

There are three QoS standards relevant to corporate networkers: Differentiated Services (Diff-Serv), Resource Reservation Protocol (RSVP) and 802.1p.

Diff-Serv redefines how the IPv4 type-of-service (ToS) byte or IPv6 Traffic Class is used to specify a QoS requirement. Diff-Serv is backward-compatible with existing use of the IP Precedence bits in the ToS field.

Diff-Serv is intended to provide QoS for general classes of traffic, or traffic aggregates, as opposed to individual flows.
RSVP is a flow-based protocol that lets an application signal the QoS (latency, jitter, bandwidth) it needs by sending end-to-end control messages across the network. Routers along the path will reserve resources for the application flow or deny admission to the network. RSVP has been implemented in Cisco and Nortel Networks routers, as well as in many other vendors ' products, for more than a year.
802.1p is a Layer 2 mechanism that allows three bits in an 802.1Q virtual LAN header to be used to mark a packet for QoS.

Enterprise network managers will likely be implementing Diff-Serv for most QoS requirements, with selected use of RSVP for very sensitive applications, such as voice over IP, that require resource reservation and admission control (better to reject a voice call than give it poor QoS).

In the Diff-Serv model, the enforcement of QoS at a network-device level involves four steps. Packets are:
Classified according to Layer 2 through Layer 4 (or higher) header information.
Marked to indicate classification by setting the Diff-Serv bits.
Policed (selectively dropped as necessary) in order to avoid congestion.
Shaped (preferentially queued and forwarded).

As advancements in Application Specific Integrated Circuit technology continue to make Layer 3 functionality more affordable, expect to see higher-layer classification and marking driven back from the WAN edges all the way to the wiring closet; this is where most vendors believe this function ultimately belongs.

In practice, classification and marking involves the creation of access control lists. Policing is accomplished by an algorithm such as random early detection or weighted random early detection. Shaping is accomplished with one of many algorithms, including weighted round robin, weighted fair queuing, class-based queuing, class-based WFQ and many others.

Currently, it is up to the network manager to configure policing and shaping algorithms on an interface-by-interface basis. No wonder large-scale implementations of IP-based QoS have been rare.

Where the vendors stand

Over the past 12 to 18 months, every major network equipment vendor has announced a policy-based network initiative, but very few have shipped a product.

Cisco

Cisco began shipping QoS Policy Manager 1.0 (QPM) in March as part of the company 's CiscoAssure Policy-Based Networking initiative. CiscoAssure also includes a policy manager for network security, called Cisco Security Manager. The QoS and security managers will remain separate going forward but will share a common framework.

QPM 's graphical user interface simplifies many aspects of QoS configuration. In a typical session, a user might add a new router, select a queuing algorithm for each interface, create a policy for the interface consisting of a classification filter and action (set IP Precedence) and schedule the policy for download to the router. Interfaces of the same type can be grouped so policies can be applied at a group level, as well as at an individual interface level.

QPM is what you might expect from a first-generation policy manager: It provides some valuable productivity gains, but still exposes a lot of detail, such as choice of queuing mechanisms and shaping parameters, to the user. Thus, the network manager is still required to understand the operation of Cisco 's many queuing algorithms.

The initial release of QPM does not use an LDAP directory and does not use COPS; expect to see both in the first half of 2000 (COPS is running in Cisco 's labs today). The next release also will increase the number of devices supported from approximately 200 to more than 1,000.

Nortel

Nortel 's Optivity Policy Services 1.0 (OPS) began shipping in August. OPS implements many of the concepts outlined in the IETF drafts, including the policy server, COPS and an LDAP-compliant directory store for policy information.

OPS currently stores policy information in its own branch of the LDAP directory tree but will be migrated to the IETF standard as the LDAP schema standard is firmed up.

Nortel is one of the first vendors to include a COPS client in a network device, namely routers running BayRS 13.20 routing software. OPS uses it for PDP-PEP communications. Other devices, including Cisco routers, are also supported.

In a typical OPS session, a user might add a router and individual interfaces, create a Traffic Pattern using filters, create an Action such as Deny, Mark or Police, and create a policy that associates a Traffic Pattern, Action and an interface. Interfaces of the same type can be grouped.

Similar to Cisco 's QPM, OPS provides some valuable productivity gains but still exposes a lot of detail to the user. One capability missing in the first release is the ability to specify and control the interface queuing mechanism. This must be done separate from the policy system via Nortel 's standard router configuration software. The company expects this capability to be added to OPS in the first quarter of 2000.

Cabletron

One could argue that Cabletron has been doing policy-based networking in live production networks longer than anyone. Four years ago, Cabletron was shipping the Virtual Network Server (VNS), a sort of early PDP.

But VNS was based on Cabletron 's proprietary SecureFast Switching technology, and the company is now moving away from proprietary technology and onto a standards-based track. The company 's SmartSwitches now support QoS standards such as 802.1p and use of the ToS/

Diff-Serv field. The SmartSwitches also support four queues per port, WFQ, and Layer 2 through Layer 4 classification and marking, which means Cabletron can provide high-layer classification and marking in the wiring closet today - something most other vendors are trying to accomplish with upgrades.

Cabletron 's QoS policy manager will be called Spectrum Policy Aware and is expected to ship in the first quarter of 2000. Policy information will be stored in an LDAP-compliant directory, and communications between the PDP and PEP will support COPS as well as other protocols. PEPs may also use LDAP to communicate with the directory server.

3Com

3Com 's policy server is also not expected to ship until the first quarter of 2000 and will tentatively be called Transcend Policy Service. It is expected to be consistent with the standards being developed in the IETF, including the policy framework and use of COPS. Policies will be stored in LDAP-compliant directories, and support for legacy devices will be provided via proxies.

3Com is also working on QoS-enabling many of its products, adding 802.1p to its Layer 2 switches, and ToS/Diff-Serv and RSVP to Layer 3 switches and routers. 3Com 's Dynamic Access product also provides the ability to classify and mark packets at the network interface card, as long as it 's a 3Com NIC card.

Multivendor management

The prospects for seeing policy-based management work across a multivendor environment are not good, at least in the near term. Implementations of the policing and shaping algorithms vary widely from vendor to vendor and even within a vendor 's product line. To make policy management truly vendor independent, the general functions of policing and shaping have to be modeled and represented in a QoS schema and Policy Information Base (PIB). The PIB will have to be supported on network devices.

Most vendors will support their own equipment and will try to support Cisco. However, Cisco supports a long list of QoS mechanisms, and the list is getting longer all the time. Keeping up with it all will be difficult for Cisco, let alone for other vendors.

Despite the gloomy prospects for near-term interoperability, there is some reason for optimism. The long-term path to interoperability is relatively clear, and vendors are buying into it.

The bottom line

Policy-based networking is certainly in its early stages of development. The IETF has made significant progress, but more needs to be done. It will likely be another year before most of the relevant standards have reached RFC status.

Perhaps more importantly, the IP community is still a year or two away from really understanding how to best use techniques such as Diff-Serv and RSVP to implement QoS in production networks. Once there is some reasonable consensus in this area, vendors will need to make it easy for customers to implement these techniques on an enterprisewide basis.

But don 't be afraid to jump in - the water 's a little chilly, but getting warmer. Getting your feet wet with the technology now will help ensure that your network will be QoS-capable in the future.

Ten steps on the road to IP-based quality of service

Review the work being done at the IETF on policy networking. Understand the conceptual framework (PDPs, PEPs, etc.), and the purpose of the COPS protocol and PIB.

Review QoS technologies, particularly Diff-Serv, RSVP and 802.1p. Understand where each might apply in your network, and understand the basic steps involved in enforcing QoS: classification, marking, policing and shaping.

Get up to speed on LDAP and directories - it's clear they will play a crucial role in your next-generation network.

Understand the roles DNS, and DHCP will play in associating IP addresses with QoS requirements. Review the capabilities of DNS/DHCP systems from leading vendors.

Begin to profile your traffic and think about how you would classify it into categories based on QoS requirements.

Determine which points in your network are potential bottlenecks, particularly as voice and video are added to the network. Consider where it would make the most sense to classify and mark packets so QoS can be applied.

Pay attention to the QoS capabilities of the switches and routers you buy; classification and marking at Layer 3 and above is being pushed out to the wiring closet, and this is likely where you will want to do it in the long run. Understand the cost of adding classification and marking capabilities to various points in your network.

Review the policy-based networking plans of your leading vendors in the areas of QoS management and network security management. Policy-based networking initiatives are initially focused on QoS, but standards bodies and vendors intend to extend the concepts to network security management.

Review emerging service provider VPN offerings that include QoS. Consider how their services might be integrated into an enterprisewide, QoS-enabled network.

If your budget allows, implement a QoS policy management system; it will give you some near-term productivity enhancements and some valuable experience for the future.