doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2170.txt b/doc/rfc/rfc2170.txt
new file mode 100644
index 0000000..fc4c56f
--- /dev/null
+++ b/doc/rfc/rfc2170.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+RFC 2170                        AREQUIPA                       July 1997
+
+
+   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.
+
+   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
+
+
+
+Almesberger, et. al.         Informational                      [Page 6]
+
+RFC 2170                        AREQUIPA                       July 1997
+
+
+   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.
+
+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
+
+
+
+Almesberger, et. al.         Informational                      [Page 7]
+
+RFC 2170                        AREQUIPA                       July 1997
+
+
+   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
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+Almesberger, et. al.         Informational                      [Page 8]
+
+RFC 2170                        AREQUIPA                       July 1997
+
+
+   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.
+
+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.
+
+
+
+
+Almesberger, et. al.         Informational                      [Page 9]
+
+RFC 2170                        AREQUIPA                       July 1997
+
+
+   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] 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
+
+
+
+Almesberger, et. al.         Informational                     [Page 10]
+