Application REQuested IP over ATM (AREQUIPA)
RFC 2170
Document | Type |
RFC - Informational
(July 1997; No errata)
Was draft-rfced-info-almesberger (individual)
|
|
---|---|---|---|
Authors | Werner Almesberger , Jean-Yves Le Boudec , Philippe Oechslin | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2170 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group W. Almesberger Request for Comments: 2170 J. Le Boudec Category: Informational P. Oechslin LRC, DI-EPFL, Switzerland July 1997 Application REQuested IP over ATM (AREQUIPA) Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note: This RFC has not had the benefit of the rigorous peer review that is part of the process in an IETF working group. The technology it describes has been implemented and is now undergoing testing. It would be wise to analyze the results of this testing as well as to understand alternatives before committing to this approach for IP over ATM with QoS guarantees. Abstract This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS). Given a mapping from service classes, as defined by INTSERV[6], to ATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward. The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud. Almesberger, et. al. Informational [Page 1] RFC 2170 AREQUIPA July 1997 We discuss the implementation of Arequipa for hosts running IPv4 and IPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service. In particular we show how - Arequipa can be implemented in IPv4 by slightly modifying the - Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache, - Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses. Finally, we address safety and security implications. 1. Introduction QoS guarantees are important for delivery of multi-media data and commercial services on the Internet. When two applications on machines running IP over ATM need to transfer data, all the necessary gears to guarantee QoS can be found in the ATM layer. We consider the case where it is desired to use end-to-end ATM connections between applications residing on ATM hosts that have end-to-end ATM connectivity. Opening direct ATM connections between two applications is possible, but then the already available transport protocols, like TCP, can not be reused. This is why we propose Application REQuested IP over ATM (AREQUIPA). Arequipa allows applications to request that two machines be connected by a direct ATM connection with given QoS at the link level. Arequipa makes sure that only data from the applications that requested the connection actually goes through that connection. After setup of the Arequipa connection, the applications can use the standard IP protocol suite to exchange data. 2. API semantics We now define a semantical API for Arequipa. Note that an actual API may perform additional functions (eg. mapping of a given service specification to ATM traffic descriptors) We define the three new API functions for the TCP/IP stack: Arequipa_preset (socket_descriptor, destination IP address, destination protid/port, destination ATM Address, ATM service and QoS parameters) Almesberger, et. al. Informational [Page 2] RFC 2170 AREQUIPA July 1997 Arequipa_preset establishes or prepares establishment of a new ATM connection to the given address with the given ATM service and QoS. It makes sure that any further data sent on the specified socket will use the new ATM connection. Arequipa_preset is invoked before a TCP/IP connection is established or before sending data(grams), respectively. (Active open.) Arequipa_expect (socket_descriptor, allow) Arequipa_expect prepares the system to use an expected incomingShow full document text