rfc2170.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 564 行 · 第 1/2 页


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]