RFC 2746 (rfc2746) - Page 3 of 25

RSVP Operation Over IP Tunnels

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