RFC 2170

Application REQuested IP over ATM (AREQUIPA) 🎀

okay so this is RFC 2170 💖 by W. Almesberger, J. Le Boudec, and P. Oechslin from LRC, DI-EPFL, Switzerland, dated July 1997. It's marked Category: Informational, and it doesn't mention obsoleting or updating any other RFC, so it's doing its own thing 💅

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 🙈

ngl this part is kinda important. This RFC hasn't had the benefit of the rigorous peer review that happens in an IETF working group. The tech it describes has been implemented and is now undergoing testing. It would be wise to analyze the results of that testing, and to understand the alternatives, before committing to this approach for IP over ATM with QoS guarantees. 🫶

Abstract 🦋

Here's the vibe: this document describes a way for ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections inside the reachable ATM cloud. They do this on request from applications, and the connection is reserved for exclusive use by the application that asked for it. The payoff is that requesting applications get to benefit, in a pretty straightforward way, from ATM's built-in ability to guarantee 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. Using Arequipa to provide integrated services when ATM is only available for intermediate links isn't discussed in this document, but it should be straightforward.

The big advantage of an approach like Arequipa is that it only needs to be implemented on the hosts that use it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud. Literally the least drama 💅

We discuss the implementation of Arequipa for hosts running IPv4 and IPv6. As an example, 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 a big deal for delivering 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're looking at the case where you want end-to-end ATM connections between applications sitting on ATM hosts that have end-to-end ATM connectivity 🧚

Opening direct ATM connections between two applications is possible, but then the transport protocols that already exist, like TCP, can not be reused. 😭

That's why we propose Application REQuested IP over ATM (AREQUIPA). Arequipa lets applications request that two machines be connected by a direct ATM connection with a given QoS at the link level. Arequipa makes sure that only data from the applications that requested the connection actually goes through that connection. Once the Arequipa connection is set up, the applications can use the standard IP protocol suite to exchange data. Iconic, honestly 👑

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 three new API functions for the TCP/IP stack.

Arequipa_preset

Arequipa_preset (socket_descriptor, destination IP address,
                 destination protid/port, destination ATM Address,
                 ATM service and QoS parameters)

Arequipa_preset establishes, or prepares the 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

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

Arequipa_close (socket_descriptor)

This closes the corresponding ATM connection. Any further traffic between the endpoints is routed like other traffic. Arequipa_close is implied when the socket is closed. 🫧

Note that using 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 fewer 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 to handle not only associations of ATM addresses and IP addresses, but also associations of one ATM address with an IP address plus endpoint (socket). This is what lets you dedicate an ATM connection to 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. Don't let it leak, bestie 🙈

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 keep an incoming Arequipa SVC from being mistaken for an IP-over-ATM SVC, the setup message uses a specific Broadband High Layer Identifier (BHLI), see below. When it sees the BHLI, ATMARP knows the SVC is of the dedicated type. The socket it has to be associated with 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). An endpoint is a protocol and port number, and we assume that a protocol with ports, such as TCP or UDP, is used. This happens 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 the 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 so 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 is 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 that data 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's 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 ✨

okay so this section is where Arequipa gets to play with IPv6 🦋 With IPv6, sources take advantage of the Flow Label field in the IPv6 header [3].

we're assuming, same as in [4], that the conceptual host model has a neighbour cache and a destination cache, among other things 💅 The destination cache holds entries about destinations that traffic was sent to recently, and the neighbour cache holds entries about neighbours that traffic was sent to recently. with the classical IP over ATM model [1], neighbour cache entries can only refer to systems in the same LIS. we want to go beyond that and let systems beyond the LIS show up there and get treated as neighbours, as long as a direct link level connection (here, an ATM connection) can be set up 🌸

the destination is keyed in [4] by the IP (destination) address. we swap that out for the IP (destination) address and flow label, so the key is a pair now 🎀

we assume that with IPv6, there will be a mechanism for applications to request flow labels that, at the host, form a unique flow-label/destination-address pair. this stops two different flows going to the same destination from accidentally using the same flow label. uniqueness like this is also desirable for other applications that rely on flow-label/destination-address pairs, like RSVP for example 🧚

