当前位置：文档库 › Abstract Support QoS in IP over ATM

Abstract Support QoS in IP over ATM

Support QoS in IP over ATM

Gung-Chou Lai,Ruay-Shiung Chang *

Department of Computer Science and Information Engineering,National Dong Hwa University,Hualien,Taiwan

Received 2June 1997;accepted 27May 1998

Abstract

An integrated service internet running real-time and multimedia applications is rapidly becoming a reality.Meanwhile,ATM technology is appearing in the marketplace.It is an important problem to integrate ATM networks into this integrated service internet.One of the approaches,classical IP over ATM,is now widely deployed,effectively solving the problem of internetworking and interoperability.A key remaining issue is to provide quality-of-service (QoS)guarantees for internet traf?c running through ATM subnets.This paper describes a priority scheme,named User Priority,for providing an IP integrated service with QoS over ATM switched virtual circuits (SVCs)to obtain better performance of packet delivery.The User Priority is de?ned as a three-bit ?eld which uses a type of service (TOS)?eld in the IP datagram header.This yields eight different service classes with a value of 7for the highest priority and 0for the lowest priority.Class 6and 7services are for real-time traf?c and have their own VCs.Packets with Classes 0through 5are sent an aggregate VC.This method is different from the IP over ATM scheme where only one VC is set up between two communicating IP hosts.Thus,packets can be treated differently according to their priorities such that they can enjoy the various QoS guarantees provided by ATM networks.It is backward-compatible with existing IP implementations.These newer options need only to be implemented on the end systems that want to take advantage of them.?1999Elsevier Science B.V.All rights reserved.

Keywords:IP over ATM;LAN emulation;Next-hop routing protocol;Resource reservation;Quality of service

1.Introduction

The asynchronous transfer mode,commonly given the acronym ATM,is the most widely studied and implemented form of cell networking [1].ATM began as a technology designed speci?cally to address the needs of the interna-tional telecommunications carrier community.It has evolved over the past few years,and the various protocols and interfaces are de?ned in a set of standards created by the International Telecommunications Union (ITU).This gives network designers a solid base on which to build ATM networks.ATM is the underlying transmission system for the ITU’s next-generation ISDN,broadband (B)ISDN.B-ISDN is designed to provide subscriber communications services over a wide range of bit rates from a few megabits to several gigabits.The current ATM standards are designed to allow subscribers access to the telephone networks at speeds of up to 622Mbits s ?1,and it is expected that even-tually,gigabit speeds will also be supported as the under-lying ATM transmission system is clearly capable of these speeds.

The major selling point of ATM is that it is the ?rst technology that can deliver different types of traf?c,such as voice,video and data,over a single digital transport mechanism.ATM can also handle scalable amounts of bandwidth as a result of its switching architecture,which can support multimedia applications and network growth for years to come.As the Internet integrated service (IIS)is becoming important,the ATM will play an important role as a backbone network technology for the Internet.

However,in a very competitive market,ATM cannot be the sole technology used;it is going to cooperate with exist-ing network technologies in the Internet environment.It is hoped that the combined networks will provide quarantees of quality of service (QoS),which is required by network users and for the performance of the Internet.These QoS guarantees,however,come at a price.Contrary to common misconceptions,ATM is a very complex technology [2],perhaps the most complex ever developed by the network-ing industry.While the structure of ATM cells and cell switching do facilitate the development of hardwired and high-performance ATM switches,the deployment of ATM networks requires an infrastructure which consists of layers of highly complex protocols and softwares.Therefore,one of the challenges that ATM faces is to interoperate with the

Computer Communications 22(1999)411–418

*Corresponding author.Fax:886-2-7376777.

E-mail address:rschang@https://www.wendangku.net/doc/192408062.html,.tw (R.-S.Chang)

