Resource Reservation over IP and ATM networks
Silvia Giordano
ICA-EPFL CH-1015 Lausanne
ExtendedAbstract
(full paper can be found at: )
Introduction
The integration of voice, data, and video services modified the target of networking technologies. Instead of simply providing best effort service, the network now has also to deal with the integration of services and, related with that, with providing Quality of Service(QoS).
ATM was born with this new issue in mind [1], and for long was regarded as the ultimate networking technology. Nowadays end-to-end ATM cannot be considered as a reality: the initially expected fast take-off of ATM in the public WAN area did not take place, and most important, it is rarely available to the end user [2].
The Internet community is also working towards introducing resource reservation and charging support in the Internet in order to provide better support for multimedia applications and service providers. Even with IP, QoS is not a reality at the moment. The proposed architectures and protocols are not yet standardised or lack sufficiently wide deployment.
Therefore, even if both technologies define QoS models to go beyond best-effort services, QoS at the application layer cannot be considered available, and there are very few QoS capable applications [3,4].
Additionally, applications are IP-based, and QoS must be kept simple to the users.
QoS in ATM Networks
ATM signalling, is used by applications to set up SVCs with prescribed QoS. To provide QoS it is also necessary end-to-end ATM connectivity, and a means for exchange the ATM addresses. One possibility is to use ATM applications, i.e. application that can use directly the ATM signalling.
Another solution, as soon as the TCP/IP structure wants to be maintained is to use protocols like CLIP [5,6], LANE [7], or Arequipa [8]. Arequipa is a method for providing the QoS of ATM to TCP/IP applications, assuming end-to-end ATM connectivity exists. Arequipa allows applications to establish end-to-end ATM connections under their own control, and to use these connections to carry the IP traffic. Therefore the QoS is guaranteed by the fact that each of these SVCs is used exclusively for one IP flow, unlike the connections set up by CLIP or LANE.
Figure1: An Arequipa connection on ATM network (2) which bypasses intermediate IP routers (on IP network (1)) completely
QoS in IP Networks
Two main solutions to support integrated services on IP based networks are represented by RSVP and Differentiated Services. A slightly different approach is given by SRP.
RSVP [9] is a very flexible and efficient protocol for providing QoS, but it has a significant limitation in the fact that it does not scale well for large number of flows. Moreover RSVP needs to be present in all the routers between client and server.
Differentiated Services groups any simple mechanism that does not depend entirely on a per flow resource reservation and allows providers to differentiate the service pro user base. The contracted network is transparent to best-effort traffic, that is transmitted as in the current Internet. Two of those possible approaches are described in [10] and [11].
SRP [12] proposes a new architecture that aggregates flows on each link in the network. Therefore it scales well even for very large numbers of flows. Admission decisions are performed by routers independently and they also estimate the current level of reservation by means of measurement, and no explicit signalling is needed.
EXPERT demo: QoS renegotiation
The demo consisted of video conferencing traffic transported on ATM by means of Arequipa protocol [13]. For this demo Vic was enabled to use Arequipa. End systems (PC running Linux over ATM [14]) and one of the switch (ATMLight Ring by ASCOM) were upgraded with (partial) UNI4.0 signalling [15] and the Q.2963.1 connection modification capability [16]. Connection modification capability, also included in Arequipa, relates to modifying the PCR of an already active CBR connection. With these an application can modify the QoS parameters, after connection setup, as illustrated in Figure 2. To our knowledge this was the first time any application had the ability to tune ATM traffic parameters at run time.
Figure 2: The Vic demo scenario: the users transfer real-time video, and can tune the PCR at run time.
Conclusion
The integration of voice, data, and video services is a hot issue. A user can request ``tightly guaranteed QoS'' or just a ``better QoS''.
When QoS must be guaranteed, the user is not tolerant to a violation of the requested QoS, therefore the network must provide specific means to assure them (e.g. signalling). One example of this type of application is some tele-medicine application, where a degradation of quality could affect a diagnosis. In this case ATM or IP with RSVP can be either a good solution.
In any case, we have to note that most of the applications are (and probably will remain) IP applications. This means that an ATM or a RSVP network could be not able to provide the requested QoS because several IP flows from different applications use the same connection. To solve this problem it is also needed some mechanism to map a single IP flow to a dedicated connection, where QoS can be respected. The work performed by the EXPERT project offers one solution. We proved that QoS can be easily offered to the user in a way that he can simply manage.
However, in most of the cases the users would simply like to be sure to receive something better than a best effort service, ideally in a way that is at the same time cheap and easy to use. Anyhow the application is tolerant to QoS variation therefore neither RSVP nor ATM are reasonable solutions. In fact, the complexity of providing this service is disproportional for the actual needs of the user. In this case, the type of service requested by the user can be offered by differentiated services mechanism or other mechanism like SRP.
References
[1]“The Asynchronous Transfer Mode: A Tutorial”
J.-Y. Le Boudec, Computer Networks and ISDN Systems, May 1992
[2]“IP and ATM: current evolution for integrated services”
Silvia Giordano, Rolf M. Schmid , Reto Beeler, Hannu Flinck, Jean-Yves Le Boudec,
Technical Report 98/2 SSC-EPFL, January 1998
[3]“RSVP enabled Vic”
S. Berson, ftp://ftp.isi.edu/rsvp/release, 1996
[4]“Using Quality of Service can be simple: Arequipa with Renegotiable ATM connections”
W. Almesberger, L. Chandran, S. Giordano, J.-Y. Le Boudec, R. Schmid
Technical Report 98/3 SSC-EPFL, January 1998
[5] RFC 1577: “Classical IP and ARP over ATM”
Mark Laubach, January 1994
[6] RFC 1483: “Multiprotocol Encapsulation over ATM Adaptation Layer 5”
J. Heinanen, January 1993
[7]“LANE v. 2.0 LUNI Interface”
af-lane-0084.000,
The ATM Forum, July 1997
[8] RFC 2170: “IP over ATM (Arequipa)”
Almesberger, Le Boudec, Oechslin, January 1996
[9]RFC2205: “Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification”
Branden B. et all, September 1997
[10] IETF draft: “A Two-bit Differential Services Architecture for the Internet”
draft-nichols-diff-svc-arch-00.txt
K.Nichols, V. Jacobson, L. Zang, November 1997
[11] IETF draft: “An Approach to Services Allocation in the Internet”
draft-clark-diff-svc-alloc-00.txt
D. Clark, J. Wroclawski, July 1997
[12] “Scalable Reservation Protocol (RSP)”
W. Almesberger, T. Ferrari, J-Y. Le Boudec
DI-EPFL Tech. Rep. 97-234, June 1997
[13]“Quality of Service Renegotiation”
W. Almesberger, L. Chandran-Wadia, S. Giordano, J-Y. Le Boudec, R. Schmid
Technical Report 98/3 SSC-EPFL, January 1998
, February 1998
[14]“ATM on Linux”,
W. Almesberger,
ftp://lrcftp.epfl.ch/pub/linux/atm/papers/atm_on_linux.ps.gz, 1996
[15]“ATM User-Network Interface (UNI) Signalling Specification Version 4.0”
The ATM Forum, af-sig-0061.000
[16]“ITU Recommendation Q.2931, Broadband Integrated Services Digital Network (B-ISDN) -- Digital subscriber signalling system no. 2 (DSS 2) --
User-network interface (UNI) --
Layer 3 specification for basic call/connection control”,
ITU Telecommunication Standardisation Sector - Study group 13, 1995