Enabling a QoS Architecture for the Internet

Enabling a QoS Architecture for the Internet Simon Pietro Romano, Roberto Canonico and Giorgio Ventre Gruppo di Ricerca Informatica Distribuita Universita di Napoli Federico II - Naples - Italy, fsprom,canonico,[email protected]

Abstract. In this paper we investigate issues related to the integration

of QoS capabilities in the framework of Internet technology. First, we take a brief look at the work undertaken by the IETF IntServ working group in order to de ne a reference model capable of providing new real-time multimedia applications, such as CSCW, telemedicine and distributed interactive simulation with the adequate quality of service. Then, we consider the architecture de ned by the Diserv working group, which implements scalable service dierentiation in the Internet by aggregating trac classi cation state along a speci ed network path. Finally, we analyse issues concerning the interoperability between the two de ned approaches, considering them as complementary tools in the pursuit of end-to-end QoS. In this scenario, the main areas of research interest fall in the elds of trac characterization, resource reservation and bandwidth optimisation. We touch upon all of these questions to give a state-of-the-art idea of current work and we try to give some hints concerning future developement trends in the Internet community.

Keywords: Quality of Service, Integration, Architecture 1 Introduction The Internet architecture, the foundations which the TCP/IP protocol suite lies upon, was developed and tested in the late 1970s by a small group of researchers. Since then, several important features have been added to it and the Internet Engineering Task Force (IETF) has been making an extraordinary eort to de ne, extend, test, engineer and standardize protocols capable of coping with the continuous changes in the basic framework. If once the main areas of interest were routing protocols, TCP performance and network management, nowadays the bulk of the question is in the eld of Quality of Service (QoS). Over the past few years, in fact, there have been increasing signs of strains on the fundamental architecture, mostly stemming from the appearence and wide-spread use of new applications such as telemedicine, computer support for collaborative work (CSCW) and distributed simulation systems, which are very demanding in terms of the constraints imposed on the communication service. The astonishing developement of this new kind of applications is highly dependent upon two enabling factors :

1. many modern workstations now come equipped with built-in, cost-eective multimedia hardware ; 2. IP multicasting is being provided by the MBONE, a temporary "multicast backbone". Nevertheless, the rst experiences have also showed the lack of a fundamental technical element : real-time applications do not work well across the Internet because of variable queueing delays and congestion losses. The Internet, as originally conceived, oers only a very simple quality of service : point-to-point besteort data delivery. Thus, before real-time applications can be broadly used, the Internet infrastructure must be modi ed in order to support more stringent QoS guarantees, mostly relating to the provision of some kind of control over endto-end packet delays. The goal is not to design new solutions from scratch, but rather to nd the appropriate extensions to the framework currently available. Real-time QoS is not the only open issue for next generation Internet traf c management policies : the ability to control the sharing of link bandwidth among dierent trac classes is another point which is worth further investigating. Based on these assumptions, in the past several years work on QoS-enabled networks has led to the developement of the Integrated Services Architecture, where the term Integrated Services (IS) is used to denote an Internet service model that includes best-eort service, real-time service and controlled link sharing. Such an architecture, together with an appropriate signalling protocol like RSVP (Resource reSerVation Protocol ) enables applications to demand per- ow guarantees from the network. However, as work as proceeded in this direction, a number of basic limitations have emerged which impede large-scale deployment of QoS mechanisms in the Internet : the reliance of IntServ protocols on per- ow state and per- ow processing schemes, in fact, brings to a level of granularity too ne to avoid scalability problems on large networks, thus raising the need to de ne a scalable architecture for service dierentiation. Such an architecture is the subject of the studies conducted by the Diserv working group in the IETF. A dierentiated-services network achieves scalability by means of aggregation of trac classi cation state conveyed in an appropriate DS eld set by IP-layer packet marking. In this paper we take a look at the current Internet quality of service capabilities, as depicted by the Integrated Services and Dierentiated Services Working Groups, together with some hints concerning future developement trends in the Internet community. The paper is organized in ve sections. An overview of the Integrated Services QoS framework is presented in section 2. Section 3 introduces a reference model for Dierentiated Services. Based on the assumption that the two approaches described may be used in conjunction in order to achieve end-to-end QoS in large internetwork environments, section 4 analyses the problem of Intserv-Diserv interoperability. Conclusions are provided in section 5.

