DIFFERENTIATED SERVICES DIFFERENTIATED SERVICES

2.6 DIFFERENTIATED SERVICES DIFFERENTIATED SERVICES

DiffServ mechanisms use edge-based packet marking, local per-class forwarding behaviors, and resource management to support multiple service levels over an IP-based network. DiffServ terminology is as follows:

■ Per-hop behavior (PHB): the DiffServ treatment (scheduling/dropping)

applied by a router to all the packets that are to experience the same DiffServ service

■ Differentiated services code point (DSCP): the value in the IP header

indicating which PHB is to be applied to the packet

■ Behavior aggregate (BA): the set of all packets that has the same DSCP

(and thus that will receive the same PHB)

■ Ordered aggregate (OA): the set of BAs that has an ordering constraint

and must go into the same queue

■ PHB scheduling class (PSC): the set of PHBs applied to an OA, which

uses the same queue

DSCPs in the packet header indicate how packets should be serviced at each hop and are marked at the ingress based on analysis of the packet. Intermediate routers service the packets based on the DSCPs. The DiffServ architecture specifies the DSCP format for each PHB. DiffServ is designed to be simpler and more scal- able than RSVP/IntServ, as no signaling or per-flow state needs to be maintained in the core network. DiffServ requires no change to applications and is efficient for core routers, as just a few bits indicate the forwarding treatment and the complex classification work is done at the network edge. Furthermore, the network transport can be IP, ATM, Frame Relay, MPLS, or a mixture. Different packet handling services and mappings are possible, for example, the service class indicator (e.g., premium and best-effort) can indicate congestion control priority where low-priority packets are discarded first.

The DSCP was formerly the IPv4 type of service (TOS) field and IPv6 traffic class field. Six bits of the TOS byte are allocated to the DSCP, and two bits are allocated to the explicit congestion notification (ECN). DiffServ per-hop behaviors are defined as follows:

■ Default : best effort

■ Expedited forwarding (EF): low delay, latency, jitter service ■ _{Assured forwarding (AF): four “relative” classes of service} ■ Class selectors: backward-compatible with IP precedence

As illustrated in Figure 2.5, routers at the edge of the DiffServ domain classify flows and mark packets with the DSCP. Edge route also measures traffic, compares to a traffic profile, and performs traffic conditioning (shape/drop as needed). Routers in the core of a DiffServ domain identify the PHB and implement PHB functionality by queue management/scheduling techniques.

By recognizing that most of the data flows generated by different applications can be ultimately classified into a few general categories (i.e., traffic classes), the DiffServ architecture provides simple and scalable service differentiation. It does this by discriminating and treating the data flows according to their traffic class, thus providing a logical separation of the traffic in the different classes. DiffServ achieves scalability and flexibility by following a hierarchical model for network resource management:

■ Interdomain resource management : service levels, and hence traffic

contracts, are agreed at each boundary point between a customer and a provider for the traffic entering the provider network.

■ Intradomain resource management : the service provider is solely

responsible for the configuration and provisioning of resources and policies within its network.

Therefore DiffServ is based on local service agreements at customer/provider boundaries, and end-to-end services are built by concatenating such local agree- ments at each domain boundary along the route to the final destination. Service providers build services with a combination of traffic classes and traffic condition- ing, to ensure that traffic characteristics conform to a traffic profile and that traffic contracts are respected, and billing.

Provisioning and partitioning of both boundary and interior resources are the responsibility of the service provider and, as such, outside the scope of DiffServ.

DS domain DiffServ Boundary DiffServ Boundary • Microflow classifier • Metering • Marking • Traffic conditioning DiffServ domain BA traffic Microflows DiffServ Interior DiffServ Interior • PHB classifier • PHB support DiffServ Boundary DiffServ Boundary • PHB classifier • Metering • Marking • Traffic conditioning • Queue mngt/schedule FIGURE 2.5 FIGURE 2.5 DiffServ processing. 2.6 2.6 Differentiated Services 2929

30

30 CHAPTER 2CHAPTER 2 Traffic Engineering and QoS Optimization Technology

DiffServ does not impose either the number of traffic classes or its characteristics on a service provider, and although traffic classes are nominally supported by interior routers, DiffServ does not impose any requirement on interior resources and functionalities. Traffic conditioning (metering, marking, shaping, or dropping) in the interior of a network is left to the discretion of the service providers.

The net result of the DiffServ approach is that per-flow state is avoided within the network, as individual flows are aggregated in classes. Compared with IntServ, traffic classes in DiffServ are accessible without signaling, which means they are readily available to applications without any setup delay. Consequently, traffic classes can provide qualitative or relative services to applications but not quantita- tive requirements. The only functionality imposed by DiffServ on interior routers is packet classification. This classification is simplified from that in RSVP because it is based on a single IP header field containing the DSCP rather than multiple fields from different headers. This has the potential of allowing functions per- formed on every packet, such as traffic policing or shaping, to be done at the boundaries of domains, so forwarding is the main operation performed within the network.

