Sitaraman VR


This is a survey paper on IP QoS over ATM. It describes the need for QoS in the Internet and the mechanisms of QoS provisioning in IP. ATM is briefly described with a view to highlight its inherent support for QoS. Then, mechanisms of providing IP QoS over an ATM network are considered. Also issues that arise in implementing the various IP QoS over ATM is considered.
See Also: Quality Of Service in Data Networks: Protocols and Standards| QoS in Data Networks:Products| QoS in Data Networks (Lecture by Prof. Jain) | Books on Quality Of Service| Quality Of Service Over IP References|
Other Reports on Recent Advances in Networking
Back to Raj Jain's Home Page

Table of Contents


ITU-T recommendation defines QoS as “The collective effect of service performance which determines the degree of satisfaction of a user of the service”. This degree of satisfaction is expressed by all r some of the following quantitative measures: End –to-end delay, delay variation or jitter and throughput. The process of providing this QoS requirements is called provisioning.

QoS was not one of the strong points of IP, but it now finds itself in need of it badly. IP is currently a best-efforts service. With the current boon in Internet usage especially due to its proliferation into business, there is a greater and more urgent need for ISPs (Internet Service Providers) to be able to provide QoS. This means providing different treatment to different customers and to be able to guarantee certain levels of service quality according to the users needs and the size of their wallets. Several methods are under discussion for such QoS provisioning.

ATM was “designed for QoS “ so to speak. ATM allows point to point and point to multipoint virtual circuit to be requested with pre-specified QOS. ATM provides a rich set of QoS mechanisms with a wide variety of service categories or QoS descriptors which offers a fine control over the traffic parameters requested and managed. ATM offers a sophisticated signaling mechanism that can be used effectively by any agent that needs to take care of QoS provisioning.

If ATM is available then IP can thus take full use of it in providing QoS. Given there is a large effort currently being made to incorporate QoS in IP, it would be wise to take full benefit of any inherent support for QoS in an underlying layer. This is especially true if that underlying layer is ATM. Moreover the many ISPs are already using ATM in their backbones. It is this topic, IP QoS over ATM that this survey paper addresses. The paper begins by first discussing QoS mechanisms that have been proposed for IP. These are Intserv, RSVP, diffserv and MPLS. Then it surveys the work that has been done on providing these QoS mechanisms over ATM.

Back to the Table of Contents.


This section will discuss the QoS mechanisms that have been proposed for IP, namely IntServ and DiffServ. A light general introduction to IP QoS can be found at [ Trillium]

Back to the Table of Contents.

MPLS is Multiprotocol Label switching. This is essentially a scheme to forward packets efficiently and therefore speedily. For MPLS a header between the layer2 and layer3 header is introduced. MPLS capable routers just look at this header in making a forwarding decision. This header consists of 20-bit label, a 3-bit Class Of Service field(COS) a 1 bit label stack indicator and an 8-bit TTL field. An MPLS capable router is termed as a Label Switched Router (LSR). The routers do not care what the network layer protocol is, they only need to look at the MPLS label. This is why it is called a Multiprotocol switching. MPLS needs a protocol to follow in distributing the label and to enable to router to understand the label to create paths and forward packets. Two protocols could be used for this, Label Distribution Protocol (LDP) or Resource Reservation Protocol(RSVP). The issue of which is more preferable is still being debated. A set to IP packets that need to be forwarded the same manner are said to belong to a single Forwarding Equivalence Class (FEC)

MPLS supports domains, hierarchical routing and can be used for tunneling. Domain boundaries are defined by boundary routers which inserts the appropriate label onto a stack, which is removed by the egress boundary router. A route can be explicitly specified by a router. During tunneling the ingress Label Switched Router defines the entire Label Switched Path through the tunnel.

Intserv is aimed at providing real-time services and an ability to share dynamically the available link capacity in a controlled manner. These services would be in addition to the currently available best-effort services. Real time QoS is essential for applications such as video conferencing. ISPs would need to be able to divvy up the available bandwidth (BW) into several classes with a certain minimum assured bandwidth to each of the classes. ISPs would also need to be able to allocate any unused bandwidth appropriately if there are users waiting for it. This would need controlled link sharing.

Intserv involves a fundamental change in that it extends the current architectural model on which the Internet is based, this extension has been called IS extension (Integrated Services Extension). There are three such fundamentally important extensions: The IS extended routers now would have to maintain flow state, routers will have a capability to reserve resources, and the resource controlling mechanism will be explicit. Such a control involves scheduling, classification and admission control all done at the router. It has been proposed that such traffic control be primarily implemented by a combination of Weighted Fair Queuing, and Priority Queuing.

Several types of services are provided by the Intserv service model. It allows for the provision of quality of services for the individual flows or for aggregate flows. The individual flows are essentially based on time of delay. The aggregate flow services are primarily based on divvying up the available BW among flow aggregates. Packets can be marked preemptable. Other components of the service model such as usage feedback and the reservation model, which deals with the question of how exactly the application requests reserves and how the network grants them, are all still under consideration.

