- 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.
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.
| |||||||||||||||||
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: 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: 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