rfc2170.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

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
     Arequipa connection for outgoing traffic of a given socket. If
     allow equals TRUE then, as soon as the socket receives data from an
     incoming Arequipa connection, all its return traffic is sent over
     that Arequipa connection. If allow equals FALSE the traffic from
     that socket is always sent over the standard IP route. Note that
     Arequipa_expect is only applicable to connection oriented sockets,
     eg. TCP sockets or connected UDP sockets.

     Arequipa_expect is invoked by the peer which is expecting
     data(grams) or accepting connections. (Passive open.) It is
     typically called immediately after a socket has been created. It
     may also be called when a data transfer is already going on.

   Arequipa_close (socket_descriptor)

     Closes the corresponding ATM connection. Any further traffic
     between the endpoints is routed like other traffic. Arequipa_close
     is implied when closing the socket.

   Note that the use of Arequipa_expect or _preset only reflects the
   direction of the initial dialog in the Arequipa connection. Actual
   data can flow in both directions.

   An actual implementation may use less arguments for Arequipa_preset
   if some of the information is already passed by other networking
   operations.

3. Implementation with IPv4

   To implement Arequipa with IPv4, ATMARP must be able not only to
   handle associations of ATM addresses and IP addresses, but also
   associations of one ATM address with an IP address plus endpoint
   (socket). This allows to dedicate an ATM connection for the traffic
   between two endpoints.





Almesberger, et. al.         Informational                      [Page 3]

RFC 2170                        AREQUIPA                       July 1997


   For the active open, a destination ATM address must be associated
   with a socket. In systems using per-socket route and ARP caching,
   this can be done by presetting the caches with the appropriate
   values. Establishment of the SVC is delegated to ATMARP. Care must be
   taken that routing and ARP information obtained through Arequipa does
   not leak to other parts of the system.

   For the passive open, an incoming SVC must be associated with the
   socket that terminates the corresponding connection or data flow.
   Most of this functionality is already available in the existing
   protocol stack. To avoid an incoming Arequipa SVC to be mistaken for
   an IP-over-ATM SVC, the setup message uses a specific Broadband High
   Layer Identifier (BHLI), see below. Seeing the BHLI, ATMARP knows
   that the SVC is of the dedicated type. The socket to which it has to
   be associated is identified as soon as a datagram is received through
   the SVC. If an Arequipa_expect has been done for that socket, then
   the SVC is used for all return traffic of that socket.

   If application A1 on host H1 wants a direct ATM connection to
   application A2 on host H2 it does the following:

   Both applications first get in contact using the standard IP over ATM
   to exchange the ATM address of the receiver (atm2) and the endpoints
   (S1, S2) (i.e. protocol and port number; we assume that a protocol
   with ports, such as TCP or UDP, is used) at both hosts between which
   communication will occur. How this is performed depends on the
   application protocols. In Section 5 we give an example for HTTP.

   A2 invokes Arequipa_expect to indicate that it wants to make use of
   an expected incoming ATM connection.

   A1 invokes Arequipa_preset to open or prepare opening of an ATM
   connection to H2 using ATM address atm2 and the QoS desired by A1 as
   soon as data is sent through S1. The connection is associated with S1
   such that no other traffic  (e.g. generated by other applications)
   uses the new ATM connection.















Almesberger, et. al.         Informational                      [Page 4]

RFC 2170                        AREQUIPA                       July 1997


   An Arequipa connection shall be signaled by using the procedures and
   codings described in RFC1755 [7], with the addition that the BHLI
   information element be included in the SETUP message, with the
   following coding:

    ------------------------------------------------------------------
    | bb_high_layer_information                                      |
    ------------------------------------------------------------------
    |  high_layer_information_type    3            (vendor-specific  |
    |                                               application id.) |
    |  high_layer_information         00-60-D7     (EPFL OUI)        |
    |                                 01-00-00-01  (Arequipa)        |
    ------------------------------------------------------------------

   As soon as data arrives from H1:S1 at H2:S2, the ATM connection the
   data has arrived on is identified as the dedicated connection for
   this data flow and S2 is changed to exclusively send on that
   connection.

   From this point on all traffic exchanged between S1 of A1 and S2 of
   A2 will use the new ATM connection with the desired QoS.

   Note that it is possible for H1 and H2 to belong to the same LIS [2]
   and still decide to use an Arequipa connection between applications,
   in addition to one or several other, non-Arequipa ATM connections
   between hosts H1 and H2. There may also exist several Arequipa
   connections between two hosts.

4. Implementation with IPv6

   With IPv6, sources take advantage of the Flow Label field in the IPv6
   header [3].

   We assume as in [4] that the conceptual host model uses, among
   others, a neighbour cache and a destination cache. The destination
   cache holds entries about destinations to which traffic has been sent
   recently, while the neighbour cache holds entries about neighbours to
   which traffic has been sent recently. With the classical IP over ATM
   model [1], entries in the neighbour cache can only refer to systems
   in the same LIS; we propose to go beyond this limitation and allow
   systems beyond the LIS to appear there and be treated as neighbours,
   in the case where a direct link level connection (here, an ATM
   connection) can be established.

   The destination is keyed in [4] by the IP (destination) address. We
   replace this by the IP (destination) address and flow label.





Almesberger, et. al.         Informational                      [Page 5]