RFC 2746 (rfc2746) - Page 3 of 25
RSVP Operation Over IP Tunnels
Alternative Format: Original Text Document
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