RFC relevance of encapsulate

As per Relevance of the word encapsulate, we have this rfc below:

Network Working Group A.
Request for Comments: 2746
Category: Standards Track J.
ArrowPoint
J.
MIT
L.

January 2000

RSVP Operation Over IP

Status of this

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

Copyright

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

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

1.

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

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

Terzis, et al. Standards Track [Page 1]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

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

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

The RSVP setup protocol [RFC2205] is one component of a
designed to extend IP to support multiple, controlled classes
service over a wide variety of link-level technologies. To
this technology with maximum flexibility, it is desirable for
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
the equipment from which the tunnel is constructed and the desires
the operator

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

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

When the two end points of the tunnel are capable of supporting
over tunnels, we would like to have proper resources reserved
the tunnel. Depending on the requirements of the situation,
might mean that one client's data flow is placed into a
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
not necessarily mean that all the intermediate routers along
tunnel path support RSVP, this is equivalent to the case of
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
header that has a protocol number other than 46 (e.g. it is 4
IP-in-IP encapsulation) and do not carry the Router-Alert option
making them virtually "invisible" to RSVP routers between the
tunnel endpoints. Moreover, the current IP-in-IP
scheme adds only an IP header as the external wrapper. It
impossible to distinguish between packets that use reservations
those that don't, or to differentiate packets belonging to
RSVP Sessions while they are in the tunnel, because no
information such as a UDP port is available in the encapsulation

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

2. The

2.1. Design

Our design choices are motivated by several goals

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

Terzis, et al. Standards Track [Page 3]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

2.2. Basic

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

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

2.2.1. Design

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

One or more Fixed-Filter style unicast reservations between the
end points of the tunnel will be used to reserve resources
packets traversing the tunnel. In the type 2 case, these
will be configured statically by a management interface. In the
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
normal way, e. g. being wrapped with an IP header only,
the tunnel entry point as source and the exit point as destination

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

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

Terzis, et al. Standards Track [Page 4]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

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

Figure 1. An example IP

2.2.2. Mapping between End-to-End and Tunnel

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

H1 H
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
H3... | Rentry |===================================| Rexit |..... H
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+

Figure 2: An example end-to-end path
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)
"original" session, and to its PATH and RESV messages as the end-to
end messages. One or more RSVP sessions may be in place
Rentry and Rexit to provide resource reservation over the tunnel.
refer to these as the tunnel RSVP sessions, and to their PATH
RESV messages as the tunnel or tunneling messages. A tunnel
session may exist independently from any end-to-end sessions.
example through network management interface one may create a
session over the tunnel to provide QoS support for data flow from H
to H4, although there is no end-to-end RSVP session between H3
H4.

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

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
application of RSVP. The tunnel RSVP session views the two
endpoints as two end hosts with a unicast Fixed-Filter
reservation in between. The original, end-to-end RSVP session
the tunnel as a single (logical) link on the path between
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
creation of new tunnel sessions, while others may be mapped into
existing tunnel RSVP session. The choice of how an end-to-end
is treated at the tunnel is a matter of local policy

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

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

2.3. Major