Intserv model used the Resource Reservation Protocol (RSVP) for setting up the reservation. RFC introducing IntServ architecture is [ RFC1633] more details can be obtained from that source and the list of bibliography that it gives.

Integrated services for the Internet has two broad classes of Quality Of Service: The Guaranteed Services (GS) and the Controlled Load Services(CLS). The specifications of these services can be found in [ RFC2211]and [ RFC2212]respectively. These services differ in how tight a guarantee the services provide. Controlled load service provides less tight guarantees. The user gives a traffic specification (TSPEC) in order to request the controlled load service. All that this service does for the applications is provide an assurance that, for the requested traffic specification, a very high fraction of the data transmitted will experience a delay close to the minimum delay seen. The packets can expect to find conditions very close to that where the network is not congested. Guaranteed Service on the other hand provide tighter guarantees. The application provides information about its token bucket for IP datagrams. This is given in terms of bucket size in bytes and token rate in terms of bytes/sec. The application also gives it peak IP datagram rate. Guaranteed Service will accept the traffic only if it can assure the application of a guaranteed upper bound on the maximum delay that the datagrams will experience. This delay is only the queuing delay and the application must also add the fixed delay to the queuing delay in order to estimate completely the actual delay the packet will experience.

Intserv however puts a lot of demand on the routers. routers must now store state information and it increases in direct proportion to the number of flows. The functionality required of the router increases too. The routers must now understand RSVP, must make more decisions on accepting flows, and must implement queues in order to classify and provide appropriate services to the flows. The next section considers a scalable service scheme, which does not put so much demand on the routers, the differentiated services, or Diffserv.

Back to the Table of Contents.

Differentiated services aims at providing differential treatments to flows or aggregates of flows by using the Type of Service bye in the IP header. An introductory white paper on the subject by Intel can be found at [ IntelDS] Six bits of this byte is used for marking differential service classes. The low order two bits is currently unused. These high order six bits comprise the DS field. The differentiated services define a base set of behaviors or groups of behaviors called the per hop behavior. As the name implies this behavior could have purely local significance. Each PHB would correspond to a particular forwarding treatment meted out to the packets. These behaviors will in all probability be implemented by using appropriate queuing policies. The DS codepoints, as the DS field markings are called, will be mapped to the Per Hop Behaviors. Customers will then negotiate their Service Level Agreements (SLA) with their Internet Service Providers. This Service Level Agreement will detail what level of services the customer has access to and will be used by the provider in implementing their specific Per Hop Behavior Groups. These Service Level Agreement can even be dynamic. IP flows requiring the same diffserv treatment are called behavior aggregates (BA)

Diffserv is different form Intserv primarily in its level of aggregation, scalability and location of complexity. Intserv, as seen above would have to maintain state information on each of the nodes. This entails a large load especially on large on fast networks. Diffserv aggregates the individual flows at the core of the network, thereby taking the load of routers where it mattered most…at the core where traffic is the highest. Also Diffserv does not depend on RSVP like Intserv. The complex task of classification is undertaken at the boundaries where speed is relatively less important. Speed however is very important at the core routers and diffserv does not burden these routers with complex tasks. In Diffserv the classification of the packet and traffic conditioning takes place at the edges. These classification is more coarse grained than in the Intserv model. As mentioned before DS field in the IP header is used to mark the aggregates. Traffic conditioning involves metering, marking, dropping and shaping. In the core, the traffic is given differentiated treatment according to the per hop behavior defined for these marked aggregates. Diffserv maintains the ordering of the packets of


Figure 1:Diffserv Architecture showing core routers, boundary routers, and their main responsibilities.

the same microflow if they belong to the same Assured Forwarding class. Any set of behavior aggregates that are all constrained by the same ordering constraint have been termed Scheduling Aggregate (SA) or Ordering Aggregate (OA) . We will come across this terminology when we visit MPLS over ATM. Per Hop Scheduling Class (PSC) refers to one or more Per Hop Behaviors applied to the set of Behavior Aggregates forming a given OA. The figure above shows a high level view of the diffserv architecture and illustrates that the responsibility of classification and conditioning is pushed to the edge or leaf routers.

Diffserv is flexible. The services provided and traffic conditioning is sufficiently decoupled from the forwarding behavior at the core. Thus new services can be easily added to the existing ones. The interaction between the edge nodes where traffic conditioning is performed the core nodes would require some sort of a control or administrative entity, possibly with a protocol of its own. The Diffserv architecture does not specify or limit what this protocol ought to be.

Interoperability with non-diffserv nodes and multicast packets give rise to some special issues. Non Diffserv nodes can only be handled if they are nodes that implements IP precedence classification and forwarding [ RFC 791, RFC1812]. If they are not, then the behavior of those nodes is undefined if the DS field is non zero. While handling multicast packets it is difficult, especially when the group membership is dynamic, to predict how much resources will be required for the traffic. This makes it difficult to give quantitative assurances to the multicast transmitter. Also multicast traffic can infringe on unicast traffic if they are not sufficiently decoupled. It has been proposed that separate DSCP


