[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 rfc2170                                                    
Internet-Draft            Expires: May 1997               Internet-Draft


Internet-Draft                                        Werner Almesberger
                                                     Jean-Yves Le Boudec
Category: Informational                                Philippe Oechslin
                                               LRC, DI-EPFL, Switzerland
                                                            October 1996


             Application REQuested IP over ATM (AREQUIPA)
                 <draft-rfced-info-almesberger-00.txt>



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific


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, Le Boudec, Oechslin                                [Page 1]


Internet-Draft            Expires: May 1997               Internet-Draft


   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
       existing implementation of support for IP over ATM [1],
     - 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)





Almesberger, Le Boudec, Oechslin                                [Page 2]


Internet-Draft            Expires: May 1997               Internet-Draft

   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)

     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.


Almesberger, Le Boudec, Oechslin                                [Page 3]


Internet-Draft            Expires: May 1997               Internet-Draft

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.

   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.

   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)        |
    ------------------------------------------------------------------


Almesberger, Le Boudec, Oechslin                                [Page 4]


Internet-Draft            Expires: May 1997               Internet-Draft

   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.

   We assume that with IPv6, a mechanism will be provided for
   applications to request flow labels which, at the host, form a
   unique flow-label/destination-address pair. This will prevent two
   different flows which go to the same destination from accidentally
   using the same flow label. Such a uniqueness requirement is also
   desirable for other applications which rely on
   flow-label/destination-address pairs, like for example RSVP.

   A typical scenario is:

   Application A1 on host H1 and application A2 on host H2 first get in
   contact using the standard IP over ATM to exchange their ATM address
   (atm1, atm2) and to define a protocol, port number pair (S1, S2) and
   flow labels (L1, L2) for the communication over the ATM connection.
   (We assume that a protocol with ports, such as TCP or UDP, is
   used). How this is performed depends on the application protocols. In
   Section 5 we give an example for HTTP.

Almesberger, Le Boudec, Oechslin                                [Page 5]


Internet-Draft            Expires: May 1997               Internet-Draft

   A2 tells its networking entity that it wants to send its outgoing
   packets with flow label L2 over an expected incoming ATM connection.
   A1 tells its data link entity to open an ATM connection to H2 using
   ATM address atm2, with the QoS desired by A1. The connection is
   associated with L1 and L2 as explained below so that no other
   traffic generated by other applications uses the new ATM
   connection.

   From this point on all traffic exchanged between applications A1 on
   H1 and application A2 on H2 will use this ATM connection.

   An example of destination and neighbour cache entries at H1 is given
   below.

  Destination Cache
           IPAddr    flowLabel   neighbourCache   pathMTU
            H2         L1          ptr1             (1)
            H2         *           ptr2             (2)

  Neighbour Cache
   IPAddr  linkLayerAddr  isRouter  reachabilityState  invalidationTimer
   H2      v2              no        (3)                t2
   R3      v3              yes       REACHABLE          t3


   In the example, the route to destination H2 for all traffic other
   than the one using the ATM connection requested between application
   A1 and A2 uses the default route (perhaps set up by the classical IP
   model), with router R3 as the next hop; v2 is a pointer to an ATM
   interface and a VPCI/VCI that identifies the Arequipa
   connection. Similarly, v3 points to the ATM connection to router
   R3. ptr1 points to the first line in Neighbour Cache, and ptr2 to the
   second one. Path MTUs (1) and (2) are obtained by ATM signaling;
   they may be different. Reachability state (3) is determined as usual
   by the reachability protocol [4].

   Host H1 must restrict the use of this ATM connection to datagrams
   with flow label L1. Other traffic from H1 to H2 must use the generic
   entry in the destination table (flow label = "*").  Host H1 must
   restrict the use of flow label L1 for destination H2 to traffic
   generated by application A1 on port S1. (The same holds by analogy
   for host H2).

   On the receiving side, host H2 may use label L1 for routing
   internally the IP packets to the appropriate entity.







Almesberger, Le Boudec, Oechslin                                [Page 6]


Internet-Draft            Expires: May 1997               Internet-Draft

5. Example: Arequipa for the Web

   This is a brief explanation of how Web [5] servers and browsers can
   use Arequipa to transmit documents with a guaranteed QoS.

   What we describe below does not violate the standards of HTML
   and HTTP but makes use of their built-in extensibility. The
   server and client we describe can thus interact seamlessly with
   non-modified servers or clients. A similar extension could
   be used if Web documents were to be exchanged using RSVP.

   Browsers add one extra field in all their requests or responses to
   indicate their ATM address. Web documents are extended with meta
   information to describe the ATM service and corresponding QoS
   needed to transmit them. Note that this information could be in
   form of an intserv flowspec and mapped to ATM traffic descriptors.

   If a browser always wants documents with QoS meta-information to be
   delivered using Arequipa, it adds an additional field in its request
   to indicate the port on which it is expecting the data.

   If a browser wants to decide whether Arequipa should be used or not,
   it does not give the port on which the server should send the data.

   When a server gets a request with an ATM address, it checks whether
   the requested document has QoS meta-information. If this is not the
   case, it delivers the document like a standard server. If the
   document has QoS meta-information, the server looks for a port
   information in the request. If it finds a port, it opens an Arequipa
   socket (Arequipa_preset) to the ATM address of the client with the
   QoS given in the document. It sends the reply through this new
   connection. If the server finds no port information, it sends only
   the header of the reply (which includes meta-information) over the
   standard HTTP connection, as if the client had issued a HEAD or GET-
   IF-MODIFIED request.

   When a client receives the header of a document it can decide whether
   it wants the document to be transmitted using Arequipa or not. A
   client without a priori knowledge about the document, may therefore
   always want to retrieve the header before requesting the full
   document.

   Illustration:

   A client requests some documents but wants to decide if QoS
   sensitive documents should be sent using Arequipa or not. Thus it
   adds to its requests its ATM address but not the socket information.

     GET batman.mpeg
     UserAgent: MyAgent/1.0
     ATM-address: my_public_address.my_private_address