vast number of TCP/IP https://www.wendangku.net/doc/192408062.html,ing IP and ATM together presents some interesting problems because they differ in fundamental ways,from their respective models of data forwarding (connectionless vs.connection-oriented)to support for the preferential treatment of packets (no support vs.the potential for support guarantees).In this paper,we will introduce some strategies and propose a priority scheme to support QoS for IP datagrams carried over the intercon-nected ATM and TCP/IP networks in IETF IP over ATM [3–5].The implications of various IP-over-ATM strategies on network performance,particularly the aspects relating to QoS,virtual circuit (VC)multiplexing,and VC manage-ment are also addressed.

The paper is structured as follows.In Section 2,the concept of IP over ATM is introduced along with some related work.The protocol design principles are described in Section 3.In Section 4,protocol implementation using ATM VCs with guarantee of performance to carry IP data-grams is shown.Finally,conclusions are given and further studies are discussed in Section 5.

2.The concepts of IP over ATM

In the current Internet,the solution to forward data through an heterogeneous internetwork is provided by the Internet protocol (IP).The IP is almost entirely independent of the subnet technology used—it just makes a few assump-tions about the nature of individual subnets.IP packets can traverse many different types of subnets (including ATM networks)without either the senders or the receivers being aware of the details of the networks encountered along the path.Unlike the ATM,the IP is a datagram protocol and does not require the establishment of connections before data are sent.

As the ATM and the Internet is likely to coexist in the future,it is desirable that hosts attaching to these two types of networks can exchange data.One approach is to use an ATM network (with an appropriate adaptation layer)as a datalink layer,similar to Ethernet and FDDI,as shown in Fig.1.

This method is commonly referred to as IP over ATM (IPOA).An interesting consideration in this approach is how to preserve the QoS in the IP conversation.In addition,the issue of ATM QoS will impact on the multiplexing and VC management.In fact,the performance of individual IP conversations and the resource reservation for a given VC

will be a trade-off among different multiplexing policies.Different VC management strategies will impact upon resource reservations and delays.

Much work relating to IP over ATM concerns various paradigms for these services,such as IETF classical IP over ATM [6],ATM Forum LAN emulation [7]and multi-protocol over ATM [8],and how they affect the issues of addressing and routing.Multiplexing and VC management in IP over ATM have been studied for the best-effort service,but QoS issues are still not addressed yet.Although various solutions for supporting QoS or performance guar-antees in the internetwork have been proposed,such as the resource reservation protocol (RSVP)[3],they did not deal with the speci?c characteristics of ATM subnets.In this paper,we will focus on support of the QoS in the IETF classical IP over ATM.We will ?rst introduce the IETF classical IP over ATM architecture in detail.Some multi-plexing policies and several types of VC management will then be discussed.

The paradigm for IETF classical IP over ATM is shown in Fig.2.Nowadays this protocol is commonly used in IP over ATM by multiple ATM switch vendors.

In Fig.2,several IP members,the LIS (logical IP subnet),have the same IP network/subnet number and address mask.Members of an LIS directly connect to the ATM network,and resolve IP addresses to ATM addresses via ATMARP and vice versa via InATMARP when using switched virtual circuits (SVCs).If a permanent virtual circuit (PVC)is used,members of an LIS will need InATMARP to resolve VCs to IP addresses.Members of an LIS would be able to commu-nicate to each other via the ATM.Two hosts belonging to different subnets but attached to the same ATM network can only communicate via the router that is a member of both subnets.In any case,only one VC will be set up between two communicating hosts.All the traf?c,with its priorities and characteristics,will be transmitted through this VC.In this paper,we modify the IP over ATM protocol such that more than one VC will be established to accommodate different kinds of data such that each VC can enjoy the QoS guarantees provided by the underlying ATM networks.

While classical IP over ATM is potentially inef?cient in that a path between ATM-attached hosts may require forwarding through a router,it has the advantage of preser-ving the original semantics of IP subnets.Another approach,taken by the Routing Over Large Clouds (ROLC)Working Group of the IETF,seeks to remove the potential inef?-ciency of the classical model.In the ROLC model,hosts attached to the same ATM network can communicate directly,even if they do not belong to the same LIS.Since part of the original IP routing model dictates that hosts on different subnets must communicate via a router (rather than directly),this method forces changes to the way that IP routing and forwarding are performed.A next-hop routing protocol (NHRP)[9]is used to send data between subnets directly across the ATM network.

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang /Computer Communications 22(1999)411–418