Figure 2:The Differentiated services field formed out of the 8-bit IP TOS field. The low order two bits are Currently Unused (CU bits)

(Differentiated Services Code Point) for unicast and having separate 7 service level agreements for unicast and multicast traffic.

Possible security hazards could arise due to the inherent capability of differentiating services of the packets transmitted. Thus security screenings must be provided, primarily at the ingress nodes, to prevent unauthorized modification of the DS field. Such a modification could lead to illegal appropriation of the resources constituting denial of service to other peers.

The previous sections considered. QoS provisioning in IP networks in general. A popular forwarding scheme, MPLS was considered briefly. Two important service currently under study, Integrated Services and Differentiates Services were considered and compared. A signaling protocol that can be used to support these schemes is RSVP. The above treatment was general in the sense it did not assume any specific underlying network. The next section will deal with the specifics if the underlying network was ATM. As mentioned in the introduction ATM could be profitably used as it has a versatile QoS mechanism already built in.

MPLS aided Diffserv
This section will consider how differentiated services can be provided when the label switching mechanism is used by the routers to forward packets. Recollect that Forwarding Equivalence Class is an MPLS concept which groups together packets that need the same forwarding performed on them. Similarly, Behavior Aggregates and Ordered Aggregates are concepts in Diffserv which refers to packets that need to be given the same treatment and same ordering respectively. An Ordered Aggregate can consists of packets belonging to several Behavior Aggregates, i.e. Ordered Aggregates form a superset of Behavior Aggregates. Now when packets that have been marked by diffserv code points arrive at an MPLS network, there needs to be a way to transfer information provided by the code points onto the MPLS label somehow. This needs to be done if MPLS has to be able to make decisions that respect the differential service requirements for which the packets have been marked. In other words this would make MPLS diffserv capable.

When MPLS is run over, say, PPP, an additional shim header is added which is a label stack with possibly more than one entry. Also in MPLS there is a 3 bit EXP field that is free to be used for any miscellaneous purposes. Now, if we restrict the number of Behavior Aggregates to 8 then all these behavior aggregates can be bundled into a single MPLS LSP by using the 3 bit EXP field of the shim header. If more than 8 behavior aggregates are to be treated then a combination of packets belonging to several behavior aggregates may need to be bundled into the same LSP. It has been proposed that in such cases a combination of a Forwarding Equivalence Class and Ordered Aggregate be routed to the same LSP. The EXP field in the shim header is used as before.

Back to the Table of Contents.


IP and ATM could be complimentary rather than competitive. IP has gained widespread acceptance and is here to stay. However its simplistic architecture that enabled to achieve its unassailable position is the weakness that research groups are trying to address now. QoS is one such important weakness of IP. However ATM boasts of an architecture which has relatively sophisticated methods of providing QoS. However due to reasons of cost, inertia and complexity ATM did not achieve its touted ethereal status. Thus the next step is obvious to make use of the complimentary strengths of IP and ATM by marrying them and hence, IP over ATM and QoS is an important offspring. Issues in implementing IP over ATM is described in [ RFC1932]. The hype aside, now to the technical issues involved in mapping IP over ATM. There are several general references available in this topic. [QosForumFaq]gives a faq on IP QoS. [ RFC2386] gives an overview of the QoS issues in the internet.

While ATM has its claims to providing QoS assurances, it however cannot do anything above layer 2. That means that all layer 3 flows that have been aggregated together cannot be differentiated by ATM, and thus they all end up competing against one and another for the same resources. Thus there is needed a way to implement finer granularity in the control of traffic flow, and this is best done in layer 3. This is where Intserv/RSVP and Diffserv come in handy.

This section will review the current state of affairs in the symbiotic interoperation of ATM and IP QoS architectures discussed in the previous section. First we consider IntServ over ATM and then Diffserv over ATM. MPLS support is then addressed. Many of these architectures rely to a lesser or greater extent on RSVP for signaling so we will visit RSVP over ATM issues in several parts of the section as we go along.

Intserv Over ATM

Classical IP over ATM is described in [ RFC2225]. This operational specification here allows for sending packets over ATM. A Logical IP Subnetwork (LIS) a section of the network whose routers and hosts are configured separately. Within the LIS the required address translation between IP and ATM is done by devices at the edge of a LIS using a protocol called ATM Address Resolution Protocol (ATMARP). Traffic that need to cross an LIS boundary necessarily has to go through an IP router, which is an ATM edge device whose underlying ATM network has been configured to belong to the LIS it is serving and possibly many other Logical IP subnetwork. This is shown schematically in figure 3. While [ RFC2225] does concern itself with IP traffic over ATM networks, it does not concern itself with providing QoS for such traffic.


Figure 3:IP Intserv packets pass through an intermediate ATM cloud. The Edge device takes care of the required address translation and speak both languages.

