idnits 2.17.1 draft-ietf-rsvp-tunnel-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 128 has weird spacing: '...that one clie...' == Line 149 has weird spacing: '...to make reser...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VPN' is mentioned on line 899, but not defined == Missing Reference: 'IPINIP4' is mentioned on line 970, but not defined ** Obsolete normative reference: RFC 1827 (ref. 'ESP') (Obsoleted by RFC 2406) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-tunnel is -07, but you're referring to -08. ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Downref: Normative reference to an Informational RFC: RFC 1702 ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-05 -- Possible downref: Normative reference to a draft: ref. 'VMMT' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force RSVP WG 3 INTERNET-DRAFT A. Terzis 4 UCLA 5 J. Krawczyk 6 ArrowPoint Communications 7 J. Wroclawski 8 MIT LCS 9 L. Zhang 10 UCLA 11 February 1999 Expiration: August 1999 13 RSVP Operation Over IP Tunnels 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes an approach for providing RSVP protocol services 40 over IP tunnels. We briefly describe the problem, the characteristics of 41 possible solutions, and the design goals of our approach. We then pre- 42 sent the details of an implementation which meets our design goals. 44 1. What's changed 46 - We tried to identify the type of tunnel assumed when discussing 47 the different cases in processing RSVP messages 49 - The sequence of steps in Section 3.3 has been changed to reflect the 50 fact that the association between end-to-end and tunnel sessions 51 is influenced by end-to-end RESV messages. 53 - Section 5.2 was radically changed to reflect the changes mentioned 54 above. 56 - The definition of the SESSION_ASSOC object was moved to a separate 57 Section (3.3.1) 59 - In Section 7.3 where MTU discovery is discussed we added the 60 alternative of Path MTU discovery using the mechanism described in 61 RFC2210. 63 - Paragraph 9 was overhauled. 65 - Several wording changes were made. 67 2. Introduction 69 IP-in-IP "tunnels" have become a widespread mechanism to transport data- 70 grams in the Internet. Typically, a tunnel is used to route packets 71 through portions of the network which do not directly implement the 72 desired service (e.g. IPv6), or to augment and modify the behavior of 73 the deployed routing architecture (e.g. multicast routing, mobile IP, 74 Virtual Private Net). 76 Many IP-in-IP tunneling protocols exist today. [IP4INIP4] details a 77 method of tunneling using an additional IPv4 header. [MINENC] describes 78 a way to reduce the size of the "inner" IP header used in [IP4INIP4] 79 when the original datagram is not fragmented. The generic tunneling 80 method in [IPV6GEN] can be used to tunnel either IPv4 or IPv6 packets 81 within IPv6. [RFC1933] describes how to tunnel IPv6 datagrams through 82 IPv4 networks. [RFC1701] describes a generic routing encapsulation, 83 while [RFC1702] applies this encapsulation to IPv4. Finally, [ESP] 84 describes a mechanism that can be used to tunnel an encrypted IP data- 85 gram. 87 >From the perspective of traditional best-effort IP packet delivery, a 88 tunnel behaves as any other link. Packets enter one end of the tunnel, 89 and are delivered to the other end unless resource overload or error 90 causes them to be lost. 92 The RSVP setup protocol [RFC2205] is one component of a framework 93 designed to extend IP to support multiple, controlled classes of service 94 over a wide variety of link-level technologies. To deploy this technol- 95 ogy with maximum flexibility, it is desirable for tunnels to act as 96 RSVP-controllable links within the network. 98 A tunnel, and in fact any sort of link, may participate in an RSVP- 99 aware network in one of three ways, depending on the capabilities of the 100 equipment from which the tunnel is constructed and the desires of the 101 operator. 103 1. The (logical) link may not support resource reservation or QoS con- 104 trol at all. This is a best-effort link. We refer to this as a 105 best-effort or type 1 tunnel in this note. 106 2. The (logical) link may be able to promise that some overall level 107 of resources is available to carry traffic, but not to allocate 108 resources specifically to individual data flows. A configured 109 resource allocation over a tunnel is an example of this. We refer 110 to this case as a type 2 tunnel in this note. 111 3. The (logical) link may be able to make reservations for individual 112 end-to-end data flows. We refer to this case as a type 3 tunnel. 113 Note that the key feature that distinguishes type 3 tunnels from 114 type 2 tunnels is that in the type 3 tunnel new tunnel reservations 115 are created and torn down dynamically as end-to-end reservations 116 come and go. 118 Type 1 tunnels exist when at least one of the routers comprising the 119 tunnel endpoints does not support the scheme we describe here. In this 120 case, the tunnel acts as a best-effort link. Our goal is simply to make 121 sure that RSVP messages traverse the link correctly, and the presence of 122 the non-controlled link is detected, as required by the integrated ser- 123 vices framework. 125 When the two end points of the tunnel are capable of supporting RSVP 126 over tunnels, we would like to have proper resources reserved along the 127 tunnel. Depending on the requirements of the situation, this might mean 128 that one client's data flow is placed into a larger aggregate reserva- 129 tion (type 2 tunnels) or that possibly a new, separate reservation is 130 made for the data flow (type 3 tunnels). Note that an RSVP reservation 131 between the two tunnel end points does not necessarily mean that all the 132 intermediate routers along the tunnel path support RSVP, this is equiva- 133 lent to the case of an existing end-to-end RSVP session transparently 134 passing through non-RSVP cloud. 136 Currently, however, RSVP signaling over tunnels is not possible. RSVP 137 packets entering the tunnel are encapsulated with an outer IP header 138 that has a protocol number other than 46 (e.g. it is 4 for IP-in-IP 139 encapsulation) and do not carry the Router-Alert option, making them 140 virtually "invisible" to RSVP routers between the two tunnel endpoints. 141 Moreover, the current IP-in-IP encapsulation scheme adds only an IP 142 header as the external wrapper. It is impossible to distinguish between 143 packets that use reservations and those that don't, or to differentiate 144 packets belonging to different RSVP Sessions while they are in the tun- 145 nel, because no distinguishing information such as a UDP port is avail- 146 able in the encapsulation. 148 This document describes an IP tunneling enhancement mechanism that 149 allows RSVP to make reservations across all IP-in-IP tunnels. This 150 mechanism is capable of supporting both type 2 and type 3 tunnels, as 151 described above, and requires minimal changes to both RSVP and other 152 parts of the integrated services framework. 154 3. The Design 156 3.1. Design Goals 158 Our design choices are motivated by several goals. 160 * Co-existing with most, if not all, current IP-in-IP tunneling 161 schemes. 162 * Limiting the changes to the RSVP spec to the minimum possible. 163 * Limiting the necessary changes to only the two end points of a tun- 164 nel. This requirement leads to simpler deployment, lower overhead 165 in the intermediate routers, and less chance of failure when the 166 set of intermediate routers is modified due to routing changes. 167 * Supporting correct inter-operation with RSVP routers that have not 168 been upgraded to handle RSVP over tunnels and with non-RSVP tunnel 169 endpoint routers. In these cases, the tunnel behaves as a non-RSVP 170 link. 172 3.2. Basic Approach 174 The basic idea of the method described in this document is to recur- 175 sively apply RSVP over the tunnel portion of the path. In this new ses- 176 sion, the tunnel entry point Rentry sends PATH messages and the tunnel 177 exit point Rexit sends RESV messages to reserve resources for the end- 178 to-end sessions over the tunnel. 180 We discuss next two different aspects of the design: how to enhance an 181 IP-in-IP tunnel with RSVP capability, and how to map end-to-end RSVP 182 sessions to a tunnel session. 184 3.2.1. Design Decisions 186 To establish a RSVP reservation over a unicast IP-in-IP tunnel, we made 187 the following design decisions: 189 One or more Fixed-Filter style unicast reservations between the two end 190 points of the tunnel will be used to reserve resources for packets 191 traversing the tunnel. In the type 2 case, these reservations will be 192 configured statically by a management interface. In the type 3 case, 193 these reservations will be created and torn down on demand, as end-to- 194 end reservation requests come and go. 196 Packets that do not require reservations are encapsulated in the normal 197 way, e. g. being wrapped with an IP header only, specifying the tunnel 198 entry point as source and the exit point as destination. 200 Data packets that require resource reservations within a tunnel must 201 have some attribute other than the IP addresses visible to the interme- 202 diate routers, so that the routers may map the packet to an appropriate 203 reservation. To allow intermediate routers to use standard RSVP filter- 204 spec handling, we choose to encapsulate such data packets by prepending 205 an IP and a UDP header, and to use UDP port numbers to distinguish pack- 206 ets of different RSVP sessions. The protocol number in the outer IP 207 header in this case will be UDP. 209 Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel entry 210 router which encapsulates data into the tunnel. Some number of interme- 211 diate routers forward the data across the network based upon the encap- 212 sulating IP header added by Rentry. Rexit is the endpoint of the tun- 213 nel. It decapsulates the data and forwards it based upon the original, 214 "inner" IP header. 216 ........... ............... ............. 217 : _______ : : _____ : 218 : | | : : | | : 219 Intranet :--| Rentry|===================|Rexit|___:Intranet 220 : |_______| : : |_____| : 221 ..........: : Internet : :........... 222 :.............. 223 |___________________| 225 Figure 1. An example IP Tunnel 227 3.2.2. Mapping between End-to-End and Tunnel Sessions 229 Figure 2 shows a simple topology with a tunnel and a few hosts. The 230 sending hosts H1 and H3 may be one or multiple IP hops away from Rentry; 231 the receiving hosts H2 and H4 may also be either one or multiple IP hops 232 away from Rexit. 234 H1 H2 235 : : 236 : : 237 +--------+ +---+ +---+ +---+ +-------+ 238 | | | | | | | | | | 239 H3... | Rentry |===================================| Rexit |..... H4 240 | | | | | | | | | | 241 +--------+ +---+ +---+ +---+ +-------+ 243 Figure 2: An example end-to-end path with 244 a tunnel in the middle. 246 An RSVP session may be in place between endpoints at hosts H1 and H2. 247 We refer to this session as the "end-to-end" (E2E for short) or "origi- 248 nal" session, and to its PATH and RESV messages as the end-to-end mes- 249 sages. One or more RSVP sessions may be in place between Rentry and 250 Rexit to provide resource reservation over the tunnel. We refer to these 251 as the tunnel RSVP sessions, and to their PATH and RESV messages as the 252 tunnel or tunneling messages. A tunnel RSVP session may exist indepen- 253 dently from any end-to-end sessions. For example through network man- 254 agement interface one may create a RSVP session over the tunnel to pro- 255 vide QoS support for data flow from H3 to H4, although there is no end- 256 to-end RSVP session between H3 and H4. 258 When an end-to-end RSVP session crosses a RSVP-capable tunnel, there are 259 two cases to consider in designing mechanisms to support an end-to-end 260 reservation over the tunnel: mapping the E2E session to an existing tun- 261 nel RSVP session (type 2 tunnel), and dynamically creating a new tunnel 262 RSVP session for each end-to-end session (type 3 tunnel). In either 263 case, the picture looks like a recursive application of RSVP. The tun- 264 nel RSVP session views the two tunnel endpoints as two end hosts with a 265 unicast Fixed-Filter style reservation in between. The original, end- 266 to-end RSVP session views the tunnel as a single (logical) link on the 267 path between the source(s) and destination(s). 269 Note that in practice a tunnel may combine type 2 and type 3 character- 270 istics. Some end-to-end RSVP sessions may trigger the creation of new 271 tunnel sessions, while others may be mapped into an existing tunnel RSVP 272 session. The choice of how an end-to-end session is treated at the 273 tunnel is a matter of local policy. 275 When an end-to-end RSVP session crosses a RSVP-capable tunnel, it is 276 necessary to coordinate the actions of the two RSVP sessions, to deter- 277 mine whether or when the tunnel RSVP session should be created and torn 278 down, and to correctly transfer error and ADSPEC information between the 279 two RSVP sessions. We made the following design decision: 281 * End-to-end RSVP control messages being forwarded through a tunnel 282 are encapsulated in the same way as normal IP packets, e.g. being 283 wrapped with the tunnel IP header only, specifying the tunnel entry 284 point as source and the exit point as destination. 286 3.3. Major Issues 288 As IP-in-IP tunnels are being used more widely for network traffic man- 289 agement purposes, it is clear we must support type 2 tunnels (tunnel 290 reservation for aggregate end-to-end sessions). Furthermore, these type 291 2 tunnels should allow more than one (configurable, static) reservation 292 to be used at once, to support different traffic classes within the tun- 293 nel. Whether it is necessary to support type 3 tunnels (dynamic per end- 294 to-end session tunnel reservation) is a policy issue that should be left 295 open. Our design supports both cases. 297 If there is only one RSVP session configured over a tunnel, then all the 298 end-to-end RSVP sessions (that are allowed to use this tunnel session) 299 will be bound to this configured tunnel session. However when more than 300 one RSVP session is in use over an IP tunnel, a second design issue is 301 how the association, or binding, between an original RSVP reservation 302 and a tunnel reservation is created and conveyed from one end of the 303 tunnel to the other. The entry router Rentry and the exit router Rexit 304 must agree on these associations so that changes in the original reser- 305 vation state can be correctly mapped into changes in the tunnel reserva- 306 tion state, and that errors reported by intermediate routers to the tun- 307 nel end points can be correctly transformed into errors reported by the 308 tunnel endpoints to the end-to-end RSVP session. 310 We require that this same association mechanism work for both the case 311 of bundled reservation over a tunnel (type 2 tunnel), and the case of 312 one-to-one mapping between original and tunnel reservations (type 3 tun- 313 nel). In our scheme the association is created when a tunnel entry point 314 first sees an end-to-end session's RESV message and either sets up a new 315 tunnel session, or adds to an existing tunnel session. This new associ- 316 ation must be conveyed to Rexit, so that Rexit can reserve resources for 317 the end-to-end sessions inside the tunnel. This information includes the 318 identifier and certain parameters of the tunnel session, and the identi- 319 fier of the end-to-end session to which the tunnel session is being 320 bound. In our scheme, all RSVP sessions between the same two routers 321 Rentry and Rexit will have identical values for source IP address, des- 322 tination IP address, and destination UDP port number. An individual ses- 323 sion is identified primarily by the source port value. 325 NOTE: (to be removed in RFC version) While in previous versions of 326 this draft the association between end-to-end and tunnel sessions 327 was done by Rentry when it received PATH messages from new end-to- 328 end sessions, to fully support RSVP semantics, where the level of 329 resources required is specified by the receivers, information from 330 the end-to-end RESV messages has to be available before a suitable 331 association can be made. For this reason Rentry waits for end-to- 332 end RESV to arrive, before mapping end-to-end sessions to the 333 appropriate tunnel sessions. 335 We identified three possible choices for a binding mechanism: 337 1. Define a new RSVP message that is exchanged only between two tunnel 338 end points to convey the binding information. 339 2. Define a new RSVP object to be attached to end-to-end PATH messages 340 at Rentry, associating the end-to-end session with one of the tun- 341 nel sessions. This new object is interpreted by Rexit associating 342 the end-to-end session with one of the tunnel sessions generated at 343 Rentry. 344 3. Apply the same UDP encapsulation to the end-to-end PATH messages as 345 to data packets of the session. When Rexit decapsulates the PATH 346 message, it deduces the relation between the source UDP port used 347 in the encapsulation and the RSVP session that is specified in the 348 original PATH message. 350 The last approach above does not require any new design. However it 351 requires additional resources to be reserved for PATH messages (since 352 they are now subject to the tunnel reservation). It also requires a 353 priori knowledge of whether Rexit supports RSVP over tunnels by UDP 354 encapsulation. If Rentry encapsulates all the end-to-end PATH messages 355 with the UDP encapsulation, but Rexit does not understand this encapsu- 356 lation, then the encapsulated PATH messages will be lost at Rexit. 358 On the other hand, options (1) and (2) can handle this case transpar- 359 ently. They allow Rexit to pass on end-to-end PATHs received via the 360 tunnel (because they are decapsulated normally), while throwing away the 361 tunnel PATHs, all without any additional configuration. We chose Option 362 (2) because it is simpler. We describe this object in the following 363 section. 365 Packet exchanges must follow the following constraints: 367 1. Rentry encapsulates and sends end-to-end PATH messages over the 368 tunnel to Rexit where they get decapsulated and forwarded down- 369 stream. 370 2. When a corresponding end-to-end RESV message arrives at Rexit, 371 Rexit encapsulates it and sends it to Rentry. 372 3. Based on some or all of the information in the end-to-end PATH mes- 373 sages, the flowspec in the end-to-end RESV message and local poli- 374 cies, Rentry decides if and how to map the end-to-end session to a 375 tunnel session. 376 4. If the end-to-end session should be mapped to a tunnel session, 377 Rentry either sends a PATH message for a new tunnel session or 378 updates an existing one. 379 5. Rentry sends a E2E Path containing a SESSION_ASSOC object associat- 380 ing the end-to-end session with the tunnel session above. Rexit 381 records the association and removes the object before forwarding 382 the Path message further. 383 6. Rexit responds to the tunnel PATH message by sending a tunnel RESV 384 message, reserving resources inside the tunnel. 385 7. Rentry UDP-encapsulates arriving packets only if a corresponding 386 tunnel session reservation is actually in place for the packets. 388 3.3.1. SESSION_ASSOC Object 390 The new object, called SESSION_ASSOC, is defined with the following for- 391 mat: 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | length | class | c-type | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 | SESSION object (for the end-to-end session) | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 | Sender FILTER-SPEC (for the tunnel session) | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 SESSION_ASSOC Object 407 Length 409 This field contains the size of the SESSION_ASSOC object in bytes. 411 Class 413 Should be 192. 415 Ctype 417 Should be sent as zero and ignored on receipt. 419 SESSION object 421 The end-to-end SESSION contained in the object is to be mapped to the 422 tunnel session described by the Sender FILTER-SPEC defined below. 424 Sender FILTER-SPEC 426 This is the tunnel session that the above mentioned end-to-end ses- 427 sion maps to over the tunnel. As we mentioned above, a tunnel session 428 is identified primarily by source port. This is why we use a Sender 429 Filter-Spec for the tunnel session, in the place of a SESSION object. 431 3.3.2. NODE_CHAR Object 433 There has to be a way (other than through configuration) for Rexit to 434 communicate to Rentry the fact that it is a tunnel endpoint supporting 435 the scheme described in this document. We have defined for this reason a 436 new object, called SENDER_CHAR, carrying this information. If a node 437 receives this object but does not understand it, it should drop it with- 438 out producing any error report. Objects with Class-Num = 10bbbbbb (`b' 439 represents a bit), as defined in the RSVP specification [RFC2205], have 440 the characteristics we need. While for now this object only carries one 441 bit of information, it can be used in the future to describe other char- 442 acteristics of an RSVP capable node that are not part of the original 443 RSVP specification. 445 The object NODE_CHAR has the following format: 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | length | class | c-type | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Reserved |T| 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Length 454 This field contains the size of the NODE_CHAR object in bytes. It 455 sould be set to eight. 457 Class 459 An appropriate value should be assigned by the IANA. We propose this 460 value to be 128. 462 Ctype 464 Should be sent as zero and ignored on receipt. 466 T bit 468 This bit shows that the node is a RSVP-tunnel capable node. 470 When Rexit receives an end-to-end reservation, it appends a SENDER_CHAR 471 object with the T bit set, to the RESV object, it encapsulates it and 472 sends it to Rentry. When Rentry receives this RESV message it deduces 473 that Rexit implements the mechanism described here and so it creates or 474 adjusts a tunnel session and associates the tunnel session to the end- 475 to-end session via a SESSION_ASSOC object. Rentry should remove the 476 NODE_CHAR object, before forwarding the RESV message upstream. If on the 477 other hand, Rentry does not support the RSVP Tunnels mechanism it would 478 simply ignore the NODE_CHAR object and not forward it further upstream. 480 4. Implementation 482 In this section we discuss several cases separately, starting from the 483 simplest scenario and moving to the more complex ones. 485 4.1. Single Configured RSVP Session over an IP-in-IP Tunnel 487 Treating the two tunnel endpoints as a source and destination host, one 488 easily sets up a FF-style reservation in between. Now the question is 489 what kind of filterspec to use for the tunnel reservation, which 490 directly relates to how packets get encapsulated over the tunnel. We 491 discuss two cases below. 493 4.1.1. In the Absence of End-to-End RSVP Session 495 In the case where all the packets traversing a tunnel use the reserved 496 resources, the current IP-in-IP encapsulation could be used. The RSVP 497 session over the tunnel would simply specify a FF style reservation 498 (with zero port number) with Rentry as the source address and Rexit as 499 the destination address. 501 However if only some of the packets traversing the tunnel should benefit 502 from the reservation, we must encapsulate the qualified packets in IP 503 and UDP. This allows intermediate routers to use standard RSVP filter- 504 spec handling, without having to know about the existence of tunnels. 506 Rather than supporting both cases we choose to simplify implementations 507 by requiring all data packets using reservations to be encapsulated with 508 an outer IP and UDP header. This reduces special case checking and han- 509 dling. 511 4.1.2. In the Presence of End-to-End RSVP Session(s) 513 According to the tunnel control policies, installed through some manage- 514 ment interface, some or all end-to-end RSVP sessions may be allowed to 515 map to the single RSVP session over the tunnel. In this case there is 516 no need to provide dynamic binding information between end-to-end ses- 517 sions and the tunnel session, given that the tunnel session is unique 518 and pre-configured, and therefore well-known. 520 Binding multiple end-to-end sessions to one tunnel session, however, 521 raises a new question of when and how the size of the tunnel reservation 522 should be adjusted to accomodate the end-to-end sessions mapped onto it. 523 Again the tunnel manager makes such policy decision. Several scenarios 524 are possible. In the first, the tunnel reservation is never adjusted. 525 This makes the tunnel the rough equivalent of a fixed-capacity hardware 526 link. In the second, the tunnel reservation is adjusted whenever a new 527 end-to-end reservation arrives or an old one is torn down. In the third, 528 the tunnel reservation is adjusted upwards or downwards occasionally, 529 whenever the end-to-end reservation level has changed enough to warrant 530 the adjustment. This trades off extra resource usage in the tunnel for 531 reduced control traffic and overhead. 533 We call a tunnel whose reservation cannot be adjusted a "hard pipe", as 534 opposed to a "soft pipe" where the amount of resources allocated is 535 adjustable. Section 5.2 explains how the adjustment can be carried out 536 for soft pipes. 538 4.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel 540 It is straightforward to build on the case of a single configured RSVP 541 session over a tunnel by setting up multiple FF-style reservations 542 between the two tunnel endpoints using a management interface. In this 543 case Rentry must carefully encapsulate data packets with the proper UDP 544 port numbers, so that packets belonging to different tunnel sessions 545 will be distinguished by the intermediate RSVP routers. Note that this 546 case and the one described before describe what we call type 2 tunnels. 548 4.2.1. In the Absence of End-to-End RSVP Session 550 Nothing more needs to be said in this case. Rentry classifies the pack- 551 ets and encapsulates them accordingly. Packets with no reservations are 552 encapsulated with an outer IP header only, while packets qualified for 553 reservations are encapsulated with a UDP header as well as an IP header. 554 The UDP source port value should be properly set to map to the corre- 555 sponding tunnel reservation the packet is supposed to use. 557 4.2.2. In the Presence of End-to-End RSVP Session(s) 559 Since in this case, there is more than one RSVP session operating over 560 the tunnel, one must explicitly bind each end-to-end RSVP session to its 561 corresponding tunnel session. As discussed previously, this binding 562 will be provided by the new SESSION_ASSOC object carried by the end-to- 563 end PATH messages. 565 4.3. Dynamically Created Tunnel RSVP Sessions 567 This is the case of a type 3 tunnel. The only differences between this 568 case and that of Section 4.2 are that: 570 - The tunnel session is created when a new end-to-end session shows 571 up. 572 - There is a one-to-one mapping between the end-to-end and tunnel 573 RSVP sessions, as opposed to possibly many-to-one mapping that is 574 allowed in the case described in Section 4.2. 576 5. RSVP Messages handling over an IP-in-IP Tunnel 578 5.1. RSVP Messages for Configured Session(s) Over A Tunnel 580 Here one or more RSVP sessions are set up over a tunnel through a man- 581 agement interface. The session reservation parameters never change for 582 a "hard pipe" tunnel. The reservation parameters may change for a "soft 583 pipe" tunnel. Tunnel session PATH messages generated by Rentry are 584 addressed to Rexit, where they are processed and deleted. 586 5.2. Handling of RSVP Messages at Tunnel Endpoints 588 5.2.1. Handling End-to-End PATH Messages at Rentry 590 When forwarding an end-to-end PATH message, a router acting as the tun- 591 nel entry point, Rentry, takes the following actions depending on the 592 end-to-end session mentioned in the PATH message. There are two possible 593 cases: 595 1. The end-to-end PATH message is a refresh of a previously known end- 596 to-end session. 597 2. The end-to-end PATH message is from a new end-to-end session. 599 If the PATH message is a refresh of a previously known end-to-end ses- 600 sion, then Rentry refreshes the Path state of the end-to-end session and 601 checks to see if this session is mapped to a tunnel session. If this is 602 the case, then when Rentry refreshes the end-to-end session, it includes 603 in the end-to-end PATH message a SESSION_ASSOC object linking this ses- 604 sion to its corresponding tunnel session It then encapsulates the end- 605 to-end PATH message and sends it over the tunnel to Rexit. If the tunnel 606 session was dynamically created, the end-to-end PATH message serves as a 607 refresh for the local tunnel state at Rentry as well as for the end-to- 608 end session. 610 Otherwise, if the PATH message is from a new end-to-end session that has 611 not yet been mapped to a tunnel session, Rentry creates Path state for 612 this new session setting the outgoing interface to be the tunnel inter- 613 face. After that, Rentry encapsulates the PATH message and sends it to 614 Rexit without adding a SESSION_ASSOC message. 616 When an end-to-end PATH TEAR is received by Rentry, this node encapsu- 617 lates and forwards the message to Rexit. If this end-to-end session has 618 a one-to-one mapping to a tunnel session or if this is the last one of 619 the many end-to-end sessions mapping to a tunnel session, Rentry tears 620 down the tunnel session by sending a PATH TEAR for that session to 621 Rexit. If, on the other hand, there are remaining end-to-end sessions 622 mapping to the tunnel session, then Rentry sends a tunnel PATH message 623 adjusting the Tspec of the tunnel session. 625 5.2.2. Handling End-to-End PATH Messages at Rexit 627 Encapsulated end-to-end PATH messages are decapsulated and processed at 628 Rexit. As a first step, Rexit sets the PHOP of the end-to-end sender to 629 Rentry. Depending on whether the end-to-end PATH message contains a SES- 630 SION_ASSOC object or not, Rexit takes the following steps: 632 1. If the end-to-end PATH message does not contain a SESSION_ASSOC 633 object, then Rentry sets the Non_RSVP flag at the Path state stored 634 for this end-to-end sender, sets the global break bit in the ADSPEC 635 and forwards the packets downstream. 637 2. If the PATH message contains a SESSION_ASSOC object and no associa- 638 tion for this end-to-end session already exists, then Rexit records 639 the association between the end-to-end session and the tunnel ses- 640 sion described by the object. If the end-to-end PATH arrives early 641 before the tunnel PATH message arrives then it creates PATH state 642 at Rexit for the tunnel session. When the actual PATH message for 643 the tunnel session arrives it is treated as an update of the exist- 644 ing PATH state and it updates any information missing. We believe 645 that this situation is another transient along with the others 646 existing in RSVP and that it does not have any long-term effects on 647 the correct operation of the mechanism described here. 649 Before further forwarding the message to the next hop along the 650 path to the destination, Rexit finds the corresponding tunnel ses- 651 sion's recorded state and turns on Non_RSVP flag in the end-to-end 652 Path state if the Non_RSVP bit was turned on for the tunnel ses- 653 sion. If the end-to-end PATH message carries an ADSPEC object, 654 Rexit performs composition of the characterization parameters con- 655 tained in the ADSPEC. It does this by considering the tunnel ses- 656 sion's overall (composed) characterization parameters as the local 657 parameters for the logical link implemented by the tunnel, and com- 658 posing these parameters with those in the end-to-end ADSPEC by exe- 659 cuting each parameter's defined composition function. In the logi- 660 cal link's characterization parameters, the minimum path latency 661 may take into account the encapsulation/decapsulation delay and the 662 bandwidth estimate can represent the decrease in available band- 663 width caused by the addition of the extra UDP header. ADSPECs and 664 composition functions are discussed in great detail in [RFC2210]. 666 If the end-to-end session has reservation state, while no reserva- 667 tion state for the matching tunnel session exists, Rexit send a 668 tunnel RESV message to Rentry matching the reservation in the end- 669 to-end session. 671 If Rentry does not support RSVP tunneling, then Rexit will have no PATH 672 state for the tunnel. In this case Rexit simply turns on the global 673 break bit in the decapsulated end-to-end PATH message and forwards it. 675 5.2.3. Handling End-to-End RESV Messages at Rexit 677 When forwarding a RESV message upstream, a router serving as the exit 678 router, Rexit, may discover that one of the upstream interfaces is a 679 tunnel. In this case the router performs a number of tests. 681 Step 1: Rexit must determine if there is a tunnel session bound to the 682 end-to-end session given in the RESV message. If not, the tunnel is 683 treated as a non-RSVP link, Rexit appends a NODE_CHAR object with the T 684 bit set, to the RESV message and forwards it over the tunnel interface 685 (where it is encapsulated as a normal IP datagram and forwarded towards 686 Rentry). 688 Step 2: If a bound tunnel session is found, Rexit checks to see if a 689 reservation is already in place for the tunnel session bound to the end- 690 to-end session given in the RESV message. If the arriving end-to-end 691 RESV message is a refresh of existing RESV state, then Rexit sends the 692 original RESV through tunnel interface (after adding the NODE_CHAR 693 object). For dynamic tunnel sessions, the end-to-end RESV message acts 694 as a refresh for the tunnel session reservation state, while for config- 695 ured tunnel sessions, reservation state never expires. 697 If the arriving end-to-end RESV message causes a change in the end-to- 698 end RESV flowspec parameters, it may also trigger an attempt to change 699 the tunnel session's flowspec parameters. In this case Rexit sends a 700 tunnel session RESV, including a RESV_CONFIRM object. 702 In the case of a "hard pipe" tunnel, a new end-to-end reservation or 703 change in the level of resources requested by an existing reservation 704 may cause the total resource level needed by the end-to-end reservations 705 to exceed the level of resources reserved by the tunnel reservation. 706 This event should be treated as an admission control failure, identi- 707 cally to the case where RSVP requests exceed the level of resources 708 available over a hardware link. A RESV_ERR message with Error Code set 709 to 01 (Admission Control failure), should be sent back to the originator 710 of the end-to-end RESV message. 712 If a RESV CONFIRM response arrives, the original RESV is encapsulated 713 and sent through the tunnel. If the updated tunnel reservation fails, 714 Rexit must send a RESV ERR to the originator of the end-to-end RESV mes- 715 sage, using the error code and value fields from the ERROR_SPEC object 716 of the received tunnel session RESV ERR message. Note that the pre- 717 existing reservations through the tunnel stay in place. Rexit continues 718 refreshing the tunnel RESV using the old flowspec. 720 Tunnel session state for a "soft pipe" may also be adjusted when an end- 721 to-end reservation is deleted. The tunnel session gets reduced whenever 722 one of the end-to-end sessions using the tunnel goes away (or gets 723 reduced itself). However even when the last end-to-end session bound to 724 that tunnel goes away, the configured tunnel session remains active, 725 perhaps with a configured minimal flowspec. 727 Note that it will often be appropriate to use some hysteresis in the 728 adjustment of the tunnel reservation parameters, rather than adjusting 729 the tunnel reservation up and down with each arriving or departing end- 730 to-end reservation. Doing this will require the tunnel exit router to 731 keep track of the resources allocated to the tunnel (the tunnel 732 flowspec) and the resources actually in use by end-to-end reservations 733 (the sum or statistical sum of the end-to-end reservation flowspecs) 734 separately. 736 When an end-to-end RESV TEAR is received by Rexit, it encapsulates and 737 forwards the message to Rentry. If the end-to-end session had created a 738 dynamic tunnel session, then a RESV TEAR for the corresponding tunnel 739 session is send by Rexit. 741 5.2.4. Handling of End-to-End RESV Messages at Rentry. 743 If the RESV message received is a refresh of an existing reservation 744 then Rentry updates the reservation state and forwards the message 745 upstream. On the other hand, if this is the first RESV message for this 746 end-to-end session and a NODE_CHAR object with the T bit set is present, 747 Rentry should initiate the mapping between this end-to-end session and 748 some (possibly new) tunnel session. This mapping is based on some or all 749 of the contents of the end-to-end PATH message, the contents of the end- 750 to-end RESV message, and local policies. For example, there could be 751 different tunnel sessions based on the bandwidth or delay requirements 752 of end-to-end sessions) 754 If Rentry decides that this end-to-end session should be mapped to an 755 existing configured tunnel session, it binds this end-to-end session to 756 that tunnel session. 758 If this end-to-end RSVP session is allowed to set up a new tunnel ses- 759 sion, Rentry sets up tunnel session PATH state as if it were a source of 760 data by starting to send tunnel-session PATH messages to Rexit, which is 761 treated as the unicast destination of the data. The Tspec in this new 762 PATH message is computed from the original PATH message by adjusting the 763 Tspec parameters to include the tunnel overhead of the encapsulation of 764 data packets. In this case Rentry should also send a PATH message from 765 the end-to-end session this time containing the SESSION_ASSOC object 766 linking the two sessions. The receipt of this PATH message from Rexit 767 will trigger an update of the end-to-end Path state which in turn will 768 have the effect of Rexit sending a tunnel RESV message, allocating 769 resources inside the tunnel. 771 The last case is when the end-to-end session is not allowed to use the 772 tunnel resources. In this case no association is created between this 773 end-to-end session and a tunnel session and no new tunnel session is 774 created. 776 One limitation of our scheme is that the first RESV message of an end- 777 to-end session determines the mapping between that end-to-end session 778 and its corresponding session over the tunnel. Moreover as long as the 779 reservation is active this mapping cannot change. 781 6. Forwarding Data 783 When data packets arrive at the tunnel entry point Rentry, Rentry must 784 decide whether to forward the packets using the normal IP-in-IP tunnel 785 encapsulation or the IP+UDP encapsulation expected by the tunnel ses- 786 sion. This decision is made by determining whether there is a resource 787 reservation (not just PATH state) actually in place for the tunnel ses- 788 sion bound to the arriving packet, that is, whether the packet matches 789 any active filterspec. 791 If a reservation is in place, it means that both Rentry and Rexit are 792 RSVP-tunneling aware routers, and the data will be correctly decapsu- 793 lated at Rexit. 795 If no tunnel session reservation is in place, the data should be encap- 796 sulated in the tunnel's normal format, regardless of whether end-to-end 797 PATH state covering the data is present. 799 7. Details 801 7.1. Selecting UDP port numbers 803 There may be multiple end-to-end RSVP sessions between the two end 804 points Rentry and Rexit. These sessions are distinguished by the source 805 UDP port. Other components of the session ID, the source and destination 806 IP addresses and the destination UDP port, are identical for all such 807 sessions. 809 The source UDP port is chosen by the tunnel entry point Rentry when it 810 establishes the initial PATH state for a new tunnel session. The source 811 UDP port associated with the new session is then conveyed to Rexit by 812 the binding mechanism. 814 The destination UDP port used in tunnel sessions should the one assigned 815 by IANA (363). 817 7.2. Error Reporting 819 When a tunnel session PATH message encounters an error, it is reported 820 back to Rentry. Rentry must relay the error report back to the original 821 source of the end-to-end session. 823 When a tunnel session RESV request fails, an error message is returned 824 to Rexit. Rexit must treat this as an error in crossing the logical link 825 (the tunnel) and forward the error message back to the end host. 827 7.3. ICMP messages 829 Since the UDP encapsulated packets should not be fragmented, tunnel 830 entry routers must support tunnel MTU discovery as discussed in section 831 5.1 of [IP4INIP4]. Alternatively, the Path MTU Discovery mechanism dis- 832 cussed in RFC 2210 [RFC2210] can be used. 834 7.4. Tspec and Flowspec Calculations 836 As multiple End-to-End sessions can be mapped to a single tunnel ses- 837 sion, there is the need to compute the aggregate Tspec of all the 838 senders of those End-to-End sessions. This aggregate Tspec will the 839 Tspec of the representative tunnel session. The same operation needs to 840 be performed for flowspecs of End-to-End reservations arriving at Rexit. 842 The semantics of these operations are not addressed here. The simplest 843 way to do them is to compute a sum of the end-to-end Tspecs, as is 844 defined in the specifications of the Controlled-Load and Guaranteed ser- 845 vices (found at [RFC2211] and [RFC2212] respectively). However, it may 846 also be appropriate to compute the aggregate reservation level for the 847 tunnel using a more sophisticated statistical or measurement-based com- 848 putation. 850 8. IPSEC Tunnels 852 In the case where the IP-in-IP tunnel supports IPSEC (especially ESP in 853 Tunnel-Mode with or without AH) then the Tunnel Session uses the GPI 854 SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in [RSVPESP] for 855 the PATH and RESV messages. 857 Data packets are not encapsulated with a UDP header since the SPI can be 858 used by the intermediate nodes for classification purposes. Notice that 859 user oriented keying must be used between Rentry and Rexit, so that dif- 860 ferent SPIs are assigned to data packets that have reservation and "best 861 effort" packets, as well as packets that belong to different Tunnel 862 Sessions if those are supported. 864 9. RSVP Support for Multicast and Multipoint Tunnels 866 [ Editorial Comment: Previous versions of this draft have mentioned, but 867 not discussed, support for "multicast tunnels". This terminology has 868 proven confusing, and is expanded slightly in the section below. ] 870 The mechanisms described above are useful for unicast tunnels. Unicast 871 tunnels provide logical point-to-point links in the IP infrastructure, 872 though they may encapsulate and carry either unicast or multicast traf- 873 fic between those points. 875 Two other types of tunnels may be imagined. The first of these is a 876 "multicast" tunnel. In this type of tunnel, packets arriving at an 877 entry point are encapsulated and transported (multicast) to -all- of the 878 exit points. This sort of tunnel might prove useful for implementing a 879 hierarchical multicast distribution network, or for emulating effi- 880 ciently some portion of a native multicast distribution tree. 882 A second possible type of tunnel is the "multipoint" tunnel. In this 883 type of tunnel, packets arriving at an entry point are normally encapsu- 884 lated and transported to -one- of the exit points, according to some 885 route selection algorithm. 887 This type of tunnel differs from all previous types in that the 'shape' 888 of the usual data distribution path does not match the 'shape' of the 889 tunnel. The topology of the tunnel does not by itself define the data 890 transmission function that the tunnel performs. Instead, the tunnel 891 becomes a way to express some shared property of the set of connected 892 tunnel endpoints. For example, the "tunnel" may be used to create and 893 embed a logical shared broadcast network within some larger network. In 894 this case the tunnel endpoints are the nodes connected to the logical 895 shared broadcast network. Data traffic may be unicast between two such 896 nodes, broadcast to all connected nodes, or multicast between some sub- 897 set of the connected nodes. The tunnel itself is used to define a 898 domain in which to manage routing and resource management - essentially 899 a virtual private network [VPN]. 901 The use of multicast and multipoint tunnels to construct VPN's using 902 logical shared broadcast networks of this sort is described further in 903 [VMMT]. Note that while a VPN of this form can always be implemented 904 using a multicast tunnel to emulate the broadcast medium, this approach 905 will be very inefficient in the case of wide area VPN's, and a multi- 906 point tunnel with appropriate control mechanisms will be preferable. 908 The following paragraphs provide some brief commentary on the use of 909 RSVP in these situations. Future versions of this note will provide more 910 concrete details and specifications. 912 Using RSVP to provide resource management over a multicast tunnel is 913 relatively straightforward. As in the unicast case, one or more RSVP 914 sessions may be used, and end-to-end RSVP sessions may be mapped onto 915 tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the 916 unicast, case, however, the mapping is complicated by RSVP's heterogene- 917 ity semantics. If different receivers have made different reservation 918 requests, it may be that the RESV messages arriving at the tunnel would 919 logically map the receiver's requests to different tunnel sessions. 920 Since the data can actually be placed into only one session, the choice 921 of session must be reconciled (merged) to select the one that will meet 922 the needs of all applications. This requires a relatively simple exten- 923 sion to the session mapping mechanism. 925 Use of RSVP to support multipoint tunnels is somewhat more difficult. In 926 this case, the goal is to give the tunnel as a whole a specific level of 927 resources. For example, we may wish to emulate a "logical shared 10 928 megabit Ethernet" rather than a "logical shared Ethernet". However, the 929 problem is complicated by the fact that in this type of tunnel the data 930 does not always go to all tunnel endpoints. This implies that we cannot 931 use the destination address of the encapsulated packets as part of the 932 packet classification filter, because the destination address will vary 933 for different packets within the tunnel. 935 This implies the need for an extension to current RSVP session semantics 936 in which the Session ID (destination IP address) is used -only- to iden- 937 tify the session state within network nodes, but is not used to classify 938 packets. Other than this, the use of RSVP for multipoint tunnels fol- 939 lows that of multicast tunnels. A multicast group is created to repre- 940 sent the set of nodes that are tunnel endpoints, and one or more tunnel 941 RSVP sessions are created to reserve resources for the encapsulated 942 packets. In the case of a tunnel implementing a simple VPN, it is most 943 likely that there will be one session to reserve resources for the whole 944 VPN. Each tunnel endpoint will participate both as a source of PATH mes- 945 sages and a source of (WF or SE) RESV messages for this single session, 946 effectively creating a single shared reservation for the entire logical 947 shared medium. 949 10. Extensions to the RSVP/Routing Interface 951 The RSVP specification [RFC2205] states that through the RSVP/Routing 952 Interface, the RSVP daemon must be able to learn the list of local 953 interfaces along with their IP addresses. In the RSVP Tunnels case, the 954 RSVP daemon needs also to learn which of the local interface(s) is (are) 955 IP-in-IP tunnel(s) having the capabilities described here. The RSVP 956 daemon can acquire this information, either by directly querying the 957 underlying network and physical layers or by using any existing inter- 958 face between RSVP and the routing protocol properly extended to provide 959 this information. 961 11. Security Considerations 963 The introduction of RSVP Tunnels raises no new security issues other 964 than those associated with the use of RSVP and tunnels. Regarding RSVP, 965 the major issue is the need to control and authenticate access to 966 enhanced qualities of service. This requirement is discussed further in 967 [RFC2205]. [RSVPCRYPTO] describes the mechanism used to protect the 968 integrity of RSVP messages carrying the information described here. The 969 security issues associated with IP-in-IP tunnels are discussed in 970 [IPINIP4] and [IPV6GEN]. 972 12. Acknowledgments 974 We thank Bob Braden for his insightful comments that helped us to pro- 975 duce this updated version of the document. 977 13. References 979 [ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, 980 August, 1995. 982 [IP4INIP4] C. Perkins, "IP Encapsulation within IP", RFC 2003, October, 983 1996. 985 [IPV6GEN] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 Speci- 986 fication", Internet Draft draft-ietf-ipngwg-ipv6-tunnel-08.txt, January, 987 1998. 989 [MINENC] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, Octo- 990 ber, 1996. 992 [RFC1701] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 993 Encapsulation (GRE)", RFC 1701, October, 1994. 995 [RFC1702] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 996 Encapsulation over IPv4 Networks", RFC 1702, October, 1994. 998 [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 999 Hosts and Routers", RFC 1933, April, 1996. 1001 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Ser- 1002 vices", RFC2210, September, 1997. 1004 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load Network 1005 Element Service", RFC2211, September, 1997. 1007 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of the 1008 Guaranteed Quality of Service", RFC2212, September, 1997. 1010 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 1011 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 1012 2205 , September, 1997. 1014 [RSVPESP] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data 1015 Flows", RFC 2207, September, 1997. 1017 [RSVPCRYPTO] F. Baker, "RSVP Cryptographic Authentication", Internet 1018 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 1020 [VMMT] S. Pegrum, D. Jamieson, M. Yuen, A. Celer "VPN Multipoint to Mul- 1021 tipoint Tunnel Protocol (VMMT)", Internet Draft draft-pegrum- 1022 vmmt-01.txt, March 1998. 1024 14. Authors' Addresses 1026 John Krawczyk 1027 ArrowPoint Communications 1028 235 Littleton Road 1029 Westford, Massachusetts 01886 1030 Phone: 978-692-5875 x27 1031 Email: jjk@tiac.net 1033 John Wroclawski 1034 MIT Laboratory for Computer Science 1035 545 Technology Sq. 1036 Cambridge, MA 02139 1038 Phone: 617-253-7885 1039 Fax: 617-253-2673 (FAX) 1040 EMail: jtw@lcs.mit.edu 1042 Lixia Zhang 1043 UCLA 1044 4531G Boelter Hall 1045 Los Angeles, CA 90095 1047 Phone: 310-825-2695 1048 EMail: lixia@cs.ucla.edu 1050 Andreas Terzis 1051 UCLA 1052 4677 Boelter Hall 1053 Los Angeles, CA 90095 1055 Phone: 310-267-2190 1056 Email: terzis@cs.ucla.edu