HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:29:07 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 30 Jan 1996 23:00:00 GMT ETag: "2e7ccb-4dad-310ea2f0" Accept-Ranges: bytes Content-Length: 19885 Connection: close Content-Type: text/plain INTERNET-DRAFT Werner Almesberger Jean-Yves Le Boudec Philippe Oechslin LRC, DI-EPFL, Switzerland January 1996 Application REQuested IP over ATM (AREQUIPA) 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract We propose 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). 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 that - Arequipa can be implemented in IPv4 by mainly modifying the implementation of ATMARP[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. Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 1] INTERNET-DRAFT draft-filename January, 1996 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 connections 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 define three new API functions for the TCP/IP stack: Arequipa_expect (socket_descriptor, source IP address, source protid/port, source ATM Address) Arequipa_expect prepares the system to accept an incoming Arequipa connection. When the connection is established, it is bound to the given socket and all data going to the given source IP address/protid/port is sent through this connection. Arequipa_expect is invoked before the socket is set up for receiving data(grams) or accepting connections. (Passive open.) 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 the TCP/IP connection is established or before sending data(grams), respectively. (Active open.) Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 2] INTERNET-DRAFT draft-filename January, 1996 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_expect and 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. 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. As soon as the incoming SVC is identified, it is associated with the corresponding socket using the same or a similar mechanism as for the active open. 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 their ATM address (atm1, 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 accept an incoming ATM connection from H1(atm1) carrying traffic from H1:S1 to H2:S2. Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 3] INTERNET-DRAFT draft-filename January, 1996 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. 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 Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 4] INTERNET-DRAFT draft-filename January, 1996 (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. A2 tells its networking entity to expect an incoming ATM connection from atm1 carrying traffic from H1:S1 to H2:S2, with label L1 in the Flow Label field for incoming packets and L2 for outgoing packets. 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 Expires 7/96 [Page 5] INTERNET-DRAFT draft-filename January, 1996 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. Servers and 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. 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.myaddress 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: Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 6] INTERNET-DRAFT draft-filename January, 1996 HTTP/1.0 200 OK Server: MyAgent/1.0 ATM.address 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.myaddress 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 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 will therefore not be forwarded anymore by the IP layer. 7. Security considerations The main security problems we see with Arequipa are that it could be used to bypass IP firewalls. Almesberger, Le Boudec, Oechslin Expires 7/96 [Page 7] INTERNET-DRAFT draft-filename January, 1996 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. 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, October 95, draft-ietf-ipatm-framework-doc-06, work in progress [3] R. Hinden and S. Deering, Internet Protocol Version (IPv6) Addressing Architecture, Internet Draft, June 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, November 95, draft-ietf-ipngwg-discovery-03.txt, work in progress [5] R. Fileding, H. Frystyk, T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, Internet Draft, March 95 draft-ietf-http-v11-spec-00.txt, work in progress 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 Expires 7/96 [Page 8]