This document introduces an approach on areas, where and how an ATM transport layer could be used to support Differential Services for the Internet. The scope of this document is to give guidance on QoS interoperability. Traffic engineering aspects play a dominant role with respect to IP over ATM. This will not be disregarded by this document. A full discussion of DiffServ over ATM traffic engineering aspects is however clearly beyond the scope of it.
The term Differential Services for the Internet is used in the following to designate Internet services according to the document "An Architecture for Differentiated Services" [RFC2475].
The purpose of this document is purely informative. Neither are the recommendations given in the following in any aspect binding for Internet2 or QBone participants nor are they intended as such. This should also be respected when reference is made to this document.
Differential Services for the Internet as described by [2BiDS] and [RFC2475] allow the support of QoS differentiated services on an IP backbone network. The services described by [2BiDS] show some similarity to actual ATM service specifications. This allows to start a discussion on whether and how ATM could be used to support Internet Differential Services based on DS PHBs like [AF] and [EF]. Chapter 2 is focused on a direct comparison of the quality of service definitions introduced by [2BiDs] with the ATM service definitions of [I.356] and [I.371]. As ATM currently supports only so called "quantitative" services, the discussion will be limited to these.
This document proposes a DiffServ to ATM service interoperability for a WAN Router network based on ATM. The assumed network architecture is important to fully understand this document and will be discussed in chapter 3. There, also the standards situation is analyzed briefly. Some conclusions close the document.
While some architectural considerations are offered in this document, it is clearly centered on QoS interoperability issues. Traffic engineering aspects neither are fully ignored nor are they discussed at length. Some ideas on DS/ATM traffic engineering may be found in the following, however readers interested in a full discussion of the subject may prefer other sources.
The Differentiated Internet Services which may be based on [EF] and [AF] PHBs are partially similar to the most convenient ATM services of today's commercial ATM networks. This partial similarity is, at least in the case of "quantitative" Differential Services, also true with respect to the implemented buffers and their management. QoS related service interoperability is of major interest for those QBone participants operating their DS domains on an ATM infrastructure. Ignoring the issue may lead to a service degradation on IP level, even if there a full set of DS mechanisms is supported. Mapping DS Premium service to e.g. ATM UBR may result in packet losses and added jitter. Hence, a DS to ATM service mapping disregarding the QoS requirements could lead to a qualification as "fake" DS domain in the worst case."The most convenient ATM services" are meant to be:
CBR: offers real time service support and is characterized by a Peak Cell Rate (PCR) and a Cell Delay Variation Tolerance (CDVT). Shaping on both parameters is required at the ATM network access and both parameters are policed by the ATM network.
VBR3: also known as VBR+, SBR3 or even nrt-VBR (not quite in the sense of ATM Forum standards!). Consists of two components each supported by a different Quality of Service. For cells with a speed of PCR a packet of Maximum Burst Size (MBS) is given a low loss guarantee, if the average usage is not violating the Sustainable Cell Rate (SCR). The PCR is bigger than the SCR. Cells conforming to the PCR, but violating either MBS or SCR will be degraded to best effort quality (i.e. tagged by setting of the Cell Loss Priority bit). Cells violating the PCR will be discarded (note, that also here a CDVT exists). By "3" it is indicated, that the tagging will be done by the network ("2" would denote tagging by the user). No delay guarantees are given for either cell flow. In current implementations, both flows share the same buffer, so cell overtaking doesn't occur.GFR: Guaranteed Frame Rate [GFR] is the ATM Forum's first frame oriented ATM transfer capability. First implementations may be getting available in 1999. Similar to VBR3. Replace the notation of the SCR by the "Minimum Cell Rate" MCR. New is the notion of the Maximum Frame Size (MFS) which determines the MBS. The other innovation is a frame and cell based policing algorithm to ensure that only full frames are tagged or discarded. The quality and buffer management is the same as for VBR3.
UBR: offers a best effort service and should be characterized by a PCR.
The ATM policing mechanisms are specified based on Leaky Bucket algorithms. Many of today's commercial ATM switches operate with two different priority queues. The lower priority queue is usually shared by cells of different service classes.
Tables 3-1 to 3-3 give an overview on similar ATM and Differential Internet Services. The Quality of Service Class model of [I.356] was used to describe the ATM services. The author isn't aware of any support for this model by the ATM Forum. The clear structure and today's widespread implementation however favor the [I.356] model to describe ATM QoS differentiation. As unfortunately [I.356] doesn't offer any prose explanation of the QoS classes, a technical explanation is annexed to this document.
| Descriptor | Differential Internet Service |
|
|
| Name | Premium Service and other Services based on EF PHB | CBR | rt-VBR |
| 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 |
Table 3-1: Premium Differential Internet Service
| Descriptor | Differential Internet Service |
|
|
| Name | Services based on AF PHB | VBR3 (Note 1) | 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 |
Note 1: GFR implementations may be getting available in 1999 and should
be preferred..
Note 2: Different implementations are possible
Table 3-2: Assured Differential Internet Service
| 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.
Note |
Note: Different implementations are possible
Table 3-3: Best Effort Service
The Premium Service based on [EF] and Priority Queuing virtually can be matched one by one with the according ATM CBR service (table 3-1). Both are designed to guarantee low delay and loss, both require shaping on a peak rate at the network boundaries. Violation of the traffic contract results in discard and queue depth and priority are similar and the same respectively. A mapping of these services will introduce a small and constant ATM shaping delay which is depending on the IP packet length and the ATM link speed. The induced shaping delay would be decreased by using ATM rt-VBR (with PCR > SCR). It might however be difficult to find a router able to shape traffic on ATM rt-VBR.
No direct ATM match can be found for IP DSes based on [AF] PHB. ATM VBR3 or GFR match with regard to the targeted QoS classes (table 3-2). However the policing, traffic descriptors and the resulting buffer administration of VBR3 and GFR are more stringent: cells violating the "assured (SCR & MBS)" traffic contract will be degraded to best effort only up to a certain limit, above which further cells will be discarded. The same holds for GFR frames with regards to the parameters MCR, MFS and MBS. The [AF] PHB supports a second level of marking excess traffic instead of discarding it. But also the buffer policy is to some extent different. The assured service will experience RIO-RED (growing discard ratio after a certain threshold is passed), while the VBR3/GFR will offer no more than Early Packet Discard (discards full packets if a single threshold of a queue is passed for the best effort component; without EPD, single cells will be discarded).
The best effort service of IP may be mapped to the well known ATM UBR service (table 3-3).
If the EF as well as AF PHBs are supported by a single IP router, it would be quite easy to develop an additional service, which will be called Low Loss Service in the following. The idea behind this service is to shape and police the AF traffic as the EF traffic (also by the same network elements as for Premium), however use the same queue as the AF based services. With a conservative Call Admission Control, the resulting QoS still offers a low packet loss probability in the backbone, while the delay will be moderate but not always meet real time requirements. It could suite the needs of users who'd like to be sure not to loose packets in the IP backbone. The mapping of this service to an existing ATM service is simple (see table 3-4). As all components required to control such a service are required to support the EF and AF PHBs, the standardization of a Low Loss Service would be relatively simple.
| Descriptor | Differential Internet Service | Matching ATM service |
| Name | Low Loss Service based on AF/ Shaped | nrt-VBR, PCR = SCR (Note) |
| Policing | Strict control of „Assured" Traffic descriptor. Violation results in packet discard. | Strict control of Traffic descriptor. Violation results in degradation of transport quality to best effort until PCR is reached. Any traffic above PCR will be discarded. |
| Traffic descriptors | Assured Packet Rate | Peak Cell Rate (= Sustainable Cell Rate) |
| QoS | low loss guarantee and moderate delay | Class 2: low loss guarantee and moderate delay |
| Buffer policy | Second Priority Queue | Second Priority Queue |
Note: A better ATM description would be CBR with QoS Class 2
Table 3-4: A possible Assured Differential Internet Service with a discard
option
In general, a usage of ATM services to transport Differential IP Services aims to replace IP hops by ATM short cuts. In consequence, ATM to DiffServ interoperability is useful aiming on end to end (host to host) or edge to edge connectivity of IP routers.
Hop by hop ATM to DiffServ interoperability and a replacement of single leased lines by ATM connections is not favorable. Frequent parameter mappings and routing table configurations will most probably result in either performance degradation or an inefficient traffic management or both. Considering this, the number ATM to DiffServ interoperability points in any route should be low.An important aspect of [RFC2475] is the focus on aggregated DS traffic only. Plenty of literature and standards are available allowing per flow IP to ATM interoperability. Results and experiences made there will be considered only, if they prove to be useful for the DS aggregate to ATM interoperability.
+--------+Figure 1 shows a simplified network architecture of Internet2. It includes all relevant elements to be taken into account when considering the advantages of an ATM to DiffServ interoperability.
No assumptions are made on the type of link layer between campus networks and Edge Routers as well as the link layer of the non-ATM network. Communications leading to complex link routes (e.g. multiple hops between non-ATM and ATM connected Edge Routers) are left for further study. In the following, only communication of type campus A to campus B (utilizing only ATM as link layer between the Edge Routers) and campus A to campus C (utilizing ATM link layer between Edge Routers 1 and 2 and non ATM link layer between Edge Routers 2 and 3) will be considered.For ATM connections of best effort quality, support of Early Packet Discard is recommended for the ATM network.
As mentioned already, ATM connections should be used to minimize IP router hops. As long as just UBR is used on the ATM layer, a full mesh is easily to achieve by just linking all Edge Routers by virtual connections. Load and performance measurements are required to support provisioning.Before going into elaborate discussions on the possible application of DS to ATM QoS features, the simplest solution is introduced: To fulfill DS QoS requirements, the underlying ATM connection should be of the same or better QoS as any DS aggregate transmitted over it. If no DSCP based ATM routing is supported by a router, the ATM connection used by the whole IP traffic should then have the quality required by the most demanding DS.
More elaborate solutions are discussed in the following.
DiffServ to ATM issues
Permanent ATM QoS VPs are relatively easy to implement and do not require too much maintenance. As again fully meshed edge to edge Edge Router connectivity would be the design aim new constraints have to be considered. As no intra domain IP transits occur, the DS aggregate CAC may be simplified. However the ATM CAC has to be respected additionally. An economic network design will not allow a huge number of hardly used ATM QoS VPs, as this is simply too expensive. On demand ATM connectivity solves the problem. Address and QoS mapping issues will have to be respected. The main issue is however the dimensioning of the ATM connection. As mentioned earlier, DiffServ pipes are intended for aggregates of flows. Frequent changes of these DS connections are not to be expected. This means, they are somewhat over provisioned. Two options seem possible:The former of both options may be implemented based on RSVP [RFC2381]. It will not be discussed in more detail, as plenty of literature is available. As RSVP allows re-negotiation of required bandwidths during the active phase of an RSVP connection and ATM doesn't [RFC2381], there may be an important argument in favor of the latter of above options. A smooth operation will be possible if the IP DS domain BB and the ATM domain "IP using ATM" policy server interoperate too (or are one and the same). This interoperability is required to exchange the IP DS aggregate pipe dimensioning information with the ATM domain.On IP level, DS aggregates are policed and administered; on ATM level, each new IP DS connection triggers a new ATM SVC set up. The advantage is clearly a certain cost effectivity. But on the cost of a high VC consumption and ATM set up delays for each single IP DS connection. The IP DS aggregate bandwidth requirements between all edge routers are calculated as if there were no ATM. From these values, ATM connection dimensioning is calculated. A reservation based ATM network would require permanent connections, while a switching based ATM network would use the first incoming IP DS connection request as a trigger for the according SVC set up. In the latter case, the release of the last IP DS connection may trigger the release of the according SVC (to save resources). To effectively use the ATM resources, it his highly recommended to transmit Best Effort/UBR traffic in parallel. This ensures, that the reserved but unused quantities of the dedicated DS SVC are not completely wasted.
ATM CAC
In the absence of QoS aware IP routing, any CAC will have to be pretty conservative. The complexity (or inefficiency) of the IP CAC will rise, if the router network topology is getting more complex. A fully meshed network leads to a relatively simple and efficient IP CAC. The possibility of a full router mesh is an advantage if ATM connections are used.
ATM resource economy
As ATM connections of higher quality are a scarce resource. Their cost is higher than that of an ATM best effort connection of the same bandwidth. DiffServ connections are transporting accumulated flows, so the ATM capacity available for QoS IP flows is not consumed completely all the time. If the Edge Routers are interconnected by a single third party ATM connection, a VP based service is preferable. Usually a single ATM connection would be characterized by a peak cell rate. A VP service allowing the establishment of VCs of different may result in the highest efficiency. BE/UBR traffic may consume ATM bandwidth reserved for DS pipe/high quality ATM traffic as long as the latter is not completely loaded. A switched service (QoS SVC set up triggered by first DS connection, SVC release triggered by last DS connection removal) may further improve the economic use of such a resource.
Availability of a full transmission system providing ATM connectivity between edge routers or ATM services controlled and offered by the IP service provider himself may allow a more relaxed ATM resource management. In these cases, also permanent ATM QoS connections or SVC's of different VPs result in network efficiency.
DiffServ Pipes are intended for unidirectional traffic. Unsymmetrical DS pipes between Edge Routers should result in unsymmetrical ATM connections
The Bandwidth Broker
Similar systems as a Bandwidth Broker are in principle known in the ATM world. These units are part of the Telecommunication Network Management (TMN). Separated interfaces provide information exchange with users, other carriers and ATM switching systems (network elements). A communication between BB's and these ATM management system is required for a smooth and flexible IP DS/ATM interoperability.
Permanent ATM VP's may be managed by entities using so called M interfaces. Specifications of these or similar interfaces are available also by other standards bodies (e.g. Xcoop and Xuser by ITU-T and ETSI).
The ATM Forum plans to base QoS differentiation for MPOA and LANE on information provided by the LANE Configuration Server [MPOAC]. This activity started in 1998 and no standard is yet available (status: January 1999).
Address Mapping
Mapping of DiffServ to ATM also covers the aspect of address mapping. Any IP packet now will have to leave the router on an ATM connections not only determined by the IP destination, but also by the demanded IP QoS. Two cases are considered: permanent ATM connections and switched ATM connections. To simplify things, it is assumed that VCs of different ATM quality are available on one ATM VP.
Permanent ATM connections could be provided by single VCs between the Edge Routers. Every IP combination of aggregated path address information and DSCP has to be mapped to a specific ATM VPI/VCI. If instead VPs are used between the edge routers, the aggregated path address information may be translated to a VPI while the DSCP may be mapped to a VCI of the requested quality. The QoS of any permanent ATM connection is pre-selected during the connection establishment by the network management.
If switched ATM connections are used, a single VP per ATM link is reserved to allow the establishment of switched VCs within it. The DSCP will have to be mapped to an ATM QoS for call set up, while the of aggregated path address information has to be mapped to an ATM NSAP address. The combination of destination addresses and the DSCP of the packets to be routed on the switched VC have to be mapped to a single VCI.
The mapping of IP address information and DSCP to a single VCI is desireable, as it is required for SVC support and may be used for permanent connections too. This option also seems to scale better, as no seperate VPI is required per destination.
The QoS of any particular ATM VP will always determine the best QoS of any particular VC within it. Further, the ATM CAC denotion of any particular VP connection limits the summed ATM VC CAC denotions within it.
Note, that the number of ATM VCs available on any single ATM port or node may be subject to vendor individual limitations.Product Availability
Proprietary implementations offering some of the mentioned features are available by now. It is not known to the author, whether any of these offerings covers all mentioned aspects. The standards situation is highlighted in the following section.
Standard LANE and MPOA so far do not support any QoS differentiation. [MPOAC] introduces a concept how to support QoS differentiation by LANE and MPOA. The proposed method would also allow to establish ATM connection for aggregated IP flows. Note that MPOA 1.0 is limited to the support of IPv4. It is based on LANE, which itself allows only Ethernet and Token Ring support.
The MPLS mechanisms to support QoS differentiation are not clear yet. One idea is to operate MPLS QoS differentiation similar as ATM networks: The QoS of a Label Switched Path is known only by the Label Switches. Marking mechanisms on packet level are suggested [MPLS-DS]. As no somewhat stable MPLS draft on differential services interoperability is yet available (status: January '99), DS to MPLS (and MPLS to ATM) interoperability remains for further study.
PNNI supports dynamic QoS routing. PNNI Augmented Routing [PAR98] allows an easy build-up of PNNI based IP overlay networks. However only routing protocol information is exchanged. So also a DS to PNNI interworking requires some management system interaction to map a DS pipe on an according ATM connection.
Given situation: An ISP plans to use ATM to establish a DS Premium connection between two Edge Routers. The DS Premium connection is characterized by a DS Peak Rate (here: 8 Mbps) and a maximum DS service MTU (here: 1000 bytes) [QBone]. In the following the required DS to ATM routing, the DS to ATM QoS mapping and ATM bandwidth are determined. The DS Peak Rate is assumed to be in [bit/s], the max. DS service MTU will be noted in [byte].
The ATM connection is established by the following steps:
The shaping delay added by the ATM shaper on a particular link is:
ATMShapdel = #ATMcells / PCR - (8*max. DS service MTU - 53*8) / link
speed.
Let's assume the link speed to be 155 Mbps, i.e. OC3. In our example
the added ATM shaping delay is ATMShapdel = 0,95 ms.
Should the IP packets of one application be of different size, ATM shaping
will induce some added packet delay variation. As mentioned earlier, ATM
shaping influence may be minimized by using rt-VBR instead of CBR. In this
case, two new parameters are introduced: the Maximum Burst Size MBS, which
should be set to #ATMcells. The Sustainable Cell Rate SCR should be equal
to the above calculated PCR. Respecting the constraint PCRrt-VBR >= SCR
leads to an arbitrary selection of a value for the PCRrt-VBR. The resulting
ATM shaping delay is calculated with MBS instead of #ATMcells and PCRrt-VBR
instead of PCR. It may however be more difficult to find routers supporting
a shaping of IP traffic to ATM rt-VBR.
The ATM shaping delay will of course also be decreased by simply selecting
a higher CBR PCR. Enforcement of resource economy may limit the applicability
of this solution.
All measures decreasing the ATM shaping delay will also decrease the
ATM shaping induced jitter, which would be induced if an application sends
packets of different length.
Keep in mind that the maximum MTU of the ATM AAL5 is limited to 9188 bytes. Prior IP segmentation may be required for lengthy packets.
Extract of the ATM QoS model according to [I.356]
The figures given by table A1 give a worst case guess for a 27500 km reference connection (air distance of two locations) passing 29 ATM systems.
QoS Class 1 should support real time services.
QoS Class 2 still guarantees low losses but no delay (moderate delay expected).
QoS Class 3 is a mix of class 2 and class U cells.
QoS Class U is best effort.
QoS class |
CTD |
2-pt. CDV |
CLR |
CLR |
Class 1 |
400 msec |
3 msec |
3,0E-7 |
none |
Class 2 |
U |
U |
1,0E-5 |
none |
Class 3 |
U |
U |
U |
1,0E-5 |
Class U |
U |
U |
U |
U |
Note 1: In principle, the "Cell Loss Priority (CLP)" bit should be ignored for QoS classes 1 and 2. In practice, it should preferably be set to 0.
Note 2: QoS class 3 consists of a mix of cells with the CLP bit either not set (in this case treatment of cells the same as for QoS class 2) or the CLP bit set. Cells with CLP bit set are treated as best effort. As both components are mixed on the same connection, the resulting overall QoS isn't guaranteed by the network.
Note 3: If the whole connection is class U, the CLP bit will be ignored again.
Table A1: ATM QoS classes according to [I.356]
Thanks to Ben Teitelbaum, Scott Brim and Larry Dunn. Their comments on earlier versions of this document for sure helped to improve it's quality.
Rüdiger Geib
<geib@advanced.org
Deutsche Telekom
c/o Advanced Network & Services, Inc.
200 Business Park Drive
Armonk, NY 10504
Phone: +1 914/765-1172