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) allowed each individual data session (each application instance) to specify its own set of QoS parameters.
- Differentiated Services (DiffServ) 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.
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), 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.