here's a typical scenario 🫶

application A1 on host H1 and application A2 on host H2 first get in contact using the standard IP over ATM to swap their ATM addresses (atm1, atm2) and to agree on a protocol, port number pair (S1, S2) and flow labels (L1, L2) for the communication over the ATM connection. (we're assuming a protocol with ports, like TCP or UDP, is used). how this happens depends on the application protocols. in Section 5 we give an example for HTTP ✨

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 A1 wants. the connection is associated with L1 and L2 as explained below, so no other traffic from other applications uses the new ATM connection 🔥

from this point on, all traffic exchanged between application A1 on H1 and application A2 on H2 uses this ATM connection 💜

here's an example of destination and neighbour cache entries at H1 🍓

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

so in the example, the route to destination H2 for all traffic other than the one on the ATM connection requested between A1 and A2 uses the default route (maybe 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. v3 points to the ATM connection to router R3. ptr1 points to the first line in the Neighbour Cache, and ptr2 to the second one. Path MTUs (1) and (2) are obtained by ATM signaling, and they may be different. Reachability state (3) is determined as usual by the reachability protocol [4] 💖

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 = "*"). 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 to route the IP packets internally to the right entity 🌈

5. Example: Arequipa for the Web 🌐

this is a quick explanation of how Web [5] servers and browsers can use Arequipa to send documents with a guaranteed QoS 🎀

what we describe below does NOT violate the standards of HTML and HTTP, it just uses their built-in extensibility. so the server and client we describe can work seamlessly with unmodified servers or clients ✨ a similar extension could be used if Web documents were exchanged using RSVP 💅

browsers add one extra field to all their requests or responses to indicate their ATM address. Web documents get extended with meta information describing the ATM service and the QoS needed to send them. note that this info could be in the form of an intserv flowspec and mapped to ATM traffic descriptors 🧚

if a browser always wants documents with QoS meta-information delivered using Arequipa, it adds an extra field to its request to indicate the port it's expecting the data on 🦋

if a browser wants to decide whether Arequipa should be used or not, it does NOT give the port the server should send the data on 🙈

when a server gets a request with an ATM address, it checks whether the requested document has QoS meta-information. if it doesn't, the server delivers the document like a standard server. if the document has QoS meta-information, the server looks for port information in the request. if it finds a port, it opens an Arequipa socket (Arequipa_preset) to the client's ATM address with the QoS given in the document, and sends the reply through this new connection. if the server finds no port information, it sends only the header of the reply (which includes the 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 sent using Arequipa or not. so a client with no a priori knowledge about the document may always want to grab the header before requesting the full document 🫶

illustration time 🎀

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

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

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. so 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 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 both 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 client's one, 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 the request was made on 🍓 for example, this lets a browser spawn a viewer before requesting the data, hand the Arequipa connection to the viewer, and still get the status of the request over the normal TCP connection 🧚

6. Safety considerations (loops) 🔁

okay real talk, a major concern with ATM shortcuts in IP networks is routing loops 😭 Arequipa is NOT prone to these 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 they 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 💀

7. Security considerations 🔐

the main security problem we see with Arequipa is that it could be used to bypass IP firewalls. this is serious, bestie 😤

IP firewalls protect private networks connected to untrusted IP networks. the network is configured so 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 can set up 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 safely by machines inside and outside a protected network if an application proxy is installed on the firewall. on the Web this is a typical scenario. proxy HTTP servers are often found on firewalls, not only for security but also for caching. if an application proxy is used, each host can set up 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] Laubach, M., Classical IP and ARP over ATM, RFC1577, January 1994.

[2] Cole, R. G., D. H. Shur, C. Villamizar, IP over ATM: A Framework Document, RFC1932, April 1996.

[3] Hinden, R. and S. Deering, Internet Protocol Version (IPv6) Addressing Architecture, RFC1884, December 1995.

[4] Narten, T., E. Nordmark and W.A. Simpson, Neighbour Discovery for IPv6 (IPv6), RFC1970, August 1996.

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

[6] Shenker, S./J. Wroclawski, Network Element Service Specification Template, Work in Progess, November, 1995.

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

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