Internet Engineering Task Force RSVP WG
INTERNET-DRAFT J. Krawczyk/J. Wroclawski/L. Zhang
draft-ietf-rsvp-tunnel-00.txt UCLA/Bay Networks/MIT LCS
June, 1996
Expires: 12/96
RSVP Operation Over IP Tunnels
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), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (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).
Abstract
This memo describes an approach for providing RSVP protocol
services over IP tunnels. We briefly describe the problem, the
characteristics of possible solutions, and the design goals of our
approach. We then present the details of an implementation which
meets our design goals.
1. Introduction
IP "tunnels" have become a widespread mechanism to transport
datagrams in the Internet. Typically, a tunnel is used to route
packets through portions of the network which do not directly
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 1]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
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).
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 datagram.
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-controllable links within the network.
A tunnel, and in fact any sort of link, may participate in an RSVP-
aware network in one of three ways, depending on the capabilities of
the equipment from which the it is constructed and the desires of the
operator.
1) The 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 link may be able to promise that some overall level of
resources is available to carry traffic, but not to allocate
resources specifically to subsets of that traffic. A simple fixed-
bandwidth wire is an example of this. We refer to this case as a
type 2 tunnel in this note.
3) The link may be able to reserve different sets of resources for
different classes of traffic. An ATM cloud does this by assigning
bandwidth to different virtual circuits. We refer to this case as a
type 3 tunnel in this note.
For the case of RSVP and IP tunnels, the first type exists when some
of the routers or links comprising the tunnel do not support RSVP or
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 2]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
integrated services. 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 the presence of the non-controlled link is
detected, as required by the integrated services framework.
When the intermediate routers along the tunnel are capable of
supporting RSVP, we would like to have proper resources reserved
along the tunnel to meet application QoS control requests. Depending
on the reqirements of the situation, this might mean that an
application's data flow is placed into a larger aggregate reservation
(type 2 tunnels) or that a new, separate reservation is made for the
data flow (type 3 tunnels).
Currently, however, such reservations are not possible. Because RSVP
control messages are carried as regular IP packets, they are
encapsulated when crossing the tunnel and become invisible to the
intermediate routers within the tunnel. Because IP packets within the
tunnel are encapsulated in varying ways, they would fail to be
recognized and classified correctly by RSVP-aware routers even if the
necessary RSVP information was available. Together these problems
eliminate the ability to support both type 2 and type 3 tunnels.
Furthermore, most the current IP-in-IP encapsulations add only an IP
header as the external wrapper. In this case it is impossible to
distinguish between packets belonging to different RSVP sessions
while they are in the tunnel, because no distinguishing information
such as a UDP port is available in the encapsulation. This eliminates
the ability to support type 3 tunnels unless each intermediate router
is prepared to decapsulate and examine all packets traversing the
tunnel.
One approach to solving this problem is to define a separate solution
for each existing tunneling protocol, based on the details of that
protocol. We considered this solution, but rejected it as impractical
and non-extensible.
Instead we propose a new tunneling 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.
NOTE: A specific RSVP extensions to support tunnels as described
in [ESP] is contained in [RSVPESP].
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 3]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
2. The Design
2.1 Design Goals
Our design choices are motivated by several goals.
* Co-existing with most, if not all, current IP-in-IP tunneling
schemes.
* Limiting the changes to the RSVP spec to the minimum possible.
* Limiting the necessary changes to only the two end points of a
tunnel. This requirement leads to simpler deployment, lower
overhead in the intermediate routers, and less chance of failure
when the set of intermediate routers is modified due to routing
changes.
* Supporting correct interoperation 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 is treated as an
unreliable, non-RSVP link.
2.2 Basic Approach
The design works by recursively applying RSVP. The original, end-to-
end RSVP views the tunnel as a single (logical) link on the path
between the source(s) and destination(s). The recursive RSVP manages
resource reservations on this logical link. This second RSVP views
the two tunnel endpoints as two end hosts, and make a unicast Fixed-
Filter style reservation to reserve resource between them.
To accomplish this it is necessary to coordinate the actions of the
two RSVP's, to determine when the recursive RSVP should create and
tear down sessions, and to correctly transfer error and adspec
information between the two RSVP's.
We made the following design decisions:
* 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.
* RSVP control messages being forwarded through a tunnel are
encapsulated in the same was as normal IP packets, 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
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 4]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
must have some per-session attribute visible to the intermediate
routers, so that the routers may distinguish between RSVP sessions
within a type 3 tunnel. 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. This allows
intermediate routers to use standard RSVP filterspec handling. We
rejected the alternative approach of teaching RSVP-aware
intermediate routers to look "inside" every possible tunnel-
specific encapsulation as inconsistant with design goals 2 and 3,
above.
Note that this does not imply that the end-to-end packets are
directly contained in IP and UDP. Mappings between our tunneling
encapsulation and other end-to-end encapsulations are possible.
Further, most of the mechanism of this note could be reused with a
different tunneling encapsulation, if desired.
Figure 1 shows the topology of an end-to-end path, including a
tunnel, between two hosts. The sending host, H1, may be multiple IP
hops from the tunnel entry router Rentry, which encapsulates data
into the tunnel. Some number of intermediate routers forward the
data along the tunnel based upon the encapsulating IP header added by
Rentry. Rexit is the endpoint of the tunnel. It decapsulates the
data and forwards it based upon the original, "inner" IP header. The
receiving host, H2, may be multiple IP hops from Rexit.
H1 H2
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
| Rentry |===================================| Rexit |
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+
Figure 1: Example Topology
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
recursive RSVP session may be in place between Rentry and Rexit to
provide resource reservation 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.
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 5]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
2.3 Major Issues
One major design decision is whether to support type 2 (single-
reservation) tunnels, type 3 (per-session reservation) tunnels, or
both. We consider this a policy issue that should be left open. Our
design supports both cases.
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
so that changes in the original reservation state can be correctly
mapped into changes in the tunnel reservation state and so that
errors reported by intermediate routers to the tunnel RSVP can be
correctly transformed into errors reported at the tunnel endpoints to
the original RSVP.
We require that this association mechanism work for both the case of
one-to-one mapping between original and tunnel reservations, and the
case of bundled reservation over a tunnel.
In our scheme the association is created when a tunnel entry point
first sees an end-to-end session's PATH message and sets up or
modifies tunnel session PATH state. The existance of this new
association must be conveyed to Rexit, so that Rexit will know how to
process arriving RESV messages from the original reservation.
The information which must be conveyed from Rentry to Rexit 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, tunnel sessions are identified primarily
by source port. For all tunnel sessions on the same path between two
routers Rentry and Rexit, the source IP address, destination IP
address, and destination UDP port values are identical.
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. This approach
costs extra packets but handles both cases well.
2) Define a new RSVP object to be attached to PATH messages
generated for the tunnel session at Rentry. This unknown object is
ignored by the intermediate routers but interpreted by Rexit.
3) Apply the same UDP encapsulation to 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
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 6]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
encapsulation and the RSVP session that is specified in the
original PATH message. This approach does not require any new
design. However it limits the information that can be transmitted
beween Rentry and Rexit, and requires additional resources to be
reserved for PATH messages (since they are now subject to the
tunnel reservation).
NOTES [due to jj]: Approach (3) requires a priori knowledge of
which tunnels support the UDP encapsulation. If Rentry
encapsulates all tunneled PATH messages with the UDP
encapsulation, but Rexit does not understand this encapsulation,
the encapsulated PATH messages will be lost at Rexit.
Option (2) is more transparent. It allows Rexit to pass on end-
to-end PATHs received via the tunnel (because they are
decapsulated normally), while throwing away the tunnel PATHs
(because they are sent to a well-known, but unused by Rexit, UDP
port), all without any additional configuration.
[jtw: I basically agree with this idea, but there is a larger
problem - data packets. You have to make them transparent too. You
can do this by specifying that the UDP encap is used only if an
actual reservation is in place for the tunnel session.
Now the handshake is:
- Rentry sends PATH messages in a format which will be caught by an
RSVP-tunneling aware router, but just decapsulated and forwarded by
a non-RSVP or non-RSVP-tunneling Rexit router.
- Rexit sends tunnel session RESV messages only if tunnel-session
PATH state is present
- Rentry udp-encapsulates data only if a tunnel session reservation
is present.
I repeated this text in section 3.4, below.
I think we should turn jj's NOTE in to a paragraph explaining that
we reject option 3 because it connot be implemented transparently,
explain that options 1 and 2 can, and forward-reference 3.4 to
explain how transparent data handling works. RESV's are already
covered by explanation elsewhere. ]
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 7]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
3. Implementation
3.1 Handling PATH messages at Rentry
When forwarding an end-to-end PATH message, a router acting as the
tunnel entry point Rentry takes the following actions. First, it
encapsulates the PATH message using the normal encapsulation and
forwards the message into the tunnel. Second, it considers the
corresponding tunnel session PATH state. If the end-to-end session
is new, it may either (1) establish a new tunnel session for the
end-to-end session, or (2) bind the end-to-end session to an existing
tunnel session. Let us discuss each of the two cases below.
In the case where the end-to-end session should be bound to a
specific tunnel session, Rentry first checks to see if tunnel session
PATH state already exists for the end-to-end session. If so, nothing
needs be done at this time; refreshment of the tunnel session's PATH
state is controlled by the RSVP refresh timer at Rentry.
If the end-to-end PATH message represents an unknown session, Rentry
sets up tunnel session PATH state as if it were a source of data by
starting to send tunnel-session PATH messages to Rexit, which is
treated as the unicast destination of the data. The Tspec in this
new PATH message is computed from the original PATH message by
adjusting the Tspec parameters to include the tunnel overhead of the
encapsulation of data packets, and perhaps also PATH messages (if
binding mechanism 3, above, is selected) in this session.
In the case that the state for the end-to-end session is to be
aggregated with an existing tunnel session, if the PATH message is a
refresh of a previously known end-to-end session, then nothing needs
to be done. If the PATH message represents an unknown end-to-end
session, Rentry adjusts the existing tunnel session PATH state by
adding the Tspec to the aggregate Tspec and send a refresh message
with the new parameters.
3.2 Handling PATH Messages at Rexit
The tunnel session PATH messages generated by Rentry are addressed to
Rexit, where they are processed and deleted. When a new end-to-end
session is recognized at Rentry, information is passed to Rexit by
one of the mechanisms described above. Rexit records the association
of the tunnel session with that of the end-to-end session, and sets
the PHOP 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 and
further forwarded to the next hop along the path to the session
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 8]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
destination address. Rexit's action at this time depends on whether
Rentry implements RSVP control of the tunnel as described in this
note.
If Rentry does not perform RSVP tunnel control, 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.
If Rentry is performing RSVP tunneling, 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.
[jtw: the bit is actually an IS general characterizaton parameter?]
Rexit then performs composition of the characterization parameters
contained in the end-to-end PATH message's adspec. It does this by
considering the tunnel session's overall (composed) characterization
parameters as the local parameters for the logical link implemented
by the tunnel, and composing these parameters with those in the end-
to-end adspec by executing each parameter's defined composition
function.
The computation of composed characterization parameters for the
tunnel session is handled in the normal manner.
3.3 Handling 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-controlled best effort link, and Rexit
simply encapsulates and forwards the RESV message as a normal IP
datagram.
Step 2: If a bound tunnel sesson 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.
Step 2a: If not, it creates and sends a fixed-filter RESV, including
a RESV_CONFIRM object, using Rentry as the source IP address, the
local interface as the destination IP address, the well-known
destination UDP port, and the source UDP port received in the
SENDER_TEMPLATE of Rentry's PATH message. See section 4.1 for details
of UDP port selection.
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 9]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
If a RESV CONFIRM arrives for this request, the tunnel-session
reservation is in place. The original RESV is now sent through the
tunnel. If the tunnel reservation fails, Rexit must send a RESV ERR
for the original RESV error, using the error code and value fields
for the ERROR_SPEC object received in response to the tunnel RESV
message. In this case, the RESV is not forwarded.
Step 2b: If a reservation is already in place for the bound tunnel
session, and the arriving end-to-end RESV message is a refresh of
existing RESV state, the Rexit marks the tunnel session RESV state as
refreshed, and sends the original RESV through the tunnel.
If the arriving end-to-end RESV 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 to include the
newly encapsulated flow and refreshes the tunnel session RESV,
including a RESV_CONFIRM object.
If a RESV CONFIRM response arrives, the original RESV is sent through
the tunnel. If the updated tunnel reservation fails, Rexit must send
a RESV ERR for the original RESV message, using the error code and
value fields from the ERROR_SPEC object of the received RESV ERR
message. Note that the pre-existing reservations through the tunnel
stay in place. Rexit continues refreshing the tunnel RESV using the
old flowspec.
Tunnel session state 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). When the last RESV on the end-to-end session bound
to that tunnel goes away, a RESV TEAR is sent for the tunnel. [jj: I
think this works....]
3.4 Forwarding Data
When data packets arrive at the tunnel entry point Rentry, the router
must decide whether to forward the packets using the normal tunnel
encapsulation or the IP/UDP encapsulation expected by the tunnel
session. This decision is made by determining whether there is a
resoruce reservation (not just PATH state) actually in place for the
tunnel session bound to the arriving packet's end-to-end state.
If a reservation is in place, it means that a handshake has occurred
indicating that both Rentry and Rexit are RSVP-tunneling aware
routers, and the data will be correctly decapsulated at RExit. This
handshake works as follows:
1) Router Rentry detects end-to-end PATH messages and generates
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 10]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
tunnel PATH messages in a format which will be recognized specially
by a RSVP-tunneling aware router at Rexit, but just decapsulated
and forwarded by a non-RSVP or non-RSVP-tunneling Rexit router.
2) Rexit sends tunnel session RESV messages in response to the
arrival of end-to-end RESV messages only if tunnel-session PATH
state is present
3) Rentry udp-encapsulates arriving data only if a corresponding
tunnel session reservation is actually in place for the data.
If no tunnel session reservation is in place, the data should be
encapsulated in the tunnels normal format, regardless of whether
end-to-end PATH state covering the data is present.
4. Details
4.1 Selecting UDP port numbers
Within a type 3 tunnel 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 sessions.
The source UDP port is chosen by the tunnel entry point Rentry when
it establishes the initial PATH state for a new tunnel session. The
source UDP port associated with the new session is then conveyed to
Rexit by the binding mechanism.
Note that this limits the number of concurrent tunnel sessions to
65535. In some circumstances this may prove to be a significant
limitation, but we do not currently have a proposal for avoiding it.
The destination UDP port used in tunnel sessions is to be assigned.
4.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.
4.3 Security Issues
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 11]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
It is possible for a node other than the encapsulating router
(Rentry) to "spoof" a reserved tunnel session's encapsulation,
thereby giving its traffic a better-than-best-effort ride through the
intermediate tunnel routers. To discourage this practice, the
decapsulating router Rexit must examine each tunneled packet which
arrives in an encapsulation matching a tunnel session to ensure that
it matches one of the end-to-end sessions bound to that tunnel
session. If not, the packet must be discarded.
This technique eliminates the end-to-end connectivity of the
"spoofer", but still allows for a denial of service attach along the
tunnel. However, this is also a problem for RSVP without tunnels.
[jtw: the above is a more verbose version of jj's text, but his
idea is ghastly expensive. I may be asleep (3AM, OK) but doesn't
it work for Rentry to just check that things aren't arriving from
outside with its source address?]
[jj: Yeah, it's not cheap, but no more expensive than the
classification done on the outbound port. The idea came from
DVMRP, which does a much simpler check (dest IP is multicast).
The Rentry check doesn't work if the packet is injected in the
middle of the tunnel. For example, suppose I knew that you had a
tunnel between MIT and UCLA that happened to pass through a router
at Nearnet. Suppose if I sent a packet to the same UCLA router
address, it would hit that same Nearnet router. Further suppose
that I figured out that you had some excess capacity on that
reserved path and if I encapsulated my audio and video destined to
someone else on the west coast, they would get a better quality
signal. That's the case I'm worried about.]
To implement a type 3 (separate reservation) tunnel, it is necessary
for the tunneling encapsulation to allow classification of the
traffic by data flow. This 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, only a type 2 tunnel can be
provided, although much of our mechanism can be reused.
4.4 ICMP messages
When a router implements UDP encapsulation for RSVP, it must be able
to convert ICMP messages generated within the tunnel into ICMP
messages for the original sender in a manner compatible with the
default tunneling scheme.
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 12]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
[jtw: but only some of them, I think. Others should only go to the
tunnel endpoints. e.g. a host-unreachable for an encap packet should
not turn into a host-unreachable to the original end-point. Or are
you saying something else completely?]
In addition, since the UDP encapsulated packets cannot be fragmented,
tunnel entry routers must support tunnel MTU discovery as discussed
in section 5.1 of [IP4INIP4].
References
[ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
1827, August, 1995.
[IP4INIP4] C. Perkins, "IP Encapsulation within IP", Internet Draft
draft-ietf-mobileip-ip4inip4-03.txt, May, 1996.
[IPV6GEN] A. Conta, S, Deering, "Generic Packet Tunneling in IPv6
Specification", Internet Draft draft-ietf-ipngwg-ipv6-tunnel-01.txt,
February, 1996.
[MINENC] C. Perkins, "Minimal Encapsulation within IP", Internet
Draft draft-ietf-mobileip-minenc-02.txt, May, 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.
[RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",
Internet Draft draft-ietf-rsvp-spec-12.txt, May, 1996.
[RSVPESP] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", Internet Draft draft-berger-rsvp-ext-03.txt, April, 1996.
Author's Address:
John J. Krawczyk
Bay Networks, Inc.
2 Federal Street
Billerica, MA 01821
+1-508-436-3811
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 13]
INTERNET-DRAFT draft-ietf-intserv-charac-01.txt June, 1996
jj@baynetworks.com
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
jtw@lcs.mit.edu
+1-617-253-7885
+1-617-253-2673 (FAX)
Lixia Zhang
Computer Science Department
4531G Boelter Hall
UCLA
Los Angeles, CA 90095
lixia@cs.ucala.edu
+1-310-825-2695
Krawczyk/Wroclawski/ZhangExpires December, 1996 [Page 14]
