rfc2746.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          A. Terzis
Request for Comments: 2746                                          UCLA
Category: Standards Track                                    J. Krawczyk
                                               ArrowPoint Communications
                                                           J. Wroclawski
                                                                 MIT LCS
                                                                L. Zhang
                                                                    UCLA
                                                            January 2000


                     RSVP Operation Over IP Tunnels

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes an approach for providing RSVP protocol
   services over IP tunnels. We briefly describe the problem, the
   characteristics of possible solutions, and the design goals of our
   approach. We then present the details of an implementation which
   meets our design goals.

1.  Introduction

   IP-in-IP "tunnels" have become a widespread mechanism to transport
   datagrams in the Internet. Typically, a tunnel is used to route
   packets through portions of the network which do not directly
   implement the desired service (e.g. IPv6), or to augment and modify
   the behavior of the deployed routing architecture (e.g. multicast
   routing, mobile IP, Virtual Private Net).

   Many IP-in-IP tunneling protocols exist today.  [IP4INIP4] details a
   method of tunneling using an additional IPv4 header.  [MINENC]
   describes a way to reduce the size of the "inner" IP header used in
   [IP4INIP4] when the original datagram is not fragmented.  The generic
   tunneling method in [IPV6GEN] can be used to tunnel either IPv4 or
   IPv6 packets within IPv6.  [RFC1933] describes how to tunnel IPv6



Terzis, et al.              Standards Track                     [Page 1]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   datagrams through IPv4 networks.  [RFC1701] describes a generic
   routing encapsulation, while [RFC1702] applies this encapsulation to
   IPv4.  Finally, [ESP] describes a mechanism that can be used to
   tunnel an encrypted IP datagram.

   From the perspective of traditional best-effort IP packet delivery, a
   tunnel behaves as any other link. Packets enter one end of the
   tunnel, and are delivered to the other end unless resource overload
   or error causes them to be lost.

   The RSVP setup protocol [RFC2205] is one component of a framework
   designed to extend IP to support multiple, controlled classes of
   service over a wide variety of link-level technologies. To deploy
   this technology with maximum flexibility, it is desirable for tunnels
   to act as RSVP-controllable links within the network.

   A tunnel, and in fact any sort of link, may participate in an RSVP-
   aware network in one of three ways, depending on the capabilities of
   the equipment from which the tunnel is constructed and the desires of
   the operator.

      1. The (logical) link may not support resource reservation or QoS
         control at all. This is a best-effort link. We refer to this as
         a best-effort or type 1 tunnel in this note.
      2. The (logical) link may be able to promise that some overall
         level of resources is available to carry traffic, but not to
         allocate resources specifically to individual data flows.  A
         configured resource allocation over a tunnel is an example of
         this.  We refer to this case as a type 2 tunnel in this note.
      3. The (logical) link may be able to make reservations for
         individual end-to-end data flows.  We refer to this case as a
         type 3 tunnel. Note that the key feature that distinguishes
         type 3 tunnels from type 2 tunnels is that in the type 3 tunnel
         new tunnel reservations are created and torn down dynamically
         as end-to-end reservations come and go.

   Type 1 tunnels exist when at least one of the routers comprising the
   tunnel endpoints does not support the scheme we describe here. In
   this case, the tunnel acts as a best-effort link. Our goal is simply
   to make sure that RSVP messages traverse the link correctly, and the
   presence of the non-controlled link is detected, as required by the
   integrated services framework.

   When the two end points of the tunnel are capable of supporting RSVP
   over tunnels, we would like to have proper resources reserved along
   the tunnel.  Depending on the requirements of the situation, this
   might mean that  one client's data flow is placed into a larger
   aggregate reservation  (type 2 tunnels) or that possibly a new,