412Fig.1.Internet protocol suite and datalink layer.

The protocol hierarchy of IP over ATM is shown in Fig. 3.It is the encapsulation and transmission of IP network or link layer packets across an ATM adaptation layer (AAL)5[10]connection.We know that audio and video applications generally run over UDP,which does not provide reliable data transport.These applications are time-sensitive and need not retransmit packets when they are lost.

2.1.Multiplexing strategies

Three different multiplexing policies [11]can be consid-ered to support the QoS in IP over ATM.

?A VC per pair of routers carrying all traf?c passing through the pair of routers,regardless of source or destination host.

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang /Computer Communications 22(1999)411–418

413

Fig.3.Protocol stack of IP over

ATM.

Fig.2.Model of IETF classical IP over ATM.

?A VC per IP conversation (e.g.TCP connection or UDP ?ow).

?A VC per application type (e.g.one VC for all telnets passing through a pair of hosts).When performing router multiplexing,it is dif?cult to preserve a meaningful QoS for each VC,because the nature of the aggregate traf?c between the routers is unknown.Therefore,all the policies that use a multiplexing policy of employing a VC per router pair do not use any of ATM’s QoS features.A VC per IP conversation is limited by the VPI/VCI quota,and may reserve too many and useless resources on a given VC.However,multimedia applications,such as digital audio and video,would like to have their own VCs because they do not want to be disturbed by other packets.In addition,one VC per applica-tion aggregates the same types of applications into one VC.This policy solves the problem described in the discussion of the policy of one VC per IP conversation.Thus,we propose a priority scheme that applies the latter two methods.2.2.VC management policies

There are three possible VC management policies [11].They are PVC,SVC and SVC/cache.

?PVC.A set of permanent virtual circuits is established to carry IP packets.These connections are never torn down.?SVC.Switched virtual circuits,with some time-out policy to be determined,are used to carry IP packets.?SVC/cache.This is similar to SVC,but with the addi-tional feature that VCs used by other IP conversations can be cached and reused to carry the packets.It should be observed that these three policies are not entirely independent.In an IP over ATM service using PVCs,it is impractical to set a QoS parameter for an unknown workload traversing a ?xed set of VCs.Moreover,the sheer number of VCs required for a complete PVC set may force a multiplexing policy of one VC per router https://www.wendangku.net/doc/192408062.html,ing a PVC to carry IP traf?c would be wasteful and

unnecessary.Thus,the only PVC policy that can be consid-ered is QoS-oblivious (no QoS).SVC-with-cache saves connection set-up and tear-down time.Applying SVC/cache sounds better than using SVC only,but a problem is that the resource requirement of the latter IP conversation may not match the previous IP conversation’s,such as telnet and FTP.Hence,both SVC and SVC/cache have their own advantages and drawbacks respectively.

3.Protocol design principles

Our goal is to extend the QoS features of an ATM network to IP applications.Although the IP in its current form has no provision for QoS support,the underlying ATM subnet has the capability to offer performance guarantees.We would therefore like Internet applications to gain some of the bene?ts of ATM performance guarantees,without the end-hosts or applications necessarily being aware of this capability.

As shown in Fig.4,there is only one SVC between each host pair in classical IP over ATM.These SVCs provide a ‘best-effort’service.They do not guarantee any QoS.To improve this,we provide a priority scheme to support the QoS.

