Differentiated Services ("DiffServ") are an architecture that defines a set of quality of service mechanisms for operation on large end-to-end networks. However, DiffServ differs from its earlier defined cousin, "Integrated Services ('IntServ')," in that it attempts to reduce the relative complexity of IntServ by reducing its scope in an end-to-end network to just the core.
The DiffServ model stemmed from the feeling that IntServ was attempting to jump too far all at once; and as evidence I would suggest by the almost non-existant roll-out of IntServ, that this may be true.
DiffServ attempts to be that incremental step above best effort routing. All complex decision making (such as packet classification) has been pushed out to the edge routers, leaving the core routers to a restricted set of CQS behaviors.
Upon the injection of often complexly classified packets into the core from the edge (see: The Differences Between Edge and Core Routers), core routers establish a "packet context," or, a packet-handling behavior based soley on the DiffServ Code Point ("DSCP") carried in every packet. The six-bit DSCP is carried within the DS field (The old IPv4 ToS byte). It is the value carried within the DSCP field which dictates the per-hop behavior ("PHB") of the packet.
The PHB for a given packet is defined by some other QoS-specific signaling protocol such as RVSP. PHBs fall into three general classes:
- Expedited Forwarding ("EF")
- Assured Forwarding ("AF")
- Best Effort Routing
EF routing is defined simply as, "sending packets as fast as they arrive," essentially squeezing the best performance (in terms of latency and throughput) possible; although it is possible with RSVP to firmly define the bounds of performance (however, this funcitonality is actually a subset of IntServ). AF routing is a soft bounds definition (unlike EF which is a hard bounds definition) that is subdivided into twelve different classes of drop precedence for packets.
The default PHB for a given packet is best effort routing, which is the coach seating of packet delivery.
In summary, what does DiffServ buy us?
- A relatively easy to implement quality of service protocol for controlling bounds on latency, throughput, and drop precedence.
- Faster QoS-capable core routers by limiting their classification and queuing stage complexity.
- Less state information to be retained accross the network, as compared to IntServ (cross-core QoS characteristics can be expressed in terms of only a few aggregate behaviors).
- Far simpler to implement as compared to IntServ, however...
- ...IntServ and DiffServ can work together to create an overall end-to-end solution: especially when traversing multiple domains.