Intserv, as seen before, uses RSVP as a signaling protocol to provide QoS. Conformance to this Integrated service model is required if QoS provisioning is to be made for any IP traffic. Thus, when the IP protocol stack is implemented on top of ATM and such conformance to the Integrated Services model is to be ensured, there is a need to map RSVP signaling to ATM signaling. Such a mapping essentially consists of two problems, one involving QoS parameters that are used and the other the virtual circuit management. QoS specification in the Integrated services model is not identical to that in ATM. Thus a QoS translation needs to be done for IP QoS over ATM. IP traffic is aggregated into flows. ATM, in layer two, aggregates it further and assigns Virtual Circuits to these aggregates. Thus there arises the issue of which flow goes into which VC and how many such VC to create.

Now we will consider in brief some of the issues that are being worked on or needs to be worked on in integrating intserv/RSVP over ATM. More details can be obtained from the [ RFC2382]. This RFC gives a good treatment of the outstanding issues and therefore and parts of the following is based on this RFC.

A) Control and data message paths: In RSVP the PATH message installs the path that the data would take. This means that RSVP PATH message must follow the same path as that of the data. In the case of an underlying ATM cloud, the ingress and egress points of the cloud should be the same for both RSVP control message and data.

B) Service Mappings between Internet and ATM [ RFC2381]. As explained before, the Integrated Services for IP essentially consists of two service types apart from the best effort service: Guaranteed and Controlled Load Service. ATM services include Constant Bit Rate (CBR), rtVBR(real time Variable Bit Rate), nrtVBR(non real time Variable Bit Rate), UBR(Unspecifies Bit Rate) and (ABR)Available Bit Rate. The following mapping has been proposed between ATM and IIS for IP.

ATM Service Internet Integrated Service
CBR or rtVBR Guranteed service
nrtVBR or ABR(Minimum Cell Rate) Controlled Load
UBR or ABR Best Effort

B) QoS connections for RSVP over ATM: In the case of PVCs the end devices must provide services to assign several flows over a given VC. Care must be taken with PVCs so as to avoid underutilization of resources due to idle PVCs. PVCs are frequently set up such that if the available BW is less than that would be required if all the PVCs are simultaneously utilized. However while using Intserv/RSVP over ATM it needs to be ensured that all the QoS that has been granted is satisfied. Otherwise there would be no point in giving a QoS assurance.

C) SVCs allow flexibility but it has its attendant complexity. Cost and the time needed to set up SVC should be taken into account before deciding on using SVCs to route QoS traffic.

D) In order to support IP multicast it would be necessary to take advantage of the point to multipoint VCs. However there is a difficulty here. ATM UNI 4.0 allows only one service class for all the recipient VCs. Thus in order to allow the recipients to request different QoS, it would be necessary to have a separate VC for the recipient. This has the potential to give rise to scaling problems.

E) Short Cut using Next Hop Resolution Protocol (NHRP): When an ATM cloud consists of several Logical IP subnets, it is possible to use NHRP to go from a router in one subnet directly to a router in another subnet. But this would mean storing of an additional state information of the address mapping. The cost-benefit analysis of this is an open issue.

F) Simultaneous best effort service: The Intserv models do not allow dropping of non-conforming packets. This is to avoid denial of service security attacks. Implementing this on ATM is an issue still to be solved.

G) Variegated VCs: It has been proposed that ATM incorporate point to multipoint VCs where different VCs have different QoS requirements. Issues that are open here concern how the cells are dropped when traffic goes from a branch with QoS corresponding it a larger BW to one with a smaller BW. Early Packet Dropping has also been proposed wherein all cells of one packet are dropped before dropping cells from another packet. This would prevent a large number of packets being rendered useless at the same time as opposed to just a few.

H) A less complex signaling mechanism has been proposed to reduce the overhead.

I) Dynamic QoS renegotiations: RSVP allows such dynamic changing of reservation parameters. It would be better integration of ATM does the same too. Some headstart has already been made in that PCR can now be changed dynamically

J) Mapping to group addresses: This would be needed to provide the many-to-many communication available in IP.

I) QoS routing: It has been proposed that RSVP while asking for the next hop for a given destination address it could also provide information regarding the QoS requirements to the routing protocol. The routing protocol can then factor in this information in arriving at routing decision. PNNI routing has also been considered for providing QoS routing [ RFC2386]

J) Mapping QoS parameters: QoS parameters need to be mapped from the ATM model to the Intserv/RSVP model. Complications can arise here due to differences in implementation methods possible, policy mismatches and cost issues. There is a need to come up with a matrix of possible mappings for various networks.

I) Policy: CAC mechanisms fit well with IP policy mechanisms. Some policies unique to IP over ATM could be not allowing a dynamic change of QoS over certain VCs.

This section began by considering the general architecture of and IP over ATM network with support for the integrated services model. The role of the edge routers was described. A proposed mapping between ATM QoS and IP QoS was provided. Then several outstanding issues in providing Integrated Services for an IP network over ATM. The next section will deal with providing Diffserv over ATM.

Back to the Table of Contents.

Diffserv over ATM

This section will deal with the issues when Diffserv is to be run over an ATM network or when diffserv packets need to pass through an intermediate ATM network. Diffserv specifies the traffic parameters as Per Hop Behaviors and says nothing about the services that are provided. The specific services are left for the service providers to craft based on the Per Hop Behaviors available. However, ATM specifies the service available at the User Network Interface and leaves the user to alter the traffic parameters accordingly. Mapping the ATM QoS parameters to the IP differentiated services so the end to end guarantees are maintained is not an easy task.

