idnits 2.17.1 draft-ietf-rsvp-tunnel-03.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 968: '...Tunnel endpoints MUST NOT make wildcar...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 119 has weird spacing: '...an that one c...' == Line 141 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 (October 1999) is 8950 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: 'IPINIP4' is mentioned on line 992, 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 (~~), 5 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 April 1999 Expiration: October 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 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes an approach for providing RSVP protocol 41 services over IP tunnels. We briefly describe the problem, the 42 characteristics of possible solutions, and the design goals of our 43 approach. We then present the details of an implementation which 44 meets our design goals. 46 1. What's changed 48 - Section 9 mentioned that endpoints of multipoint tunnels could send 49 WF RESVs. Given that destination IP address is not used in 50 the classification of packets traveling over multipoint tunnels, a 51 wildcard reservation would mean that all packets could use the 52 reserved 53 resources. This behavior is clearly undesirable and for this reason 54 WF reservations are considered illegal for multipoint tunnels. 56 - An "IANA Considerations" section was added. 58 2. Introduction 60 IP-in-IP "tunnels" have become a widespread mechanism to transport 61 datagrams in the Internet. Typically, a tunnel is used to route 62 packets through portions of the network which do not directly 63 implement the desired service (e.g. IPv6), or to augment and modify 64 the behavior of the deployed routing architecture (e.g. multicast 65 routing, mobile IP, Virtual Private Net). 67 Many IP-in-IP tunneling protocols exist today. [IP4INIP4] details a 68 method of tunneling using an additional IPv4 header. [MINENC] 69 describes a way to reduce the size of the "inner" IP header used in 70 [IP4INIP4] when the original datagram is not fragmented. The generic 71 tunneling method in [IPV6GEN] can be used to tunnel either IPv4 or 72 IPv6 packets within IPv6. [RFC1933] describes how to tunnel IPv6 73 datagrams through IPv4 networks. [RFC1701] describes a generic 74 routing encapsulation, while [RFC1702] applies this encapsulation to 75 IPv4. Finally, [ESP] describes a mechanism that can be used to 76 tunnel an encrypted IP datagram. 78 From the perspective of traditional best-effort IP packet delivery, a 79 tunnel behaves as any other link. Packets enter one end of the 80 tunnel, and are delivered to the other end unless resource overload 81 or error causes them to be lost. 83 The RSVP setup protocol [RFC2205] is one component of a framework 84 designed to extend IP to support multiple, controlled classes of 85 service over a wide variety of link-level technologies. To deploy 86 this technology with maximum flexibility, it is desirable for tunnels 87 to act as RSVP-controllable links within the network. 89 A tunnel, and in fact any sort of link, may participate in an RSVP- 90 aware network in one of three ways, depending on the capabilities of 91 the equipment from which the tunnel is constructed and the desires of 92 the operator. 94 1. The (logical) link may not support resource reservation or QoS 95 control at all. This is a best-effort link. We refer to this as 96 a best-effort or type 1 tunnel in this note. 97 2. The (logical) link may be able to promise that some overall 98 level of resources is available to carry traffic, but not to 99 allocate resources specifically to individual data flows. A 100 configured resource allocation over a tunnel is an example of 101 this. We refer to this case as a type 2 tunnel in this note. 102 3. The (logical) link may be able to make reservations for 103 individual end-to-end data flows. We refer to this case as a 104 type 3 tunnel. Note that the key feature that distinguishes type 105 3 tunnels from type 2 tunnels is that in the type 3 tunnel new 106 tunnel reservations are created and torn down dynamically as 107 end-to-end reservations come and go. 109 Type 1 tunnels exist when at least one of the routers comprising the 110 tunnel endpoints does not support the scheme we describe here. In 111 this case, the tunnel acts as a best-effort link. Our goal is simply 112 to make sure that RSVP messages traverse the link correctly, and the 113 presence of the non-controlled link is detected, as required by the 114 integrated services framework. 116 When the two end points of the tunnel are capable of supporting RSVP 117 over tunnels, we would like to have proper resources reserved along 118 the tunnel. Depending on the requirements of the situation, this 119 might mean that one client's data flow is placed into a larger 120 aggregate reservation (type 2 tunnels) or that possibly a new, 121 separate reservation is made for the data flow (type 3 tunnels). 122 Note that an RSVP reservation between the two tunnel end points does 123 not necessarily mean that all the intermediate routers along the 124 tunnel path support RSVP, this is equivalent to the case of an 125 existing end-to-end RSVP session transparently passing through non- 126 RSVP cloud. 128 Currently, however, RSVP signaling over tunnels is not possible. 129 RSVP packets entering the tunnel are encapsulated with an outer IP 130 header that has a protocol number other than 46 (e.g. it is 4 for 131 IP-in-IP encapsulation) and do not carry the Router-Alert option, 132 making them virtually "invisible" to RSVP routers between the two 133 tunnel endpoints. Moreover, the current IP-in-IP encapsulation 134 scheme adds only an IP header as the external wrapper. It is 135 impossible to distinguish between packets that use reservations and 136 those that don't, or to differentiate packets belonging to different 137 RSVP Sessions while they are in the tunnel, because no distinguishing 138 information such as a UDP port is available in the encapsulation. 140 This document describes an IP tunneling enhancement mechanism that 141 allows RSVP to make reservations across all IP-in-IP tunnels. This 142 mechanism is capable of supporting both type 2 and type 3 tunnels, as 143 described above, and requires minimal changes to both RSVP and other 144 parts of the integrated services framework. 146 3. The Design 148 3.1. Design Goals 150 Our design choices are motivated by several goals. 152 * Co-existing with most, if not all, current IP-in-IP tunneling 153 schemes. 154 * Limiting the changes to the RSVP spec to the minimum possible. 155 * Limiting the necessary changes to only the two end points of a 156 tunnel. This requirement leads to simpler deployment, lower 157 overhead in the intermediate routers, and less chance of failure 158 when the set of intermediate routers is modified due to routing 159 changes. 160 * Supporting correct inter-operation with RSVP routers that have 161 not been upgraded to handle RSVP over tunnels and with non-RSVP 162 tunnel endpoint routers. In these cases, the tunnel behaves as a 163 non-RSVP link. 165 3.2. Basic Approach 167 The basic idea of the method described in this document is to 168 recursively apply RSVP over the tunnel portion of the path. In this 169 new session, the tunnel entry point Rentry sends PATH messages and 170 the tunnel exit point Rexit sends RESV messages to reserve resources 171 for the end-to-end sessions over the tunnel. 173 We discuss next two different aspects of the design: how to enhance 174 an IP-in-IP tunnel with RSVP capability, and how to map end-to-end 175 RSVP sessions to a tunnel session. 177 3.2.1. Design Decisions 179 To establish a RSVP reservation over a unicast IP-in-IP tunnel, we 180 made the following design decisions: 182 One or more Fixed-Filter style unicast reservations between the two 183 end points of the tunnel will be used to reserve resources for 184 packets traversing the tunnel. In the type 2 case, these reservations 185 will be configured statically by a management interface. In the type 186 3 case, these reservations will be created and torn down on demand, 187 as end-to-end reservation requests come and go. 189 Packets that do not require reservations are encapsulated in the 190 normal way, e. g. being wrapped with an IP header only, specifying 191 the tunnel entry point as source and the exit point as destination. 193 Data packets that require resource reservations within a tunnel must 194 have some attribute other than the IP addresses visible to the 195 intermediate routers, so that the routers may map the packet to an 196 appropriate reservation. To allow intermediate routers to use 197 standard RSVP filterspec handling, we choose to encapsulate such data 198 packets by prepending an IP and a UDP header, and to use UDP port 199 numbers to distinguish packets of different RSVP sessions. The 200 protocol number in the outer IP header in this case will be UDP. 202 Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel 203 entry router which encapsulates data into the tunnel. Some number of 204 intermediate routers forward the data across the network based upon 205 the encapsulating IP header added by Rentry. Rexit is the endpoint 206 of the tunnel. It decapsulates the data and forwards it based upon 207 the original, "inner" IP header. 209 ........... ............... ............. 210 : _______ : : _____ : 211 : | | : : | | : 212 Intranet :--| Rentry|===================|Rexit|___:Intranet 213 : |_______| : : |_____| : 214 ..........: : Internet : :........... 215 :.............. 216 |___________________| 218 Figure 1. An example IP Tunnel 220 3.2.2. Mapping between End-to-End and Tunnel Sessions 222 Figure 2 shows a simple topology with a tunnel and a few hosts. The 223 sending hosts H1 and H3 may be one or multiple IP hops away from 224 Rentry; the receiving hosts H2 and H4 may also be either one or 225 multiple IP hops away from Rexit. 227 H1 H2 228 : : 229 : : 230 +--------+ +---+ +---+ +---+ +-------+ 231 | | | | | | | | | | 232 H3... | Rentry |===================================| Rexit |..... H4 233 | | | | | | | | | | 234 +--------+ +---+ +---+ +---+ +-------+ 236 Figure 2: An example end-to-end path with 237 a tunnel in the middle. 239 An RSVP session may be in place between endpoints at hosts H1 and H2. 240 We refer to this session as the "end-to-end" (E2E for short) or 241 "original" session, and to its PATH and RESV messages as the end-to- 242 end messages. One or more RSVP sessions may be in place between 243 Rentry and Rexit to provide resource reservation over the tunnel. We 244 refer to these as the tunnel RSVP sessions, and to their PATH and 245 RESV messages as the tunnel or tunneling messages. A tunnel RSVP 246 session may exist independently from any end-to-end sessions. For 247 example through network management interface one may create a RSVP 248 session over the tunnel to provide QoS support for data flow from H3 249 to H4, although there is no end-to-end RSVP session between H3 and 250 H4. 252 When an end-to-end RSVP session crosses a RSVP-capable tunnel, there 253 are two cases to consider in designing mechanisms to support an end- 254 to-end reservation over the tunnel: mapping the E2E session to an 255 existing tunnel RSVP session (type 2 tunnel), and dynamically 256 creating a new tunnel RSVP session for each end-to-end session (type 257 3 tunnel). In either case, the picture looks like a recursive 258 application of RSVP. The tunnel RSVP session views the two tunnel 259 endpoints as two end hosts with a unicast Fixed-Filter style 260 reservation in between. The original, end-to-end RSVP session views 261 the tunnel as a single (logical) link on the path between the 262 source(s) and destination(s). 264 Note that in practice a tunnel may combine type 2 and type 3 265 characteristics. Some end-to-end RSVP sessions may trigger the 266 creation of new tunnel sessions, while others may be mapped into an 267 existing tunnel RSVP session. The choice of how an end-to-end session 268 is treated at the tunnel is a matter of local policy. 270 When an end-to-end RSVP session crosses a RSVP-capable tunnel, it is 271 necessary to coordinate the actions of the two RSVP sessions, to 272 determine whether or when the tunnel RSVP session should be created 273 and torn down, and to correctly transfer error and ADSPEC information 274 between the two RSVP sessions. We made the following design 275 decision: 277 * End-to-end RSVP control messages being forwarded through a 278 tunnel are encapsulated in the same way as normal IP packets, 279 e.g. being wrapped with the tunnel IP header only, specifying 280 the tunnel entry point as source and the exit point as 281 destination. 283 3.3. Major Issues 285 As IP-in-IP tunnels are being used more widely for network traffic 286 management purposes, it is clear we must support type 2 tunnels 287 (tunnel reservation for aggregate end-to-end sessions). Furthermore, 288 these type 2 tunnels should allow more than one (configurable, 289 static) reservation to be used at once, to support different traffic 290 classes within the tunnel. Whether it is necessary to support type 3 291 tunnels (dynamic per end-to-end session tunnel reservation) is a 292 policy issue that should be left open. Our design supports both 293 cases. 295 If there is only one RSVP session configured over a tunnel, then all 296 the end-to-end RSVP sessions (that are allowed to use this tunnel 297 session) will be bound to this configured tunnel session. However 298 when more than one RSVP session is in use over an IP tunnel, a second 299 design issue is how the association, or binding, between an original 300 RSVP reservation and a tunnel reservation is created and conveyed 301 from one end of the tunnel to the other. The entry router Rentry and 302 the exit router Rexit must agree on these associations so that 303 changes in the original reservation state can be correctly mapped 304 into changes in the tunnel reservation state, and that errors 305 reported by intermediate routers to the tunnel end points can be 306 correctly transformed into errors reported by the tunnel endpoints to 307 the end-to-end RSVP session. 309 We require that this same association mechanism work for both the 310 case of bundled reservation over a tunnel (type 2 tunnel), and the 311 case of one-to-one mapping between original and tunnel reservations 312 (type 3 tunnel). In our scheme the association is created when a 313 tunnel entry point first sees an end-to-end session's RESV message 314 and either sets up a new tunnel session, or adds to an existing 315 tunnel session. This new association must be conveyed to Rexit, so 316 that Rexit can reserve resources for the end-to-end sessions inside 317 the tunnel. This information includes the identifier and certain 318 parameters of the tunnel session, and the identifier of the end-to- 319 end session to which the tunnel session is being bound. In our 320 scheme, all RSVP sessions between the same two routers Rentry and 321 Rexit will have identical values for source IP address, destination 322 IP address, and destination UDP port number. An individual session is 323 identified primarily by the source port value. 325 NOTE: (to be removed in RFC version) While in previous versions 326 of this draft the association between end-to-end and tunnel 327 sessions was done by Rentry when it received PATH messages from 328 new end-to-end sessions, to fully support RSVP semantics, where 329 the level of resources required is specified by the receivers, 330 information from the end-to-end RESV messages has to be 331 available before a suitable association can be made. For this 332 reason Rentry waits for end-to-end RESV to arrive, before 333 mapping end-to-end sessions to the 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 338 tunnel end points to convey the binding information. 339 2. Define a new RSVP object to be attached to end-to-end PATH 340 messages at Rentry, associating the end-to-end session with one 341 of the tunnel sessions. This new object is interpreted by Rexit 342 associating the end-to-end session with one of the tunnel 343 sessions generated at Rentry. 344 3. Apply the same UDP encapsulation to the end-to-end PATH messages 345 as to data packets of the session. When Rexit decapsulates the 346 PATH message, it deduces the relation between the source UDP 347 port used in the encapsulation and the RSVP session that is 348 specified in the 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 355 messages with the UDP encapsulation, but Rexit does not understand 356 this encapsulation, then the encapsulated PATH messages will be lost 357 at Rexit. 359 On the other hand, options (1) and (2) can handle this case 360 transparently. They allow Rexit to pass on end-to-end PATHs received 361 via the tunnel (because they are decapsulated normally), while 362 throwing away the tunnel PATHs, all without any additional 363 configuration. We chose Option (2) because it is simpler. We 364 describe this object in the following section. 366 Packet exchanges must follow the following constraints: 368 1. Rentry encapsulates and sends end-to-end PATH messages over the 369 tunnel to Rexit where they get decapsulated and forwarded 370 downstream. 371 2. When a corresponding end-to-end RESV message arrives at Rexit, 372 Rexit encapsulates it and sends it to Rentry. 373 3. Based on some or all of the information in the end-to-end PATH 374 messages, the flowspec in the end-to-end RESV message and local 375 policies, Rentry decides if and how to map the end-to-end 376 session to a tunnel session. 377 4. If the end-to-end session should be mapped to a tunnel session, 378 Rentry either sends a PATH message for a new tunnel session or 379 updates an existing one. 380 5. Rentry sends a E2E Path containing a SESSION_ASSOC object 381 associating the end-to-end session with the tunnel session 382 above. Rexit records the association and removes the object 383 before forwarding the Path message further. 384 6. Rexit responds to the tunnel PATH message by sending a tunnel 385 RESV message, reserving resources inside the tunnel. 386 7. Rentry UDP-encapsulates arriving packets only if a corresponding 387 tunnel session reservation is actually in place for the packets. 389 3.3.1. SESSION_ASSOC Object 391 The new object, called SESSION_ASSOC, is defined with the following 392 format: 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | length | class | c-type | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 | SESSION object (for the end-to-end session) | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 | Sender FILTER-SPEC (for the tunnel session) | 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 SESSION_ASSOC Object 408 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 422 the tunnel session described by the Sender FILTER-SPEC defined 423 below. 425 Sender FILTER-SPEC 427 This is the tunnel session that the above mentioned end-to-end 428 session maps to over the tunnel. As we mentioned above, a tunnel 429 session is identified primarily by source port. This is why we use 430 a Sender Filter-Spec for the tunnel session, in the place of a 431 SESSION object. 433 3.3.2. NODE_CHAR Object 435 There has to be a way (other than through configuration) for Rexit to 436 communicate to Rentry the fact that it is a tunnel endpoint 437 supporting the scheme described in this document. We have defined for 438 this reason a new object, called NODE_CHAR, carrying this 439 information. If a node receives this object but does not understand 440 it, it should drop it without producing any error report. Objects 441 with Class-Num = 10bbbbbb (`b' represents a bit), as defined in the 442 RSVP specification [RFC2205], have the characteristics we need. While 443 for now this object only carries one bit of information, it can be 444 used in the future to describe other characteristics of an RSVP 445 capable node that are not part of the original RSVP specification. 447 The object NODE_CHAR has the following format: 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | length | class | c-type | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Reserved |T| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Length 457 This field contains the size of the NODE_CHAR object in bytes. It 458 sould be set to eight. 460 Class 462 An appropriate value should be assigned by the IANA. We propose 463 this value to be 128. 465 Ctype 467 Should be sent as zero and ignored on receipt. 469 T bit 471 This bit shows that the node is a RSVP-tunnel capable node. 473 When Rexit receives an end-to-end reservation, it appends a NODE_CHAR 474 object with the T bit set, to the RESV object, it encapsulates it and 475 sends it to Rentry. When Rentry receives this RESV message it deduces 476 that Rexit implements the mechanism described here and so it creates 477 or adjusts a tunnel session and associates the tunnel session to the 478 end-to-end session via a SESSION_ASSOC object. Rentry should remove 479 the NODE_CHAR object, before forwarding the RESV message upstream. If 480 on the other hand, Rentry does not support the RSVP Tunnels mechanism 481 it would simply ignore the NODE_CHAR object and not forward it 482 further upstream. 484 4. Implementation 486 In this section we discuss several cases separately, starting from 487 the simplest scenario and moving to the more complex ones. 489 4.1. Single Configured RSVP Session over an IP-in-IP Tunnel 491 Treating the two tunnel endpoints as a source and destination host, 492 one easily sets up a FF-style reservation in between. Now the 493 question is what kind of filterspec to use for the tunnel 494 reservation, which directly relates to how packets get encapsulated 495 over the tunnel. We discuss two cases below. 497 4.1.1. In the Absence of End-to-End RSVP Session 499 In the case where all the packets traversing a tunnel use the 500 reserved resources, the current IP-in-IP encapsulation could be used. 501 The RSVP session over the tunnel would simply specify a FF style 502 reservation (with zero port number) with Rentry as the source address 503 and Rexit as the destination address. 505 However if only some of the packets traversing the tunnel should 506 benefit from the reservation, we must encapsulate the qualified 507 packets in IP and UDP. This allows intermediate routers to use 508 standard RSVP filterspec handling, without having to know about the 509 existence of tunnels. 511 Rather than supporting both cases we choose to simplify 512 implementations by requiring all data packets using reservations to 513 be encapsulated with an outer IP and UDP header. This reduces special 514 case checking and handling. 516 4.1.2. In the Presence of End-to-End RSVP Session(s) 518 According to the tunnel control policies, installed through some 519 management interface, some or all end-to-end RSVP sessions may be 520 allowed to map to the single RSVP session over the tunnel. In this 521 case there is no need to provide dynamic binding information between 522 end-to-end sessions and the tunnel session, given that the tunnel 523 session is unique and pre-configured, and therefore well-known. 525 Binding multiple end-to-end sessions to one tunnel session, however, 526 raises a new question of when and how the size of the tunnel 527 reservation should be adjusted to accomodate the end-to-end sessions 528 mapped onto it. Again the tunnel manager makes such policy decision. 529 Several scenarios are possible. In the first, the tunnel reservation 530 is never adjusted. This makes the tunnel the rough equivalent of a 531 fixed-capacity hardware link. In the second, the tunnel reservation 532 is adjusted whenever a new end-to-end reservation arrives or an old 533 one is torn down. In the third, the tunnel reservation is adjusted 534 upwards or downwards occasionally, whenever the end-to-end 535 reservation level has changed enough to warrant the adjustment. This 536 trades off extra resource usage in the tunnel for reduced control 537 traffic and overhead. 539 We call a tunnel whose reservation cannot be adjusted a "hard pipe", 540 as opposed to a "soft pipe" where the amount of resources allocated 541 is adjustable. Section 5.2 explains how the adjustment can be carried 542 out for soft pipes. 544 4.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel 546 It is straightforward to build on the case of a single configured 547 RSVP session over a tunnel by setting up multiple FF-style 548 reservations between the two tunnel endpoints using a management 549 interface. In this case Rentry must carefully encapsulate data 550 packets with the proper UDP port numbers, so that packets belonging 551 to different tunnel sessions will be distinguished by the 552 intermediate RSVP routers. Note that this case and the one described 553 before describe what we call type 2 tunnels. 555 4.2.1. In the Absence of End-to-End RSVP Session 557 Nothing more needs to be said in this case. Rentry classifies the 558 packets and encapsulates them accordingly. Packets with no 559 reservations are encapsulated with an outer IP header only, while 560 packets qualified for reservations are encapsulated with a UDP header 561 as well as an IP header. The UDP source port value should be properly 562 set to map to the corresponding tunnel reservation the packet is 563 supposed to use. 565 4.2.2. In the Presence of End-to-End RSVP Session(s) 567 Since in this case, there is more than one RSVP session operating 568 over the tunnel, one must explicitly bind each end-to-end RSVP 569 session to its corresponding tunnel session. As discussed 570 previously, this binding will be provided by the new SESSION_ASSOC 571 object carried by the end-to-end PATH messages. 573 4.3. Dynamically Created Tunnel RSVP Sessions 575 This is the case of a type 3 tunnel. The only differences between 576 this case and that of Section 4.2 are that: 578 - The tunnel session is created when a new end-to-end session 579 shows up. 580 - There is a one-to-one mapping between the end-to-end and tunnel 581 RSVP sessions, as opposed to possibly many-to-one mapping that 582 is allowed in the case described in Section 4.2. 584 5. RSVP Messages handling over an IP-in-IP Tunnel 585 5.1. RSVP Messages for Configured Session(s) Over A Tunnel 587 Here one or more RSVP sessions are set up over a tunnel through a 588 management interface. The session reservation parameters never 589 change for a "hard pipe" tunnel. The reservation parameters may 590 change for a "soft pipe" tunnel. Tunnel session PATH messages 591 generated by Rentry are addressed to Rexit, where they are processed 592 and deleted. 594 5.2. Handling of RSVP Messages at Tunnel Endpoints 596 5.2.1. Handling End-to-End PATH Messages at Rentry 598 When forwarding an end-to-end PATH message, a router acting as the 599 tunnel entry point, Rentry, takes the following actions depending on 600 the end-to-end session mentioned in the PATH message. There are two 601 possible cases: 603 1. The end-to-end PATH message is a refresh of a previously known 604 end-to-end session. 605 2. The end-to-end PATH message is from a new end-to-end session. 607 If the PATH message is a refresh of a previously known end-to-end 608 session, then Rentry refreshes the Path state of the end-to-end 609 session and checks to see if this session is mapped to a tunnel 610 session. If this is the case, then when Rentry refreshes the end-to- 611 end session, it includes in the end-to-end PATH message a 612 SESSION_ASSOC object linking this session to its corresponding tunnel 613 session It then encapsulates the end-to-end PATH message and sends it 614 over the tunnel to Rexit. If the tunnel session was dynamically 615 created, the end-to-end PATH message serves as a refresh for the 616 local tunnel state at Rentry as well as for the end-to-end session. 618 Otherwise, if the PATH message is from a new end-to-end session that 619 has not yet been mapped to a tunnel session, Rentry creates Path 620 state for this new session setting the outgoing interface to be the 621 tunnel interface. After that, Rentry encapsulates the PATH message 622 and sends it to Rexit without adding a SESSION_ASSOC message. 624 When an end-to-end PATH TEAR is received by Rentry, this node 625 encapsulates and forwards the message to Rexit. If this end-to-end 626 session has a one-to-one mapping to a tunnel session or if this is 627 the last one of the many end-to-end sessions mapping to a tunnel 628 session, Rentry tears down the tunnel session by sending a PATH TEAR 629 for that session to Rexit. If, on the other hand, there are remaining 630 end-to-end sessions mapping to the tunnel session, then Rentry sends 631 a tunnel PATH message adjusting the Tspec of the tunnel session. 633 5.2.2. Handling End-to-End PATH Messages at Rexit 635 Encapsulated end-to-end PATH messages are decapsulated and processed 636 at Rexit. As a first step, Rexit sets the PHOP of the end-to-end 637 sender to Rentry. Depending on whether the end-to-end PATH message 638 contains a SESSION_ASSOC object or not, Rexit takes the following 639 steps: 641 1. If the end-to-end PATH message does not contain a SESSION_ASSOC 642 object, then Rentry sets the Non_RSVP flag at the Path state 643 stored for this end-to-end sender, sets the global break bit in 644 the ADSPEC and forwards the packets downstream. 646 2. If the PATH message contains a SESSION_ASSOC object and no 647 association for this end-to-end session already exists, then 648 Rexit records the association between the end-to-end session and 649 the tunnel session described by the object. If the end-to-end 650 PATH arrives early before the tunnel PATH message arrives then 651 it creates PATH state at Rexit for the tunnel session. When the 652 actual PATH message for the tunnel session arrives it is treated 653 as an update of the existing PATH state and it updates any 654 information missing. We believe that this situation is another 655 transient along with the others existing in RSVP and that it 656 does not have any long-term effects on the correct operation of 657 the mechanism described here. 659 Before further forwarding the message to the next hop along the 660 path to the destination, Rexit finds the corresponding tunnel 661 session's recorded state and turns on Non_RSVP flag in the end- 662 to-end Path state if the Non_RSVP bit was turned on for the 663 tunnel session. If the end-to-end PATH message carries an 664 ADSPEC object, Rexit performs composition of the 665 characterization parameters contained in the ADSPEC. It does 666 this by considering the tunnel session's overall (composed) 667 characterization parameters as the local parameters for the 668 logical link implemented by the tunnel, and composing these 669 parameters with those in the end-to-end ADSPEC by executing each 670 parameter's defined composition function. In the logical link's 671 characterization parameters, the minimum path latency may take 672 into account the encapsulation/decapsulation delay and the 673 bandwidth estimate can represent the decrease in available 674 bandwidth caused by the addition of the extra UDP header. 675 ADSPECs and composition functions are discussed in great detail 676 in [RFC2210]. 678 If the end-to-end session has reservation state, while no 679 reservation state for the matching tunnel session exists, Rexit 680 send a tunnel RESV message to Rentry matching the reservation in 681 the end-to-end session. 683 If Rentry does not support RSVP tunneling, then Rexit will have no 684 PATH state for the tunnel. In this case Rexit simply turns on the 685 global break bit in the decapsulated end-to-end PATH message and 686 forwards it. 688 5.2.3. Handling End-to-End RESV Messages at Rexit 690 When forwarding a RESV message upstream, a router serving as the exit 691 router, Rexit, may discover that one of the upstream interfaces is a 692 tunnel. In this case the router performs a number of tests. 694 Step 1: Rexit must determine if there is a tunnel session bound to 695 the end-to-end session given in the RESV message. If not, the tunnel 696 is treated as a non-RSVP link, Rexit appends a NODE_CHAR object with 697 the T bit set, to the RESV message and forwards it over the tunnel 698 interface (where it is encapsulated as a normal IP datagram and 699 forwarded towards Rentry). 701 Step 2: If a bound tunnel session is found, Rexit checks to see if a 702 reservation is already in place for the tunnel session bound to the 703 end-to-end session given in the RESV message. If the arriving end- 704 to-end RESV message is a refresh of existing RESV state, then Rexit 705 sends the original RESV through tunnel interface (after adding the 706 NODE_CHAR object). For dynamic tunnel sessions, the end-to-end RESV 707 message acts as a refresh for the tunnel session reservation state, 708 while for configured tunnel sessions, reservation state never 709 expires. 711 If the arriving end-to-end RESV message causes a change in the end- 712 to-end RESV flowspec parameters, it may also trigger an attempt to 713 change the tunnel session's flowspec parameters. In this case Rexit 714 sends a tunnel session RESV, including a RESV_CONFIRM object. 716 In the case of a "hard pipe" tunnel, a new end-to-end reservation or 717 change in the level of resources requested by an existing reservation 718 may cause the total resource level needed by the end-to-end 719 reservations to exceed the level of resources reserved by the tunnel 720 reservation. This event should be treated as an admission control 721 failure, identically to the case where RSVP requests exceed the level 722 of resources available over a hardware link. A RESV_ERR message with 723 Error Code set to 01 (Admission Control failure), should be sent back 724 to the originator of the end-to-end RESV message. 726 If a RESV CONFIRM response arrives, the original RESV is encapsulated 727 and sent through the tunnel. If the updated tunnel reservation fails, 728 Rexit must send a RESV ERR to the originator of the end-to-end RESV 729 message, using the error code and value fields from the ERROR_SPEC 730 object of the received tunnel session RESV ERR message. Note that the 731 pre-existing reservations through the tunnel stay in place. Rexit 732 continues refreshing the tunnel RESV using the old flowspec. 734 Tunnel session state for a "soft pipe" may also be adjusted when an 735 end-to-end reservation is deleted. The tunnel session gets reduced 736 whenever one of the end-to-end sessions using the tunnel goes away 737 (or gets reduced itself). However even when the last end-to-end 738 session bound to that tunnel goes away, the configured tunnel session 739 remains active, perhaps with a configured minimal flowspec. 741 Note that it will often be appropriate to use some hysteresis in the 742 adjustment of the tunnel reservation parameters, rather than 743 adjusting the tunnel reservation up and down with each arriving or 744 departing end-to-end reservation. Doing this will require the tunnel 745 exit router to keep track of the resources allocated to the tunnel 746 (the tunnel flowspec) and the resources actually in use by end-to-end 747 reservations (the sum or statistical sum of the end-to-end 748 reservation flowspecs) separately. 750 When an end-to-end RESV TEAR is received by Rexit, it encapsulates 751 and forwards the message to Rentry. If the end-to-end session had 752 created a dynamic tunnel session, then a RESV TEAR for the 753 corresponding tunnel session is send by Rexit. 755 5.2.4. Handling of End-to-End RESV Messages at Rentry. 757 If the RESV message received is a refresh of an existing reservation 758 then Rentry updates the reservation state and forwards the message 759 upstream. On the other hand, if this is the first RESV message for 760 this end-to-end session and a NODE_CHAR object with the T bit set is 761 present, Rentry should initiate the mapping between this end-to-end 762 session and some (possibly new) tunnel session. This mapping is based 763 on some or all of the contents of the end-to-end PATH message, the 764 contents of the end-to-end RESV message, and local policies. For 765 example, there could be different tunnel sessions based on the 766 bandwidth or delay requirements of end-to-end sessions) 768 If Rentry decides that this end-to-end session should be mapped to an 769 existing configured tunnel session, it binds this end-to-end session 770 to that tunnel session. 772 If this end-to-end RSVP session is allowed to set up a new tunnel 773 session, Rentry sets up tunnel session PATH state as if it were a 774 source of data by starting to send tunnel-session PATH messages to 775 Rexit, which is treated as the unicast destination of the data. The 776 Tspec in this new PATH message is computed from the original PATH 777 message by adjusting the Tspec parameters to include the tunnel 778 overhead of the encapsulation of data packets. In this case Rentry 779 should also send a PATH message from the end-to-end session this time 780 containing the SESSION_ASSOC object linking the two sessions. The 781 receipt of this PATH message from Rexit will trigger an update of the 782 end-to-end Path state which in turn will have the effect of Rexit 783 sending a tunnel RESV message, allocating resources inside the 784 tunnel. 786 The last case is when the end-to-end session is not allowed to use 787 the tunnel resources. In this case no association is created between 788 this end-to-end session and a tunnel session and no new tunnel 789 session is created. 791 One limitation of our scheme is that the first RESV message of an 792 end-to-end session determines the mapping between that end-to-end 793 session and its corresponding session over the tunnel. Moreover as 794 long as the reservation is active this mapping cannot change. 796 6. Forwarding Data 798 When data packets arrive at the tunnel entry point Rentry, Rentry 799 must decide whether to forward the packets using the normal IP-in-IP 800 tunnel encapsulation or the IP+UDP encapsulation expected by the 801 tunnel session. This decision is made by determining whether there 802 is a resource reservation (not just PATH state) actually in place for 803 the tunnel session bound to the arriving packet, that is, whether the 804 packet matches any active filterspec. 806 If a reservation is in place, it means that both Rentry and Rexit are 807 RSVP-tunneling aware routers, and the data will be correctly 808 decapsulated at Rexit. 810 If no tunnel session reservation is in place, the data should be 811 encapsulated in the tunnel's normal format, regardless of whether 812 end-to-end PATH state covering the data is present. 814 7. Details 815 7.1. Selecting UDP port numbers 817 There may be multiple end-to-end RSVP sessions between the two end 818 points Rentry and Rexit. These sessions are distinguished by the 819 source UDP port. Other components of the session ID, the source and 820 destination IP addresses and the destination UDP port, are identical 821 for all such sessions. 823 The source UDP port is chosen by the tunnel entry point Rentry when 824 it establishes the initial PATH state for a new tunnel session. The 825 source UDP port associated with the new session is then conveyed to 826 Rexit by the binding mechanism. 828 The destination UDP port used in tunnel sessions should the one 829 assigned by IANA (363). 831 7.2. Error Reporting 833 When a tunnel session PATH message encounters an error, it is 834 reported back to Rentry. Rentry must relay the error report back to 835 the original source of the end-to-end session. 837 When a tunnel session RESV request fails, an error message is 838 returned to Rexit. Rexit must treat this as an error in crossing the 839 logical link (the tunnel) and forward the error message back to the 840 end host. 842 7.3. ICMP messages 844 Since the UDP encapsulated packets should not be fragmented, tunnel 845 entry routers must support tunnel MTU discovery as discussed in 846 section 5.1 of [IP4INIP4]. Alternatively, the Path MTU Discovery 847 mechanism discussed in RFC 2210 [RFC2210] can be used. 849 7.4. Tspec and Flowspec Calculations 851 As multiple End-to-End sessions can be mapped to a single tunnel 852 session, there is the need to compute the aggregate Tspec of all the 853 senders of those End-to-End sessions. This aggregate Tspec will the 854 Tspec of the representative tunnel session. The same operation needs 855 to be performed for flowspecs of End-to-End reservations arriving at 856 Rexit. 858 The semantics of these operations are not addressed here. The 859 simplest way to do them is to compute a sum of the end-to-end Tspecs, 860 as is defined in the specifications of the Controlled-Load and 861 Guaranteed services (found at [RFC2211] and [RFC2212] respectively). 862 However, it may also be appropriate to compute the aggregate 863 reservation level for the tunnel using a more sophisticated 864 statistical or measurement-based computation. 866 8. IPSEC Tunnels 868 In the case where the IP-in-IP tunnel supports IPSEC (especially ESP 869 in Tunnel-Mode with or without AH) then the Tunnel Session uses the 870 GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in 871 [RSVPESP] for the PATH and RESV messages. 873 Data packets are not encapsulated with a UDP header since the SPI can 874 be used by the intermediate nodes for classification purposes. 875 Notice that user oriented keying must be used between Rentry and 876 Rexit, so that different SPIs are assigned to data packets that have 877 reservation and "best effort" packets, as well as packets that belong 878 to different Tunnel Sessions if those are supported. 880 9. RSVP Support for Multicast and Multipoint Tunnels 882 [ Editorial Comment: Previous versions of this draft have mentioned, 883 but not discussed, support for "multicast tunnels". This terminology 884 has proven confusing, and is expanded slightly in the section below. 885 ] 887 The mechanisms described above are useful for unicast tunnels. 888 Unicast tunnels provide logical point-to-point links in the IP 889 infrastructure, though they may encapsulate and carry either unicast 890 or multicast traffic between those points. 892 Two other types of tunnels may be imagined. The first of these is a 893 "multicast" tunnel. In this type of tunnel, packets arriving at an 894 entry point are encapsulated and transported (multicast) to -all- of 895 the exit points. This sort of tunnel might prove useful for 896 implementing a hierarchical multicast distribution network, or for 897 emulating efficiently some portion of a native multicast distribution 898 tree. 900 A second possible type of tunnel is the "multipoint" tunnel. In this 901 type of tunnel, packets arriving at an entry point are normally 902 encapsulated and transported to -one- of the exit points, according 903 to some route selection algorithm. 905 This type of tunnel differs from all previous types in that the 906 'shape' of the usual data distribution path does not match the 907 'shape' of the tunnel. The topology of the tunnel does not by itself 908 define the data transmission function that the tunnel performs. 909 Instead, the tunnel becomes a way to express some shared property of 910 the set of connected tunnel endpoints. For example, the "tunnel" may 911 be used to create and embed a logical shared broadcast network within 912 some larger network. In this case the tunnel endpoints are the nodes 913 connected to the logical shared broadcast network. Data traffic may 914 be unicast between two such nodes, broadcast to all connected nodes, 915 or multicast between some subset of the connected nodes. The tunnel 916 itself is used to define a domain in which to manage routing and 917 resource management - essentially a virtual private network. 919 The use of multicast and multipoint tunnels to construct VPN's using 920 logical shared broadcast networks of this sort is described further 921 in [VMMT]. Note that while a VPN of this form can always be 922 implemented using a multicast tunnel to emulate the broadcast medium, 923 this approach will be very inefficient in the case of wide area 924 VPN's, and a multipoint tunnel with appropriate control mechanisms 925 will be preferable. 927 The following paragraphs provide some brief commentary on the use of 928 RSVP in these situations. Future versions of this note will provide 929 more concrete details and specifications. 931 Using RSVP to provide resource management over a multicast tunnel is 932 relatively straightforward. As in the unicast case, one or more RSVP 933 sessions may be used, and end-to-end RSVP sessions may be mapped onto 934 tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the 935 unicast, case, however, the mapping is complicated by RSVP's 936 heterogeneity semantics. If different receivers have made different 937 reservation requests, it may be that the RESV messages arriving at 938 the tunnel would logically map the receiver's requests to different 939 tunnel sessions. Since the data can actually be placed into only one 940 session, the choice of session must be reconciled (merged) to select 941 the one that will meet the needs of all applications. This requires a 942 relatively simple extension to the session mapping mechanism. 944 Use of RSVP to support multipoint tunnels is somewhat more difficult. 945 In this case, the goal is to give the tunnel as a whole a specific 946 level of resources. For example, we may wish to emulate a "logical 947 shared 10 megabit Ethernet" rather than a "logical shared Ethernet". 948 However, the problem is complicated by the fact that in this type of 949 tunnel the data does not always go to all tunnel endpoints. This 950 implies that we cannot use the destination address of the 951 encapsulated packets as part of the packet classification filter, 952 because the destination address will vary for different packets 953 within the tunnel. 955 This implies the need for an extension to current RSVP session 956 semantics in which the Session ID (destination IP address) is used 957 -only- to identify the session state within network nodes, but is not 958 used to classify packets. Other than this, the use of RSVP for 959 multipoint tunnels follows that of multicast tunnels. A multicast 960 group is created to represent the set of nodes that are tunnel 961 endpoints, and one or more tunnel RSVP sessions are created to 962 reserve resources for the encapsulated packets. In the case of a 963 tunnel implementing a simple VPN, it is most likely that there will 964 be one session to reserve resources for the whole VPN. Each tunnel 965 endpoint will participate both as a source of PATH messages and a 966 source of (FF or SE) RESV messages for this single session, 967 effectively creating a single shared reservation for the entire 968 logical shared medium. Tunnel endpoints MUST NOT make wildcard 969 reservations over multipoint tunnels. 971 10. Extensions to the RSVP/Routing Interface 973 The RSVP specification [RFC2205] states that through the RSVP/Routing 974 Interface, the RSVP daemon must be able to learn the list of local 975 interfaces along with their IP addresses. In the RSVP Tunnels case, 976 the RSVP daemon needs also to learn which of the local interface(s) 977 is (are) IP-in-IP tunnel(s) having the capabilities described here. 978 The RSVP daemon can acquire this information, either by directly 979 querying the underlying network and physical layers or by using any 980 existing interface between RSVP and the routing protocol properly 981 extended to provide this information. 983 11. Security Considerations 985 The introduction of RSVP Tunnels raises no new security issues other 986 than those associated with the use of RSVP and tunnels. Regarding 987 RSVP, the major issue is the need to control and authenticate access 988 to enhanced qualities of service. This requirement is discussed 989 further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used to 990 protect the integrity of RSVP messages carrying the information 991 described here. The security issues associated with IP-in-IP tunnels 992 are discussed in [IPINIP4] and [IPV6GEN]. 994 12. IANA Considerations 996 IANA should assign a Class number for the NODE_CHAR object defined in 997 Section 3.3.2. This number should be in the 10bbbbbb range. The 998 suggested value is 128. 1000 13. Acknowledgments 1002 We thank Bob Braden for his insightful comments that helped us to 1003 produce this updated version of the document. 1005 14. References 1007 [ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1008 1827, August, 1995. 1010 [IP4INIP4] C. Perkins, "IP Encapsulation within IP", RFC 2003, 1011 October, 1996. 1013 [IPV6GEN] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 1014 Specification", Internet Draft draft-ietf-ipngwg-ipv6-tunnel-08.txt, 1015 January, 1998. 1017 [MINENC] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, 1018 October, 1996. 1020 [RFC1701] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 1021 Encapsulation (GRE)", RFC 1701, October, 1994. 1023 [RFC1702] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing 1024 Encapsulation over IPv4 Networks", RFC 1702, October, 1994. 1026 [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 1027 Hosts and Routers", RFC 1933, April, 1996. 1029 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1030 Services", RFC2210, September, 1997. 1032 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 1033 Network Element Service", RFC2211, September, 1997. 1035 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of the 1036 Guaranteed Quality of Service", RFC2212, September, 1997. 1038 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 1039 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1040 Specification", RFC 2205 , September, 1997. 1042 [RSVPESP] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data 1043 Flows", RFC 2207, September, 1997. 1045 [RSVPCRYPTO] F. Baker, "RSVP Cryptographic Authentication", Internet 1046 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 1048 [VMMT] S. Pegrum, D. Jamieson, M. Yuen, A. Celer "VPN Multipoint to 1049 Multipoint Tunnel Protocol (VMMT)", Internet Draft draft-pegrum- 1050 vmmt-01.txt, March 1998. 1052 15. Authors' Addresses 1054 John Krawczyk 1055 ArrowPoint Communications 1056 235 Littleton Road 1057 Westford, Massachusetts 01886 1058 Phone: 978-692-5875 x27 1059 Email: jjk@tiac.net 1061 John Wroclawski 1062 MIT Laboratory for Computer Science 1063 545 Technology Sq. 1064 Cambridge, MA 02139 1066 Phone: 617-253-7885 1067 Fax: 617-253-2673 (FAX) 1068 EMail: jtw@lcs.mit.edu 1070 Lixia Zhang 1071 UCLA 1072 4531G Boelter Hall 1073 Los Angeles, CA 90095 1075 Phone: 310-825-2695 1076 EMail: lixia@cs.ucla.edu 1078 Andreas Terzis 1079 UCLA 1080 4677 Boelter Hall 1081 Los Angeles, CA 90095 1083 Phone: 310-267-2190 1084 Email: terzis@cs.ucla.edu