RSVP over Tunnels: RSVP Operation Over IP Tunnels
How tunnel endpoints run RSVP between themselves so end-to-end reservations can cross an IP-in-IP tunnel.
Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, DOI 10.17487/RFC2746, January 2000, <https://www.rfc-editor.org/info/rfc2746>.
@misc{rfc2746,
series = {Request for Comments},
number = 2746,
howpublished = {RFC 2746},
publisher = {RFC Editor},
doi = {10.17487/RFC2746},
url = {https://www.rfc-editor.org/info/rfc2746},
author = {A. Terzis and J. Krawczyk and J. Wroclawski and L. Zhang},
title = {{RSVP Operation Over IP Tunnels}},
pagetotal = 25,
year = 2000,
month = jan,
} RFC text
Contents
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
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,
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.
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.
........... ............... .............
: _______ : : _____ :
: | | : : | | :
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
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
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
(type 3 tunnel). In our scheme the association is created when a
tunnel entry point first sees an end-to-end session's RESV message
and either sets up a new tunnel session, or adds to an existing
tunnel session. This new association must be conveyed to Rexit, so
that Rexit can reserve resources for the end-to-end sessions inside
the tunnel. This information includes the identifier and certain
parameters of the tunnel session, and the identifier of the end-to-
end session to which the tunnel session is being bound. In our
scheme, all RSVP sessions between the same two routers Rentry and
Rexit will have identical values for source IP address, destination
IP address, and destination UDP port number. An individual session is
identified primarily by the source port value.
We identified three possible choices for a binding mechanism:
1. Define a new RSVP message that is exchanged only between two
tunnel end points to convey the binding information.
2. Define a new RSVP object to be attached to end-to-end PATH
messages at Rentry, associating the end-to-end session with one
of the tunnel sessions. This new object is interpreted by Rexit
associating the end-to-end session with one of the tunnel
sessions generated at Rentry.
3. Apply the same UDP encapsulation to the end-to-end PATH
messages as to data packets of the session. When Rexit
decapsulates the PATH message, it deduces the relation between
the source UDP port used in the encapsulation and the RSVP
session that is specified in the original PATH message.
The last approach above does not require any new design. However it
requires additional resources to be reserved for PATH messages (since
they are now subject to the tunnel reservation). It also requires a
priori knowledge of whether Rexit supports RSVP over tunnels by UDP
encapsulation. If Rentry encapsulates all the end-to-end PATH
messages with the UDP encapsulation, but Rexit does not understand
this encapsulation, then the encapsulated PATH messages will be lost
at Rexit.
On the other hand, options (1) and (2) can handle this case
transparently. They allow Rexit to pass on end-to-end PATHs received
via the tunnel (because they are decapsulated normally), while
throwing away the tunnel PATHs, all without any additional
configuration. We chose Option (2) because it is simpler. We
describe this object in the following section.
Packet exchanges must follow the following constraints:
1. Rentry encapsulates and sends end-to-end PATH messages over the
tunnel to Rexit where they get decapsulated and forwarded
downstream.
2. When a corresponding end-to-end RESV message arrives at Rexit,
Rexit encapsulates it and sends it to Rentry.
3. Based on some or all of the information in the end-to-end PATH
messages, the flowspec in the end-to-end RESV message and local
policies, Rentry decides if and how to map the end-to-end
session to a tunnel session.
4. If the end-to-end session should be mapped to a tunnel session,
Rentry either sends a PATH message for a new tunnel session or
updates an existing one.
5. Rentry sends a E2E Path containing a SESSION_ASSOC object
associating the end-to-end session with the tunnel session
above. Rexit records the association and removes the object
before forwarding the Path message further.
6. Rexit responds to the tunnel PATH message by sending a tunnel
RESV message, reserving resources inside the tunnel.
7. Rentry UDP-encapsulates arriving packets only if a
corresponding tunnel session reservation is actually in place
for the packets.
2.3.1. SESSION_ASSOC Object
The new object, called SESSION_ASSOC, is defined with the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SESSION object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender FILTER-SPEC (for the tunnel session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object
Length
This field contains the size of the SESSION_ASSOC object in bytes.
Class
Should be 192.
Ctype
Should be sent as zero and ignored on receipt.
SESSION object
The end-to-end SESSION contained in the object is to be mapped to
the tunnel session described by the Sender FILTER-SPEC defined
below.
Sender FILTER-SPEC
This is the tunnel session that the above mentioned end-to-end
session maps to over the tunnel. As we mentioned above, a tunnel
session is identified primarily by source port. This is why we use
a Sender Filter-Spec for the tunnel session, in the place of a
SESSION object.
2.3.2. NODE_CHAR Object
There has to be a way (other than through configuration) for Rexit to
communicate to Rentry the fact that it is a tunnel endpoint
supporting the scheme described in this document. We have defined for
this reason a new object, called NODE_CHAR, carrying this
information. If a node receives this object but does not understand
it, it should drop it without producing any error report. Objects
with Class-Num = 10bbbbbb (`b' represents a bit), as defined in the
RSVP specification [RFC2205], have the characteristics we need. While
for now this object only carries one bit of information, it can be
used in the future to describe other characteristics of an RSVP
capable node that are not part of the original RSVP specification.
The object NODE_CHAR has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
This field contains the size of the NODE_CHAR object in bytes. It
should be set to eight.
Class
An appropriate value should be assigned by the IANA. We propose
this value to be 128.
Ctype
Should be sent as zero and ignored on receipt.
T bit
This bit shows that the node is a RSVP-tunnel capable node.
When Rexit receives an end-to-end reservation, it appends a NODE_CHAR
object with the T bit set, to the RESV object, it encapsulates it and
sends it to Rentry. When Rentry receives this RESV message it deduces
that Rexit implements the mechanism described here and so it creates
or adjusts a tunnel session and associates the tunnel session to the
end-to-end session via a SESSION_ASSOC object. Rentry should remove
the NODE_CHAR object, before forwarding the RESV message upstream. If
on the other hand, Rentry does not support the RSVP Tunnels mechanism
it would simply ignore the NODE_CHAR object and not forward it
further upstream.
3. Implementation
In this section we discuss several cases separately, starting from
the simplest scenario and moving to the more complex ones.
3.1. Single Configured RSVP Session over an IP-in-IP Tunnel
Treating the two tunnel endpoints as a source and destination host,
one easily sets up a FF-style reservation in between. Now the
question is what kind of filterspec to use for the tunnel
reservation, which directly relates to how packets get encapsulated
over the tunnel. We discuss two cases below.
3.1.1. In the Absence of End-to-End RSVP Session
In the case where all the packets traversing a tunnel use the
reserved resources, the current IP-in-IP encapsulation could be used.
The RSVP session over the tunnel would simply specify a FF style
reservation (with zero port number) with Rentry as the source address
and Rexit as the destination address.
However if only some of the packets traversing the tunnel should
benefit from the reservation, we must encapsulate the qualified
packets in IP and UDP. This allows intermediate routers to use
standard RSVP filterspec handling, without having to know about the
existence of tunnels.
Rather than supporting both cases we choose to simplify
implementations by requiring all data packets using reservations to
be encapsulated with an outer IP and UDP header. This reduces special
case checking and handling.
3.1.2. In the Presence of End-to-End RSVP Session(s)
According to the tunnel control policies, installed through some
management interface, some or all end-to-end RSVP sessions may be
allowed to map to the single RSVP session over the tunnel. In this
case there is no need to provide dynamic binding information between
end-to-end sessions and the tunnel session, given that the tunnel
session is unique and pre-configured, and therefore well-known.
Binding multiple end-to-end sessions to one tunnel session, however,
raises a new question of when and how the size of the tunnel
reservation should be adjusted to accommodate the end-to-end sessions
mapped onto it. Again the tunnel manager makes such policy decision.
Several scenarios are possible. In the first, the tunnel reservation
is never adjusted. This makes the tunnel the rough equivalent of a
fixed-capacity hardware link. In the second, the tunnel reservation
is adjusted whenever a new end-to-end reservation arrives or an old
one is torn down. In the third, the tunnel reservation is adjusted
upwards or downwards occasionally, whenever the end-to-end
reservation level has changed enough to warrant the adjustment. This
trades off extra resource usage in the tunnel for reduced control
traffic and overhead.
We call a tunnel whose reservation cannot be adjusted a "hard pipe",
as opposed to a "soft pipe" where the amount of resources allocated
is adjustable. Section 5.2 explains how the adjustment can be carried
out for soft pipes.
3.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel
It is straightforward to build on the case of a single configured
RSVP session over a tunnel by setting up multiple FF-style
reservations between the two tunnel endpoints using a management
interface. In this case Rentry must carefully encapsulate data
packets with the proper UDP port numbers, so that packets belonging
to different tunnel sessions will be distinguished by the
intermediate RSVP routers. Note that this case and the one described
before describe what we call type 2 tunnels.
3.2.1. In the Absence of End-to-End RSVP Session
Nothing more needs to be said in this case. Rentry classifies the
packets and encapsulates them accordingly. Packets with no
reservations are encapsulated with an outer IP header only, while
packets qualified for reservations are encapsulated with a UDP header
as well as an IP header. The UDP source port value should be properly
set to map to the corresponding tunnel reservation the packet is
supposed to use.
3.2.2. In the Presence of End-to-End RSVP Session(s)
Since in this case, there is more than one RSVP session operating
over the tunnel, one must explicitly bind each end-to-end RSVP
session to its corresponding tunnel session. As discussed
previously, this binding will be provided by the new SESSION_ASSOC
object carried by the end-to-end PATH messages.
3.3. Dynamically Created Tunnel RSVP Sessions
This is the case of a type 3 tunnel. The only differences between
this case and that of Section 4.2 are that:
- The tunnel session is created when a new end-to-end session
shows up.
- There is a one-to-one mapping between the end-to-end and tunnel
RSVP sessions, as opposed to possibly many-to-one mapping that
is allowed in the case described in Section 4.2.
4. RSVP Messages handling over an IP-in-IP Tunnel
4.1. RSVP Messages for Configured Session(s) Over A Tunnel
Here one or more RSVP sessions are set up over a tunnel through a
management interface. The session reservation parameters never
change for a "hard pipe" tunnel. The reservation parameters may
change for a "soft pipe" tunnel. Tunnel session PATH messages
generated by Rentry are addressed to Rexit, where they are processed
and deleted.
4.2. Handling of RSVP Messages at Tunnel Endpoints
4.2.1. Handling End-to-End PATH Messages at Rentry
When forwarding an end-to-end PATH message, a router acting as the
tunnel entry point, Rentry, takes the following actions depending on
the end-to-end session mentioned in the PATH message. There are two
possible cases:
1. The end-to-end PATH message is a refresh of a previously known
end-to-end session.
2. The end-to-end PATH message is from a new end-to-end session.
If the PATH message is a refresh of a previously known end-to-end
session, then Rentry refreshes the Path state of the end-to-end
session and checks to see if this session is mapped to a tunnel
session. If this is the case, then when Rentry refreshes the end-to-
end session, it includes in the end-to-end PATH message a
SESSION_ASSOC object linking this session to its corresponding tunnel
session It then encapsulates the end-to-end PATH message and sends it
over the tunnel to Rexit. If the tunnel session was dynamically
created, the end-to-end PATH message serves as a refresh for the
local tunnel state at Rentry as well as for the end-to-end session.
Otherwise, if the PATH message is from a new end-to-end session that
has not yet been mapped to a tunnel session, Rentry creates Path
state for this new session setting the outgoing interface to be the
tunnel interface. After that, Rentry encapsulates the PATH message
and sends it to Rexit without adding a SESSION_ASSOC message.
When an end-to-end PATH TEAR is received by Rentry, this node
encapsulates and forwards the message to Rexit. If this end-to-end
session has a one-to-one mapping to a tunnel session or if this is
the last one of the many end-to-end sessions mapping to a tunnel
session, Rentry tears down the tunnel session by sending a PATH TEAR
for that session to Rexit. If, on the other hand, there are remaining
end-to-end sessions mapping to the tunnel session, then Rentry sends
a tunnel PATH message adjusting the Tspec of the tunnel session.
4.2.2. Handling End-to-End PATH Messages at Rexit
Encapsulated end-to-end PATH messages are decapsulated and processed
at Rexit. Depending on whether the end-to-end PATH message contains a
SESSION_ASSOC object or not, Rexit takes the following steps:
1. If the end-to-end PATH message does not contain a SESSION_ASSOC
object, then Rentry sets the Non_RSVP flag at the Path state
stored for this end-to-end sender, sets the global break bit in
the ADSPEC and forwards the packets downstream. Alternatively,
if tunnel sessions exist and none of them has the Non_RSVP flag
set, Rexit can pick the worst-case Path ADSPEC params from the
existing tunnel sessions and update the end-to-end ADSPEC using
these values. This is a conservative estimation of the composed
ADSPEC but it has the benefit of avoiding to set the break bit
in the end-to-end ADSPEC before mapping information is
available. In this case the Non_RSVP flag at the end-to-end
Path state is not set.
2. If the PATH message contains a SESSION_ASSOC object and no
association for this end-to-end session already exists, then
Rexit records the association between the end-to-end session
and the tunnel session described by the object. If the end-to-
end PATH arrives early before the tunnel PATH message arrives
then it creates PATH state at Rexit for the tunnel session.
When the actual PATH message for the tunnel session arrives it
is treated as an update of the existing PATH state and it
updates any information missing. We believe that this situation
is another transient along with the others existing in RSVP and
that it does not have any long-term effects on the correct
operation of the mechanism described here.
Before further forwarding the message to the next hop along the
path to the destination, Rexit finds the corresponding tunnel
session's recorded state and turns on Non_RSVP flag in the
end-to-end Path state if the Non_RSVP bit was turned on for the
tunnel session. If the end-to-end PATH message carries an
ADSPEC object, Rexit performs composition of the
characterization parameters contained in the ADSPEC. It does
this by considering the tunnel session's overall (composed)
characterization parameters as the local parameters for the
logical link implemented by the tunnel, and composing these
parameters with those in the end-to-end ADSPEC by executing
each parameter's defined composition function. In the logical
link's characterization parameters, the minimum path latency
may take into account the encapsulation/decapsulation delay and
the bandwidth estimate can represent the decrease in available
bandwidth caused by the addition of the extra UDP header.
ADSPECs and composition functions are discussed in great detail
in [RFC2210].
If the end-to-end session has reservation state, while no
reservation state for the matching tunnel session exists, Rexit
send a tunnel RESV message to Rentry matching the reservation
in the end-to-end session.
If Rentry does not support RSVP tunneling, then Rexit will have no
PATH state for the tunnel. In this case Rexit simply turns on the
global break bit in the decapsulated end-to-end PATH message and
forwards it.
4.2.3. Handling End-to-End RESV Messages at Rexit
When forwarding a RESV message upstream, a router serving as the exit
router, Rexit, may discover that one of the upstream interfaces is a
tunnel. In this case the router performs a number of tests.
Step 1: Rexit must determine if there is a tunnel session bound to
the end-to-end session given in the RESV message. If not, the tunnel
is treated as a non-RSVP link, Rexit appends a NODE_CHAR object with
the T bit set, to the RESV message and forwards it over the tunnel
interface (where it is encapsulated as a normal IP datagram and
forwarded towards Rentry).
Step 2: If a bound tunnel session is found, Rexit checks to see if a
reservation is already in place for the tunnel session bound to the
end-to-end session given in the RESV message. If the arriving end-
to-end RESV message is a refresh of existing RESV state, then Rexit
sends the original RESV through tunnel interface (after adding the
NODE_CHAR object). For dynamic tunnel sessions, the end-to-end RESV
message acts as a refresh for the tunnel session reservation state,
while for configured tunnel sessions, reservation state never
expires.
If the arriving end-to-end RESV message causes a change in the end-
to-end RESV flowspec parameters, it may also trigger an attempt to
change the tunnel session's flowspec parameters. In this case Rexit
sends a tunnel session RESV, including a RESV_CONFIRM object.
In the case of a "hard pipe" tunnel, a new end-to-end reservation or
change in the level of resources requested by an existing reservation
may cause the total resource level needed by the end-to-end
reservations to exceed the level of resources reserved by the tunnel
reservation. This event should be treated as an admission control
failure, identically to the case where RSVP requests exceed the level
of resources available over a hardware link. A RESV_ERR message with
Error Code set to 01 (Admission Control failure), should be sent back
to the originator of the end-to-end RESV message.
If a RESV CONFIRM response arrives, the original RESV is encapsulated
and sent through the tunnel. If the updated tunnel reservation fails,
Rexit must send a RESV ERR to the originator of the end-to-end RESV
message, using the error code and value fields from the ERROR_SPEC
object of the received tunnel session RESV ERR message. Note that the
pre-existing reservations through the tunnel stay in place. Rexit
continues refreshing the tunnel RESV using the old flowspec.
Tunnel session state for a "soft pipe" may also be adjusted when an
end-to-end reservation is deleted. The tunnel session gets reduced
whenever one of the end-to-end sessions using the tunnel goes away
(or gets reduced itself). However even when the last end-to-end
session bound to that tunnel goes away, the configured tunnel session
remains active, perhaps with a configured minimal flowspec.
Note that it will often be appropriate to use some hysteresis in the
adjustment of the tunnel reservation parameters, rather than
adjusting the tunnel reservation up and down with each arriving or
departing end-to-end reservation. Doing this will require the tunnel
exit router to keep track of the resources allocated to the tunnel
(the tunnel flowspec) and the resources actually in use by end-to-end
reservations (the sum or statistical sum of the end-to-end
reservation flowspecs) separately.
When an end-to-end RESV TEAR is received by Rexit, it encapsulates
and forwards the message to Rentry. If the end-to-end session had
created a dynamic tunnel session, then a RESV TEAR for the
corresponding tunnel session is send by Rexit.
4.2.4. Handling of End-to-End RESV Messages at Rentry.
If the RESV message received is a refresh of an existing reservation
then Rentry updates the reservation state and forwards the message
upstream. On the other hand, if this is the first RESV message for
this end-to-end session and a NODE_CHAR object with the T bit set is
present, Rentry should initiate the mapping between this end-to-end
session and some (possibly new) tunnel session. This mapping is based
on some or all of the contents of the end-to-end PATH message, the
contents of the end-to-end RESV message, and local policies. For
example, there could be different tunnel sessions based on the
bandwidth or delay requirements of end-to-end sessions)
If Rentry decides that this end-to-end session should be mapped to an
existing configured tunnel session, it binds this end-to-end session
to that tunnel session.
If this end-to-end RSVP session is allowed to set up a new tunnel
session, Rentry sets up tunnel session PATH state as if it were a
source of data by starting to send tunnel-session PATH messages to
Rexit, which is treated as the unicast destination of the data. The
Tspec in this new PATH message is computed from the original PATH
message by adjusting the Tspec parameters to include the tunnel
overhead of the encapsulation of data packets. In this case Rentry
should also send a PATH message from the end-to-end session this time
containing the SESSION_ASSOC object linking the two sessions. The
receipt of this PATH message by Rexit will trigger an update of the
end-to-end Path state which in turn will have the effect of Rexit
sending a tunnel RESV message, allocating resources inside the
tunnel.
The last case is when the end-to-end session is not allowed to use
the tunnel resources. In this case no association is created between
this end-to-end session and a tunnel session and no new tunnel
session is created.
One limitation of our scheme is that the first RESV message of an
end-to-end session determines the mapping between that end-to-end
session and its corresponding session over the tunnel. Moreover as
long as the reservation is active this mapping cannot change.
5. Forwarding Data
When data packets arrive at the tunnel entry point Rentry, Rentry
must decide whether to forward the packets using the normal IP-in-IP
tunnel encapsulation or the IP+UDP encapsulation expected by the
tunnel session. This decision is made by determining whether there
is a resource reservation (not just PATH state) actually in place for
the tunnel session bound to the arriving packet, that is, whether the
packet matches any active filterspec.
If a reservation is in place, it means that both Rentry and Rexit are
RSVP-tunneling aware routers, and the data will be correctly
decapsulated at Rexit.
If no tunnel session reservation is in place, the data should be
encapsulated in the tunnel's normal format, regardless of whether
end-to-end PATH state covering the data is present.
6. Details
6.1. Selecting UDP port numbers
There may be multiple end-to-end RSVP sessions between the two end
points Rentry and Rexit. These sessions are distinguished by the
source UDP port. Other components of the session ID, the source and
destination IP addresses and the destination UDP port, are identical
for all such sessions.
The source UDP port is chosen by the tunnel entry point Rentry when
it establishes the initial PATH state for a new tunnel session. The
source UDP port associated with the new session is then conveyed to
Rexit by the SESSION_ASSOC object.
The destination UDP port used in tunnel sessions should the one
assigned by IANA (363).
6.2. Error Reporting
When a tunnel session PATH message encounters an error, it is
reported back to Rentry. Rentry must relay the error report back to
the original source of the end-to-end session.
When a tunnel session RESV request fails, an error message is
returned to Rexit. Rexit must treat this as an error in crossing the
logical link (the tunnel) and forward the error message back to the
end host.
6.3. MTU Discovery
Since the UDP encapsulated packets should not be fragmented, tunnel
entry routers must support tunnel MTU discovery as discussed in
section 5.1 of [IP4INIP4]. Alternatively, the Path MTU Discovery
mechanism discussed in RFC 2210 [RFC2210] can be used.
6.4. Tspec and Flowspec Calculations
As multiple End-to-End sessions can be mapped to a single tunnel
session, there is the need to compute the aggregate Tspec of all the
senders of those End-to-End sessions. This aggregate Tspec will the
Tspec of the representative tunnel session. The same operation needs
to be performed for flowspecs of End-to-End reservations arriving at
Rexit.
The semantics of these operations are not addressed here. The
simplest way to do them is to compute a sum of the end-to-end Tspecs,
as is defined in the specifications of the Controlled-Load and
Guaranteed services (found at [RFC2211] and [RFC2212] respectively).
However, it may also be appropriate to compute the aggregate
reservation level for the tunnel using a more sophisticated
statistical or measurement-based computation.
7. IPSEC Tunnels
In the case where the IP-in-IP tunnel supports IPSEC (especially ESP
in Tunnel-Mode with or without AH) then the Tunnel Session uses the
GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in
[RSVPESP] for the PATH and RESV messages.
Data packets are not encapsulated with a UDP header since the SPI can
be used by the intermediate nodes for classification purposes.
Notice that user oriented keying must be used between Rentry and
Rexit, so that different SPIs are assigned to data packets that have
reservation and "best effort" packets, as well as packets that belong
to different Tunnel Sessions if those are supported.
8. RSVP Support for Multicast and Multipoint Tunnels
The mechanisms described above are useful for unicast tunnels.
Unicast tunnels provide logical point-to-point links in the IP
infrastructure, though they may encapsulate and carry either unicast
or multicast traffic between those points.
Two other types of tunnels may be imagined. The first of these is a
"multicast" tunnel. In this type of tunnel, packets arriving at an
entry point are encapsulated and transported (multicast) to -all- of
the exit points. This sort of tunnel might prove useful for
implementing a hierarchical multicast distribution network, or for
emulating efficiently some portion of a native multicast distribution
tree.
A second possible type of tunnel is the "multipoint" tunnel. In this
type of tunnel, packets arriving at an entry point are normally
encapsulated and transported to -one- of the exit points, according
to some route selection algorithm.
This type of tunnel differs from all previous types in that the '
shape' of the usual data distribution path does not match the 'shape'
of the tunnel. The topology of the tunnel does not by itself define
the data transmission function that the tunnel performs. Instead,
the tunnel becomes a way to express some shared property of the set
of connected tunnel endpoints. For example, the "tunnel" may be used
to create and embed a logical shared broadcast network within some
larger network. In this case the tunnel endpoints are the nodes
connected to the logical shared broadcast network. Data traffic may
be unicast between two such nodes, broadcast to all connected nodes,
or multicast between some subset of the connected nodes. The tunnel
itself is used to define a domain in which to manage routing and
resource management - essentially a virtual private network.
Note that while a VPN of this form can always be implemented using a
multicast tunnel to emulate the broadcast medium, this approach will
be very inefficient in the case of wide area VPNs, and a multipoint
tunnel with appropriate control mechanisms will be preferable.
The following paragraphs provide some brief commentary on the use of
RSVP in these situations. Future versions of this note will provide
more concrete details and specifications.
Using RSVP to provide resource management over a multicast tunnel is
relatively straightforward. As in the unicast case, one or more RSVP
sessions may be used, and end-to-end RSVP sessions may be mapped onto
tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the
unicast, case, however, the mapping is complicated by RSVP's
heterogeneity semantics. If different receivers have made different
reservation requests, it may be that the RESV messages arriving at
the tunnel would logically map the receiver's requests to different
tunnel sessions. Since the data can actually be placed into only one
session, the choice of session must be reconciled (merged) to select
the one that will meet the needs of all applications. This requires a
relatively simple extension to the session mapping mechanism.
Use of RSVP to support multipoint tunnels is somewhat more difficult.
In this case, the goal is to give the tunnel as a whole a specific
level of resources. For example, we may wish to emulate a "logical
shared 10 megabit Ethernet" rather than a "logical shared Ethernet".
However, the problem is complicated by the fact that in this type of
tunnel the data does not always go to all tunnel endpoints. This
implies that we cannot use the destination address of the
encapsulated packets as part of the packet classification filter,
because the destination address will vary for different packets
within the tunnel.
This implies the need for an extension to current RSVP session
semantics in which the Session ID (destination IP address) is used
-only- to identify the session state within network nodes, but is not
used to classify packets. Other than this, the use of RSVP for
multipoint tunnels follows that of multicast tunnels. A multicast
group is created to represent the set of nodes that are tunnel
endpoints, and one or more tunnel RSVP sessions are created to
reserve resources for the encapsulated packets. In the case of a
tunnel implementing a simple VPN, it is most likely that there will
be one session to reserve resources for the whole VPN. Each tunnel
endpoint will participate both as a source of PATH messages and a
source of (FF or SE) RESV messages for this single session,
effectively creating a single shared reservation for the entire
logical shared medium. Tunnel endpoints MUST NOT make wildcard
reservations over multipoint tunnels.
9. Extensions to the RSVP/Routing Interface
The RSVP specification [RFC2205] states that through the RSVP/Routing
Interface, the RSVP daemon must be able to learn the list of local
interfaces along with their IP addresses. In the RSVP Tunnels case,
the RSVP daemon needs also to learn which of the local interface(s)
is (are) IP-in-IP tunnel(s) having the capabilities described here.
The RSVP daemon can acquire this information, either by directly
querying the underlying network and physical layers or by using any
existing interface between RSVP and the routing protocol properly
extended to provide this information.
10. Security Considerations
The introduction of RSVP Tunnels raises no new security issues other
than those associated with the use of RSVP and tunnels. Regarding
RSVP, the major issue is the need to control and authenticate access
to enhanced qualities of service. This requirement is discussed
further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used to
protect the integrity of RSVP messages carrying the information
described here. The security issues associated with IP-in-IP tunnels
are discussed in [IPINIP4] and [IPV6GEN].
11. IANA Considerations
IANA should assign a Class number for the NODE_CHAR object defined in
Section 3.3.2. This number should be in the 10bbbbbb range. The
suggested value is 128.
12. Acknowledgments
We thank Bob Braden for his insightful comments that helped us to
produce this updated version of the document.
13. References
[ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[IP4INIP4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[IPV6GEN] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[MINENC] Perkins, C., "Minimal Encapsulation within IP", RFC
2004, October 1996.
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation over IPv4 Networks", RFC 1702,
October 1994.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC 2212,
September 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
14. Authors' Addresses
John Krawczyk
ArrowPoint Communications
50 Nagog Park
Acton, MA 01720
Phone: 978-206-3027
EMail: jj@arrowpoint.com
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
Phone: 617-253-7885
Fax: 617-253-2673
EMail: jtw@lcs.mit.edu
Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90095
Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
Andreas Terzis
UCLA
4677 Boelter Hall
Los Angeles, CA 90095
Phone: 310-267-2190
EMail: terzis@cs.ucla.edu
15. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Tunnels and the Problem for RSVP
IP-in-IP tunnels have become a widespread mechanism for transporting datagrams through the Internet. A tunnel is typically used to route packets through parts of the network that do not directly implement the desired service, such as IPv6, or to augment and modify the behaviour of the deployed routing architecture, for example multicast routing, Mobile IP and virtual private networks.
Many tunneling methods exist. RFC 2003 tunnels using an additional IPv4 header. RFC 2004 reduces the size of the inner IP header used that way when the original datagram is not fragmented. The generic tunneling method of RFC 2473 can tunnel either IPv4 or IPv6 packets within IPv6, and RFC 1933 describes tunneling IPv6 datagrams through IPv4 networks. RFC 1701 describes a generic routing encapsulation and RFC 1702 applies it to IPv4. RFC 1827 describes a mechanism that can tunnel an encrypted IP datagram.
From the point of view of ordinary best-effort IP delivery, a tunnel behaves like any other link: packets enter one end and are delivered to the other unless resource overload or an error loses them.
RSVP, the setup protocol of RFC 2205, is one component of a framework designed to extend IP with several controlled classes of service over many kinds of link. To deploy it with the most flexibility, it is desirable for tunnels to act as RSVP-controllable links inside the network.
At the time of writing, RSVP signalling over tunnels is not possible. RSVP packets entering a tunnel are encapsulated with an outer IP header whose protocol number is something other than 46, which is 4 for IP-in-IP encapsulation, and they do not carry the Router-Alert option, so they are effectively invisible to the RSVP routers between the two tunnel endpoints. The current IP-in-IP encapsulation adds only an IP header as the external wrapper. It is therefore impossible to tell packets that use reservations from those that do not, or to tell apart packets belonging to different RSVP sessions, because the wrapper carries no distinguishing information such as a UDP port.
A tunnel wraps packets in a second IP header so they can cross a network that would not otherwise carry them. That wrapper hides RSVP messages from the routers inside the tunnel, and it carries nothing that says which packets have been given a reservation. The memo fixes both problems.
- A second RSVP sessionThe two tunnel endpoints run RSVP between themselves, over the tunnel.
- An extra UDP headerReserved data is wrapped in IP and UDP, so the routers in between can tell sessions apart.
- SESSION_ASSOCA new RSVP object that says which end-to-end session maps to which tunnel session.
- NODE_CHARA new RSVP object that lets the exit router say it understands the scheme.
- Only the ends changeRouters inside the tunnel keep using ordinary RSVP filter matching.
§1Three Kinds of Tunnel
A tunnel, like any link, can take part in an RSVP-aware network in one of three ways, depending on the capabilities of the equipment it is built from and on what the operator wants.
A type 1 tunnel is a best-effort link. It does not support resource reservation or QoS control at all. Type 1 tunnels exist when at least one of the routers forming the tunnel endpoints does not support the scheme described in the memo, in which case the tunnel acts as a best-effort link and the goal is only to make sure that RSVP messages traverse it correctly and that the presence of the uncontrolled link is detected, as the integrated services framework requires.
A type 2 tunnel can promise that some overall level of resources is available to carry traffic, but cannot allocate resources to individual flows. A configured resource allocation over a tunnel is the example given.
A type 3 tunnel can make reservations for individual end-to-end data flows. The feature that distinguishes type 3 from type 2 is that in a type 3 tunnel new tunnel reservations are created and torn down dynamically as end-to-end reservations come and go.
When both ends of a tunnel can support RSVP over tunnels, the memo would like proper resources to be reserved along it. Depending on the requirements, that means putting one client's data flow into a larger aggregate reservation, which is the type 2 case, or making a separate reservation for the flow, which is the type 3 case.
The memo adds an important qualification. An RSVP reservation between the two tunnel endpoints does not mean that every router along the tunnel path supports RSVP. That is the same situation as an existing end-to-end RSVP session passing transparently through a cloud of routers that do not support RSVP.
There are three kinds of tunnel. A type 1 tunnel gives no guarantees at all. A type 2 tunnel holds a fixed amount of reserved capacity that several flows share. A type 3 tunnel makes and cancels a separate reservation for each flow. Whether the routers inside the tunnel support RSVP does not matter; the reservation is between the two ends.
| Aspect | Type 1 | Type 2 | Type 3 |
|---|---|---|---|
| Reservation | None, the tunnel is best effort | One overall level for the tunnel | One per end-to-end flow |
| When it is made | Never | Statically, through a management interface | Created and torn down as end-to-end reservations come and go |
| How flows are mapped | Not applicable | Many end-to-end sessions into one tunnel session | One end-to-end session to one tunnel session |
| Tunnel reservation size | Not applicable | Fixed, a hard pipe, or adjustable, a soft pipe | Set per end-to-end session |
§2Design Goals and Basic Approach
The design is motivated by four goals: to coexist with most, if not all, current IP-in-IP tunneling schemes; to limit the changes to the RSVP specification to the minimum possible; to limit the necessary changes to only the two endpoints of a tunnel, which gives simpler deployment, lower overhead in the intermediate routers and less chance of failure when the set of intermediate routers changes because of a routing change; and to interoperate correctly with RSVP routers that have not been upgraded to handle RSVP over tunnels and with non-RSVP tunnel endpoint routers, in which case the tunnel behaves as a non-RSVP link.
The basic idea is to apply RSVP recursively over the tunnel portion of the path. In this new session, the tunnel entry point, called Rentry, sends PATH messages and the tunnel exit point, called Rexit, sends RESV messages, to reserve resources for the end-to-end sessions that cross the tunnel.
Four design decisions follow. One or more Fixed-Filter style unicast reservations between the two endpoints of the tunnel are used to reserve resources for the packets traversing it; in the type 2 case these are configured statically through a management interface, and in the type 3 case they are 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, being wrapped with an IP header only, naming the tunnel entry point as source and the exit point as destination. Data packets that do require resource reservations inside a tunnel must have some attribute other than the IP addresses visible to the intermediate routers, so that the routers can map the packet to an appropriate reservation; to let intermediate routers use standard RSVP filter specification handling, such packets are encapsulated by prepending an IP and a UDP header, and UDP port numbers distinguish packets of different RSVP sessions. The protocol number in the outer IP header is then UDP.
The memo explains the arrangement of the two endpoints and the routers between them. Rentry is the tunnel entry router that encapsulates the data into the tunnel. Some number of intermediate routers forward the data across the network based on the encapsulating IP header added by Rentry. Rexit is the endpoint of the tunnel: it decapsulates the data and forwards it based on the original, inner, IP header.
The memo keeps the changes small: only the two tunnel endpoints need to know about it, and the RSVP specification itself changes very little. The entry router and the exit router run a second RSVP session between them, and reserved data is given an extra UDP header so the routers in between can sort it out with the rules they already have.
- E2E PATHThe end-to-end PATH message is wrapped with the tunnel IP header and sent to Rexit.
- E2E RESVThe matching end-to-end RESV arrives at Rexit and is encapsulated back to Rentry.
- TUNNEL PATH with SESSION_ASSOCRentry creates or updates the tunnel session and states which end-to-end session it belongs to.
- TUNNEL RESVRexit reserves resources inside the tunnel and answers.
§2.3Binding Sessions, and the Two New Objects
When an end-to-end RSVP session crosses an RSVP-capable tunnel there are two cases: mapping it to an existing tunnel RSVP session, which is the type 2 tunnel, or creating a new tunnel RSVP session for each end-to-end session, which is the type 3 tunnel. In both cases the tunnel session views the two tunnel endpoints as two end hosts with a unicast Fixed-Filter style reservation in between, while the end-to-end session views the tunnel as a single logical link on the path. A tunnel may combine type 2 and type 3 characteristics, and the choice of how an end-to-end session is treated is a matter of local policy.
The problem is that the entry router and the exit router have to agree on which end-to-end reservation maps to which tunnel reservation, so that changes in one are reflected in the other and errors reported by intermediate routers can be transformed correctly. The memo identified three possible mechanisms. One is a new RSVP message exchanged only between the two tunnel endpoints. The second is a new RSVP object attached to end-to-end PATH messages at Rentry, associating the end-to-end session with one of the tunnel sessions, and interpreted by Rexit. The third is to apply the same UDP encapsulation to the end-to-end PATH messages as to the data packets of the session, so that Rexit deduces the relation from the source UDP port when it decapsulates the message.
The third approach needs no new design, but it reserves extra resources for PATH messages, since they become subject to the tunnel reservation, and it needs to be known in advance whether Rexit supports RSVP over tunnels by UDP encapsulation. If Rentry encapsulates all the end-to-end PATH messages that way and Rexit does not understand it, the encapsulated PATH messages are lost at Rexit.
The first two options handle that case transparently, because they let Rexit pass on end-to-end PATH messages it receives through the tunnel, since they are decapsulated normally, while discarding the tunnel PATH messages, all without extra configuration. The memo chose the second option because it is simpler.
SESSION_ASSOC is the new object. It carries a length field holding the size of the object in bytes, a class field that should be 192, a c-type field that should be sent as zero and ignored on receipt, the end-to-end SESSION object, and the Sender FILTER-SPEC of the tunnel session that the end-to-end session is mapped to. A Sender FILTER-SPEC is used in place of a SESSION object for the tunnel session because a tunnel session is identified primarily by its source port.
NODE_CHAR is the second new object. It gives Rexit a way, other than through configuration, to tell Rentry that it is a tunnel endpoint supporting the scheme. A node that receives the object but does not understand it should drop it without producing any error report. The object uses a class number of the form 10bbbbbb, as defined in the RSVP specification, and for now carries a single bit of information, though it could in future describe other characteristics of an RSVP-capable node that are not part of the original RSVP specification. Its length should be set to eight bytes, the class value 128 is proposed, the c-type should be sent as zero and ignored on receipt, and the T bit shows that the node is an RSVP-tunnel capable node.
When Rexit receives an end-to-end reservation it appends a NODE_CHAR object with the T bit set to the RESV object, encapsulates the message and sends it to Rentry. Rentry then knows that Rexit implements the mechanism, so it creates or adjusts a tunnel session and associates it with the end-to-end session through a SESSION_ASSOC object. Rentry should remove the NODE_CHAR object before forwarding the RESV message upstream, and if Rentry does not support the mechanism it simply ignores the object and does not forward it further upstream.
The two ends of the tunnel have to agree on which end-to-end reservation belongs to which tunnel reservation. The memo does that with a new object, SESSION_ASSOC, carried in the PATH messages, and a second new object, NODE_CHAR, which is how the exit router tells the entry router that it understands the scheme.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION object (for the end-to-end session) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender FILTER-SPEC (for the tunnel session) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+§4Handling RSVP Messages at the Tunnel Endpoints
The memo lists the packet exchanges the design has to follow. Rentry encapsulates and sends end-to-end PATH messages over the tunnel to Rexit, where they are decapsulated and forwarded downstream. When the corresponding end-to-end RESV message arrives at Rexit, Rexit encapsulates it and sends it to Rentry. Based on some or all of the information in the end-to-end PATH messages, the flow specification in the end-to-end RESV message and local policies, Rentry decides whether and how to map the end-to-end session to a tunnel session. If it should be mapped, Rentry either sends a PATH message for a new tunnel session or updates an existing one. Rentry then sends an end-to-end PATH containing a SESSION_ASSOC object that ties the end-to-end session to the tunnel session, and Rexit records the association and removes the object before forwarding the PATH further. Rexit answers the tunnel PATH message with a tunnel RESV message, reserving resources inside the tunnel. Finally, Rentry applies UDP encapsulation to arriving packets only if a tunnel session reservation is actually in place for them.
At Rentry, a PATH message that refreshes a previously known end-to-end session leads to the path state being refreshed, and if the session is mapped to a tunnel session the refreshed PATH carries a SESSION_ASSOC object linking the two. A PATH from a new end-to-end session leads to path state being created with the outgoing interface set to the tunnel interface, and the message is sent on without a SESSION_ASSOC object. When an end-to-end PATH TEAR arrives, the message is forwarded to Rexit; if the session had a one-to-one mapping, or was the last of several mapping to a tunnel session, the tunnel session is torn down with a PATH TEAR, and otherwise a tunnel PATH message adjusting the traffic specification of the tunnel session is sent.
At Rexit, an encapsulated end-to-end PATH without a SESSION_ASSOC object means the entry router does not support the mechanism, so Rexit sets the Non_RSVP flag in the path state and the global break bit in the ADSPEC and forwards the message. If tunnel sessions exist and none of them has the Non_RSVP flag set, Rexit can instead take the worst-case path ADSPEC parameters from the existing tunnel sessions and update the end-to-end ADSPEC with them, which is a conservative estimate of the composed ADSPEC and avoids setting the break bit before the mapping information is available.
When an end-to-end PATH does carry a SESSION_ASSOC object and no association for that session exists yet, Rexit records it, and if the end-to-end PATH arrived before the tunnel PATH it creates path state for the tunnel session, treating the later tunnel PATH as an update. Before forwarding further, Rexit turns on the Non_RSVP flag in the end-to-end path state if it was on for the tunnel session. If the end-to-end PATH carries an ADSPEC object, Rexit composes the characterization parameters in it, taking the tunnel session's composed parameters as the local parameters of the logical link the tunnel implements and applying each parameter's composition function. The minimum path latency may account for the encapsulation and decapsulation delay, and the bandwidth estimate may account for the loss of bandwidth caused by the extra UDP header. If the end-to-end session has reservation state while the matching tunnel session does not, Rexit sends a tunnel RESV matching the reservation of the end-to-end session.
At Rexit, forwarding a RESV message upstream may reveal that one of the upstream interfaces is a tunnel. Rexit first checks whether a tunnel session is bound to the end-to-end session in the RESV. If not, the tunnel is treated as a non-RSVP link and Rexit appends a NODE_CHAR object with the T bit set and forwards the message over the tunnel interface. If a bound tunnel session is found, Rexit checks whether a reservation is already in place for it. A refresh of existing RESV state is sent through the tunnel with the NODE_CHAR object added, and for dynamic tunnel sessions the end-to-end RESV acts as a refresh for the tunnel session reservation state, while for configured tunnel sessions reservation state never expires.
A change in the end-to-end flow specification may also trigger a change in the tunnel session's, in which case Rexit sends a tunnel session RESV with a RESV_CONFIRM object. On a hard pipe, where the tunnel reservation cannot be adjusted, a new end-to-end reservation or a change in the resources requested may make the total exceed what the tunnel reserved. That is treated as an admission control failure, exactly as if RSVP requests exceeded the resources available over a hardware link, and a RESV_ERR message with error code 01 is sent back to the originator.
On a soft pipe, where the amount of allocated resources can be adjusted, the tunnel session is reduced whenever one of the end-to-end sessions using it goes away or is reduced, and the configured tunnel session stays active even after the last end-to-end session bound to it has gone, perhaps with a configured minimal flow specification. The memo notes that hysteresis is often appropriate, rather than adjusting the tunnel reservation up and down with each arriving or departing reservation, and that doing so requires the exit router to track the resources allocated to the tunnel and the resources actually in use by the end-to-end reservations separately.
At Rentry, a RESV that refreshes an existing reservation updates the reservation state and is forwarded upstream. A first RESV for an end-to-end session that carries a NODE_CHAR object with the T bit set causes Rentry to start the mapping between the end-to-end session and some, possibly new, tunnel session, based on the contents of the PATH and RESV messages and on local policies. If the session maps to an existing configured tunnel session, Rentry binds it there. If the session is allowed to set up a new tunnel session, Rentry creates tunnel session path state as if it were a source of data and starts sending tunnel-session PATH messages to Rexit, with the traffic specification computed from the original PATH by adjusting its parameters to include the tunnel overhead of the encapsulation. It also sends a PATH from the end-to-end session containing the SESSION_ASSOC object, and the receipt of that message at Rexit triggers an update of the end-to-end path state, which in turn makes Rexit send a tunnel RESV allocating resources inside the tunnel. If the end-to-end session is not allowed to use the tunnel resources, no association and no tunnel session are created.
The memo names one limitation: the first RESV message of an end-to-end session determines the mapping between that session and its counterpart over the tunnel, and as long as the reservation is active the mapping cannot change.
Once the mapping is decided, the two ends exchange four kinds of message: the end-to-end PATH, the end-to-end RESV coming back the other way, a tunnel PATH that sets up the reservation inside the tunnel, and a tunnel RESV that confirms it. The exit router also adjusts the reservation it holds in the tunnel as end-to-end reservations come and go, unless the tunnel is a hard pipe, in which case a request that does not fit is refused as an admission control failure.
§5Forwarding Data, Ports and Other Details
When data packets arrive at Rentry, the router must decide whether to forward them with the normal IP-in-IP tunnel encapsulation or with the IP and UDP encapsulation the tunnel session expects. The decision is made by determining whether a resource reservation, and not merely path state, is actually in place for the tunnel session bound to the arriving packet, that is, whether the packet matches any active filter specification. If a reservation is in place, both Rentry and Rexit are RSVP-tunneling aware routers and the data will be decapsulated correctly at Rexit. If no tunnel session reservation is in place, the data is encapsulated in the tunnel's normal format, regardless of whether end-to-end path state covering the data is present.
UDP port numbers. There may be several end-to-end RSVP sessions between the two endpoints, and they are distinguished by the source UDP port. The other components of the session identifier, the source and destination IP addresses and the destination UDP port, are identical for all such sessions. The source UDP port is chosen by Rentry when it establishes the initial path state for a new tunnel session, and it is conveyed to Rexit by the SESSION_ASSOC object. The destination UDP port used in tunnel sessions should be the one assigned by IANA, which is 363.
Error reporting. When a tunnel session PATH message meets an error it is reported back to Rentry, which must relay the error report back to the original source of the end-to-end session. When a tunnel session RESV request fails, an error message is returned to Rexit, which treats this as an error in crossing the logical link and forwards the error message back to the end host.
MTU discovery. Because the UDP encapsulated packets should not be fragmented, tunnel entry routers must support tunnel MTU discovery, or the path MTU discovery mechanism of RFC 2210 can be used.
Traffic and flow specification calculations. Since several end-to-end sessions can be mapped to a single tunnel session, the aggregate traffic specification of all their senders has to be computed, and that aggregate becomes the traffic specification of the representative tunnel session. The same operation is needed for the flow specifications of end-to-end reservations arriving at Rexit. The memo does not fix the semantics of these operations. The simplest way to do them is to compute a sum of the end-to-end traffic specifications, as the Controlled-Load and Guaranteed service specifications define, but a more sophisticated statistical or measurement-based computation of the aggregate reservation level may also be appropriate.
IPsec tunnels. Where the IP-in-IP tunnel supports IPsec, especially ESP in tunnel mode with or without AH, the tunnel session uses the GPI SESSION and the GPI SENDER_TEMPLATE or FILTER_SPEC defined in RFC 2207 for its PATH and RESV messages. Data packets are not then encapsulated with a UDP header, because the SPI can be used by the intermediate nodes for classification. User oriented keying must be used between Rentry and Rexit, so that different SPIs are assigned to packets that have a reservation, to best-effort packets, and to packets belonging to different tunnel sessions if those are supported.
Reserved packets get the extra UDP header only when a reservation is really in place for them. The UDP source port tells the two ends which tunnel session a packet belongs to, and the destination port is the one IANA assigned, 363. The memo also covers error reporting, how the right packet size is found, how several flows are added up into one tunnel reservation, and how the same idea works over an IPsec tunnel.
§8Multicast and Multipoint Tunnels
The mechanisms so far are for unicast tunnels, which provide logical point-to-point links in the IP infrastructure, though they may carry either unicast or multicast traffic between those points. The memo imagines two other kinds.
A multicast tunnel encapsulates packets arriving at an entry point and transports them, by multicast, to all of the exit points. Such a tunnel might be useful for a hierarchical multicast distribution network, or for emulating part of a native multicast distribution tree.
A multipoint tunnel normally encapsulates packets arriving at an entry point and transports them to one of the exit points, chosen by some route selection algorithm. This differs from the previous kinds in that the shape of the usual data distribution path does not match the shape of the tunnel: the topology of the tunnel does not by itself define the data transmission function. Instead the tunnel becomes a way to express a shared property of the set of connected tunnel endpoints, for example a logical shared broadcast network inside a larger network, with the tunnel endpoints as the nodes connected to it. Data traffic may then be unicast between two of those nodes, broadcast to all of them, or multicast between a subset. The tunnel defines a domain in which to manage routing and resource management, essentially a virtual private network. A VPN of this form can always be built with a multicast tunnel emulating a broadcast medium, but that is very inefficient for wide area VPNs, and a multipoint tunnel with the right control mechanisms is preferable.
Using RSVP over a multicast tunnel is relatively straightforward. One or more RSVP sessions may be used, and end-to-end sessions may be mapped onto tunnel sessions many-to-one or one-to-one as in the unicast case. The mapping is complicated by RSVP's heterogeneity semantics: if different receivers have made different reservation requests, the RESV messages arriving at the tunnel would logically map those requests to different tunnel sessions, yet the data can only be placed in one session, so the choice has to be reconciled to select the one that meets the needs of all the applications. That needs a relatively simple extension to the session mapping mechanism.
Using RSVP for multipoint tunnels is more difficult, because the goal is to give the tunnel as a whole a specific level of resources, such as a logical shared 10 megabit Ethernet rather than a logical shared Ethernet. The complication is that in this kind of tunnel the data does not always go to all the endpoints, so the destination address of the encapsulated packets cannot be part of the packet classification filter, because it varies between packets within the tunnel. This needs an extension to the current RSVP session semantics, in which the session identifier, the destination IP address, is used only to identify the session state inside the network nodes and not to classify packets.
Otherwise the use of RSVP for multipoint tunnels follows the multicast case. A multicast group represents the set of nodes that are tunnel endpoints, and one or more tunnel RSVP sessions reserve resources for the encapsulated packets. For a simple VPN there is most likely one session reserving resources for the whole VPN, and each tunnel endpoint takes part both as a source of PATH messages and as a source of Fixed-Filter or Shared-Filter RESV messages for that session, creating a single shared reservation for the entire logical shared medium. Tunnel endpoints must not make wildcard reservations over multipoint tunnels.
Finally, the memo notes that the RSVP daemon has to learn which of its local interfaces are IP-in-IP tunnels with the capabilities described here, since the RSVP specification only requires it to learn the list of local interfaces and their IP addresses. The daemon can get this information by querying the underlying network and physical layers directly, or through an existing interface between RSVP and the routing protocol, properly extended to provide it.
The scheme is written for tunnels between two points. The memo also sketches a multicast tunnel that reaches every exit point, and a multipoint tunnel that picks one exit point per packet. For the multipoint case the destination address cannot be used to recognise which session a packet belongs to, because the address changes from packet to packet, so the session rules have to be extended. The memo leaves the details of both for a later version.
§10Security Considerations
The memo says that introducing RSVP tunnels raises no new security issues beyond those already associated with the use of RSVP and of tunnels. For RSVP itself, the major issue is the need to control and authenticate access to enhanced qualities of service, a requirement discussed further in RFC 2205. RFC 2747 describes the mechanism used to protect the integrity of the RSVP messages that carry the information described in the memo. The security issues associated with IP-in-IP tunnels are discussed in RFC 2003 and RFC 2473.
The memo finds no new security problems beyond those that RSVP and tunnels already have. It points to the RSVP specification for the question of who may ask for a better level of service, and to a separate document for protecting the integrity of the RSVP messages.