Internet Draft

Internet Engineering Task Force                                  RSVP WG
INTERNET-DRAFT                                                 A. Terzis
<draft-ietf-rsvp-tunnel-01.txt>                                     UCLA
                                                             J. Krawczyk
                                               ArrowPoint Communications
                                                           J. Wroclaswki
                                                                 MIT LCS
                                                                L. Zhang
                                                                    UCLA
August 1998                                    Expiration: February 1999



                      RSVP Operation Over IP Tunnels

                      <draft-ietf-rsvp-tunnel-01.txt>



Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments of the  Internet Engineering Task Force (IETF), its areas, and its
working groups.  Note that other groups may also distribute working doc-
uments as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

This document is a product of the RSVP working group of the Internet
Engineering Task Force. Comments are solicited and should be addressed
to the working group's mailing list at rsvp@isi.edu and/or the
author(s).










draft-ietf-rsvp-tunnel-01.txt                                   [Page 1]


INTERNET-DRAFT                                               August 1998


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 pre-
sent the details of an implementation which meets our design goals.


1.  What's changed

Note: The changes described here are from a interim version of the draft
that was not published as an IETF Internet Draft but can be found at
UCLA IRL's web site (http://irl.cs.ucla.edu). We choose to do since
there is small resemblance of this draft to the previously published
version (01).

- The definitions of a type 1 tunnel has changed to mean that at least
one of the tunnel endpoints does not support RSVP Tunnels.

- Definitions of type 2 and 3 tunnels were also changed.

- The SESSION_ASSOC object is now carried by end-to-end PATH messages
and not by Tunnel PATH messages.

- The C-type for the SESSION_ASSOC message is 0.

- The title of paragraph 4.2 was changed to reflect the reorganization
of the whole fourth paragraph.

- Paragraph 4.2.1 was radically changed.

- Paragraph 4.2.2 was changed to match the changes in 4.2.1

- Paragraph 4.2.3 was corrected. Now includes two cases for refreshing
of tunnel RESV state for "hard" and "soft" pipes.

- Paragraphs 4.3, 4.3.1, 4.3.2, 4.4 (the ones talking about handling of
dynamic tunnels) were removed. It was felt that there was a lot of over-
lap between those paragraphs and the corresponding ones talking about
configured tunnels. The handling of configured and dynamic tunnels are
described in paragraphs 4.2 - 4.2.3.

- Paragraph 6.1 now contains the source UDP port assigned by IANA.

- The first part of paragraph 6.3 (ICMP messages) was removed.

- Paragraph 8 (RSVP Support over Multicast Tunnels) is complete updated.




draft-ietf-rsvp-tunnel-01.txt                                   [Page 2]


INTERNET-DRAFT                                               August 1998


- A new Paragraph 9 was added containing the extensions needed to the
RSVP/Routing Interface by RSVP Tunnels.

- Several wording changes were made.


2.  Introduction

IP-in-IP "tunnels" have become a widespread mechanism to transport data-
grams 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 IP4 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 data-
gram.

>From the perspective of traditional best-effort IP packet delivery, a
tunnel behaves as would 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 [RSVP] 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-control-
lable 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 quality-
     of- service 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



draft-ietf-rsvp-tunnel-01.txt                                   [Page 3]


INTERNET-DRAFT                                               August 1998


     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 in
     this note.

