INTERNET DRAFT Tunnels/RSVP Interoperability March 1997
INTERNET DRAFT John J. Krawczyk
RSVP Working Group Bay Networks, Inc.
draft-ietf-rsvp-tunnels-interop-00.txt March 11, 1997
Expires: September, 1997
Designing Tunnels for Interoperability with RSVP
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents 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 learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).
2. Abstract
This memo provides information for designers of tunneling
protocols that use IP-in-IP encapsulation. It describes how
to design a tunnel header so that RSVP [RSVPv1] can be used to
signal the Quality of Service requirements for individual
flows within an IP-in-IP tunnel.
JJ Krawczyk Expires September 1997 [Page 1]
INTERNET DRAFT Tunnels/RSVP Interoperability March 1997
3. Introduction
There are many issues concerning the use of RSVP when data is
encapsulated within IP-in-IP tunnels. This memo discusses the
problem of classifying flows within a tunnel. It is hoped
that this will aid those designing new tunneling mechanisms to
make their proposals "RSVP friendly".
A problem with most of the existing IP-in-IP tunneling
mechanisms is the inability to distinguish between flows
within a tunnel based upon the tunnel "wrapper", or outer
header. Therefore, while it is possible to make a reservation
for the tunnel itself, all traffic in the tunnel is then
treated in the same manner.
Performing classification based upon the tunnel payload is
undesirable. Two major reasons are:
Examing additional fields in a packet can have severe
performance penalties.
The payload may be encrypted.
Therefore, it is desirable to be able to distinguish flows
based on fields in the encapsulating header. This memo
explains how to design a tunnel header to meet this goal.
4. Requirements for an RSVP-Friendly Tunnel Header
We will assume here that any simplex IP-in-IP tunnel, unicast
or multicast, can, at a minimum, be identified by the source
and destination IP addresses and an IP protocol number [e.g.,
RFC2003]. In order to classify individual flows within a
tunnel, at least one additional field is needed. To be
compliant with RSVP version 1, the following alternatives can
be considered:
UDP/TCP ports, or fields in the same location in the
packet for protocols other than UDP and TCP.
For IPv6, the Flow ID.
Any mechanism compliant with the Generalized Port
JJ Krawczyk Expires September 1997 [Page 2]
INTERNET DRAFT Tunnels/RSVP Interoperability March 1997
Identifier as described in [RSVPIPSEC].
If classification on any other fields is desired, new RSVP
SESSION and/or FILTER_SPEC / SENDER_TEMPLATE C-Types have to
be defined.
5. An Example: UDP Encapsulation
A UDP encapsulation scheme would be compatible with RSVP
version 1. A well-known port number is necessary for the UDP
destination port field. Up to 65534 individual flows could
then be multiplexed over the tunnel by using a different value
for the UDP source port for each flow.
6. Security Considerations
Using a tunnel header as described in this document allows for
a type of traffic pattern analysis. The required level of
exposure may be acceptable in many situations because the
actual source and destination of the traffic will not be
visible if the end-to-end packet format does not make it so.
If this exposure is unacceptable, per-flow classification is
not possible.
7. References
[RSVPv1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", Internet Draft draft-ietf-rsvp-spec-14.txt,
November, 1996.
[RFC2003] C. Perkins, "IP Encapsulation within IP", IETF RFC
2003, October, 1996.
[RSVPIPSEC] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", Internet Draft draft-berger-rsvp-ext-06.txt, Jan,
1997.
JJ Krawczyk Expires September 1997 [Page 3]
INTERNET DRAFT Tunnels/RSVP Interoperability March 1997
8. Author's Address
John J. Krawczyk
Bay Networks, Inc.
2 Federal Street
Billerica, MA 01821
+1-508-916-3811
jj@baynetworks.com
JJ Krawczyk Expires September 1997 [Page 4]
