HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:35:56 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 06 Dec 1996 12:04:30 GMT ETag: "2f51e7-7f4c-32a80bce" Accept-Ranges: bytes Content-Length: 32588 Connection: close Content-Type: text/plain 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]