1 Introduction

Using Quality of Service can be simple: Arequipa with Renegotiable ATM connections y y y Werner Almesb erger , Leena Chandran-Wadia , Silvia Giordano , y z Jean-Yves Le Boudec , Rolf Schmid Abstract: Wehave mo di ed the p opular Mb one to ol Vic (VIdeo Conferencing) to use Arequipa (Application REQuested IP over ATM). The latter enables applications and in particular Vic, to request a direct ATM connection for its exclusive use and to directly control the trac parameters of this connection. We have also implemented ATM Forum's UNI4.0 signaling and ITU-T's connection mo di cation recommendation Q.2963.1, on end-systems as well as on switches. This implementation, coupled with the Arequipa mechanism, allowed Vic to negotiate and renegotiate ATM bandwidth at will, at run time. We describ e how Vic accomplished that over the ATM WAN of SWISSCOM, transferring live video from Lausanne to Basel and Zuric hover switched, renegotiable ATM connections. To our knowledge, this was the rst time any application had the capacity to tune ATM trac parameters at run time. 1 Intro duction ATM networks [2,3]o erarich set of features to supp ort guaranteed qualityof 1 service (QoS), including several trac and QoS parameters which can b e set by the user. Despite this rich structure, the main b o dy of applications to daystill use ATM only via the IP layer, and thus do not b ene t from the p ossibilities for QoS selection o ered byATM. We have been studying ATM networks with a view to making the QoS selection capability visible to the user, and to do this in as simple a way as p ossible. Towards this end wehavedevelop ed a mechanism, Arequipa,bywhich IP applications can havethe option of selecting QoS parameters. Among the manychoices for the latter we b elieve that, from the users' p ointofview,itis work done in collab oration with the ACTS EXPERT pro ject - AC094 [1] y ICA (Institute for computer Communications and Applications), EPFL (Swiss Federal Institute of Technology), Lausanne, Switzerland z ASCOM Tech. Ltd, Bern, Switzerland 1 We use QoS to refer to quality of service in general but also sometimes to ATM connection QoS parameters. The meaning will always b e clear from the context. 1 appropriate to restrict that choice to just the bandwidth, or ATM p eak cell rate (PCR). The ATM Forum and the ITU [4,5] de ne a large numberofATM connection typ es, ranging from constant bit rate (CBR) to Available bit rate (ABR). In the work rep orted here, we fo cus on the use of renegotiable CBR connections, because it provides a simple means to o er a visible qualityof service, under explicit control from the end-user. Renegotiable CBR connections are connections with a maximum p eak cell rate, which can b e mo di ed by the user at any time (see Section 2). Arequipa or Application REQuested IP over ATM [6, 7] is a metho d for providing the quality of service of ATM to TCP/IP applications, assuming end- to-end ATM connectivity exists. The Arequipa mechanism do es not require anychanges in the network but twochanges need to b e made at the end systems. First, in order to implement Arequipa , some changes need to b e made to the TCP/IP proto col stack (on the end systems). Second, applications using Arequipa to obtain QoS need to b e mo di ed slightly to make use of our simple extension to the so cket interface. The latter consists of just four calls for setting up, tearing down and mo difying the trac parameters of connections. The applications then make use of the end-to-end ATM connectivityand Arequipa to set up a direct switched virtual channel connection (SVC) from the sender to the receiver application (Fig. 1). The rst applications to be made Arequipa-capable were the Arena Web browser and the CERN http d Web server [6,7]. These were used to transfer live video across a trans-europ ean WAN from Lausanne to Helsinki with guaranteed QoS [8]. Since then we have partially implemented UNI4.0 signaling and the Q.2963.1 connection mo di cation capability on the end systems and on switches. Simultaneously wehave extended the Arequipa mechanism and API to include the connection mo di cation capability. With these an application can now mo dify the QoS parameters at run time, after connection setup. We demonstrate this in the case of the Mb one VIdeo Conferencing to ol Vic whichwehave mo di ed to b e Arequipa-capable. Vic was used [9] to video conference with QoS, in p oint-to-p oint mo de, b etween Basel and Lausanne and also b etween Zuric h and Lausanne. We describ e details of this demo whichwas done over the ATM WAN of SWISSCOM. To our knowledge this was the rst time any application had the ability to tune ATM trac parameters at run time. Arequipa only works in situations where end-to-end ATM connectivity exists, but this assumption is not unrealistic in Europ e where many countries have extensive ATM already deployed, not just in the backb ones but also in the LANs. The following section describ es the main features of UNI4.0 signaling and Q.2963.1 connection mo di cation capabilities. Sections 3and 4 describ e Are- quipa and Vic resp ectively, while sections 5 and 6 describ e details of implementation issues and the demo. 2 R1 R3 R2 ATM LAN ATM WAN ATM LAN Figure 1: An Arequipa connection between two ATM attached hosts which bypasses intermediate IP routers completely 2 Renegotiable CBR Connections ATM signaling is used by applications to set up SVCs with prescrib ed QoS. As mentioned in the intro duction, we fo cus here on ATM connections of the CBR class with renegotiation, which we call renegotiable CBR. We refer to renegotiation as the connection mo di cation capability de ned in the ITU recommendation Q.2963.1. The latter relates to mo difying the trac parameter of an already active CBR connection. The only connection characteristic that can b e mo di ed according to Q.2963.1 is the p eak cell rate (PCR). In order to change the PCR of an active connection without renegotiation, the only p ossibilities are to (1) op en a new connection and to close the old one once the new connection is available, or (2) to close the old connection rst and to op en the new one afterwards. In (1), the sum of the old and the new bandwidth is allo cated for a moment, whichmay cause the mo di cation to b e rejected, although the new PCR alone would be acceptable. Also, data can reach the destination on two distinct paths, so the sequence of cells is no longer guaranteed and some synchronization is required. In case (2), connectivity is interrupted for a short moment, and, if the new PCR cannot b e supp orted by the ATM network, the connection may b e lost entirely. Renegotiation has neither of those drawbacks and also has shorter latency and less pro cessing, as the mo di cation messages are small and the ATM network only needs to p erform connection admission control but no addressing, routing or other pro cessing required for call establishment. The exchange of signaling messages during bandwidth renegotiation b etween two applications is shown in Fig. 2. When an application requests a mo di- cation, a MODIFY REQUEST is sent out to the called user provided lo cal resources are available. Similarly a MODIFY ACKNOWLEDGE message is returned to the calling user only if resources are available at the called user. The lo cal resources at the calling user are rechecked b efore the mo di cation is considered to b e agreed up on. Then a con rmation is senttothe application and the p eak cell rate is changed. A renegotiation requesting a rate increase may fail, in which case the p eak cell rate remains at its previous value. Connection mo di cation is going to be an imp ortant capability in future commercial broadband networks, where users will wanttocontrol the sp eed and 3 Application Signaling Signaling Application NETWORK Application request MODIFY REQUEST MODIFY ACKNOWLEDGE Confirmation to application CONNECTION AVAILABLE Figure 2: Message sequence during bandwidth renegotiation quality of the data stream b ecause they will b e charged for network usage (e.g. bandwidth, time). Mo di cation is esp ecially suited for interactivemultimedia applications where bandwidth usage is likely to vary considerably over time. Note that renegotiation is di erent from the initial QoS negotiation. The latter capability (de ned in UNI 4.0) takes place at call setup time, and consists in allowing network no des, or the called user, to negotiate the trac descriptor requested by the calling user. Contrary to negotiation, re-negotiation o ccurs after the connection is set up. Renegotiable CBR connections also di er from Available Bit Rate (ABR) connections [10]. With ABR connections, the maximum cell rate (allowed cell rate) is also variable, but here the value of this rate is dictated by the network, not the user. Also, with ABR connections, there is a concept of minimum cell rate. Extension of our work to ABR connections would b e interesting but still remains to b e done. 3 Arequipa 3.1 Overview of Arequipa The rst step in running IP over ATM is to have a means to carry IP packets on ATM.

Load more