The first type 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 pres-
ence of the non-controlled link is detected, as required by the inte-
grated 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 reserva-
tion  (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 equiva-
lent 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, current IP-in-IP encapsulation scheme adds only an IP header
as the external wrapper, thus it is impossible to distinguish between
packets that use reservations from those that don't, or packets belong-
ing to different RSVP sessions, while they are in the tunnel, because no
distinguishing information such as a UDP port is available in the encap-
sulation.

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.








draft-ietf-rsvp-tunnel-01.txt                                   [Page 4]


INTERNET-DRAFT                                               August 1998


3.  The Design

3.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 tun-
     nel.  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.


3.2.  Basic Approach

The basic idea of the method described in this document is to recur-
sively apply RSVP over the tunnel portion of the path. In this new ses-
sion, 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.


3.2.1.

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

Set up a Fixed-Filter style unicast reservation between the two end
points of the tunnel.

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 IP addresses, visible to the intermedi-
ate  routers, so that the routers may distinguish between packets that
use a reservation from others that do not, and if more than one



draft-ietf-rsvp-tunnel-01.txt                                   [Page 5]


INTERNET-DRAFT                                               August 1998


reservation exists, which one the packets belong to.

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.


Figure 1 shows an RSVP over a tunnel where Rentry is the tunnel entry
router which encapsulates data into the tunnel.  Some number of interme-
diate routers forward the data across the network based upon the encap-
sulating IP header added by Rentry.  Rexit is the endpoint of the tun-
nel.  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



3.2.2.

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 Ren-
try; 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.




draft-ietf-rsvp-tunnel-01.txt                                   [Page 6]


INTERNET-DRAFT                                               August 1998


An RSVP session may be in place between endpoints at hosts H1 and H2.
We refer to this session as the "end-to-end" or "original" session, and
to its PATH and RESV messages as the end-to-end messages.  A RSVP ses-
sion may be in place between Rentry and Rexit to provide resource reser-
vation over the tunnel. We refer to this as the tunnel RSVP session, and
to its PATH and RESV messages as the tunnel or tunneling messages.  A
tunnel RSVP session may exist independently from any end-to-end ses-
sions.  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 tun-
nel RSVP session, and creating a new tunnel RSVP session for each end-
to-end session.  In either case, the picture looks like a recursive
application of RSVP.  The tunnel RSVP session views the two tunnel end-
points 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 destina-
tion(s).

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 deter-
mine 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 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.




3.3.  Major Issues

As IP-in-IP tunnels are being used more widely for network traffic man-
agement purposes, it is clear we must support type 2 tunnels (tunnel
reservation for aggregate end-to-end sessions).  Furthermore, we should
allow more than one reservation to be made over an IP-in-IP tunnel.
Whether it is necessary to support type 3 tunnels (per end-to-end ses-
sion 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



draft-ietf-rsvp-tunnel-01.txt                                   [Page 7]


INTERNET-DRAFT                                               August 1998


end-to-end RSVP sessions (that are allowed to use this tunnel session)
will be bound to this configured tunnel session.  However given more
than one RSVP sessions are allowed 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 association mechanism work for both the case of
bundled reservation over a tunnel, and the case of one-to-one mapping
between original and tunnel reservations.

In our scheme the association is created when a tunnel entry point first
sees an end-to-end session's PATH message and either sets up a new tun-
nel session, or adds to an existing tunnel session.  This new associa-
tion must be conveyed to Rexit, so that Rexit will know how to process
arriving RESV messages from the original reservation.  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, individual tunnel sessions are identified
primarily by the source port value.  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 tun-
     nel session. 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



draft-ietf-rsvp-tunnel-01.txt                                   [Page 8]


INTERNET-DRAFT                                               August 1998


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 encapsu-
lation, then the encapsulated PATH messages will be lost at Rexit.

On the other hand, options (1) (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.

The new object, called SESSION_ASSOC, is defined with the following for-
mat:


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

                        SESSION_ASSOC Object


The semantics of a SESSION_ASSOC object are that the end-to-end SESSION
contained in the object is to be mapped to the tunnel session contained
at the same object.

The length field contains the size of the SESSION_ASSOC object in bytes.

Class=192.

Ctype should be sent as zero and ignored on receipt.

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 ses-
sion, in the place of a SESSION object.



The packet exchanges must follow the following constraints:




draft-ietf-rsvp-tunnel-01.txt                                   [Page 9]


INTERNET-DRAFT                                               August 1998


  1. Rentry sends tunnel PATH messages in the standard RSVP format which
     is understood by all RSVP routers and ignored by non-RSVP Rexit
     router.
  2. Rexit sends tunnel session RESV messages only if the tunnel-session
     PATH state is present.
  3. Rentry UDP-encapsulates arriving packets only if a corresponding
     tunnel session reservation is actually in place for the packets.


4.  Implementation

In this section we discuss several cases separately starting from the
simplest to the more complex scenarios.


4.1.  Single Configured RSVP Session over an IP-in-IP Tunnel

Treating the two tunnel ends as a source and destination host, one eas-
ily 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.


4.1.1.  In the Absence of End-to-End RSVP Session

If all the packets traversing a tunnel can use the reserved resources,
then the current IP-in-IP encapsulation could suffice.  The RSVP session
over the tunnel simply specifies a FF style reservation (with zero port
number) with Rentry as the source address and Rexit as the destination
address.

However if only part of the packets traversing the tunnel can use the
reservation, we encapsulate the qualified packets in IP and UDP.  This
allows intermediate routers to use standard RSVP filterspec handling
without knowing the existence of tunnels.

To simplify implementations by reducing special case checking and han-
dling, we require that all data packets using reservations be encapsu-
lated in IP+UDP.


4.1.2.  In the Presence of End-to-End RSVP Session(s)

According to the tunnel control policies through some management inter-
face, some or all end-to-end RSVP sessions may be allowed to map to this
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



draft-ietf-rsvp-tunnel-01.txt                                  [Page 10]


INTERNET-DRAFT                                               August 1998


tunnel session, given the tunnel session is pre-configured thus well-
known and there is only one out there.

Binding multiple end-to-end sessions to one tunnel session, however,
raises a new question of whether the amount of tunnel reservation
should/can be adjusted by the sum of the end-to-end sessions mapped onto
it.  Again the tunnel manager makes such policy decision.  We call a
tunnel reservation a "hard pipe" if the amount cannot be adjusted, oth-
erwise a "soft pipe" if it can be adjusted.  Section 4.2.1 explains how
the adjustment can be carried out for soft pipes.


4.2.  Multiple Configured RSVP Sessions over an IP-in-IP Tunnel

Like the case of a single configured RSVP session over a tunnel, it is
trivial to set up multiple FF-style reservations between the two tunnel
points.  However in this case Rentry must carefully encapsulate quali-
fied data packets with proper UDP port numbers, so that packets belong-
ing to difference tunnel sessions can be distinguished by the intermedi-
ate RSVP routers.


4.2.1.  In the Absence of End-to-End RSVP Session

Nothing more need to be said in this case.  Rentry classifies the pack-
ets and encapsulates accordingly.  Packets with no reservations are
encapsulated in IP only, packets qualified for reservations are encapsu-
lated in IP+UDP, with the UDP source port value properly set to map to
the corresponding tunnel reservation the packet is supposed to use.


4.2.2.  In the Presence of End-to-End RSVP Session(s)

Now because there are more than one RSVP sessions over the tunnel, one
must explicitly bind each end-to-end RSVP session to its corresponding
tunnel session.  As discussed in Section 2.3, this binding will be pro-
vided by the new SESSION_ASSOC object carried in the end-to-end PATH
messages.

4.3.  Dynamically Created Tunnel RSVP Sessions

The only differences between this case and that of 3.2.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 3.2.2 case.



draft-ietf-rsvp-tunnel-01.txt                                  [Page 11]


INTERNET-DRAFT                                               August 1998


5.  RSVP Messages handling over an IP-in-IP Tunnel

5.1.  RSVP Messages for Configured Session(s) Over A Tunnel

Here one or more RSVP sessions are set up over a tunnel through a man-
agement interface.  The session reservation parameters never change for
a "hard pipe" reservation.  The reservation parameters may change for a
"soft pipe" reservation.

The tunnel session PATH messages generated by Rentry are addressed to
Rexit, where they are processed and deleted.


5.2.  Handling End-to-End RSVP Messages


5.2.1.  Handling End-to-End PATH messages at Rentry

When forwarding an end-to-end PATH message, a router acting as the tun-
nel entry point, Rentry, takes the following actions. First, it consid-
ers the corresponding tunnel session. There are four 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 session is new and it "matches" to a configured tun-
     nel session.
  3. The end-to-end session is new and according to the configuration, a
     new dynamic tunnel session should be created.
  4. The end-to-end session is new but according to the tunnel configu-
     ration, it is not allowed to make a reservation over the tunnel.

We describe each of the four cases in the paragraphs that follow.

If the PATH message is a refresh of a previously known end-to-end ses-
sion, then the association between the end-to-end session and the corre-
sponding tunnel session has already been made.

If the end-to-end session is new and Rentry finds a match in some man-
agement database for an existing configured tunnel session, it binds the
new end-to-end session to an existing tunnel session. Before it sends
the PATH message, Rentry also checks to see if the sum of all end-to-end
session Tspec's exceeds the tunnel session's Tspec.

  * If not, nothing more needs be done at this time.
  * If yes, Rentry further checks to see if the tunnel reservation is a
     hard or soft pipe.  For a hard pipe, Rentry sends an alarm message
     to the tunnel manager.  For a soft pipe, it increases the tunnel
     session Tspec accordingly and includes the new parameters in the



draft-ietf-rsvp-tunnel-01.txt                                  [Page 12]


INTERNET-DRAFT                                               August 1998


     PATH message and sends it.

If on the other hand, the end-to-end session is new, and according to
the tunnel policy the new end-to-end RSVP session, represented by this
new PATH message, 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 parame-
ters to include the tunnel overhead of the encapsulation of data pack-
ets.

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.

After finding the corresponding tunnel session, Rentry adds the appro-
priate SESSION_ASSOC object (with the exception of the case where the
end-to-end session is not mapped to a tunnel session, where no SES-
SION_ASSOC object is added) to the end-to-end PATH message and and sends
it over the tunnel. Nothing needs to be done for the tunnel session,
since refreshment of the tunnel session's PATH state is controlled by
the RSVP refresh timer at Rentry.

When an end-to-end PATH TEAR is received by Rentry, it encapsulates and
forwards the message to Rexit, and initiates a PATH TEAR for the corre-
sponding tunnel session possibly adjusting the Tspec of the tunnel ses-
sion.


5.2.2.  Handling End-to-End PATH Messages at Rexit

When a new end-to-end session is recognized at Rentry, information is
passed to Rexit by a binding object in end-to-end PATH message. Rexit
records  the association of the tunnel session with that of the end-to-
end session, and sets the PHOP of the end-to-end session to Rentry.
Rexit also notes the state of non-RSVP flag in the tunnel session PATH
messages.

Encapsulated end-to-end PATH messages are decapsulated at Rexit.  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 the end-to-end PATH message's non-RSVP bit if it was
turned on for the tunnel session.  If the end-to-end PATH message car-
ries an ADSPEC object, Rexit performs composition of the characteriza-
tion parameters contained in the ADSPEC. It does this by considering the
tunnel session's overall (composed) characterization parameters as the



draft-ietf-rsvp-tunnel-01.txt                                  [Page 13]


INTERNET-DRAFT                                               August 1998


local parameters for the logical link implemented by the tunnel, and
composing these parameters with those in the end- to-end ADSPEC by exe-
cuting each parameter's defined composition function.

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 non-RSVP
bit in the decapsulated end-to-end PATH message and forwards it.


5.2.3.  Handling End-to-End RESV messages

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, and Rexit simply forwards the RESV message
over the tunnel interface (where it is encapsulated as a normal IP data-
gram 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. For dynamic tunnel sessions, the
end-to-end RESV message acts as a refresh for the tunnel session RESV
state, while for configured tunnel sessions, reservation state never
expires (the amount of resources reserved changes though).

If the arriving end-to-end RESV message causes a change in the end-to-
end RESV flowspec parameters (either a new or changed end-to-end flow),
Rexit updates the tunnel session's flowspec parameters.  If the change
is an increase and the tunnel session is a "soft pipe", Rexit sends a
tunnel session RESV, including a RESV_CONFIRM object.

If the increase causes the sum of all end-to-end RESV parameters to
exceed that of the tunnel RESV parameters for a "hard pipe", a warning
message should be sent to the tunnel manager and 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 mes-
sage, 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



draft-ietf-rsvp-tunnel-01.txt                                  [Page 14]


INTERNET-DRAFT                                               August 1998


refreshing the tunnel RESV using the old flowspec.

Tunnel session state for a "soft pipe" must 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.

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.


6.  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 ses-
sion.  This decision is made by determining whether there is a resource
reservation (not just PATH state) actually in place for the tunnel ses-
sion 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 decapsu-
lated at Rexit.

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


7.  Details

7.1.  Selecting UDP port numbers

There may be multiple 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 ses-
sions.

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 binding mechanism.



draft-ietf-rsvp-tunnel-01.txt                                  [Page 15]


INTERNET-DRAFT                                               August 1998


The destination UDP port used in tunnel sessions is a well known one and
has be assigned by IANA (363).


7.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.


7.3.  ICMP messages

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].


7.4.  Tspec and Flowspec Calculations

As multiple End-to-End sessions can be mapped to a single tunnel ses-
sion, there is the need to compute the "sum" of all the Tspecs from all
the senders to the 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.

These operations are not addressed here but are defined in the specifi-
cations of the Controlled-Load and Guaranteed services (found at
[RFC2211] and [RFC2212] respectively).


8.  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 dif-
ferent SPIs are assigned to data packets that have reservation and "best
effort" packets, as well as packets that belong to different Tunnel Ses-
sions if those are supported.



draft-ietf-rsvp-tunnel-01.txt                                  [Page 16]


INTERNET-DRAFT                                               August 1998


9.  RSVP Support over Multicast Tunnels

In the last version of the draft we said that support for "multicast
tunnels" was worthwhile and deserved more investigation. Since then,
other people have also proposed the use of multicast tunnels in a VPN
scenario (see [VMMT] for example).

A multicast tunnel is one that has one entry point and multiple exit
points. An RSVP reservation over such a tunnel can be viewed as a simple
multicast reservation over the tunnel tree, and can be done with the
mechanisms described in this draft in the same way as RSVP over unicast
tunnels.  However there is a new issue raised by RSVP over multicast
tunnels: which data flows can use the tunnel reservations?  Are they
multicast data flows along the same multicast tree, or unicast data
flows  that individually use different branches of the tree only?

The VPN scenario presents a usage of the latter type only. A VPN topol-
ogy is made of a number of sites that are remote to each other but
interconnected virtual links (IP-in-IP tunnels).  The VPN runs its own
routing protocol over this virtual topology to compute the forwarding
table for data delivery to all the sites on the VPN.  Data packets are
unicast-encapsulated when they traverse between sites.  To provide
assured bandwidth among all the points on the same VPN, a single multi-
point SE-style RSVP session can be established over the virtual topol-
ogy, and the reserved bandwidth can be used by encapsulated data traffic
flows between any points.

This decoupling of reservation from usage is totally different from the
unicast tunnel case, where RSVP reservation is made between the same
tunnel entry and exit routers that data traffic goes through.  However
from the view of RSVP operations over IP tunnels, a multicast tunnel is
not much different from a unicast tunnel.  All RSVP daemons participat-
ing in the set of tunnel end points join the multicast group (the
address of the multicast group is decided by means outside the scope of
this draft).  To set up duplex reservations over the virtual topology,
each multicast tunnel end node behaves both as a sender and as a
receiver, thus sending both RSVP PATH and RESV messages to the multicast
group.  The RSVP session may use either WF or SE style, with all the
tunnel end points listed as eligible sources in the latter case (because
they each may send encapsulated data packets).  Since the RSVP session
uses a multicast address, while the data packets that use the reserva-
tion are unicast-delivered to individual tunnel endpoints, we resolve
this issue by setting the destination address field in the packet filter
to wildcard.

Different from RSVP support over unicast tunnels, however, it is not
feasible to map individual unicast end-to-end RSVP sessions onto a mul-
ticast RSVP session, simply because the latter is multicast, thus any



draft-ietf-rsvp-tunnel-01.txt                                  [Page 17]


INTERNET-DRAFT                                               August 1998


adjustment of the parameters would change the reservation over the whole
multicast tree.  Whenever it is necessary to support end-to-end RSVP
sessions over tunnels, one should use RSVP tunnel over unicast tunnels.

Except VPN, at this time we are not aware of other general uses for RSVP
over multicast tunnels that assume data is multicast to all receiving
points. (we are aware of the use by mobile IP, which is considered a
very special case that is beyond the interest of RSVP standardization).


10.  Extensions to the RSVP/Routing Interface

[RSVP] 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. This can be done by setting a special flag
for tunnel interfaces in the response from the routing protocol. In the
paragraphs that follow we present, as an example, the modifications
needed in one of the existing RSVP/Routing Interfaces to support RSVP
Tunnels.

One particular routing interface for RSVP, called RSRR, is described in
[RSRR]. Using RSRR, an RSVP daemon makes an Interface Query to the rout-
ing protocol asking for the list of local interfaces. A list of the
local interfaces is provided as a reply to this query. The format of the
Interface Reply is shown in the following figure.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version       | Type          | Flags         | Num           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vif ID-1      |Vif Threshold-1| Prefix        | Vif Status-1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                | Address Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vif Local Address-1                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |...                                                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vif ID-N      |Vif Threshold-N| Prefix        | Vif Status-N  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                | Address Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vif Local Address-N                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




draft-ietf-rsvp-tunnel-01.txt                                  [Page 18]


INTERNET-DRAFT                                               August 1998


The bit vector represents the vif status:


           +-+-+-+-+-+-+-+-+
           |     |T|N|P|U|M|
           +-+-+-+-+-+-+-+-+


Where:

     N = 1 if notification will be made in case of vif changes.
    P = 1 if vif is physical interface, 0 if it is virtual.
    U = 1 if vif is unicast-disabled, 0 if it is enabled.
    M = 1 if vif is multicast-disabled, 0 if it is enabled.

What we propose is adding a new bit T in the vif status bit flag, where
T=1 if the interface is a RSVP Tunnel, or 0 otherwise.


11.  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
[RSVP]. [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].


12.  References

[ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827,
August, 1995.

[IGMPv3] B. Cain, S. Deering, A. Thyagarajan, "Internet Group Management
Protocol, Version 3", Internet Draft draft-ietf-idmr-igmp-v3-00.txt,
November 1997.

[IP4INIP4] C. Perkins, "IP Encapsulation within IP", RFC 2003, October,
1996.

[IPV6GEN] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 Speci-
fication", Internet Draft draft-ietf-ipngwg-ipv6-tunnel-08.txt, January,
1998.

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



draft-ietf-rsvp-tunnel-01.txt                                  [Page 19]


INTERNET-DRAFT                                               August 1998


October, 1996.

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

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

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

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

[RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of the
Guaranteed Quality of Service", RFC2212, September, 1997.

[RSRR] D. Zappala, J. Kann, "RSRR: A Routing Interface for RSVP", Inter-
net Draft, draft-ietf-rsvp-routing-02.txt, July 1998.

[RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC
2205 , September, 1997.

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

[RSVPCRYPTO] F. Baker, "RSVP Cryptographic Authentication", Internet
Draft, draft-ietf-rsvp-md5-05.txt, August 1997.

[VMMT] S. Pegrum, D. Jamieson, M. Yuen, "VPN Multipoint to Multipoint
Tunnel Protocol (VMMT)", Internet Draft draft-pegrum-vmmt-00.txt, March
1998.



13.  Authors' Addresses

   John Krawczyk
   ArrowPoint Communications
   235 Littleton Road
   Westford, Massachusetts 01886
   Phone: 978-692-5875 x27
   Email: jjk@tiac.net


   John Wroclawski
   MIT Laboratory for Computer Science



draft-ietf-rsvp-tunnel-01.txt                                  [Page 20]


INTERNET-DRAFT                                               August 1998


   545 Technology Sq.
   Cambridge, MA  02139

   Phone: 617-253-7885
   Fax:   617-253-2673 (FAX)
   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



























draft-ietf-rsvp-tunnel-01.txt                                  [Page 21]