IP QoS: Two generations of class-of-service tools

IP QoS: Two generations of class-of-service tools

Fifteen years ago, life was pure and simple: Service providers offered point-to-point links with specified quality of service (QoS) -- usually committed and excess bit rates. The Internet Protocol (IP) lacked any QoS mechanisms. Things got complicated when people started using IP in mission-critical networks, and as is usually the case, two competing architectures were developed to provide QoS on IP:
  • Integrated Services (IntServ; RFC 1633) allowed each individual data session (each application instance) to specify its own set of QoS parameters.
  • Differentiated Services (DiffServ; RFC 2475) grouped user data in coarse classes (for example, real-time, mission-critical and "other" traffic) and provided QoS guarantees to each class, but not to every single session within the class.

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information:

By submitting your registration information to SearchTelecom.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here

  • Your use of SearchTelecom.com is governed by our Terms of Use
  • We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
  • If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.

Service providers that don't want to compete solely on pricing should provide IP quality-of-service guarantees to their customers.
Ivan Pepelnjak
Chief Technology AdvisorNIL Data Communications

Integrated services architecture failed the scalability challenge owing to the same problem that had plagued X.25 and legacy IBM networking: You simply cannot provide individual QoS guarantees to millions of flows traversing the same high-speed link. So instead, all high-speed service provider designs use differentiated services architecture.

Initial implementations of DiffServ architecture used the IP precedence field in IP packets to indicate the desired class of service. This field is three bits long; you can thus provide up to six different classes of service (values 6 and 7 are reserved for control traffic).

When it became evident that we needed a wider range of values, the type-of-service octet in the IP header was redefined as the Differentiated Services field (DSCP; see RFC 2474), which gives you the full range of IP precedence values, as well as four additional assured forwarding classes, each with three different drop priorities (the drop priority is similar to the discard eligibility bit in Frame Relay or the cell loss priority bit in ATM), as well as the expedited forwarding class used for real-time traffic.

IP quality of service mechanisms

A typical high-speed QoS implementation in modern routers and Layer 3 switches might include the following mechanisms:

  • Metering (policing) and marking. The metering function should ensure that traffic sent by customers conforms to contractual limits. Excess traffic could be dropped and relabeled as less-important traffic or marked with different drop priority. Note: Drop priorities are better than traffic relabeling because relabeling can cause out-of-order packets, which can severely degrade the throughput of customers' applications.
  • Queuing based on DSCP or IP precedence values. Most devices support priority queuing, which should be used for real-time traffic (voice, for example) and class-based queuing, which allocates a percentage of available bandwidth to each traffic class.
  • Dropping (including random early drop) based on drop priorities. When encountering output link congestion, the network devices should preferentially drop packets with high drop priority (assuming these packets are out-of-contract traffic marked at the network's ingress boundary).

Most software-based devices also include the shaping functionality. Instead of dropping or relabeling out-of-contract traffic (as policing does), shaping delays out-of-contract packets. Shaping is preferred to policing, as it results in much better end-to-end application performance, but it is usually implemented in software and thus is unusable on high-speed links. Note: Recent high-end router modules, the 4-port Gigabit Ethernet module for Cisco's 7600 router, for example, support hardware-shaping queus, making PE-to-CE shaping a viable solution.

Ideally, the customer edge (CE) router should perform outbound shaping, and the provider edge (PE) router should use policing to monitor traffic contract compliance.

Summary

Service providers that don't want to compete solely on pricing should provide IP quality-of-service guarantees to their customers. To implement contractual obligations, the service provider network should use the following tools:

  • Policing and marking on ingress PE routers.
  • Differentiated queuing and dropping on core links.
  • Shaping (or policing, based on line speeds and hardware deployed in the network) and differentiated queuing on egress PE-CE links.

In my next article, I'll discuss different QoS models that modern service providers can offer their customers and the actual IP QoS mechanisms needed to implement them.

About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html


This was first published in October 2008

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.