Two important per hop behavior has been defined by IETF for diffserv. Expedited forwarding (EF) PHB [ EF]assures bandwidth availability irrespective of other traffic sharing the link. This PHB provides facilities for peak rate specification and traffic policing. This service is similar to that provided in ATM CBR or rt-VBR. This Assured Forwarding (AF) [ AF] assures a certain minimum amount of available of BW. Assured Forwarding itself consists of four sub classes of traffic. AF PHB is then similar to ABR and nrt-VBR of ATM.

However the mapping, taken as such, is not identical. ATM provides end-to-end BW guarantee. Neither does EF or AF have connection admission control. Diffserv is designed to avoid flow control at small levels so as to impart scalability in the amount of work that the core routers need to perform or the amount of state information it needs to store. Providing end-to-end services is not a trivial task with diffserv as it has be implemented as a concatenation of several PHBs. The proposed mappings are shown below in the following tables. These tables are from [ ATMF99-205]

Table 1. Differentiated Services and their Corresponding ATM services

Descriptor Differential Internet Service Matching ATM service Matching ATM service
Name Premium service and other services
based on EF PHB
Policing Strict control of traffic descriptor. Violation results in discard. Strict control of traffic descriptor. Violation results in cell discard. Strict control of traffic descriptor. Violation results in cell discard.
Traffic descriptors Peak Packet Rate
Maximum Packet Size
Peak Cell Rate
Cell Delay Variation Tolerance
Peak Cell Rate
Cell Delay Variation Tolerance
Sustainable Cell Rate
Maximum Burst Size
QoS Low Loss and low delay guarantee; Suiting real time requirements Class 1: Low loss and low delay guarantee; Suiting real time requirements Class 1: Low loss and low delay guarantee; Suiting real time requirements
Buffer policy Highest Priority Queue
(or similar)
Depth 1 or 2 packets
Highest Priority Queue
Depth ca. 100 cells
Highest Priority Queue
Depth ca. 100 cells

Descriptor Differential Internet Service Matching ATM service Matching ATM service
Name Services based on AF PHB VBR3 GFR
Policing Strict control of the „Assured" traffic descriptor. Violation results in degradation of transport quality to best effort [DSOP0] for the violating packets Strict control of the "SCR and MBS" traffic descriptors. Violation results in degradation of transport quality to best effort. Cells above PCR will be discarded. Strict control of the "MCR, MFS and MBS" traffic descriptors. Violation results in degradation of transport quality to best effort. Cells above PCR will be discarded.
Traffic descriptors Assured Packet Rate; Maximum Burst Size Peak Cell Rate Sustainable Cell Rate; Maximum Burst Size Peak Cell Rate Minimum Cell Rate; Maximum Frame Size, Maximum Burst Size
QoS Assured component (marked): moderate loss delay.
Best Effort (mark removed) other packets
„Class 3 (bi-level)": Class 2 service (low loss guarantee and moderate delay) for the traffic up to SCR/MBS. Best Effort (Class U) up to PCR. „Class 3 (bi-level)": Class 2 service (low loss guarantee and moderate delay) for the traffic up to MCR/MFS/MBS. Best Effort (Class U) up to PCR.
Buffer policy Second Priority Queue (or similar), shared by assured & best effort traffic. Discard threshold for best effort traffic much lower then that for assured traffic. RIO-RED. Second Priority Queue, shared by Class 2 traffic & Class U traffic. Discard threshold for best effort traffic much lower then that for Class 2 quality traffic. (Some implementations may support EPD). Note 2 Second Priority Queue, shared by Class 2 & Class U traffic. Discard threshold for best effort traffic much lower then that for Class 2 quality traffic. (EPD or PPD should be supported). Note 2

Descriptor Differential Internet Service Matching ATM service
Name Best Effort UBR
Policing None None
Traffic descriptors None None (informative Peak Cell Rate proposed by specification to support network planning)
QoS Best Effort Best Effort (Class U)
Buffer policy Lowest Priority Queue. Discard Threshold for best effort traffic much lower than that for any other traffic. Lowest Priority Queue. Discard Threshold for Class U traffic much lower than that for any other traffic.

Diffserv over ATM would necessitate a mapping of the IP header to a VC, which can read frame boundaries. Also a mapping between the DS code point (DSCP) and the PHBs need to be identified.

Some of the issues in providing interoperability between ATM and Diffserv will now be considered.

A) Permanent VPs with QoS. This is easy to implement but may lead to a wastage if the link is underutilized.

B) Mapping with SVCs Each new IP DS connection is carried by a separate ATM SVC. Though this method does not cost in terms of unused BW, however, does increase the set up time and could lead to a VC explosion. RSVP can be used to implement this method.

C) Role of router topology in deciding simplicity of Connection Admission Control (CAC): CAC complexity increases with the router network topology.

D) Bandwidth can be used more economically: This is achieved by letting best-efforts/UBR traffic to consume unused resources that were occupied by the original ATM VP.

