Differentiated Services [DiffServ] provides a simple and coarse method of classifying services of various applications. Although others are possible, there are currently two standard per hop behaviors (PHBs) defined that effectively represent two service levels (traffic classes):

• Expedited Forwarding (EF): Has a single codepoint (DiffServ value). EF minimizes delay and jitter and provides the highest level of aggregate quality of service. Any traffic that exceeds the traffic profile (which is defined by local policy) is discarded [DiffServ EF].
• Assured Forwarding (AF): Has four classes and three drop-precedences within each class (so a total of twelve codepoints). Excess AF traffic is not delivered with as high probability as the traffic "within profile," which means it may be demoted but not necessarily dropped [DiffServ AF].

As illustrated in Figure 2, PHBs are applied by the conditioner to traffic at a network ingress point (network border entry) according to pre-determined policy criteria. The traffic may be marked at this point, and routed according to the marking, then unmarked at the network egress (network border exit). Originating hosts can also apply the DiffServ marking, and there are a number of advantages in doing so [e2e-QoS, DiffServ Arch].

Figure 2: Differentiated Services Architecture, with a break out of some specifics. This functionality is enabled in every DiffServ enabled router, although not all functions are used all the time. Typically, border routers--at ingress and egress points--apply functions, but interior routers may also.

DiffServ assumes the existence of a service level agreement (SLA) between networks that share a border. The SLA establishes the policy criteria, and defines the traffic profile. It is expected that traffic will be policed and smoothed at egress points according to the SLA, and any traffic "out of profile" (i.e. above the upper-bounds of bandwidth usage stated in the SLA) at an ingress point have no guarantees (or may incur extra costs, according to the SLA). The policy criteria used can include time of day, source and destination addresses, transport, and/or port numbers (i.e. application Ids). Basically, any context or traffic content (including headers or data) can be used to apply policy.

Figure 3: Differentiated Services Code Points (DSCP) redefine the IPv4 Type of Service byte. IP Precedence bits are preserved in class selector codepoints & PHBs, but TOS values are not.

When applied, the protocol mechanism that the service uses are bit patterns in the "DS-byte," which for IPv4 is Type-of-Service (TOS) octet and for IPv6 is the Traffic Class octet. As illustrated in Figure 3, although the DS field uses the IPv4 TOS byte [DiffServ Field], as defined in RFC 791 [IP], it does not preserve the original IPv4 TOS bit values as defined by RFC 1349 [TOS]. The IP Precedence bits (0-2) are preserved, however. And although it is possible to assign any PHB to the codepoints in this range, the (required) default PHBs are equivalent to IP Precedence service descriptions, as described in detail in RFC 1812 [RouterReqs].

The simplicity of DiffServ to prioritize traffic belies its flexibility and power. When DiffServ uses RSVP parameters or specific application types to identify and classify constant-bit-rate (CBR) traffic, it will be possible to establish well-defined aggregate flows that may be directed to fixed bandwidth pipes. As a result, you could share resources efficiently and still provide guaranteed service. We will describe this type of usage later as we describe the various QoS architectures possible.

Wed, 23 July, 2003 13:07