Our idea is to group different application types into differ-ent VCs.For example,different FTP sessions can be aggre-gated into one FTP VC and so do telnets and HTTPs.Each VC circuit is used by one application type.As shown in Fig.5,the same applications share the same VC because they have the same resource requirement characteristic.For example,HTTPs care response time and telnets focus on delay.All these VCCs are SVCs.These VCs are created on demand.In contrast,real-time traf?c would like to have its own VC to transmit data,as shown in Fig.6,such that the other packets cannot disturb https://www.wendangku.net/doc/192408062.html,ing the above idea,we propose a priority scheme by using the precedence bits in the type of service (TOS)?eld of the IP header to determine whether a ?ow should initiate a new VC or join

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang /Computer Communications 22(1999)411–418

414Fig.4.Virtual circuit connection in classical IP over

ATM.

Fig.5.Schematic showing that sessions in the same application type aggregate to one virtual circuit per host pair.

an existing one.In contrast,traditional IP over ATM networks use only one SVC to transmit IP packets.There is no bandwidth or delay guarantee in classical IP over ATM networks.

4.Protocol implementation

In this section,we introduce the proposed priority scheme.It uses the TOS [12]?eld in the IP datagram header and is backward-compatible with existing IP implementa-tion.These newer options need only be implemented on the end systems that wish to take advantage of them.4.1.Speci?cation of the TOS octet

As shown in Fig.7,the precedence (named ‘User Prior-ity’in this paper)facility is one of the features of the TOS octet in the IP datagram header.The TOS octet consists of three ?elds.

The ?rst ?eld,‘precedence’,is intended to denote the

importance or priority of the datagram.This ?eld is not de?ned and used in current IP implementation.We take this ?eld as the ‘User Priority’to determine the QoS types.The four TOS bits are ‘minimize delay’,‘maximize throughput’,‘maximize reliability’,and ‘minimize mone-tary cost’,respectively.Table 1shows the recommendation values of the TOS [12].Only one of these four bits can be turned on.If all four bits are zero,normal service is implied.RFC 1340[13]speci?es how these bits should be set by all the standard applications.RFC 1349[12]contains some corrections to RFC 1340and a more detailed description of the TOS feature.The TOS feature is not supported by most TCP/IP implementations today,although it is being set by newer systems starting with 4.3BSD Reno.Additionally,new routing protocols such as OSPF and IS–IS are capable of making routing decisions based on this ?eld.

The last ?eld,labeled MBZ (must-be-zero)above,is currently unused.The originator of a datagram sets this ?eld to zero (unless participating in an Internet protocol experiment,which makes use of that bit).Routers and reci-pients of datagrams ignore the value of this ?eld.The ?eld is copied on fragmentation.

4.2.Speci?cation of the User Priority octet

The three-bit User Priority ?eld yields eight different service classes with value 7denoting the highest priority and 0the lowest priority.Table 2de?nes the semantics of

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang /Computer Communications 22(1999)411–418

415

Fig.7.Type of service in IP datagram header.

Table 1

Recommended values for the type-of-service ?eld Application Minimize Maximize Maximize Minimize Hex value for delay throughput reliability monetary cost TOS Octet Telnet/Rlogin 10000×10FTP(control)10000×10(Data)

01000×08(Any bulk data)01000×08TFTP 10000×10SMT

0×10(Command phase)1000(Data phase)

01000×08DNS(UDP query)10000×10(TCP query)00000×00(Zone transfer)01000×08ICMP(error)00000×00(Query)00000×00(Any IGP)00100×04SNMP 00100×04NNTP 00010×02BOOTP

0×

Fig.6.Schematic showing that two video ?ows have their own VC,respectively.

the User Priority?eld values.0is referred to as the default User Priority.

4.3.Selecting User Priority classes

The remaining question is how to set the User Priority ?eld.Table1describes the priority values for various Inter-net applications.The next step is to determine the type of application.We distinguish between different applications by the well-known port numbers.The port number is included in the TCP or UDP protocol header[14].Most of the TCP or UDP applications have the property that they are assigned‘well-known’ports.Assigning?xed port numbers to certain applications enables client processes to easily locate server processes.For example,a telnet client applica-tion knows that it can locate telnet servers on remote hosts on the TCP port23.An ATM-attached router can check the source and destination port numbers of a TCP packet;if it sees a well-known port number in the TCP source port?eld, the packet is likely to be transmitted by a server process to a client process.Conversely,if a well-known port number appears in the TCP destination port?eld,the packet is likely to be transmitted by a client process to a server process.For non-default port numbers,a con?guration table can be built ?rst into IP over ATM.