E) New Communication Protocols needed: Diffserv makes use of what are called Bandwidth Brokers to maintain a database QoS requests from the members of a domain and act as an ambassador to facilitate communication with external domain as regards to resource management and traffic control.. In order for IP QoS over ATM to work the ATM management system must communicate with the bandwidth brokers for Diffserv. Protocols are needed for this.

F) Address Mapping: Permanent ATM connection are mapped to individual VCs. VPs may also be used between the end users to map the aggregated IP addresses, while the individual DSCP address of the flows will then be mapped on to the corresponding VCs of that VP. The advantage of this option is that it is required for SVCs anyway and the scalability property is better too. The resources granted to the individual VCs then are limited by the resources allotted to the VP to which it belongs.

Now we will look into what are the actions that need to take place at the ATM switch for DiffServ over ATM [ ATMF99-204]. These actions can be broadly classified as bandwidth provisioning, relative resource allocation, and priority control. We will consider them one by one in the following..

Bandwidth provisioning VCs are mapped and threaded through a sequence of Per Hop Bandwidth Aggregates(PHBA). The threading is necessary because the PHBAs are not end to end but only hop to hop. The binding of VCs to PHBAs is done by a Behavior Class Selector.


Figure 4:Per Hop Behavior Aggregates mapped to VCs in a switch with 3 ports. Each port has two Per Hop Behavior Aggregates and two Behavior Classes.

The figure shows the mapping of PHBA to Virtual Circuits. 1,2,3 are ports. X and Y are separate Behavior Class Selectors (BCS). PHBA6/Y etc. are PHBA configuration, here stating that the aggregate no. 6 with the BCS identifier Y. Five Vcs are shown in the figure. The function of the BCS is that it defines which PHBA is mapped on the output port. Incoming Vcs from port 1 are routed to port 2 and those from port 3 are routed to port 1. The actual mapping can be done by setting up a PVC or by using signaling to create to SVCs. The DSCP can be mapped now to the BCS number. All VCs within a same PHBA can be allocated the same UBR service category. It is assumed that the competition among the VCs within a PHBA will be fair.

Figure 4 shows one such PHBA configuration over an intranetwork. The network


Figure 5:PHBA configuration for an intra network consisting of two BCSs X and Y

has two BCS and each link has that many number of PHBAs (two in this case) associated with it. The scalability of Diffserv is also evident from this. Thus the node involved in routing would just need to pick an appropriate PHBA to forward the packet to. The actual computation of the route can be done using traditional ATM’s PNNI.


Relative Weighting of VCs within a service category: ATM does not inherently support such a differential weighting within a service category. This is achieved by creating a number of VC classes with no predefined QoS parameters for the VCs. These VCs use the UBR service category. The network operator then manually configures the resource weights for the classes. It is these resource weights that enable the provision of services that are relatively weighted.

Priority Queuing: The traffic class is determined from the BCS value corresponding to the VC. Cells from a particular queue belonging to a traffic class is selected for dispatch only if the queues corresponding to numerically higher values of traffic class (higher priority) are all empty.

To summarize, features of Diffserv over ATM implementation as proposed in are the following
* Support for AF, and 802.1D user priorities
* Uses UBR for the VCs
* Now new service category need be created
* Current ATM switches emulate Diffserv Router
* Individual VCs are signaled with BCS for each of those VCs.
* No bandwidth signaled for PCs.

Recently it has been suggested that the BCS will not be sufficient. ISPs would be serving several customers at a time. BCS can only identify the PHBA-VC pair given a port number at the node. However it cannot identify the individual customers, which is what the ISPs would want to do. An open issue here is that [ ATMF99-091]

Who has a say in how much buffer space and bandwidth is allocated at the edge devices? It could be the edge device itself or the job could be left in the control of the network operator. The authors here argue that in the case of multiple customers the control is better left to the edge devices. The reason being that if there are many customers handling and coordinating all the BCS, this would cause too much overhead at the ISP equipment side. The multiple customers must also be isolated from each other. This might again call for a “bundling” of VCs from a particular customer or for each source-distinct destination pair of a customer. End to end service creation is also a goal the achievability of which is not very obvious. These issues have not yet been addressed properly and are still being hotly debated..

Back to the Table of Contents.

MPLS aided Diffserv over ATM

Before we discuss MPLS aided QoS, we will first talk briefly about the interoperability of label switching and ATM first. The introductory internet drafts for MPLS is [ MPLS1] Then we consider diffserv over ATM MPLS.[ Wu-mpls-diff-ext-01]. We begin by considering the issues when using ATM hardware to build a label switch. Since the label swapping is done on the cell header the size and placement of the labels in the packet is that much constrained. Since point to multipoint and multipoint –to-multipoint VCs are not supported usually, VC-merge cannot be done. TTL cannot be decrement as in IP headers.