2 The Integrated Services Model IP has been playing for several years the most important role in global internetworking. Its surprisingly rapid growth makes it the dominating protocol in the scene of networking research. However, IP choice does not only rely on the fact that the vast majority of applications has been conceived for it. The connectionless nature of IP has proved to be a key feature to support integrated services networks. Based on this assumption, the IETF Integrated Services working group has speci ed a control QoS framework [5] in order to provide new applications with the appropriate support. Such a framework proposes an extension to the Internet architecture and protocols which aims at making broadly available integrated services across the Internet. The main features of the QoS framework are : { the de nition of a reference model for the integrated services architecture ; { the speci cation of a reservation protocol compatible with the assumptions of the reference model ; { the de nition of a number of service classes satisfying the needs of the different kinds of network applications ; { the design of an appropriate service model for all of the de ned classes. In the following sections we'll go into some of the details concerning each of the points mentioned above.

2.1 The reference model

The key assumption on which the reference model for integrated services is built is that network resources ( rst of all its bandwidth) must be explicitly managed in order to meet application requirements. The overall goal in a real-time service, in fact, is that of satisfying a given set of application-speci c requirements, and it looks clear that guarantees are hardly achieved without reservations. Thus, resource reservation and admission control will be playing an extremely important role in the global framework. The new element which arises in this context, with respect to the old (nonreal-time) Internet model, is the need to maintain ow-speci c state in the routers, that must now be capable to take an active part in the reservation process. Based on these considerations, the components included in the reference framework are ( gure 1) : a packet scheduler, an admission control module, a packet classi er and an appropriate reservation setup protocol. In today's Internet, all packets of a given ow receive the same quality of service and are typically forwarded using a simple FIFO queueing discipline. As gure 1 shows, for the integrated services paradigm, a router is compelled to implement an appropriate function to guarantee QoS on a per- ow basis. Such a function, with the associated implementation mechanisms, is called trac control, which is in turn made up of three dierent building blocks : the packet scheduler, the packet classi er and the admission control module.

HOST

Appl.

ROUTER

Reservation setup protocol

Reservation setup protocol

Routing Daemon

Admis.Ctrl. Packet Class.

Packet Sched.

Packet Class.

Packet Sched.

Fig. 1. The reference QoS framework. The packet scheduler takes into account the forwarding of dierent packet streams by appropriate management of a set of queues together with other related mechanisms like timers. It must be implemented as a link-layer protocol at the output driver level of the operating system. The function of the classi er is to perform the mapping of incoming packets into some service class, in order to achieve the twofold goal of trac control and accounting. All packets belonging to the same class get the same treatment from the packet scheduler. Finally, admission control is invoked at each node throughout the network at the time a host requires a real-time service along a speci ed path. It has the responsibility to determine, on a local basis, whether a router or host can grant a new ow the requested QoS without impacting earlier guarantees to previous

ows. The last block showed in the gure refers to the reservation setup protocol needed to create and manage state information along the whole path that a speci c ow crosses between two network end-points. One of the features required to such a protocol is that of carrying the so-called owspec object, that is a list of parameters specifying the desired QoS needed by an application. At each intermediate network element along a speci ed path, this object is passed to admission control to test for acceptability and, in the case that the request may be satis ed, used to appropriately parameterize the packet scheduler. In the next section we'll present RSVP, the resource reservation protocol recommended by IntServ.

2.2 The reservation setup protocol

To allow applications to request active end-to-end QoS control along the path of a packet ow, a signaling protocol must be integrated into the architecture. Such a protocol serves as a front end between the application requesting QoS control and the communication service. The Resource ReserVation Protocol (RSVP [1]) has been conceived to grant new applications the possibility of exploiting a data transport service characterized by a QoS speci ed and negotiated before starting the transmission phase. It introduces a mechanism to discriminate among dierent ows and to handle each of them in a dierent way : this feature represents

a major breakthrough for the Internet, but also arises many logistic questions of a certain complexity. The main characteristics of RSVP are :

{ the reservation is simplex, i.e. it's valid in only one direction ; { it is a control signalling protocol built upon the IP network layer ; { it is receiver-initiated, in the sense that it is the receiving host's responsibility { { { { { {

to decide the amount of resources that must be reserved in order to grant the application a speci c quality of service ; it is able to manage both point-to-point and multipoint-to-multipoint reservations ; it dynamically ts to changes in routing paths and in group composition ; it does not interfere with routing protocols. It must then be integrated with the extra-functionalities made available by routers (routing, admission control, ltering, etc.) ; it manages a periodically updated soft state of the network ; it makes available multiple reservation styles, indicating how intermediate network elements must aggregate reservation requests from receivers belonging to a speci c multicast group ; it can take into account the presence of non-RSVP routers in a transparent way.

RSVP messages are encapsulated into normal IP datagrams and ordinarily forwarded. Data treated by RSVP are of three natures according to the entity that supplies (sender and receiver) or modi es (intermediate network elements) them. The information supplied by each sender, and conveyed in the Sender TSpec object, concerns the type of trac that it is going to generate. The FlowSpec object provided by each receiver is built of two parts, Receiver TSpec and RSpec (both contained into a message called Resv ). The former contains the trac description the resource reservation should apply to while the latter carries the service class to be used and the corresponding quality of service parameters. The information modi ed by intermediate network elements is carried in the ADSPEC object which contains available services, delay and bandwidth estimates, and additional service speci c parameters. This information is used by the receivers to choose a service and determine the reservation parameters. ADSPEC and Sender TSpec objects are both contained into a PATH message. The RSVP speci cation does not de ne the internal format of RSVP protocol elds or objects described above. Rather, they are speci ed by each QoS control service according to its needs. Figure 2 shows the use of the de ned messages during the resource reservation phase. The lter-spec object showed in the gure is used to select a subset of the packets of the ow, with respect to the source or by means of a higher layer protocol. Each reservation is associated to a speci ed style, which makes possible ow aggregation. The associated parameters vary in accordance with the

RECEIVING

SENDING END-SYSTEM

END-SYSTEM INTERMEDIATE

APPLICATION PATH

NETWORK ELEMENT

SENDER_TSPEC RSVP

Initial ADSPEC

APPLICATION PATH SENDER_TSPEC

Traffic

Updated ADSPEC

API

Control API

FLOWSPEC

Merged FLOWSPEC RSVP RESV

RSVP

FILTERSPEC RESV

RESERVATION QoS (GS, CL) Receiver TSPEC [Receiver RSPEC]

Fig. 2. RSVP objects and the reservation phase. capacity of the ows to share a particular resource on the basis of an alternation mechanism (shared or distinct ) and the explicit or implicit expression of the sources (explicit or wildcard). By combining these parameters, we obtain three dierent styles : wildcard- lter, shared explicit and xed lter. Finally, gure 3 shows the role of the packet classi er and packet scheduler in the context of an RSVP-capable network element. filterspec

flowspec

Packet Scheduler INPUT INPUT

DRIVER

Packet Classifier

OUTPUT

OUTPUT DRIVER

Fig. 3. The role of the packet classi er and packet scheduler.

2.3 The service classes IntServ service classes de ne a framework for specifying services provided by network elements and available to applications, in an internetwork capable of oering multiple, dynamically selectable qualities of service. Each de nition speci es the characteristics that must be possessed by a network element (e.g., a router) to support a particular service, de nes the invocation parameters speci c of each available service and characterizes the end-to-end

behavior obtained by utilizing the same kind of service along all the hops of a speci c path. The goal of these services is that of bypassing the current limitations of the traditional, best-eort service made available by the Internet by providing dierent qualities of service to dierent applications, allowing them to request network packet delivery characteristics according to their perceived needs. Two dierent service classes have so far been de ned : guaranteed quality of service and controlled load quality of service. Let's take a look at both of them.

Guaranteed Service The Guaranteed Service (GS) class provides the clients

data ow with rm bounds on the end-to-end delay experienced by a packet while traversing network queues [2]. It guarantees both bandwidth and delay. The GS emulates the service that would be oered by a dedicated communication channel between the emitter and the receiver. Two parameters apply to this service: TSpec and RSpec. The former describes the trac characteristics for which service is being requested. It is composed of a token bucket (b) plus a peak rate (p), a minimum policed unit (m), and a maximum datagram size (M). The RSpec speci es the QoS a given ow demands from a network element and it takes the form of a clearing rate R and a slack term S . The clearing rate is computed to give a guaranteed end-to-end delay and the slack term denotes the dierence between desired and guaranteed end-to-end delay after the receiver has chosen a value for R. During the reservation phase [7], each intermediate network element i computes Ci and Di which represent the deviation from a uid server which operates at the clearing rate R demanded by a potential receiver for a given ow. Thus, the delay encountered by any bit of the ow in network element i is required to be no more than the one it would be subject to in an hypothetical system that rst delays the ow by Ci =R + Di units of time and then serves it at the reserved rate R. Ci and Di are accumulated into the Ctot and Dtot elds within the ADSPEC object of a PATH message. So, given a (b; r; p) ow (to which a \service curve" like that showed in gure 4 is associated), the following equation (1) applies to the end-to-end delay bound computation for a network element with MTU size equal to L:

Di

8 (b ? L) (p ? R) L > > > > < R (p ? r) + R =>  i  Cj X L > > > + + Dj :

R j=1 R

+

i  Cj X



+ Dj if p > R; j=1 R if p  R:

(1)

Similarly, the buer requirement at network element i is given by :

i X Bi = L + ((pp??Xr))  (b ? L) + j=1



Cj + Dj   X; R

(2)

slope = r

A( t

)

G E

delay

F

buffer

b

L

slope = R

slope = p

H i

Σ ( Cj / R + Dj )

j=1

Fig. 4. The service curve associated to a (

) ow.

b; r; p

where :  i  Cj X ; + D if (bp ?? Lr )  j j=1  R  i Cj X=> (b ? L) > X > R if + D j & p > R; > > p ? r j=1 R > > : p otherwise: 8 > > > r > > >