Almesberger, Le Boudec, Oechslin                                [Page 7]


Internet-Draft            Expires: May 1997               Internet-Draft

   The server checks batman.mpeg for QoS meta info. It finds the meta
   info and sees an ATM address, but no socket pragma in the
   request. It only returns the header of the document, which includes
   the meta-information:


                                        HTTP/1.0 200 OK
                                        Server: MyAgent/1.0
                                        ATM-Service: CBR
                                        ATM-QoS-PCR: 2000
                                        Content-type: video/mpeg


   The client sees the QoS info and decides that it wants to download
   the document using Arequipa. It opens a TCP socket for listening,
   makes the Arequipa_expect call and sends the following request:

     GET batman.mpeg
     UserAgent: MyAgent/1.0
     ATM-address: my_public_address.my_private_address
     Pragma: socket=TCP.8090

   Again the server checks batman.mpeg for QoS meta info. It finds the
   meta info and sees the ATM address and the socket pragma in the
   request. It creates a TCP socket, makes the Arequipa_preset call,
   connects its TCP socket to the one of the client and sends the
   response over the new TCP connection:

                                        HTTP/1.0 200 OK
                                        Server: MyAgent/1.0 ATM.address
                                        ATM-Service: CBR
                                        ATM-QoS-PCR: 2000
                                        Content-type: video/mpeg

                                        <mpeg data>

   When the server sends the data over the new TCP connection it also
   sends a copy of the response header over the TCP connection on which
   the request was made. For example, this allows a browser to spawn a
   viewer before requesting the data, to give the Arequipa connection to
   the viewer and to still get the status of the request over the normal
   TCP connection.


6. Safety considerations (loops)

   A major concern about ATM shortcuts in IP networks are routing
   loops. Arequipa is not prone to such dangers since it establishes
   connections between applications and not between hosts. All datagrams
   traveling through an Arequipa connection are destined for a given
   socket on the machine at the end of the connection and don't need to
   be forwarded by the IP layer. Therefore, neither hosts nor routers
   implementing Arequipa as described in this document must ever forward
   IP packets received over Arequipa connections.


Almesberger, Le Boudec, Oechslin                                [Page 8]


Internet-Draft            Expires: May 1997               Internet-Draft

7. Security considerations

   The main security problem we see with Arequipa is that it could be
   used to bypass IP firewalls.

   IP firewalls are used to protect private networks connected to
   untrusted IP networks. The network is configured such that all
   traffic going into or coming from the protected network has to go
   through the machine(s) acting as a firewall.

   If hosts in a network protected by a firewall are able to establish
   direct ATM connections to hosts outside the protected network, then
   Arequipa could be used to bypass the firewall. To avoid this, hosts
   inside a protected network should not be given direct connectivity to
   the outside of the network.

   Arequipa can be used in a safe way by machines inside and outside a
   protected network, if an application proxy is installed on the
   firewall. In the Web, this is a typical scenario. Proxy HTTP servers
   are often found on firewalls, not only for security reasons, but also
   for caching. If an application proxy is used, each host can establish
   an Arequipa connection to the proxy which can then relay and monitor
   the traffic across the firewall.

   Note that hosts can easily identify (and refuse) unsolicited
   Arequipa connections by the BHLI identifier that is passed at
   connection setup.

8. References

  [1] M. Laubach, Classical IP and ARP over ATM, IETF RFC 1577

  [2] R. G. Cole, D. H. Shur, C. Villamizar, IP over ATM: A Framework
      Document, Internet Draft, April 96,
      draft-ietf-ipatm-framework-doc-07, work in progress

  [3] R. Hinden and S. Deering, Internet Protocol Version (IPv6)
      Addressing Architecture, Internet Draft, December 1995,
      draft-ietf-ipngwg-addr-arch-03.txt, work in progress

  [4] T. Narten, E. Nordmark and W.A. Simpson, Neighbour Discovery for
      IPv6 (IPv6), Internet Draft, March 96,
      draft-ietf-ipngwg-discovery-06.txt, work in progress

  [5] T. Berners-Lee, R. Fielding, H. Nielsen, Hypertext Transfer
      Protocol -- HTTP/1.0, IETF RFC1945, May 1996.

  [6] S. Shenker/J. Wroclawski, Network Element Service Specification
      Template, Internet Draft, November, 1995,
      draft-ietf-intserv-svc-template-02.txt, work in progress

  [7] M. Perez, F.-C. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
      ATM Signaling Support for IP over ATM, IETF RFC1755, 1995.

Almesberger, Le Boudec, Oechslin                                [Page 9]


Internet-Draft            Expires: May 1997               Internet-Draft
9.  Authors' Address

   Werner Almesberger,
   Jean-Yves Le Boudec,
   Philippe Oechslin (contact author)

   Laboratoire de Reseaux de Communication
   Swiss Federal Institute of Technology (EPFL)
   1015 Lausanne
   Switzerland

   email: {almesber, leboudec, oechslin}@di.epfl.ch









































Almesberger, Le Boudec, Oechslin                               [Page 10]

Internet-Draft            Expires: May 1997               Internet-Draft