https://www.wendangku.net/doc/192408062.html,e of the User Priority?eld in the Internet protocol For the User Priority facility to be useful,the User Prior-ity?eld in IP packets must be?lled in with reasonable values.When sending a datagram,the Internet protocol sets the User Priority according to the port number.There is no requirement that both the client and server in a connec-tion use the same User Priority.That is called the‘asym-metric transfer mode’.For example,the server sends packets on the QoS VC,but the client uses the best effort (BE)VC.

When the IP over ATM receives a new connection request,it needs to decide whether this request should initi-ate a new VC or join an existing one.Fig.8shows a?ow chart of these procedures.

In Fig.8,when joining an existing VC,the algorithm checks whether the number of sessions in this VC is already enough.When initiating a new VC,depending on the type of application a different QoS parameter is set before allocat-ing the VC.

4.5.Mapping between the IPv6priority and the IPv4User Priority?eld

The Internet Engineering Task Force is currently design-ing a successor to IP,known as IPv6(IP version6)[15]. IPv6addresses the primary limitations of IPv4,while retain-ing much of the same basic protocol architecture.Among the features of IPv6are an expanded address space(128-bit addresses vs.32-bit IPv4addresses),ease of route aggrega-tion for scalability,a redesigned packet header(see Fig.9) for ef?cient packet processing,and explicit support for security and authentication.

The4-bit priority?eld in the IPv6datagram header enables a source to identify the desired delivery priority of its packets,relative to other packets from the same source. The priority values are divided into two ranges.Values0 through7are used to specify the priority of traf?c for which the source is provided congestion control,such as TCP traf-?c.Values8through15are used to specify the priority of traf?c that does not back-off in response to congestion.For example,real-time packets are being sent at a constant bit rate.

For congestion-controlled traf?c,the priorities shown in Table3are recommended for particular application cate-gories.

For non-congestion-controlled traf?c,the lowest priority value(8)should be used for those packets that the sender is most willing to have discarded under conditions of conges-tion,such as high-?delity video traf?c;and the highest value (15)should be used for those packets that the sender is least willing to have discarded,such as low-?delity audio traf?c. There is no relative ordering implied between the conges-tion-controlled priorities and the non-congestion-controlled priorities.

We can use the MBZ bit in the TOS?eld of the IPv4 datagram header to simulate the fourth bit in the IPv6prior-ity?eld.By using the MBZ bit,the User Priority?eld in the IPv4datagram header can be extended to two range prio-rities as for the IPv6priority?eld.Therefore,when IPv6 traf?c is tunnelling through IPv4networks,the priority concept in IPv6can be still applied.Also,if the IPv4packets

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang/Computer Communications22(1999)411–418 416

Table2

Recommendation values of user priority

Priority Service ATM QoS Application

0Best effort(BE)UBR Unspeci?ed traf?c

1Bulk transfer(background)ABR NNTP,SMTP

2Bulk transfer ABR FTP,HTTP

3Interactive traf?c ABR Telnet,HTTP

4Internet control message ABR ICMP

5Non-real-time(VBR)NRT VBR NRT digital video

6Real-time(VBR)RT VBR Digital video

7Real-time(CRB)CBR Digital audio

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang/Computer Communications22(1999)411–418417

Fig.8.How the QoS is implemented in IP over ATM.

Fig.9.IPv6header format.

?nally pass an ATM subnet,the method proposed in this paper could be used to satisfy the QoS requested by the IPv6 packets.

5.Conclusions and future work

In this paper,we have proposed a priority scheme(named the User Priority)by extending the IP datagram header.The goal is to enable a better packet delivery performance in traditional IP over ATM networks with QoS guarantees. Today’s networks consist of mostly IP traf?c.They can be bene?ted by application of the method when passing through ATM networks.

