Application REQuested IP over ATM (AREQUIPA)
RFC 2170

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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 incoming