Terzis, et al.              Standards Track                     [Page 2]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   separate reservation is made for the data flow (type 3 tunnels).
   Note that an RSVP reservation between the two tunnel end points does
   not necessarily mean that all the intermediate routers along the
   tunnel path support RSVP, this is equivalent to the case of an
   existing end-to-end RSVP session transparently passing through non-
   RSVP cloud.

   Currently, however, RSVP signaling over tunnels is not possible.
   RSVP packets entering the tunnel are encapsulated with an outer IP
   header that has a protocol number other than 46 (e.g. it is 4 for
   IP-in-IP encapsulation) and do not carry the Router-Alert option,
   making them virtually "invisible" to RSVP routers between the two
   tunnel endpoints.  Moreover, the current IP-in-IP encapsulation
   scheme adds only an IP header as the external wrapper. It is
   impossible to distinguish between packets that use reservations and
   those that don't, or to differentiate packets belonging to different
   RSVP Sessions while they are in the tunnel, because no distinguishing
   information such as a UDP port is available in the encapsulation.

   This document describes an IP tunneling enhancement mechanism that
   allows RSVP to make  reservations across all IP-in-IP tunnels. This
   mechanism is capable of supporting both type 2 and type 3 tunnels, as
   described above, and requires minimal changes to both RSVP and other
   parts of the integrated services framework.

2.  The Design

2.1.  Design Goals

   Our design choices are motivated by several goals.

      * Co-existing with most, if not all, current IP-in-IP tunneling
        schemes.
      * Limiting the changes to the RSVP spec to the minimum possible.
      * Limiting the necessary changes to only the two end points of a
        tunnel.  This requirement leads to simpler deployment, lower
        overhead in the intermediate routers, and less chance of failure
        when the set of intermediate routers is modified due to routing
        changes.
      * Supporting correct inter-operation with RSVP routers that have
        not been upgraded to handle RSVP over tunnels and with non-RSVP
        tunnel endpoint routers. In these cases, the tunnel behaves as a
        non-RSVP link.








Terzis, et al.              Standards Track                     [Page 3]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


2.2.  Basic Approach

   The basic idea of the method described in this document is to
   recursively apply RSVP over the tunnel portion of the path. In this
   new session, the tunnel entry point Rentry sends PATH messages and
   the tunnel exit point Rexit sends RESV messages to reserve resources
   for the end-to-end sessions over the tunnel.

   We discuss next two different aspects of the design: how to enhance
   an IP-in-IP tunnel with RSVP capability, and how to map end-to-end
   RSVP sessions to a tunnel session.

2.2.1.  Design Decisions

   To establish a RSVP reservation over a unicast IP-in-IP tunnel, we
   made the following design decisions:

   One or more Fixed-Filter style unicast reservations between the two
   end points of the tunnel will be used to reserve resources for
   packets traversing the tunnel. In the type 2 case, these reservations
   will be configured statically by a management interface. In the type
   3 case, these reservations will be created and torn down on demand,
   as end-to-end reservation requests come and go.

   Packets that do not require reservations are encapsulated in the
   normal way, e. g. being wrapped with an IP header only, specifying
   the tunnel entry point as source and the exit point as destination.

   Data packets that require resource reservations within a tunnel must
   have some attribute other than the IP addresses visible to the
   intermediate routers, so that the routers may map the packet to an
   appropriate reservation.  To allow intermediate routers to use
   standard RSVP filterspec handling, we choose to encapsulate such data
   packets by prepending an IP and a UDP header, and to use UDP port
   numbers to distinguish packets of different RSVP sessions. The
   protocol number in the outer IP header in this case will be UDP.

   Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel
   entry router which encapsulates data into the tunnel.  Some number of
   intermediate routers forward the data across the network based upon
   the encapsulating IP header added by Rentry.  Rexit is the endpoint
   of the tunnel.  It decapsulates the data and forwards it based upon
   the original, "inner" IP header.








Terzis, et al.              Standards Track                     [Page 4]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


     ...........             ...............            .............
               :   _______   :             :   _____    :
               :  |       |  :             :  |     |   :
     Intranet  :--| Rentry|===================|Rexit|___:Intranet
               :  |_______|  :             :  |_____|   :
     ..........:             :   Internet  :            :...........
                             :..............
                          |___________________|

                 Figure 1.  An example IP Tunnel

