doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

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