[MPLS1] gives a discussion of Label Switching with ATM switches. Fundamentally the operation of ATM switches is very simlar to that of label swithches. However with MPLS and ATM interoperability demands that the MPLS labels be somehow encoded into fields that the ATM switch can recognize. ATM switches that can do this are called ATM-LSR (ATM Label Switch Routers). Note that unlike the case discussed for PPP, ATM does not use a shim header. What has been proposed [MPLS1] is that the a combination of VPI/VCI fields be used for this purpose to encode one or more label stacks. It is very possible to encounter a situation where different ATM-LSRs will use different encoding techniques. However, ATM swithces do not posses the ability to translate encodings. Thus if MPLS is to be used then successive LSRs should necessarily use the same encoding. Switches that are capable of both using the VPI/VCI field to encode the label and of using a shim header would be necessary in the case of networks that have both ATM switches acting as Label Swithced Routers and other Label Switch Router that use only a shim header. ATM swithches may have an option of taking the label of packets which could all be different but need to be all forwarded onto one Forward Equiavant Class. This would mean that the different labels on the packets will be replaced with an identical one. This process is called VC Merge and the swithces that do this are called VC merge capable Label Switched Routers.

The MPLS header, as seen before, should be invisible to layer 2 protocols. ATM should not see the MPLS header directly. It has been proposed that that a separate Label Switched Path be created for each Forwarding Equivalent Class/Scheduling Aggregate pair. Diffrentiation in treatment of packets from different behavior aggregates would have to be implemented by maping the CLP bit to drop precedence. Thus when the underlying technology used is ATM. it can only support two levels of drop precedence. However, by making use of the EXP field in the shim header for the top label stack entry, support for all the drop precedence can be provided in PPP MPLS clouds that may surround an ATM MPLS cloud.

implemented per Forwarding Equivalence Class, Scheduling Aggregate pair, as opposed to 8 were the EXP field of a shim header be used.

The essential stages involved in Diffserv label switching are details can be had from [ Wu992]

A) Incoming Per Hop Behavior and Forwarding Equivalence Determination

B) Outgoing Per Hop Behavior determination by local policy and traffic conditioning(optional)

C) Outgoing EXP field and label determination.

Extensions have been proposed to the protocols, LSP and RSVP, that are used in establishing a Label Switched Path.The Per Hop Scheduling should be signaled in the MPLS label request messages. New message formats have been proposed for RSVP and LDP signaling protocols. The new RSVP format is shown in figure below. This is an object class defined as class of service.

Fig5 a)The new LDP Time-Length-Value field and the b)RSVP Object format.


Figure 6 a) shows the fields for the new LDP format and Fig. b shows the same for RSVP.

This object can be carried in the PATH message that carries the label request object to indicate the PHS for which a label is required. It can also be used in the RESV messages carrying the label object indicating the PHS for which the label is to be used. All LDP messages have a common structure and uses what is called a Type-Length-Value encoding scheme (TLV). It has been proposed to encode the above illustrated PHS TLV as a nested TLV in the COS value of the COS TLV. The advantage of this is that future additions of new TLVs can all be grouped logically inside the COS TLV. New security mechanisms have not been proposed specific to this implementation. Thus it retains only the mechanisms available in DiffServ, MPLS and RSVP.

Back to the Table of Contents.


QoS provisioning in the Internet is topic that has been rightfully getting some urgent attention from the networking community. The most popular ones heading for standardization now are DiffServ and InterServ which promises to provide QoS, possibly end to end in IP. While engaging in the effort to standardize the technical specifications are in a state of flux and evolving. On the other side of networking field ATM is establishing for itself a niche, at least for now, in the ISP backbones and in these regions the network engineers are concerned with the interoperability of IP over ATM. While this has been done pretty much done, the challenges lie in making effective use of the inherent capabilities of QoS mechanisms in ATM when running IP on top of it. Such measures, specifically Intserv and DiffServ and MPLS-DiffServ over ATM were considered along with the interoperation of the signaling protocol RSVP (RSVP is much simpler that the ATMs native signaling protocol). Issues that have been addressed and the open issues were stated from the literature.

Back to the Table of Contents.