2.2.2.  Mapping between End-to-End and Tunnel Sessions

   Figure 2 shows a simple topology with a tunnel and a few hosts. The
   sending hosts H1 and H3 may be one or multiple IP hops away from
   Rentry; the receiving hosts H2 and H4 may also be either one or
   multiple IP hops away from Rexit.

             H1                                          H2
             :                                            :
             :                                            :
         +--------+     +---+     +---+     +---+     +-------+
         |        |     |   |     |   |     |   |     |       |
   H3... | Rentry |===================================| Rexit |.....  H4
         |        |     |   |     |   |     |   |     |       |
         +--------+     +---+     +---+     +---+     +-------+

            Figure 2: An example end-to-end path with
                      a tunnel in the middle.

   An RSVP session may be in place between endpoints at hosts H1 and H2.
   We refer to this session as the "end-to-end" (E2E for short) or
   "original" session, and to its PATH and RESV messages as the end-to-
   end messages.  One or more RSVP sessions may be in place between
   Rentry and Rexit to provide resource reservation over the tunnel. We
   refer to these as the tunnel RSVP sessions, and to their PATH and
   RESV messages as the tunnel or tunneling messages.  A tunnel RSVP
   session may exist independently from any end-to-end sessions.  For
   example through network management interface one may create a RSVP
   session over the tunnel to provide QoS support for data flow from H3
   to H4, although there is no end-to-end RSVP session between H3 and
   H4.

   When an end-to-end RSVP session crosses a RSVP-capable tunnel, there
   are two cases to consider in designing mechanisms to support an end-
   to-end reservation over the tunnel: mapping the E2E session to an
   existing tunnel RSVP session (type 2 tunnel), and dynamically
   creating a new tunnel RSVP session for each end-to-end session (type



Terzis, et al.              Standards Track                     [Page 5]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   3 tunnel).  In either case, the picture looks like a recursive
   application of RSVP.  The tunnel RSVP session views the two tunnel
   endpoints as two end hosts with a unicast Fixed-Filter style
   reservation in between.  The original, end-to-end RSVP session views
   the tunnel as a single (logical) link on the path between the
   source(s) and destination(s).

   Note that in practice a tunnel may combine type 2 and type 3
   characteristics. Some end-to-end RSVP sessions may trigger the
   creation of new tunnel sessions, while others may be mapped into an
   existing tunnel RSVP session. The choice of how an end-to-end session
   is treated at the tunnel is a matter of local policy.

   When an end-to-end RSVP session crosses a RSVP-capable tunnel, it is
   necessary to coordinate the actions of the two RSVP sessions, to
   determine whether or when the tunnel RSVP session should be created
   and torn down, and to correctly transfer error and ADSPEC information
   between the two RSVP sessions.  We made the following design
   decision:

      * End-to-end RSVP control messages being forwarded through a
        tunnel are encapsulated in the same way as normal IP packets,
        e.g. being wrapped with the tunnel IP header only, specifying
        the tunnel entry point as source and the exit point as
        destination.

2.3.  Major Issues

   As IP-in-IP tunnels are being used more widely for network traffic
   management purposes, it is clear we must support type 2 tunnels
   (tunnel reservation for aggregate end-to-end sessions).  Furthermore,
   these type 2 tunnels should allow more than one (configurable,
   static) reservation to be used at once, to support different traffic
   classes within the tunnel. Whether it is necessary to support type 3
   tunnels (dynamic per end-to-end session tunnel reservation) is a
   policy issue that should be left open.  Our design supports both
   cases.

   If there is only one RSVP session configured over a tunnel, then all
   the end-to-end RSVP sessions (that are allowed to use this tunnel
   session) will be bound to this configured tunnel session.  However
   when more than one RSVP session is in use over an IP tunnel, a second
   design issue is how the association, or binding, between an original
   RSVP reservation and a tunnel reservation is created and conveyed
   from one end of the tunnel to the other. The entry router Rentry and
   the exit router Rexit must agree on these associations so that





Terzis, et al.              Standards Track                     [Page 6]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   changes in the original reservation state can be correctly mapped
   into changes in the tunnel reservation state, and that errors
   reported by intermediate routers to the tunnel end points can be
   correctly transformed into errors reported by the tunnel endpoints to
   the end-to-end RSVP session.

   We require that this same association mechanism work for both the
   case of bundled reservation over a tunnel (type 2 tunnel), and the
   case of one-to-one mapping between original and tunnel reservations