Currently,the User Priority scheme does not support a dynamic change of the QoS.There are several commonly mentioned reasons for a change of the reserved QoS.First, an existing receiver can request a new,larger QoS.Second, a sender may change its traf?c speci?cation,which can trigger a change in the reservation requests of the receivers. Finally,a new receiver can make a reservation that is larger than existing reservations.Since the ATM service, as currently de?ned in UNI3.×[16]and UNI4.0,does not allow renegotiation of the QoS of a VC,dynamically changing the reservation means creating a new VC with the new QoS,and tearing down an established VC.Tearing down a VC and setting up a new VC in ATM are time-consuming.

Furthermore,we need an enhanced signalling protocol. Setting up a connection is a hop-by-hop process in UNI3.×and4.0.A possible candidate is the connection request protocol(CRP)[17].It uses a parallel connection set-up and resource management scheme.Its key feature is that it combines address resolution with connection set-up to improve performance.Further,it eliminates the need for IP end-points to support ATM signalling protocols,thereby signi?cantly simplifying their con?guration and manage-ment.

Acknowledgements

This research is supported in part by the NSC under contract numbers NSC86-2622-E-007-001and NSC86-2213-E-011-056.

References

[1]Craig Patridge,Gigabit Networking,Addison-Wesley,1994.

[2]Anthony Alles,ATM Internetworking,Engineering InterOp,Las

Vegas,March1995.

[3]Steve Berson,Classical RSVP and IP over ATM,USC Information

Science Institute,April1,1996.

[4]R.Cole,D.Shur,C.Villamizar,IP over ATM:a framework docu-

ment,Internet Request for Comments1932,April1996.

[5]M.Perez,F.Liaw,A.Mankin,E.Hoffman,D.Grossman,A.Malis,

(Eds.),ATM signaling supporting for IP over ATM,Internet Request for Comments1755,February1995.

[6]https://www.wendangku.net/doc/192408062.html,ubach(Ed.),Classical IP and ARP over ATM,Internet Request

for Comments1577,January1994.

[7]ATM Forum,LAN Emulation Over ATM,Version1.0,January1995.

[8]ATM Forum,MPOA Baseline,Revision9,September3,1996.

[9]James V.Luciani,Dave Katz,David Piscitello,Bruce Cole,NBMA

next hop resolution protocol(NHRP),Internet draft draft-ietf-rolc-nhrp-10,October1996.

[10]Juha Heinanen(Ed.),Multiprotocol encapsulation over ATM adapta-

tion layer5,Internet Request for Comments1483,July1993. [11]B.Mah,On the use of quality service in IP over ATM,Technical

Report UCB/CSD-95-884,University of California,Berkeley,CA, September1995.

[12]P.Almquist,Type of service in the Internet protocol suite,Internet

Request for Comments,1349,July1992.

[13]S.J.Reynolds,J.Postel,Assigned numbers,Internet Request for

Comments1340,July1992.

[14]W.Richard Stevens,TCP/IP Illustrated,Vol.3,Addison-Wesley,

1995.

[15]S.Deering,Internet protocol,version6(IPv6)speci?cation,Internet

Request for Comments1883,December1995.

[16]ATM User–network interface(UNI)speci?cation,version 3.1,

Prentice Hall.

[17]Clark Woodworth,Malathi Veeraraghavan,David Shur,Connection

request protocol(CRP)for IP over ATM,IEEE Global Telecommu-nications Conference,November1996.

https://www.wendangku.net/doc/192408062.html,i,R.-S.Chang/Computer Communications22(1999)411–418 418

Table3

Recommendation values of IPv6priority

Priority Description Application

0Uncharacterized traf?c Default

1‘Filler’traf?c Netnews

2Unattended data transfer E-mail

3(Reserved)–

4Attended bulk transfer FTP,NFS

5(Reserved)–

6Interactive traf?c Telnet

7Internet control traf?c Routing protocol,SNMP