Simultaneously providing several services with differing qualities within the same network is a difficult task. Despite its apparent simplicity, DiffServ does not make this task any simpler. Instead, in DiffServ it was decided to keep the operat- ing mode of the network simple by pushing as much complexity as possible onto network provisioning and configuration. Provisioning requires knowledge of traffic patterns and volumes traversing each node of the network, which also requires a good knowledge of network topology and routing. Provisioning is per- formed on a much slower timescale than the timescales at which traffic dynamics and network dynamics (e.g., route changes) occur, which means it is impossible to guarantee that overloading of resources will be avoided. This is caused by two factors:

1. Packets can be bound to any destination and thus may be routed toward any border router in the domain; in the worst case, a substantial proportion of the entering packets might all exit the domain through the same border router.

2. Route changes can suddenly shift vast amounts of traffic from one router to another.

Therefore, even with capacity overprovisioned at both interior and border routers, traffic and network dynamics can cause congestion and violation of service agreements. In addition, capacity overprovisioning results in a very poor statistical multiplexing gain and is therefore inefficient and expensive. Bandwidth is a class property shared by all the flows in the class, and the bandwidth received by an individual flow depends on the number of competing flows in the class as well as the fairness of their respective responses to traffic conditions in the class. Therefore, to receive some quantitative bandwidth guarantees, a flow must reserve its share of bandwidth along the data path, which involves some form of end-to-

end signaling and admission control among logical entities called DiffServ band- width brokers (TQO processors). This end-to-end signaling should also track network dynamics (i.e., route changes) to enforce the guarantees, which can prove very complex.

However, delay and error rates are class properties that apply to every flow of a class. This is because in every router visited, all the packets sent in a given class share the queue devoted to that class. Consequently, as long as each router manages its queues to maintain a relative relationship between the delay and/or error rate of different classes, relative service agreements can be guaranteed without any signaling. However, if quantitative delay or error rate bounds are required, end-to-end signaling and admission control are also required. End-to-end signaling and admission control would increase the complexity of the DiffServ architecture. The idea of dynamically negotiable service agreements has also been suggested as a way of improving resource usage in the network. Such dynamic service-level agreements would require complex signaling, as the changes might affect the agreements a provider has with several neighboring networks.

Therefore in its simplest and most general form, DiffServ can efficiently provide pure relative service agreements on delay and error rates among classes. However, unless complex signaling and admission control are introduced in the DiffServ architecture or robustness is sacrificed to some extent, guarantees on bandwidth, as well as quantitative bounds on delay and error rates, cannot be provided. It should be noted that from a complexity point of view, a DiffServ scenario with dynamic provisioning and admission control is very close to an IntServ scenario with flow aggregation. The difference is that precise delay and error rate bounds might not be computed with DiffServ, as the delays and error rates introduced by each router in the domain may not be available to the DiffServ bandwidth broker/ TQO processor.

DiffServ alone, therefore, does not represent the ultimate solution for QoS support for all types of applications, and combining DiffServ and IntServ capa- bilities could combine their individual advantages and mitigate some of their individual drawbacks. Figure 2.6 illustrates an approach to the integration of Diff- Serv and IntServ. RSVP messages flow end to end, which are ignored by DiffServ routers in the core of the network. Edge routers in this configuration perform both IntServ and DiffServ QoS mechanisms, while backbone routers only perform DiffServ QoS functions. An IntServ flow is tunneled through the core DiffServ domain in this configuration.

As detailed in RFC 2998 , significant benefits can be achieved by combining IntServ and DiffServ to support dynamic provisioning and topology-aware admis- sion control, including aggregated RSVP reservations, per flow RSVP, or a DiffServ bandwidth broker/TQO processor. The advantage of using aggregated RSVP res- ervations is that it offers dynamic, topology-aware admission control over the DiffServ region without the scalability burden of per-flow reservations and the associated level of RSVP signaling in the DiffServ core. RFC 3175 describes an architecture where multiple end-to-end RSVP reservations share the same ingress

2.6

32

32 CHAPTER 2CHAPTER 2 Traffic Engineering and QoS Optimization Technology

router (aggregator) and the same egress router (deaggregator) at the edges of an aggregation region and can be mapped onto a single aggregate reservation within the aggregation region. This considerably reduces the amount of reservation state that needs to be maintained by routers within the aggregation region. Further- more, traffic belonging to aggregate reservations is classified in the data path purely using DiffServ marking.