idnits 2.17.1 draft-ietf-mpls-rsvp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 154 has weird spacing: '...t seems neces...' == Line 204 has weird spacing: '...ontains no la...' == Line 327 has weird spacing: '...indings distr...' -- 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 (March 1998) is 9511 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) -- Looks like a reference, but probably isn't: 'R3' on line 274 == Unused Reference: '3' is defined on line 481, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 490, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-01) exists of draft-farinacci-multicast-tagsw-00 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-02) exists of draft-ietf-rsvp-routing-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-01) exists of draft-davie-mpls-atm-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-rosen-tag-stack-03 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruce Davie 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: September 1998 5 Yakov Rekhter 6 Cisco Systems, Inc. 8 Eric Rosen 9 Cisco Systems, Inc. 11 Arun Viswanathan 12 Lucent Technologies 14 Vijay Srinivasan 15 IBM Corp. 17 Steven Blake 18 IBM Corp. 20 March 1998 22 Use of Label Switching With RSVP 24 draft-ietf-mpls-rsvp-00.txt 26 Status of this Memo 28 This document is an Internet-Draft. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 To learn the current status of any Internet-Draft, please check the 39 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 40 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 41 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 42 ftp.isi.edu (US West Coast). 44 Abstract 46 Multiprotocol Label Switching (MPLS) allows labels to be bound to 47 various granularities of forwarding information, including 48 application flows. In this document we present a specification for 49 allocating and binding labels to RSVP flows, and to distributing the 50 appropriate binding information using RSVP messages. 52 Contents 54 1 Introduction ........................................... 2 55 2 Specification .......................................... 3 56 2.1 Label Allocation ....................................... 3 57 2.2 Choice of label for data forwarding .................... 4 58 2.3 Label space partitioning on shared media ............... 5 59 2.4 Label withdrawal ....................................... 5 60 2.5 Reservation Styles ..................................... 5 61 2.6 ATM-LSR considerations ................................. 6 62 2.7 RSVP Object Definitions ................................ 8 63 2.8 Non RSVP routers ....................................... 9 64 3 Examples ............................................... 10 65 3.1 Unicast ................................................ 10 66 3.2 Multicast .............................................. 11 67 4 Security Considerations ................................ 11 68 5 References ............................................. 12 69 6 Author's Addresses ..................................... 12 71 1. Introduction 73 The purpose of this document is to propose a standard method for 74 hosts and routers that support both label switching [1] and RSVP [4] 75 to associate labels with RSVP flows. The goal is to enable label 76 switching routers (LSRs) to be able to identify the appropriate 77 reservation state for a packet based on its label value. To this end, 78 the document describes a set of procedures for allocating and binding 79 labels, and a way to distribute the bindings using RSVP messages. It 80 also defines two new RSVP Objects: RSVP_LABEL, to carry a label in an 81 RSVP message, and HOP_COUNT, to enable TTL processing for RSVP flows 82 which pass through ATM-LSRs. 84 While there are several alternatives to mapping RSVP flows to labels, 85 this document specifies a model in which, on a given link, each 86 sender to a single RSVP session is associated with one label. (There 87 is one exception, described below.) The rationale for this choice is 88 discussed below. 90 2. Specification 92 As mentioned above, in a label switching environment it is desirable 93 to associate each RSVP flow with a label. An RSVP flow [4] is a 94 simplex flow from a sending application to a set of receiving 95 applications identified by an IP address (and perhaps a transport 96 protocol port), and a session may contain several flows. An RSVP 97 reservation may be flow specific (fixed filter) or shared across 98 flows (shared explicit and wildcard). 100 For the purposes of this specification, we assume that all routers on 101 a given link are capable of sending and receiving labeled packets 102 over that link. Thus, for example, one would not enable labeling on 103 some routers on a LAN but not on others. 105 2.1. Label Allocation 107 The association between RSVP flows and labels involves the allocation 108 of a label to a flow, which could in principle be initiated by either 109 the upstream or downstream node. However, there are some strong 110 arguments in favor of downstream allocation that arise from the need 111 to coordinate label allocation for RSVP with other label allocation 112 schemes, e.g., the allocation of labels for best effort traffic. If 113 some labels were allocated by the receiver of data and some by the 114 sender, race conditions could arise in which both sender and receiver 115 allocated the same label for different purposes. This can most easily 116 be avoided by leaving allocation to one party. Since the receiver of 117 data allocates labels for best effort traffic, we believe this is 118 also the best choice for traffic with resource reservations. 120 Even when label allocation is performed by the downstream nodes, it 121 may be necessary to communicate label bindings from upstream to 122 downstream. For example, if two routers on a shared media LAN are 123 receiving data for the same session, that data should be sent with 124 the same label to both receivers. The best way to accomplish this 125 while retaining downstream allocation is for one of the receivers to 126 allocate a label, communicate the label-to-session binding to the 127 sender(s) on the LAN using RESV messages, and then have the sender(s) 128 communicate the binding to the receivers in PATH messages. The PATH 129 message should be sent as soon as the reservation with the label 130 binding is installed (rather than waiting for the normal PATH refresh 131 interval), so that receivers of labeled data will be notified at once 132 of the fact that labeled data is about to arrive. 134 It is possible in this case that two or more receivers might try to 135 allocate the label for a single session. In this case, the upstream 136 node(s) will receive RESV messages for the session advertising 137 different labels. Any node receiving conflicting labels in this way 138 must break the tie in some way. The only requirement on the tie- 139 breaking is that it be consistent (i.e., once a choice has been made, 140 it should not be reversed at some later time). Simply choosing the 141 label in the first RESV message received is an adequate approach. 142 Having broken the tie, the selected label will appear in subsequent 143 PATH messages, and the recipients of these PATH messages must accept 144 the result. If for some reason (e.g. hardware limitation) the 145 assigned LABEL value was not acceptable to a recipient, it would need 146 to generate a PATH error message. Methods outside the scope of this 147 document (e.g. LDP) may be used to determine acceptable label ranges. 149 One unfortunate consequence of this method of label distribution on 150 shared media is that even nodes which do not wish to make 151 reservations for some session may receive PATH messages corresponding 152 to that session indicating that some other node has made a 153 reservation and that data for that session will now arrive with a new 154 (non-best effort) label. It seems necessary for the node that made 155 no reservation to accept the new label. At present, it is not clear 156 how to make the sender of data aware that all nodes are ready to 157 receive data with the new label. This is an area for further study. 159 2.2. Choice of label for data forwarding 161 As soon as a LSR has installed a reservation on one of its interfaces 162 and has received a label binding for that reservation (either for the 163 whole session or for some flows in the session) it should use the 164 chosen label for all appropriate flows. Any flows or sessions for 165 which label bindings have not been received must be sent using the 166 appropriate best effort label. This best effort label will have been 167 advertised by some other mechanism, such as PIM (for multicast) or 168 LDP (for unicast). When a router is forwarding packets out multiple 169 interfaces, it may be the case that reservations are installed on 170 some interfaces and not others. In this case, the best effort 171 allocated label should be used on those interfaces for which no 172 reservation is present. 174 2.3. Label space partitioning on shared media 176 To ensure that a single label is not allocated twice for different 177 purposes by different routers, it is necessary to partition the label 178 space among routers on a shared media, just as described in [2]. In 179 fact, such partitioning is only needed for multicast sessions, and 180 thus the exact mechanism described in [2] can be used. A router which 181 has thus obtained a portion of the label space can decide 182 unilaterally which labels from this space to use for multicast of 183 best effort traffic and which to use for RSVP sessions. Similarly, in 184 the unicast case, a router decides locally which labels it will 185 allocate for best effort traffic and which for RSVP sessions. 187 2.4. Label withdrawal 189 When the original allocator of a label no longer wishes to have a 190 reservation for the corresponding flow or session, or if the 191 allocator crashes, it will stop refreshing the reservation with RESV 192 messages. It may also issue a ResvTear message. Upstream nodes which 193 had been redistributing that label using PATH messages must stop 194 doing so when the reservation times out or is torn down. They will 195 thus resume sending PATH messages with no labels, and any recipient 196 of those PATH messages will be at liberty to allocate a new label and 197 place it in a RESV message. However, it may be that the nodes that 198 did not crash will keep refreshing the reservation using the old 199 label. It is important that a router that is newly rebooted does not 200 try to assign that label; this should be possible, since it will 201 receive the PATH messages once it reboots. 203 A label may be withdrawn without removing the reservation by sending 204 a RESV message which contains no label. This would similarly be 205 propagated via PATH messages to other receivers, who would have the 206 option of allocating a new label. 208 2.5. Reservation Styles 210 So far we have glossed over the exact mapping between labels and 211 sessions or labels and flows. It seems clear that for fixed filter 212 (FF) style reservations, a label per sender is needed, since each 213 sender has its own allocated resources. Because of the merging rules 214 for SE reservations, we believe a label per sender is needed in this 215 case also. The following example illustrates the point. 217 Consider the following arrangement of LSRs: 219 [R3] 220 / 221 / 222 [R1]----------[R2]------[R4] 224 where data is flowing from left to right and there are at least 2 225 senders to the session, S1 and S2. Suppose one of the receivers 226 downstream of R3 makes a shared explicit (SE) reservation for data 227 coming from two senders S1 and S2, while a receiver downstream of R4 228 makes a reservation for data coming from one sender S1. These would 229 be merged at R2 as a single SE reservation before forwarding to R1. 230 So, if we used a single label per session on the link from R1 to R2, 231 there would be no way for R2 to distinguish packets from sender S1 232 (which are covered by a reservation on both outgoing links) from 233 those from S2 (which are covered by a reservation only on the link to 234 R3. Thus, we need a label per sender for SE reservations. 236 Finally, for the WF case, we might imagine that a single label could 237 be used for the session, since all senders to the session are covered 238 by the reservation. For a shared tree, this is true, but for source 239 specific trees we need different labels for different senders since 240 the fact that two trees share a link at some point does not mean they 241 will not diverge at some later point on the way to a receiver. If we 242 were to use a single label for all senders to a WF session on 243 source-specific trees, it would be impossible to determine the 244 appropriate forwarding action at a point where the trees diverge. 246 Thus, the general rule is one label per sender to a session, with the 247 exception being that one label can be used for all senders to a 248 session with a WF reservation who are using a shared tree. Note that 249 some senders to a session may use a shared tree while others may be 250 on the source specific tree. The router allocating labels and sending 251 them in RESV messages needs to know which senders are on which type 252 of tree; it can find this out using the interface to routing 253 described in [5]. 255 2.6. ATM-LSR considerations 257 In most respects, an ATM-LSR behaves like any other LSR that is 258 connected to its neighbors with point to point links. One minor 259 difference is that that, on ATM-LSRs which do not support VC-merge, a 260 label per sender is needed for all reservation styles. In theory, 261 this could be reduced to a label per ingress router per session for 262 WF reservations on a shared tree, but procedures to allocate labels 263 appropriately have not yet been defined. 265 Note that, in WF and SE styles, resources are allocated to 266 reservations, not to specific senders. An ATM-LSR therefore needs to 267 be able to allocate resources to a collection of labels to support 268 these filter styles correctly. 270 More significantly, ATM-LSRs which cannot perform VC merge create a 271 problem when some but not all of their downstream neighors make 272 reservations. For example, in the following arrangement of four LSRs: 274 [R3] 275 / 276 / 277 [R1]----------[R2]------[R4] 279 Assume R2 receives a reservation from R3 but not from R4. R2 will 280 bind a label to the reservation and advertise it to R1. Packets from 281 R1 which match that reservation will arrive at R2 carrying the label 282 R2 assigned. Best effort packets from R1 will arrive at R2 carrying 283 the best effort label. Both sets of packets should be sent to R4 with 284 the best effort label. However, if R2 is not capable of VC merge, 285 best effort packets and reserved packets will become interleaved on 286 the way to R4. 288 The problem could be averted by assigning an extra label for use on 289 the link between R2 and R4 for each label that R2 creates on the link 290 to R1. Since this label is for best effort traffic, it could be 291 allocated using the Label Distribution Protocol in the downstream on 292 demand mode. This enables R2 to force the label allocation without 293 introducing the complexity of mixing upstream and downstream 294 allocation. Note that this may cause allocation of numerous labels 295 for best effort traffic on the R2-R4 link as a label per sender per 296 session will be allocated on the R1-R2 link. 298 When IP packets are label switched by ATM-LSRs, the TTL value in the 299 IP header cannot be decremented, and no TTL is available in the ATM 300 header. To enable TTL to be decremented by the number of ATM-LSR 301 hops, the proposed HOP_COUNT Object is used to count the number of 302 consecutive LSR hops. The object is inserted into the Path message by 303 a non-ATM LSR whose next hop for the session is an ATM-LSR, and 304 initialized with a hop count of 1. Subsequent ATM-LSRs increment the 305 hop-count only if there is a label-switched path for that sender flow 306 through that LSR. All LSRs maintain the hop count in the Path State. 307 The `egress' LSR, i.e., the first frame-based LSR to receive the 308 HOP_COUNT object, uses the count to decrement the TTL on packets for 309 that sender flow, and removes the HOP_COUNT object from the PATH 310 message. 312 2.7. RSVP Object Definitions 314 As discussed above, labels may be carried in both PATH and RESV 315 messages. When a label is to be associated with a single sender, it 316 must immediately follow the FILTER_SPEC for that sender in the RESV 317 or the SENDER_TEMPLATE in the PATH message. 319 The wildcard filter case is the most complicated. If all senders are 320 using the shared tree, then only one label is needed, and can be 321 placed immediately following the FLOW_SPEC in the RESV. In this case, 322 all PATH messages must contain the same label, again following the 323 SENDER_TEMPLATE. 325 If some senders to a WF session are not using the shared tree, then 326 seperate labels need to be allocated for those senders and the 327 bindings distributed. It is necessary to enumerate the senders who 328 are using source specific trees and associate a label with each one; 329 this can be done by including a FILTER_SPEC object followed by an 330 RSVP_LABEL object for each such sender. All senders using the shared 331 tree will use the label that follows the single FLOW_SPEC in the 332 message. 334 The RSVP_LABEL object class conforms to the standard RSVP object 335 format: 337 RSVP_LABEL class = 16, C_Type = 1 339 0 1 2 3 340 +-------------+-------------+-------------+-------------+ 341 | Length (bytes) | Class-Num | C-Type | 342 +-------------+-------------+-------------+-------------+ 343 | | 344 // (Object contents) // 345 | | 346 +-------------+-------------+-------------+-------------+ 348 The contents of a Label object is a stack of labels, where each label 349 is encoded right aligned in 4 octets. The top of the stack is in the 350 rightmost 4 octets of the object contents. The label stack can be 351 carried in packets using an encoding such as decribed in [7]. When an 352 ATM link is used, the low order 28 bits of the top label in the stack 353 are carried in the VPI/VCI field of the ATM cells. 355 When no labels have been allocated to a session, the PATH messages 356 for that session must contain no RSVP_LABEL object. If labels have 357 been allocated for some senders but not others in a session, then 358 RSVP_LABEL objects should be included only after the SENDER_TEMPLATEs 359 of those senders for who labels are assigned. This enables receivers 360 of PATH messages to determine if a label has been assigned or if a 361 label assignment is required. 363 A node receiving a PATH message containing a label must use that 364 label in subsequent RESV messages for the same sender or session. If 365 for some reason it is unable to do this, it must generate a PATH 366 error message. 368 The HOP_COUNT object class conforms to the standard RSVP object 369 format: 371 HOP_COUNT object: Class = 17, C-Type = 1 373 0 1 2 3 374 +-------------+-------------+-------------+-------------+ 375 | Length (bytes) | Class-Num | C-Type | 376 +-------------+-------------+-------------+-------------+ 377 | Hop Count | Reserved | 378 +-------------+-------------+-------------+-------------+ 380 Hop Count 381 Counts the length (in ISR hops) of the switched path. 383 2.8. Non RSVP routers 385 RSVP is designed to cope gracefully with non-RSVP routers anywhere in 386 the path between senders and receivers. However, non-RSVP routers 387 will not be able to receive label bindings conveyed in PATH or RESV 388 messages. This means that if a LSR has a downstream neighbor who is 389 not RSVP capable, it must not use labels advertised by RSVP messages 390 when forwarding data to that neighbor. This includes the case where 391 some routers on a LAN are RSVP capable and some are not; if an RSVP 392 capable router on the LAN advertises a label binding in a RESV 393 message, the recipient of that message cannot send labeled data using 394 that label if there are any non-RSVP routers on the LAN that have 395 joined the multicast group for that session. 397 Also, when RESV messages are received by a non-RSVP router, it 398 unwittingly passes them on towards the previous hop RSVP router. This 399 could result in a label being advertised to a router which was not 400 directly connected to the advertiser of the label. Such a label would 401 be useless for data forwarding. Thus, RESV messages containing label 402 binding information must not be sent toward a previous hop when it 403 would pass through non-RSVP routers on the way. [4] describes how 404 routers may determine the presence of non-RSVP routers in a path. 406 3. Examples 408 3.1. Unicast 410 The figure below shows a simple example network in which two hosts H1 411 and H2 communicate through a sequence of label switched routers (R1, 412 R2). 414 [H1]------[R1]------[R2]------[H2] 416 Following RSVP procedures, H1 sends a RSVP PATH messages to H2. The 417 PATH messages traverse through R1 and R2. 419 When H2 determines that it would like to setup a reservation for this 420 particular session, it allocates a label, and sends a RESV message 421 containing this label to R2. H2 stores this label as an identifier 422 for the session, and can use it to demultiplex arriving data packets 423 to the appropriate application or device. When R2 receives the RESV 424 message, along with normal RSVP processing, it stores the value of 425 the label as part of the reservation state for this session and 426 interface. This will be the outgoing label for data packets sent by 427 R2 to H2. R2 then allocates a label, and sends a RESV message 428 containing this label to R1. When R1 receives this message, it 429 behaves similarly to R2, storing the label received from R2 and 430 allocating a new label which it sends in a RESV message to H1. Upon 431 receiving the message, H1 proceeds to start sending the session's 432 data with the label received from R1. R1 forwards the data to R2 433 using the label it received from R2, and R2 sends data to H2 using 434 the label received from H2. 436 3.2. Multicast 438 The figure below shows a network in which two senders H1 and H2 send 439 traffic to two receivers H3 and H4. Routers R1, R2 and R3 are on a 440 shared media LAN. 442 |-[R3]--------[H3] 443 | 444 | 445 [H1]---[R1]-|-[R2]--------[H4] 446 / 447 [H2]---/ 449 Assume that H1 and H2 are using the shared multicast tree to send 450 data. H1 and H2 send PATH messages toward H3 and H4. Assume H3 makes 451 a WF reservation by sending a RESV to R3. H3 allocates a label and 452 includes it in the RESV message. R3 stores this label as the label to 453 use for data traffic to H3 for this session. R3 allocates a label 454 and includes it in the RESV that it sends to R1. R1 stores this label 455 and includes it in subsequent PATH messages to R2 and R3. R1 456 allocates a label for the session and sends it in RESV messages to H1 457 and H2 (different labels may be used on different interfaces, as a 458 matter of implementation choice). 460 Assume H4 then makes a WF reservation. H4 allocates a label and sends 461 it in a RESV message to R2. R2 stores this label and will use it for 462 data packets to H4. R2 now sends a RESV to R1 using the label 463 contained in the PATH message from R1. 465 4. Security Considerations 467 Security considerations are not addressed in this version of the 468 document. We presume that the security procedures defined for RSVP 469 will handle any security issues that arise with coupling label 470 switching with RSVP. 472 5. References 474 [1] Rosen, E. et al. A Proposed Architecture for MPLS, Internet 475 Draft, draft-ietf-mpls-arch-00.txt, Aug. 1997. 477 [2] Farinacci, D. Partitioning Tag Space among Multicast Routers on a 478 Common Subnet, Internet Draft, draft-farinacci-multicast-tag-part- 479 00.txt, Dec. 1996. 481 [3] Farinacci, D. Multicast Tag Binding and Distribution using PIM, 482 Internet Draft, draft-farinacci-multicast-tagsw-00.txt, Dec. 1996. 484 [4] Braden, R. et al. Resource ReSerVation Protocol (RSVP) -- Version 485 1 Functional Specification, RFC 2205, Sep. 1997. 487 [5] Zappala, D. RSRR: A Routing Interface For RSVP, Internet Draft, 488 draft-ietf-rsvp-routing-01.txt, Nov. 1996. 490 [6] Davie, B. et al. Use of Label Switching With ATM, Internet Draft, 491 draft-davie-mpls-atm-00.txt, Nov. 1997. 493 [7] Rosen, E. et al. Label Switching: Label Stack Encodings, Internet 494 Draft, draft-rosen-tag-stack-03.txt, July, 1997. 496 6. Author's Addresses 498 Bruce Davie 499 Cisco Systems, Inc. 500 250 Apollo Drive 501 Chelmsford, MA, 01824 503 E-mail: bsd@cisco.com 505 Yakov Rekhter 506 Cisco Systems, Inc. 507 170 Tasman Drive 508 San Jose, CA, 95134 510 E-mail: yakov@cisco.com 511 Eric Rosen 512 Cisco Systems, Inc. 513 250 Apollo Drive 514 Chelmsford, MA, 01824 516 E-mail: erosen@cisco.com 518 Vijay Srinivasan 519 IBM Corporation 520 P. O. Box 12195 521 Research Triangle Park, NC 27709 523 E-mail: vijay@raleigh.ibm.com 525 Arun Viswanathan 526 Lucent Technologies 527 101 Crawford Corner Rd., #4D-537 528 Holmdel, NJ 07733 530 E-mail: arunv@dnrc.bell-labs.com 532 Steven Blake 533 IBM Corporation 534 PO Box 12195 535 Research Triangle Park, NC 27709 537 Email: slblake@raleigh.ibm.com