References used in this paper:
  1. [qosforumfaq] http://www.qosforum.com/docs/faq/ This is QoS forums Web Site Gives a list of FAQs on QoS.
  3. [RFC 791] "Internet Protocol Sept 1981", 45 pages, http://www.ietf.org/rfc/rfc0791.txt?number=0791 An early RFC on the Internet Protocol
  4. [IntelDS]
  5. [RFC 1812] "Requirements for IP Version 4 Routers", June 1995, http://tools.ietf.org/rfc/rfc1812.txtThis RFC gives the requirements for IP version 4 routers. Another early RFC.
  6. [RFC1633] "Integrated Services in the Internet Architecture: an Overview", 33 Pages, June 1994, http://tools.ietf.org/rfc/rfc1633.txtThis RFC gives and introductory overview of Integrated Services.
  7. [RFC1932] "IP over ATM: A Framework Document", April 1996, 31 Pages, http://tools.ietf.org/rfc/rfc1932.txtThis RFC talks about the various proposals for transmitting IP over ATM
  8. [RFC2211] "Specification of the Controlled-Load Network Element Service", 19 Pages, http://tools.ietf.org/rfc/rfc2211.txtGives a description of the controlled load service which forms a part of Integrated Services.
  9. [RFC2212] "Specification of Guaranteed Quality of Service", Sept. 1997, http://tools.ietf.org/rfc/rfc2212.txtGives a description of the guranteed service which forms a part of Integrated services.
  10. [RFC2225] "Classical IP and ARP over ATM", April 1998, 28 pages, http://tools.ietf.org/rfc/rfc2225.txtDefines the application of classical IP over ATM
  11. [RFC2381] "Interoperation of Controlled-Load Service and Guaranteed Service with ATM," August 1998, 43 Pages, http://tools.ietf.org/rfc/rfc2381.txtTalks about the interoperation of Controlled Load Service and Guaranteed Service with ATM
  12. [RFC2382] "A Framework for Integrated Services and RSVP over ATM", 30 Pages, August 1998, http://tools.ietf.org/rfc/rfc2382.txt Gives a framework of Integrated services/RSVP over ATM
  13. [RFC2386] "A Framework for QoS-based Routing in the Internet", Aug 1998, 37 Pages, http://tools.ietf.org/rfc/rfc2386.txtGives a framework of QoS based routing issues on the Internet
  14. [EF] [ RFC2598]"An Expedited Forwarding PHB", June 1999, 12 Pages, http://tools.ietf.org/rfc/rfc2598.txtIntroduces Expedited Forwarding scheme
  15. [AF] RFC2597 "Assured Forwarding PHB Group," June 1999, 12 Pages, http://tools.ietf.org/rfc/rfc2597.txtIntroduces Assured forwarding scheme
  16. [ATMF99-204] "ATM Signalling Requirements for IP Differentiated Services and IEEE 802.1D," Feb 1999, 5 Pages. This contribution talks about the ATM signaling requirements for IP differentiated services.
  17. [ATMF99-205] "Reference Models for ATM Support of Diffserv and 802.1D" Feb 1999. This contribution talks about the reference models for IP differentiated services.
  18. [ATMF99-091] "A Concept of VC-to-VP Mapping to Support Differentiated Services," Feb 1999, 6 pages. Proposes the school of thought wherein VPs are used to provide differentiated services.
  19. [MPLS1] "Multiprotocol Label Switching Architecture," Aug 1999, 62 Pages, Internet Draft. Provides and architectureal framework for MPLS and also talks about interoperability with ATM.
  20. [Wu991] "MPLS Support of Differentiated Services by ATM LSRs and Frame Relay LSRs," June 1999, 13 Proposes a method by which one could offer Diffserv with MPLS support on ATM
  21. [mpls-atm-02] "MPLS using LDP and ATM VC Switching", April 1999, 19 Pages, Internet Draft. Goes into more detail on interoperability with ATM and MPLS than [MPLS1]

Back to the Table of Contents.

Related WWW Links:
  1. Cisco, "IP to ATM Class of Service Design Guide," http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/ipatmdg.htm
  2. "Going the Distance with QoS: Tech Tutorial," http://www.data.com/issue/990207/distance.html," Data Communications (3/7/99)
  3. "Hot Topics in Networking References," http://www.cse.wustl.edu/~jain/refs/hot_refs.htm] ", A comprehensive set of links and references on almost every new networking topic.
  4. "The Internet Engineering Task Force," http://www.ietf.cnri.reston.va.us/home.html] ",
  5. "Tech Tutorial: DiffServ and MPLS," http://www.data.com/issue/981121/quality.html] ", Details and differences between two leading IP QoS protocols.
  6. "IETF DiffServ Working Group home page" http://www.ietf.org/html.charters/diffserv-charter.html,
  7. QoS Forum home page, http://www.stardust.com/qosforum/

Back to the Table of Contents.

Appendix B. ACRONYMS

MPLS:Multi Protocol Label Switching
ISP:Internet Service Provider
COS:Class of Service
TTL:Time To Live
IETF:Internet Engineering Task Force
LDP:Label Distribution Protocol
RSVP:Resource Reservation Protocol
FEC:Forwarding Equivalent Class
CLS:Controlled Load Service
GS:Guaranteed Service
PHB:Per Hop Behavior
PHBA:Per Hop Behavior Aggregate
SLA:Service Level Agreement
SA:Scheduling Aggregate
OA:Ordering Aggregate
PSC:Per Hop Scheduling Class
DSCP:Differential Services Code Point
LSP:Label Switched Path
ATMARP:ATM Adress Resolution Protocol
CBR: Constant Bit Rate
ABR:Available Bit Rate
UBR:Unspecified Bit Rate
SVC:Swithced Virtual Circuit
PNNI:Private Network to Network Interface
CAC: Connection Admission Control
NHRP:Next Hop Resolution Protocol
EF:Expedited Forwarding
AF:Assured Forwarding
BCS:Behavior Class Selectors
LSR:Label Switched Routers

Back to the Table of Contents.

Last modified November16, 1999.
Note: This paper is available on-line at http://www.cse.wustl.edu/~jain/cis788-99/ip_qos_atm/index.html