As IP-in-IP tunnels are being used more widely for network
management purposes, it is clear we must support type 2
(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
classes within the tunnel. Whether it is necessary to support type 3
tunnels (dynamic per end-to-end session tunnel reservation) is
policy issue that should be left open. Our design supports
cases

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

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
into changes in the tunnel reservation state, and that
reported by intermediate routers to the tunnel end points can
correctly transformed into errors reported by the tunnel endpoints
the end-to-end RSVP session

We require that this same association mechanism work for both
case of bundled reservation over a tunnel (type 2 tunnel), and
case of one-to-one mapping between original and tunnel
(type 3 tunnel). In our scheme the association is created when
tunnel entry point first sees an end-to-end session's RESV
and either sets up a new tunnel session, or adds to an
tunnel session. This new association must be conveyed to Rexit,
that Rexit can reserve resources for the end-to-end sessions
the tunnel. This information includes the identifier and
parameters of the tunnel session, and the identifier of the end-to
end session to which the tunnel session is being bound. In
scheme, all RSVP sessions between the same two routers Rentry
Rexit will have identical values for source IP address,
IP address, and destination UDP port number. An individual session
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
tunnel end points to convey the binding information
2. Define a new RSVP object to be attached to end-to-end
messages at Rentry, associating the end-to-end session with
of the tunnel sessions. This new object is interpreted by
associating the end-to-end session with one of the
sessions generated at Rentry
3. Apply the same UDP encapsulation to the end-to-end
messages as to data packets of the session. When
decapsulates the PATH message, it deduces the relation
the source UDP port used in the encapsulation and the
session that is specified in the original PATH message

Terzis, et al. Standards Track [Page 7]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

The last approach above does not require any new design. However
requires additional resources to be reserved for PATH messages (
they are now subject to the tunnel reservation). It also requires
priori knowledge of whether Rexit supports RSVP over tunnels by
encapsulation. If Rentry encapsulates all the end-to-end
messages with the UDP encapsulation, but Rexit does not
this encapsulation, then the encapsulated PATH messages will be
at Rexit

On the other hand, options (1) and (2) can handle this
transparently. They allow Rexit to pass on end-to-end PATHs
via the tunnel (because they are decapsulated normally),
throwing away the tunnel PATHs, all without any
configuration. We chose Option (2) because it is simpler.
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
tunnel to Rexit where they get decapsulated and
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
messages, the flowspec in the end-to-end RESV message and
policies, Rentry decides if and how to map the end-to-
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
updates an existing one
5. Rentry sends a E2E Path containing a SESSION_ASSOC
associating the end-to-end session with the tunnel
above. Rexit records the association and removes the
before forwarding the Path message further
6. Rexit responds to the tunnel PATH message by sending a
RESV message, reserving resources inside the tunnel
7. Rentry UDP-encapsulates arriving packets only if
corresponding tunnel session reservation is actually in
for the packets

Terzis, et al. Standards Track [Page 8]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

2.3.1. SESSION_ASSOC

The new object, called SESSION_ASSOC, is defined with the
format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SESSION object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender FILTER-SPEC (for the tunnel session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SESSION_ASSOC

This field contains the size of the SESSION_ASSOC object in bytes

Should be 192.

Should be sent as zero and ignored on receipt

SESSION

The end-to-end SESSION contained in the object is to be mapped
the tunnel session described by the Sender FILTER-SPEC
below

Sender FILTER-

This is the tunnel session that the above mentioned end-to-
session maps to over the tunnel. As we mentioned above, a
session is identified primarily by source port. This is why we
a Sender Filter-Spec for the tunnel session, in the place of
SESSION object

Terzis, et al. Standards Track [Page 9]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

2.3.2. NODE_CHAR

There has to be a way (other than through configuration) for Rexit
communicate to Rentry the fact that it is a tunnel
supporting the scheme described in this document. We have defined
this reason a new object, called NODE_CHAR, carrying
information. If a node receives this object but does not
it, it should drop it without producing any error report.
with Class-Num = 10bbbbbb (`b' represents a bit), as defined in
RSVP specification [RFC2205], have the characteristics we need.
for now this object only carries one bit of information, it can
used in the future to describe other characteristics of an
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This field contains the size of the NODE_CHAR object in bytes.
should be set to eight

An appropriate value should be assigned by the IANA. We
this value to be 128.

Should be sent as zero and ignored on receipt

T

This bit shows that the node is a RSVP-tunnel capable node

When Rexit receives an end-to-end reservation, it appends a NODE_
object with the T bit set, to the RESV object, it encapsulates it
sends it to Rentry. When Rentry receives this RESV message it
that Rexit implements the mechanism described here and so it
or adjusts a tunnel session and associates the tunnel session to
end-to-end session via a SESSION_ASSOC object. Rentry should
the NODE_CHAR object, before forwarding the RESV message upstream.

Terzis, et al. Standards Track [Page 10]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

on the other hand, Rentry does not support the RSVP Tunnels
it would simply ignore the NODE_CHAR object and not forward
further upstream

3.

In this section we discuss several cases separately, starting
the simplest scenario and moving to the more complex ones

3.1. Single Configured RSVP Session over an IP-in-IP

Treating the two tunnel endpoints as a source and destination host
one easily sets up a FF-style reservation in between. Now
question is what kind of filterspec to use for the
reservation, which directly relates to how packets get
over the tunnel. We discuss two cases below

3.1.1. In the Absence of End-to-End RSVP

In the case where all the packets traversing a tunnel use
reserved resources, the current IP-in-IP encapsulation could be used
The RSVP session over the tunnel would simply specify a FF
reservation (with zero port number) with Rentry as the source
and Rexit as the destination address

However if only some of the packets traversing the tunnel
benefit from the reservation, we must encapsulate the
packets in IP and UDP. This allows intermediate routers to
standard RSVP filterspec handling, without having to know about
existence of tunnels

Rather than supporting both cases we choose to
implementations by requiring all data packets using reservations
be encapsulated with an outer IP and UDP header. This reduces
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
management interface, some or all end-to-end RSVP sessions may
allowed to map to the single RSVP session over the tunnel. In
case there is no need to provide dynamic binding information
end-to-end sessions and the tunnel session, given that the
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
reservation should be adjusted to accommodate the end-to-end

Terzis, et al. Standards Track [Page 11]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

mapped onto it. Again the tunnel manager makes such policy decision
Several scenarios are possible. In the first, the tunnel
is never adjusted. This makes the tunnel the rough equivalent of
fixed-capacity hardware link. In the second, the tunnel
is adjusted whenever a new end-to-end reservation arrives or an
one is torn down. In the third, the tunnel reservation is
upwards or downwards occasionally, whenever the end-to-
reservation level has changed enough to warrant the adjustment.
trades off extra resource usage in the tunnel for reduced
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
is adjustable. Section 5.2 explains how the adjustment can be
out for soft pipes

3.2. Multiple Configured RSVP Sessions over an IP-in-IP

It is straightforward to build on the case of a single
RSVP session over a tunnel by setting up multiple FF-
reservations between the two tunnel endpoints using a
interface. In this case Rentry must carefully encapsulate
packets with the proper UDP port numbers, so that packets
to different tunnel sessions will be distinguished by
intermediate RSVP routers. Note that this case and the one
before describe what we call type 2 tunnels

3.2.1. In the Absence of End-to-End RSVP

Nothing more needs to be said in this case. Rentry classifies
packets and encapsulates them accordingly. Packets with
reservations are encapsulated with an outer IP header only,
packets qualified for reservations are encapsulated with a UDP
as well as an IP header. The UDP source port value should be
set to map to the corresponding tunnel reservation the packet
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
over the tunnel, one must explicitly bind each end-to-end
session to its corresponding tunnel session. As
previously, this binding will be provided by the new SESSION_
object carried by the end-to-end PATH messages

Terzis, et al. Standards Track [Page 12]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

3.3. Dynamically Created Tunnel RSVP

This is the case of a type 3 tunnel. The only differences
this case and that of Section 4.2 are that

- The tunnel session is created when a new end-to-end
shows up
- There is a one-to-one mapping between the end-to-end and
RSVP sessions, as opposed to possibly many-to-one mapping
is allowed in the case described in Section 4.2.

4. RSVP Messages handling over an IP-in-IP

4.1. RSVP Messages for Configured Session(s) Over A

Here one or more RSVP sessions are set up over a tunnel through
management interface. The session reservation parameters
change for a "hard pipe" tunnel. The reservation parameters
change for a "soft pipe" tunnel. Tunnel session PATH
generated by Rentry are addressed to Rexit, where they are
and deleted

4.2. Handling of RSVP Messages at Tunnel

4.2.1. Handling End-to-End PATH Messages at

When forwarding an end-to-end PATH message, a router acting as
tunnel entry point, Rentry, takes the following actions depending
the end-to-end session mentioned in the PATH message. There are
possible cases

1. The end-to-end PATH message is a refresh of a previously
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-
session, then Rentry refreshes the Path state of the end-to-
session and checks to see if this session is mapped to a
session. If this is the case, then when Rentry refreshes the end-to
end session, it includes in the end-to-end PATH message
SESSION_ASSOC object linking this session to its corresponding
session It then encapsulates the end-to-end PATH message and sends
over the tunnel to Rexit. If the tunnel session was
created, the end-to-end PATH message serves as a refresh for
local tunnel state at Rentry as well as for the end-to-end session

Terzis, et al. Standards Track [Page 13]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

Otherwise, if the PATH message is from a new end-to-end session
has not yet been mapped to a tunnel session, Rentry creates
state for this new session setting the outgoing interface to be
tunnel interface. After that, Rentry encapsulates the PATH
and sends it to Rexit without adding a SESSION_ASSOC message

When an end-to-end PATH TEAR is received by Rentry, this
encapsulates and forwards the message to Rexit. If this end-to-
session has a one-to-one mapping to a tunnel session or if this
the last one of the many end-to-end sessions mapping to a
session, Rentry tears down the tunnel session by sending a PATH
for that session to Rexit. If, on the other hand, there are
end-to-end sessions mapping to the tunnel session, then Rentry
a tunnel PATH message adjusting the Tspec of the tunnel session

4.2.2. Handling End-to-End PATH Messages at

Encapsulated end-to-end PATH messages are decapsulated and
at Rexit. Depending on whether the end-to-end PATH message contains
SESSION_ASSOC object or not, Rexit takes the following steps

1. If the end-to-end PATH message does not contain a SESSION_
object, then Rentry sets the Non_RSVP flag at the Path
stored for this end-to-end sender, sets the global break bit
the ADSPEC and forwards the packets downstream. Alternatively
if tunnel sessions exist and none of them has the Non_RSVP
set, Rexit can pick the worst-case Path ADSPEC params from
existing tunnel sessions and update the end-to-end ADSPEC
these values. This is a conservative estimation of the
ADSPEC but it has the benefit of avoiding to set the break
in the end-to-end ADSPEC before mapping information
available. In this case the Non_RSVP flag at the end-to-
Path state is not set

2. If the PATH message contains a SESSION_ASSOC object and
association for this end-to-end session already exists,
Rexit records the association between the end-to-end
and the tunnel session described by the object. If the end-to
end PATH arrives early before the tunnel PATH message
then it creates PATH state at Rexit for the tunnel session
When the actual PATH message for the tunnel session arrives
is treated as an update of the existing PATH state and
updates any information missing. We believe that this
is another transient along with the others existing in RSVP
that it does not have any long-term effects on the
operation of the mechanism described here

Terzis, et al. Standards Track [Page 14]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

Before further forwarding the message to the next hop along
path to the destination, Rexit finds the corresponding
session's recorded state and turns on Non_RSVP flag in
end-to-end Path state if the Non_RSVP bit was turned on for
tunnel session. If the end-to-end PATH message carries
ADSPEC object, Rexit performs composition of
characterization parameters contained in the ADSPEC. It
this by considering the tunnel session's overall (composed
characterization parameters as the local parameters for
logical link implemented by the tunnel, and composing
parameters with those in the end-to-end ADSPEC by
each parameter's defined composition function. In the
link's characterization parameters, the minimum path
may take into account the encapsulation/decapsulation delay
the bandwidth estimate can represent the decrease in
bandwidth caused by the addition of the extra UDP header
ADSPECs and composition functions are discussed in great
in [RFC2210].

If the end-to-end session has reservation state, while
reservation state for the matching tunnel session exists,
send a tunnel RESV message to Rentry matching the
in the end-to-end session

If Rentry does not support RSVP tunneling, then Rexit will have
PATH state for the tunnel. In this case Rexit simply turns on
global break bit in the decapsulated end-to-end PATH message
forwards it

4.2.3. Handling End-to-End RESV Messages at

When forwarding a RESV message upstream, a router serving as the
router, Rexit, may discover that one of the upstream interfaces is
tunnel. In this case the router performs a number of tests

Step 1: Rexit must determine if there is a tunnel session bound
the end-to-end session given in the RESV message. If not, the
is treated as a non-RSVP link, Rexit appends a NODE_CHAR object
the T bit set, to the RESV message and forwards it over the
interface (where it is encapsulated as a normal IP datagram
forwarded towards Rentry).

Step 2: If a bound tunnel session is found, Rexit checks to see if
reservation is already in place for the tunnel session bound to
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
sends the original RESV through tunnel interface (after adding
NODE_CHAR object). For dynamic tunnel sessions, the end-to-end

Terzis, et al. Standards Track [Page 15]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

message acts as a refresh for the tunnel session reservation state
while for configured tunnel sessions, reservation state
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
change the tunnel session's flowspec parameters. In this case
sends a tunnel session RESV, including a RESV_CONFIRM object

In the case of a "hard pipe" tunnel, a new end-to-end reservation
change in the level of resources requested by an existing
may cause the total resource level needed by the end-to-
reservations to exceed the level of resources reserved by the
reservation. This event should be treated as an admission
failure, identically to the case where RSVP requests exceed the
of resources available over a hardware link. A RESV_ERR message
Error Code set to 01 (Admission Control failure), should be sent
to the originator of the end-to-end RESV message

If a RESV CONFIRM response arrives, the original RESV is
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
message, using the error code and value fields from the ERROR_
object of the received tunnel session RESV ERR message. Note that
pre-existing reservations through the tunnel stay in place.
continues refreshing the tunnel RESV using the old flowspec

Tunnel session state for a "soft pipe" may also be adjusted when
end-to-end reservation is deleted. The tunnel session gets
whenever one of the end-to-end sessions using the tunnel goes
(or gets reduced itself). However even when the last end-to-
session bound to that tunnel goes away, the configured tunnel
remains active, perhaps with a configured minimal flowspec

Note that it will often be appropriate to use some hysteresis in
adjustment of the tunnel reservation parameters, rather
adjusting the tunnel reservation up and down with each arriving
departing end-to-end reservation. Doing this will require the
exit router to keep track of the resources allocated to the
(the tunnel flowspec) and the resources actually in use by end-to-
reservations (the sum or statistical sum of the end-to-
reservation flowspecs) separately

When an end-to-end RESV TEAR is received by Rexit, it
and forwards the message to Rentry. If the end-to-end session
created a dynamic tunnel session, then a RESV TEAR for
corresponding tunnel session is send by Rexit

Terzis, et al. Standards Track [Page 16]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

4.2.4. Handling of End-to-End RESV Messages at Rentry

If the RESV message received is a refresh of an existing
then Rentry updates the reservation state and forwards the
upstream. On the other hand, if this is the first RESV message
this end-to-end session and a NODE_CHAR object with the T bit set
present, Rentry should initiate the mapping between this end-to-
session and some (possibly new) tunnel session. This mapping is
on some or all of the contents of the end-to-end PATH message,
contents of the end-to-end RESV message, and local policies.
example, there could be different tunnel sessions based on
bandwidth or delay requirements of end-to-end sessions

If Rentry decides that this end-to-end session should be mapped to
existing configured tunnel session, it binds this end-to-end
to that tunnel session

If this end-to-end RSVP session is allowed to set up a new
session, Rentry sets up tunnel session PATH state as if it were
source of data by starting to send tunnel-session PATH messages
Rexit, which is treated as the unicast destination of the data.
Tspec in this new PATH message is computed from the original
message by adjusting the Tspec parameters to include the
overhead of the encapsulation of data packets. In this case
should also send a PATH message from the end-to-end session this
containing the SESSION_ASSOC object linking the two sessions.
receipt of this PATH message by Rexit will trigger an update of
end-to-end Path state which in turn will have the effect of
sending a tunnel RESV message, allocating resources inside
tunnel

The last case is when the end-to-end session is not allowed to
the tunnel resources. In this case no association is created
this end-to-end session and a tunnel session and no new
session is created

One limitation of our scheme is that the first RESV message of
end-to-end session determines the mapping between that end-to-
session and its corresponding session over the tunnel. Moreover
long as the reservation is active this mapping cannot change

Terzis, et al. Standards Track [Page 17]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

5. Forwarding

When data packets arrive at the tunnel entry point Rentry,
must decide whether to forward the packets using the normal IP-in-
tunnel encapsulation or the IP+UDP encapsulation expected by
tunnel session. This decision is made by determining whether
is a resource reservation (not just PATH state) actually in place
the tunnel session bound to the arriving packet, that is, whether
packet matches any active filterspec

If a reservation is in place, it means that both Rentry and Rexit
RSVP-tunneling aware routers, and the data will be
decapsulated at Rexit

If no tunnel session reservation is in place, the data should
encapsulated in the tunnel's normal format, regardless of
end-to-end PATH state covering the data is present

6.

6.1. Selecting UDP port

There may be multiple end-to-end RSVP sessions between the two
points Rentry and Rexit. These sessions are distinguished by
source UDP port. Other components of the session ID, the source
destination IP addresses and the destination UDP port, are
for all such sessions

The source UDP port is chosen by the tunnel entry point Rentry
it establishes the initial PATH state for a new tunnel session.
source UDP port associated with the new session is then conveyed
Rexit by the SESSION_ASSOC object

The destination UDP port used in tunnel sessions should the
assigned by IANA (363).

6.2. Error

When a tunnel session PATH message encounters an error, it
reported back to Rentry. Rentry must relay the error report back
the original source of the end-to-end session

When a tunnel session RESV request fails, an error message
returned to Rexit. Rexit must treat this as an error in crossing
logical link (the tunnel) and forward the error message back to
end host

Terzis, et al. Standards Track [Page 18]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

6.3. MTU

Since the UDP encapsulated packets should not be fragmented,
entry routers must support tunnel MTU discovery as discussed
section 5.1 of [IP4INIP4]. Alternatively, the Path MTU
mechanism discussed in RFC 2210 [RFC2210] can be used

6.4. Tspec and Flowspec

As multiple End-to-End sessions can be mapped to a single
session, there is the need to compute the aggregate Tspec of all
senders of those End-to-End sessions. This aggregate Tspec will
Tspec of the representative tunnel session. The same operation
to be performed for flowspecs of End-to-End reservations arriving
Rexit

The semantics of these operations are not addressed here.
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
Guaranteed services (found at [RFC2211] and [RFC2212] respectively).
However, it may also be appropriate to compute the
reservation level for the tunnel using a more
statistical or measurement-based computation

7. IPSEC

In the case where the IP-in-IP tunnel supports IPSEC (especially
in Tunnel-Mode with or without AH) then the Tunnel Session uses
GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined
[RSVPESP] for the PATH and RESV messages

Data packets are not encapsulated with a UDP header since the SPI
be used by the intermediate nodes for classification purposes
Notice that user oriented keying must be used between Rentry
Rexit, so that different SPIs are assigned to data packets that
reservation and "best effort" packets, as well as packets that
to different Tunnel Sessions if those are supported

8. RSVP Support for Multicast and Multipoint

The mechanisms described above are useful for unicast tunnels
Unicast tunnels provide logical point-to-point links in the
infrastructure, though they may encapsulate and carry either
or multicast traffic between those points

Terzis, et al. Standards Track [Page 19]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

Two other types of tunnels may be imagined. The first of these is
"multicast" tunnel. In this type of tunnel, packets arriving at
entry point are encapsulated and transported (multicast) to -all-
the exit points. This sort of tunnel might prove useful
implementing a hierarchical multicast distribution network, or
emulating efficiently some portion of a native multicast
tree

A second possible type of tunnel is the "multipoint" tunnel. In
type of tunnel, packets arriving at an entry point are
encapsulated and transported to -one- of the exit points,
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
the data transmission function that the tunnel performs. Instead
the tunnel becomes a way to express some shared property of the
of connected tunnel endpoints. For example, the "tunnel" may be
to create and embed a logical shared broadcast network within
larger network. In this case the tunnel endpoints are the
connected to the logical shared broadcast network. Data traffic
be unicast between two such nodes, broadcast to all connected nodes
or multicast between some subset of the connected nodes. The
itself is used to define a domain in which to manage routing
resource management - essentially a virtual private network

Note that while a VPN of this form can always be implemented using
multicast tunnel to emulate the broadcast medium, this approach
be very inefficient in the case of wide area VPNs, and a
tunnel with appropriate control mechanisms will be preferable

The following paragraphs provide some brief commentary on the use
RSVP in these situations. Future versions of this note will
more concrete details and specifications

Using RSVP to provide resource management over a multicast tunnel
relatively straightforward. As in the unicast case, one or more
sessions may be used, and end-to-end RSVP sessions may be mapped
tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike
unicast, case, however, the mapping is complicated by RSVP'
heterogeneity semantics. If different receivers have made
reservation requests, it may be that the RESV messages arriving
the tunnel would logically map the receiver's requests to
tunnel sessions. Since the data can actually be placed into only
session, the choice of session must be reconciled (merged) to
the one that will meet the needs of all applications. This requires
relatively simple extension to the session mapping mechanism

Terzis, et al. Standards Track [Page 20]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

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
level of resources. For example, we may wish to emulate a "
shared 10 megabit Ethernet" rather than a "logical shared Ethernet".
However, the problem is complicated by the fact that in this type
tunnel the data does not always go to all tunnel endpoints.
implies that we cannot use the destination address of
encapsulated packets as part of the packet classification filter
because the destination address will vary for different
within the tunnel

This implies the need for an extension to current RSVP
semantics in which the Session ID (destination IP address) is
-only- to identify the session state within network nodes, but is
used to classify packets. Other than this, the use of RSVP
multipoint tunnels follows that of multicast tunnels. A
group is created to represent the set of nodes that are
endpoints, and one or more tunnel RSVP sessions are created
reserve resources for the encapsulated packets. In the case of
tunnel implementing a simple VPN, it is most likely that there
be one session to reserve resources for the whole VPN. Each
endpoint will participate both as a source of PATH messages and
source of (FF or SE) RESV messages for this single session
effectively creating a single shared reservation for the
logical shared medium. Tunnel endpoints MUST NOT make
reservations over multipoint tunnels

9. Extensions to the RSVP/Routing

The RSVP specification [RFC2205] states that through the RSVP/
Interface, the RSVP daemon must be able to learn the list of
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
querying the underlying network and physical layers or by using
existing interface between RSVP and the routing protocol
extended to provide this information

Terzis, et al. Standards Track [Page 21]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

10. Security

The introduction of RSVP Tunnels raises no new security issues
than those associated with the use of RSVP and tunnels.
RSVP, the major issue is the need to control and authenticate
to enhanced qualities of service. This requirement is
further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used
protect the integrity of RSVP messages carrying the
described here. The security issues associated with IP-in-IP
are discussed in [IPINIP4] and [IPV6GEN].

11. IANA

IANA should assign a Class number for the NODE_CHAR object defined
Section 3.3.2. This number should be in the 10bbbbbb range.
suggested value is 128.

12.

We thank Bob Braden for his insightful comments that helped us
produce this updated version of the document

13.

[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
IPv6 Specification", RFC 2473, December 1998.

[MINENC] Perkins, C., "Minimal Encapsulation within IP",
2004, October 1996.

[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "
Routing Encapsulation (GRE)", RFC 1701, October 1994.

[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "
Routing Encapsulation over IPv4 Networks", RFC 1702,
October 1994.

[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 1933, April 1996.

Terzis, et al. Standards Track [Page 22]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Services", RFC 2210, September 1997.

[RFC2211] Wroclawski, J., "Specification of the Controlled-
Network Element Service", RFC 2211, September 1997.

[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "
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) --
1 Functional Specification", RFC 2205, September 1997.

[RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for
Data Flows", RFC 2207, September 1997.

[RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "
Cryptographic Authentication", RFC 2747, January 2000.

Terzis, et al. Standards Track [Page 23]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

14. Authors'

John
ArrowPoint
50 Nagog
Acton, MA 01720

Phone: 978-206-3027
EMail: jj@arrowpoint.

John
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139

Phone: 617-253-7885
Fax: 617-253-2673
EMail: jtw@lcs.mit.

Lixia

4531G Boelter
Los Angeles, CA 90095

Phone: 310-825-2695
EMail: lixia@cs.ucla.

Andreas

4677 Boelter
Los Angeles, CA 90095

Phone: 310-267-2190
EMail: terzis@cs.ucla.

Terzis, et al. Standards Track [Page 24]

RFC 2746 RSVP Operation Over IP Tunnels January 2000

15. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Terzis, et al. Standards Track [Page 25]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX