Services mapping between Diffserv architecture and ATM
Chi-Ping Lai, Cheng-Yuan Tang, and Wei-Shyh Chang
Computer Center, Huafan University
Department of Information Management, Huafan University
{cplai, cytang, paul}@huafan.hfu.edu.tw
Abstract
The best-effort service model in the Internet does not provide any form of service differentiation and performance assurance to flows. To support service differentiation and performance assurance in the Internet, the Internet community has developed differentiated service (Diffserv) architectures. Service mapping between Diffserv over ATM network is an important issue because ATM has been widely deployed in Internet backbones, such as TANET. In this paper, first we introduce QoS and Diffserv architecture. Then ATM service category is described. Finally, according to the ATM Forum recommendations, we briefly summarize how to provide Diffserv on ATM network.
Keywords: QoS, Differentiated Service, Integrated Service, Per-hop behavior, ATM service category.
1. Introduction
Today, the Internet has become a part of our life. There has been a rapid evolution in the Internet applications. It provides a broad range of services, which vary from a simple E-mail to complex client/server applications or delay-sensitive multimedia services such as World Wide Web, audio/video transport. These new applications have very different requirements and have brought us new challenges. Since the best-effort service model is no longer adequate, two issues will be addressed. One is service differentiation and another is performance assurance [1]. For the service differentiation, the Internet is difficult to offer multiple levels of service because the best-effort model treats all packets in the same way. For examples, Internet telephony is sensitive to latency and, in contrast, E-mail can tolerate a fair amount of delay. Obviously, the Internet needs to provide different services requirements. For the performance assurance, most real time applications require minimal resources to operate effectively. However, the best-effort model has few resource management capabilities and cannot provide resource guarantee to users. Thus, it is difficult to support performance assurance in the Internet. At the forefront of achieving service differentiation and resource assurance is what is commonly referred to as quality of service (QoS).
To guarantee services that have specific performance requirements, QoS concerns itself with
bandwidth, latency, jitter, and loss. Bandwidth concerns how the network manages the entire stream of data packets flowing through it, particularly in times of congestion. To achieve bandwidth guarantee is an important issue of providing QoS. Those who pay more for large pipes into network should not be unfairly penalized during times of congestion. Latency is the end-to-end delay of a flow. A flow is a single stream of packets transmitted by a specific sender to one or more specified receivers. Some real-time applications, like voice and video, have a specific end-to-end delay budget. If a packet is delayed beyond the allocated delay budget, the data may become stale. Jitter is the variation in latency between packets. Most it is due to the variations in the volume of other flows competing for the output link. Some delay-sensitive applications, such as continue media services, have stringent jitter requirements. There are two conditions that loss occurs. First, discarding packets competing for the output link to relieve the level of congestion. Second, when sending hosts notice that some packets are being discarded, they usually reduce the volume of traffic. Although loss is an effective approach for managing congestion, many applications can only tolerate a small amount of packet loss.
Since the best-effort service model does not provide service differentiation and performance assurance to flows, the Internet architecture has to be extended so that certain users/applications can get better service than that of others. The Internet community has developed two service architectures: integrated service (Intserv) [2,3,4,5] and differentiated service (Diffserv) [6,7,8,9].
The Intserv was the first attempt to enhance the Internet with QoS capabilities. It provides end-to-end guaranteed or controlled load services on a per flow basis. Each flow can request specific levels of service, i.e., minimum service rate, end-to-end delay bound or loss ratio, from the network through Resource Reservation Protocol (RSVP) [2,3]. The guaranteed service [4] is defined to support real-time traffic and the controlled load service [5] to support a non-real time service. The RSVP is used to manage QoS requirements and allocate resource for individual flows. Based on per-flow resource reservation, a flow must make a reservation before it can transmit traffic onto the network. Although the Intserv architecture provides absolute service guarantees, resource reservation
process requires each router to maintain a considerable amount of processing overhead and states. Moreover, maintaining per flow states causes the scalability and manageability problems. It does not cope with a very large number of flows. Alternative solution, Diffserv architecture, is proposed to support QoS in the Internet. It avoids the limitations of Intserv architecture by focusing on traffic aggregates, rather than individual flow, and provides more scalable/manageable architecture in IP network.
ATM Forum has proposed QoS service model [10,11] on the ATM network that is the QoS-enabled network, 80 percent of network service providers intend to build their multiservice networks on ATM infrastructures. It supports QoS very well and has been widely deployed in Internet backbones, such as TANET. Thus, Diffserv over ATM network is an important issue and is addressed by the ATM Forum and the IETF [12,13,14]. This paper discusses the current development of QoS mapping between Diffserv and ATM.
The rest of this paper is as follows. Section 2 makes an overview of how Diffserv can be used to support application’s requirements in the Internet. The ATM service category is described in Section 3. According to the ATM Forum recommendations, we briefly summarize how to provide Diffserv on ATM network in Section 4. Finally, Section 5 concludes this work.
2. Differentiated Services Framework
Instead of making per-flow reservation in Intserv, Diffserv aggregates flows into forwarding classes by the edge router at the boundaries of the network and forwarding classes are assigned to different behavior aggregates. Each behavior aggregate is identified by a single Diffserv Code Point (DSCP), which is contained in the packet header. Within the network, packets are forwarded according to the Per-Hop Behavior (PHB) associated with DSCP [7]. In the following, we briefly introduce the concepts and architecture of Diffserv.
2.1 Concepts behind Diffserv
The basic concepts behind Diffserv [7,8,9] are introduced as follows.
z To address the scaling concerns, the Diffserv divides traffic flows into a number of traffic aggregations called forwarding classes. Each forwarding class represents a predefined forwarding treatment. Resources are allocated to individual forwarding classes rather than individual flows.
z Forward classes can be defined for a single domain. Domain service provider may map their service definitions through bilateral agreements.
z Diffserv model provides relative resource allocation rather than absolute resource guarantee.
No QoS requirements are exchanged between the source and destination. Diffserv provides resource assurance for a forwarding class through prioritization and provisioning. That is, a forwarding treatment defines drop priority and bandwidth allocation. However, network traffic will become dynamic and the QoS guarantee becomes more difficult. For this reason, the Diffserv does not attempt to support an absolute resource assurance, but rather strives for a relative ordering of forwarding classes such that some will receive better or worse treatment relative to other.
z Diffserv model emphasis service level agreement (SLA) rather than dynamic signaling. The purpose of Diffserv is to ensure that the SLAs between customers and service providers are honored.
z Diffserv have its distinction between the edge and the core in Diffserv domain (DS domain). A DS domain refers to a set of hosts and routers supporting the same service policies and behaviors. In Diffserv, only boundary nodes of a DS domain classify traffic and mark packets. The interior nodes of a DS domain use the forwarding classes to determine the forwarding treatment of the packets. In contrast, Intserv requires all nodes to perform packet classification to identify packets and schedule them with per-flow queuing.
From the above discussion, the different between Intserv and Diffserv is quite subtle. A service can be implemented with a forwarding treatment and admission control. Forwarding treatment refers to the externally observable behavior of a specific algorithm or a mechanism that is implemented in a node. In contrast, service is defined by the overall performance that a customer’s traffic receives. For example, we define a service called no-loss service, which guarantee no packet losses for customers of this service. The no-loss service can be implemented with the express forwarding by assigning high priority to the packets of the customers. Proper traffic control, such as admission control, is also needed to prevent too many high-priority packets from arriving at the output link.
2.2 Diffserv Architecture
Figure 1 shows the network architecture for the deployment of Diffserv, consisting of a set of interconnected Diffserv domains. Traffic classification and conditioning are done in the boundary nodes and a limited set of PHBs in the interior nodes. Traffic entering the domain must be classified, marked and possibly conditioned according to the Traffic Condition Agreement (TCA) and Service Level Agreement (SLA). The function components in Diffserv edge node consist of packet classifier, meter, marker and shaper/dropper. Packet classifier identifies packets in a traffic stream based
on the content of some portion of packet header. After a flow is classified, its resource consumption will be measured. Meter is used to estimate the traffic stream against the traffic profile. Marker ensures that each packet is appropriately marked to identify its forwarding behavior supported in the domain. Shaper is used to delay some of the packets in a traffic stream in order to bring the stream into compliance with the traffic profile. When a flow exceeds the configured profile, dropper may drop one or more packets in the flow. Figure 2 shows the function modules of the Diffserv architecture.
customer network customer network DS domain B DS domain A customer
network Traffic classifyingSLA: Traffic conditioning
traffic flow
Boundary Node Interior Node
Figure 1: Diffserv network architecture
Classifier
queuing sheduler
Buffer management
Per Hop Behavior Traffic Conditioner
Classifier
Meter
Marker dropperShaper/
Interior Node Boundary Node
TCA SLA
Figure 2: the function modules in Diffserv architecture
2.3 Per-Hop Behaviors (PHBs)
In Diffserv, externally observable forwarding treatments at a single node are described by the term per-hop behavior (PHB). Each PHB is represented by a 6-bit value called a DSCP. All packets with the same code point are referred to as a behavior aggregate, and they receive the same forwarding treatment. A set of PHBs may form a PHB group that describes resource allocation in relative in terms of bandwidth allocation and drop priority. They are typically implemented by means of buffer management and packet scheduling. In [14], four PHB groups are defined as follows.
z Expedited Forwarding (EF): The EF PHB is characterized by a configurable amount of bandwidth that is available all the time irrespective
of the fluctuations of the other traffic sharing the link. The EF PHB is defined as a forwarding treatment for a particular aggregate where the departure rate of the aggregate’s packets from any Diffserv node must equal or exceed the configured rate. The EF PHB is used to build a low loss, low latency, low jitter, and assured bandwidth and provide a premium service (i.e., virtual leased line, VLL).
z Assured Forwarding (AF): The AF PHB group provides four independently forwarded AF classes. Within each AF class, an IP packed can be assigned one of three different levels of drop precedence. A configurable, minimum amount of forwarding resources (e.g. buffer space and bandwidth) is allocated for each class. However, there is no standard relationship between the performances of the four AF classes
z The Class Selector (CS) PHB group: The Class Selector (CS) PHB group was created to enable partial backward compatibility with the IP v4 Type of Service (TOS) field. Its coding (xxx000) subsumes the bit patterns most commonly used in the TOS field. At least two levels of precedence (to which the 8 possible CS values are mapped) should be implemented. The probability of time forwarding for traffic with a given CS code point should be not less than that with a numerically smaller CS code point.
z The Default PHB: The Default PHB was created to explicitly grandfather the most common setting of the TOS field (000000). The associated forwarding behavior is expected to be “best effort”. Note that by virtue of coding, the Default PHB is actually one of the 8 CS PHBs.
Note that a DS node must implement all four AF classes. Although the AF standard does not specify how excessive bandwidth above the minimum allocation should be shard, implementation must describe the exact algorithm for allocation and configuration. Moreover, the Diffserv architecture does not define end-to-end services. Network service provider needs to mutually agree with their customers on service level agreements (SLA).
3. ATM Services Categories (ASC)
ATM technology is intended to support a wide variety of services as well as to satisfy various users’ quality needs. As defined by the ATM Forum, the different types of services are categorized into four service classes: constant bit rate (CBR), variable bit rate (VBR), available bit rate (ABR), and unspecified bit rate (UBR). In the service architecture provided at the ATM layer, CBR and real-time VBR connections have stringent delay and cell loss ratio (CLR) requirements. The offering of this service over ATM network is designed for circuit emulation, which requires a constant bandwidth capacity for each call. A typical example is 64 Kbps voice as in PSTN to be
transported over ATM. The traffic rate for a VBR connection may fluctuate around its average rate but not exceed its peak cell rate (PCR). ATM technology allows flexibility in the selection of connection bit rates and enables the statistical multiplexing of VBR traffic streams. The high bandwidth offered by ATM networks makes multimedia applications, such as variable-bit-rate audio/video transport, feasible. In addition, variable bit rate transmission allows more efficient use of network resources and increases multiplexing gain. Since many data applications are unable to precisely specify their traffic parameters such as bit rate, these applications generally require a dynamic share of the available bandwidth among all active connections, they are called available-bit-rate (ABR) service. The traffic rate for an ABR connection can be adjusted, and its minimum cell rate (MCR) is specified. ABR service is not expected to support real-time applications. Cell delay variation is not controlled in this service. An UBR source may send as fast as it desires (up to its PCR), but the network does not guarantee any QOS for it. ATM networks mainly supports absolute services except UBR.
ATM networks are designed to provide end-to-end transport of user data with specified QOS, which is expected to satisfy through effective traffic control. When the network receives a new connection request associated with traffic descriptors and performance parameters, the connection admission control (CAC) procedure is executed to decide whether to accept or to reject the call. The ATM end system can specify traffic descriptors [10] including peak cell rate (PCR), maximum burst size (MBS), sustainable cell rate (SCR) and minimum cell rate (MCR) to concretely describe the intrinsic source traffic characteristics. Since a new connection request will be accepted if the network has enough resources to provide the QOS requirements of the connection without affecting the QOS already established in the network. Hence, when a new connection request satisfies the above two conditions, the CAC procedure must further decide whether admitting the new connection causes the QOS violation of existed low priority connection or not.
In the following, discussions of ATM service type with the associated traffic descriptors are presented.
z Constant bit rate (CBR) service: This service category is used by connections that request a static amount of bandwidth that is continuously available during the connection lifetime. This amount of bandwidth is characterized by a peak cell rate (PCR) value. In the CBR capability, the source can emit cells at the PCR at any time. The performance parameters are characterized by CTD and CDV and. the cell loss CLR.
z Real-time variable bit rate (rt-VBR) service: This service category is intended to support real-time applications. An rt-VBR connection is
characterized in terms of PCR, SCR, and MBS. Sources are expected to transmit at a rate that varies with time or at “bursty”.
z Nonreal-time variable bit rate (nrt-VBR) service: This service category is intended for nonreal-time applications that have bursty data without delay sensitivity. This service is characterized in terms of a PCR, SCR, and MBR. In addition, it expects a low cell rate.
z Available bit rate (ABR) service: The ABR service is not to support real-time applications. On the establishment of an ABR connection, the end system specifies to the network both a PCR and MCR.
z Unspecified bit rate (UBR) service: It is intended for non-real time applications such as file transfer and e-mail. The UBR service category does not specify traffic-related service guarantee. The UBR service category is enhanced with an associated per-hop Behavior Class Selector (BCS) value. In [14], the specification defines a mechanism by which a UBR connection may be associated with one of a set of network-specific behavior classes. The behavior class is indicated via the Behavior Class Selector (BCS) parameter. The mechanism we will describe in the next section. Table 1 shows the parameters needed for ATM service category.
Rate Delay Loss
CBR PCR CTD&CDV CLR
rt-VBR SCR CTD&CDV CLR
nrt-VBR SCR no guarantee CLR
ABR MCR&ACR no guarantee CLR
UBR no guarantee no guarantee no guarantee Table 1: The parameters for ATM service
category
4. Diffserv over ASC
Before discussing the service mapping between Diffserv and ASC, it is certainly to distinguish the supported services between Diffserv architecture and ATM network. Then we discuss how ATM supports Diffserv and how Diffserv defines the services.
4.1 Differences between Diffserv Architecture and ATM network
First, Diffserv can support both absolute and relative services, while ATM QoS objectives are always absolute. The absolute QoS is that the QoS
commitment of one connection is defined solely and is not relative to the service provided to any other connection. In contrast, the relative QoS may be influenced by the services of other connections. Second, per-hop behavior is the basic component of the Diffserv architecture but ASC is based on end-to–end notion. A particular PHB can be used to build a variety of services depending on other factors, e.g., the traffic conditioning rules implemented at the edge nodes. PHBs may be mapped to any appropriate
ASC. Third, the Diffserv architecture supports service differentiation among aggregated flows. Traffic flows are classified upon ingress nodes and interior nodes determine the correct PHB and thus need not provide per-flow discrimination. In the following, according to the absolute and relative services, we discuss the service mapping between Diffserv and ATM.
Application Example IP ATM IP-based services (Examples ) PHB Service category Parameter mapping Virtual leased line
(VLL) Premium service EF CBR or rt-VBR Peak rate ÆSCR, PCR
Voice and video Real-time service AF
(one of the AF classes) ABR,GFR or nrt-VBR CIRÆMCR Voice and video Real-time service (one of the AF classes)AF rt-VBR or ABR parameters to be mapped Application specific
to PCR,MBS and SCR
VPN Olympic service AF
(three of the AF classes) UBR BCS values
Table 2 : examples of IP-based service to ATM service mapping
Internet service :
Service based on AF PHB ATM service: VBR Policing
Strict control of the assured traffic descriptor. Violation results in degradation
of transport quality to best effort for the violating packets.
Strict control of the “SCR” and “MBR” traffic descriptors. Violation results in degradation of transport quality to best
effort. Traffic descriptors
Assured packet rate Maximum burst size
Peak cell rate > sustainable cell rate; maximum burst size
QoS
Moderate loss, delay. Best effort other packets
Low loss guarantee and moderate delay for the traffic up to SCR/MBS.
Best effort up to PCB
4.2. Absolute Services
Since the Diffserv does not include service definitions, the solutions of how to map an IP quality of service/class of service to an ATM service category is depend on the granularity of services. A network provider/Internet service provider has the flexibility to define those services that suit to the user requirements. To support absolute service, the choice of the service mapping between ATM and Diffserv should be based on QoS measures. For example, a delay-sensitive service based on Diffserv can be mapped to one of the real-time ATM service categories. As a result, a different service mapping within the network providers will occur. Although [12,13,14] does not provide a precise criterion to map an IP absolute service to an ATM service, it can consider the mapping according to traffic policy, traffic parameters and QoS characteristics. For example, the premium service (e.g., virtual leased line) could be mapped to the CBR service category in order to meet its low loss and delay. Table 2 shows examples of IP-based service to ATM service mapping [12,13,14]. Table 3 is an example of IP service based on AF PHB plus policing and QoS may map to ATM service VBR.
4.3. Relative Services
A characteristic of a relative service is that no service request needs to be denied due to lack of resources. Performance may be allowed to degrade as the increase of resource competition. It depends on relative treatments, which is identified by assigning different DSCP. Because ATM UBR does not guarantee QoS characteristics, UBR service category is well suited for this type of behavior. To support relative services, ATM Forum has proposed Differentiated UBR to support differentiated service [10].
To support Diffserv, multiple UBR virtual channel connections are established between each pair of ATM-attached IP devices. Behavior class selector (BCS) is proposed to be a function module in ATM network. DSCP in the packet header will be translated into a BSC value. Then, according to the BCS value, BCS will select a corresponding cell switch behavior for a virtual channel. The translation from DSCP to BCS value is shown in Figure 3.
5. Conclusions
Since ATM has been widely deployed in Internet backbones, such as TANET, service mapping between Diffserv over ATM network is an important issue. In this paper, we describe how ATM supports Diffserv that can support both absolute and relative services. For absolute services, there is no particular service-to-service mapping between Diffserv and ATM. To support the relative services of Diffserv,
ATM UBR service category is well suited for this type of behavior. The ATM-based Internet is popular in the world. The service management of ATM and Diffserv is more important. Because the Diffserv does not include service definitions and its services definitions are heuristic, there seems need to consider ATM network in the service definitions of Diffserv for performance assurance and network utilization. The mapping between Diffserv and ATM is under way. We will observe the development continuously.
6. References
[1] Zheng Wang, Internet QoS--Architecture and Mechanisms for Quality of Service, Morgan Kaufmann Publishers, 2001.
[2] B. Braden,., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [3] J. Wroclawski, “The Use of RSVP with IETF
Integrated Services”, IETF RFC 2210, September 1997.
[4] J. Wroclawski, “Specification of the Controlled-Load Network Element Service”, IETF RFC 2211, September 1997.
[5] S. Shenker, C. Partridge and R. Guerin, “Specification of Guaranteed Quality of Service”, IETF RFC 2212, September 1997.
[6] K. Nichols et. al., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, IETF RFC2474, December 1998.
[7] S. Blake, et. al., “An Architecture for Differentiated Services,” IETF RFC2475, December 1998.
[8] J. Heinanen, et. al., “Assured Forwarding PHB Group,” IETF RFC2597, June 1999.
[9] V. Jacobson, et. al., ”An Expedited Forwarding PHB,” IETF RFC2598, June 1999.
[10]ATM Forum “Traffic Management Specification version 4.1,” AF-TM-DIFF-0121.000, March 1999.
[11]ATM Forum, “Differentiated UBR,” AF-TMP-0149.000, July 2000.
[12]ATM Forum, “Enhancements to support IP Differentiated Services and IEEE 802.1D over ATM,” BTD-TM-DIFF-01.02 draft, November 1999.
[13]ATM Forum, “Enhancements to support IP Differentiated Services and IEEE 802.1D over ATM,” BTD-TM-DIFF-01.03 draft, February 2000.
[14]ATM Forum, “Enhancements to support IP Differentiated Services and IEEE 802.1D over ATM,” BTD-TM-DIFF-01.04 draft, May 2000.
