idnits 2.17.1 draft-davie-mpls-atm-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-04-25) 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1997) is 9658 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 == Outdated reference: A later version (-04) exists of draft-doolan-tdp-spec-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-rosen-tag-stack-03 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruce Davie 3 Internet Draft Jeremy Lawrence 4 Expiration Date: May 1998 Keith McCloghrie 5 Yakov Rekhter 6 Eric Rosen 7 George Swallow 8 Cisco Systems, Inc. 10 Paul Doolan 11 Ennovate Networks, Inc. 13 November 1997 15 Use of Label Switching With ATM 17 draft-davie-mpls-atm-00.txt 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 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 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 38 A Multi Protocol Label Switching architecture is described in [1]. 39 Label Switching enables the use of ATM Switches as Label Switching 40 Routers. The ATM Switches run network layer routing algorithms (such 41 as OSPF, IS-IS, etc.), and their data forwarding is based on the 42 results of these routing algorithms. No ATM-specific routing or 43 addressing is needed. 45 This document describes how the label switching architecture is 46 applied to ATM switches. 48 Contents 50 1 Introduction ........................................... 2 51 2 Definitions ............................................ 3 52 3 Special Characteristics of ATM Switches ................ 3 53 4 Label Switching Control Component for ATM .............. 4 54 5 Hybrid Switches (Ships in the Night) ................... 5 55 6 Use of VPI/VCIs ....................................... 5 56 7 Label Allocation and Maintenance Procedures ............ 6 57 7.1 Edge LSR Behavior ...................................... 6 58 7.2 Conventional ATM Switches (non-VC-merge) ............... 7 59 7.3 VC-merge-capable ATM Switches .......................... 9 60 7.4 Efficient use of label space ........................... 11 61 8 Encapsulation .......................................... 11 62 9 Security Considerations ................................ 12 63 10 Intellectual Property Considerations ................... 12 64 11 References ............................................. 12 65 12 Acknowledgments ........................................ 12 66 13 Authors' Addresses ..................................... 12 68 1. Introduction 70 A label switching architecture is described in [1]. It is possible to 71 use ATM switches as label switching routers. Such ATM switches run 72 network layer routing algorithms (such as OSPF, IS-IS, etc.), and 73 their forwarding is based on the results of these routing algorithms. 74 No ATM-specific routing or addressing is needed. 76 When an ATM switch is used for label switching, the label on which 77 forwarding decisions are based is carried in the VCI and/or VPI 78 fields. (It is possible to carry multiple labels in the VCI and/or 79 VPI fields, but the scope of this document is restricted to the case 80 of a single label.) 82 The characteristics of ATM switches require some specialized 83 procedures and conventions to support label switching. This document 84 describes those aspects of label switching which are specific to ATM. 86 2. Definitions 88 A Label Switching Router (LSR) is a device which implements the label 89 switching control and forwarding components described in [1]. 91 A label switching controlled ATM (LC-ATM) interface is an ATM 92 interface controlled by the label switching control component. 93 Packets traversing such an interface carry labels in the VCI and/or 94 VPI field. 96 An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards 97 cells between these interfaces using labels carried in the VCI and/or 98 VPI field. 100 A frame-based LSR is a LSR which forwards complete frames between its 101 interfaces. Note that such a LSR may have zero, one or more LC-ATM 102 interfaces. 104 An ATM-LSR cloud is a set of ATM-LSRs which are mutually 105 interconnected by LC-ATM interfaces. 107 The Edge Set of an ATM-LSR cloud is the set of frame-based LSRs which 108 are connected to the cloud by LC-ATM interfaces. 110 VC-merge is the process by which a switch receives cells on several 111 incoming VCIs and transmits them on a single outgoing VCI without 112 causing the cells of different AAL5 PDUs to become interleaved. 114 3. Special Characteristics of ATM Switches 116 While the label switching architecture permits considerable 117 flexibility in LSR implementation, an ATM-LSR is constrained by the 118 capabilities of the (possibly pre-existing) hardware and the 119 restrictions on such matters as cell format imposed by ATM standards. 120 Because of these constraints, some special procedures are required 121 for ATM-LSRs. 123 Some of the key features of ATM switches that affects their behavior 124 as LSRs are: 126 - the label swapping function is performed on fields (the VCI 127 and/or VPI) in the cell header; this dictates the size and 128 placement of the label(s) in a packet. 130 - multipoint-to-point and multipoint-to-multipoint VCs are 131 generally not supported. This means that most switches cannot 132 support `VC-merge' as defined above. 134 - there is generally no capability to perform a `TTL-decrement' 135 function as is performed on IP headers in routers. 137 This document describes ways of applying label switching to ATM 138 switches which work within these constraints. 140 4. Label Switching Control Component for ATM 142 To support label switching an ATM switch must implement the control 143 component of label switching. This consists primarily of label 144 allocation and maintenance procedures. Label binding information is 145 communicated by several mechanisms, notably the Label Distribution 146 Protocol (LDP). Candidate protocols being considered by the LDP 147 design team are described in [2, 4]. This document imposes certain 148 requirements on the LDP. 150 Since the label switching control component uses information learned 151 directly from network layer routing protocols, this implies that the 152 switch must participate as a peer in these protocols (e.g., OSPF, 153 IS-IS). 155 In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP) 156 to distribute label bindings. In these cases, an ATM LSR would need 157 to participate in these protocols. 159 Support of label switching on an ATM switch does not require the 160 switch to support the ATM control component defined by the ITU and 161 ATM Forum (e.g., UNI, PNNI). An ATM-LSR may optionally respond to OAM 162 cells. 164 5. Hybrid Switches (Ships in the Night) 166 The existence of the label switching control component on an ATM 167 switch does not preclude the ability to support the ATM control 168 component defined by the ITU and ATM Forum on the same switch and the 169 same interfaces. The two control components, label switching and the 170 ITU/ATM Forum defined, would operate independently. 172 Definition of how such a device operates is beyond the scope of this 173 document. However, only a small amount of information needs to be 174 consistent between the two control components, such as the portions 175 of the VPI/VCI space which are available to each component. 177 6. Use of VPI/VCIs 179 Label switching is accomplished by associating labels with routes and 180 using the label value to forward packets, including determining the 181 value of any replacement label. See [1] for further details. In an 182 ATM-LSR, the label is carried in the VPI and/or VCI field. Just as in 183 conventional ATM, for a cell arriving at an interface, the VPI/VCI is 184 looked up, replaced, and the cell is switched. 186 ATM-LSRs may be connected by ATM virtual paths to enable 187 interconnection of ATM-LSRs over a cloud of conventional ATM 188 switches. In this case, the label is carried in the VCI field. 190 For two connected ATM-LSRs, a connection must be available for LDP. 191 The default is for this connection to be on VPI 0, VCI 32. For ATM- 192 LSRs connected by a VPI of value x, the default for the LDP 193 connection is VPI x, VCI 32. Additionally, for all VPI values, VCIs 0 194 - 32 are not used as labels. 196 With the exception of these reserved values, the VPI/VCI values used 197 in the two directions of the link may be treated as independent 198 spaces. 200 The allowable ranges of VPI/VCIs are always communicated through LDP. 201 If more than one VPI is used for label switching, the allowable range 202 of VCIs may be different for each VPI, and each range is communicated 203 through LDP. 205 7. Label Allocation and Maintenance Procedures 207 ATM-LSRs use the downstream-on-demand allocation mechanism described 208 in [1]. The procedures for label allocation depend on whether the 209 switches support VC-merge or not. We therefore describe the two 210 scenarios in turn. We begin by describing the behavior of members of 211 the Edge Set of an ATM-LSR cloud; these edge LSRs are not themselves 212 ATM-LSRs, and their behavior is the same whether the cloud contains 213 VC-merge capable LSRs or not. 215 7.1. Edge LSR Behavior 217 Consider a member of the Edge Set of an ATM-LSR cloud. Assume that, 218 as a result of its routing calculations, it selects an ATM-LSR as the 219 next hop of a certain route, and that the next hop is reachable via a 220 LC-ATM interface. The Edge LSR uses LDP's binding request message to 221 request a label binding from the next hop. The hop count field in 222 the request is set to 1. Once the Edge LSR receives the label 223 binding information, the label is used as an outgoing label. The 224 binding received by the edge LSR may contain a hop count, which 225 represents the number of hops a packet will take to cross the ATM-LSR 226 cloud when using this label. The edge LSR may either 228 - use this hop count to decrement the TTL of packets before 229 transmitting them over the cloud 231 - decrement the TTL of packets by one before transmitting them 232 over the cloud. 234 The choice between these two options should be made based on local 235 configuration. 237 When a member of the Edge Set of the ATM-LSR cloud receives a label 238 binding request from an ATM-LSR, it allocates a label, creates a new 239 entry in its Label Information Base (LIB), places that label in the 240 incoming label component of the entry, and returns (via LDP) a 241 binding containing the allocated label back to the peer that 242 originated the request. It sets the hop count in the binding to 1. 244 When a routing calculation causes an Edge LSR to change the next hop 245 for a route, and the former next hop was in the ATM-LSR cloud, the 246 Edge LSR should notify the former next hop (via LDP) that the label 247 binding associated with the route is no longer needed. 249 7.2. Conventional ATM Switches (non-VC-merge) 251 When an ATM-LSR receives (via LDP) a label binding request for a 252 certain route from a peer connected to the ATM-LSR over a LC-ATM 253 interface, the ATM-LSR takes the following actions: 255 - it allocates a label, creates a new entry in its Label 256 Information Base (LIB), and places that label in the incoming 257 label component of the entry; 259 - it requests (via LDP) a label binding from the next hop for 260 that route; 262 - it returns (via LDP) a binding containing the allocated 263 incoming label back to the peer that originated the request. 265 The hop count field in the request that the ATM-LSR sends (to the 266 next hop LSR) is set to the hop count field in the request that it 267 received from the upstream LSR plus one. Once the ATM-LSR receives 268 the binding from the next hop, it places the label from the binding 269 into the outgoing label component of the LIB entry. 271 The ATM-LSR may choose to wait for the request to be satisfied from 272 downstream before returning the binding upstream (a "conservative" 273 approach). In this case, the ATM-LSR increments the hop count it 274 received from downstream and uses this value in the binding it 275 returns upstream. If the value of the hop count equals MAX_HOP_COUNT 276 the ATM-LSR should notify the upstream neighbor that it could not 277 satisfy the binding request. 279 Alternatively, the ATM-LSR may return the binding upstream without 280 waiting for a binding from downstream (an "optimistic" approach). In 281 this case, it uses a reserved value for hop count in the binding, 282 indicating that it is unknown. The correct value for hop count will 283 be returned later, as described below. 285 Since both the conservative and the optimistic approaches have 286 advantages and disadvantages, this is left as an implementation 287 choice. 289 Note that an ATM-LSR, or a member of the edge set of an ATM-LSR 290 cloud, may receive multiple binding requests for the same route from 291 the same ATM-LSR. It must generate a new binding for each request 292 (assuming adequate resources to do so), and retain any existing 293 binding(s). For each request received, an ATM-LSR should also 294 generate a new binding request toward the next hop for the route. 296 When a routing calculation causes an ATM-LSR to change the next hop 297 for a route, the ATM-LSR should notify the former next hop (via LDP) 298 that the label binding associated with the route is no longer needed. 300 When a LSR receives a notification that a particular label binding is 301 no longer needed, the LSR may deallocate the label associated with 302 the binding, and destroy the binding. In the case where an ATM-LSR 303 receives such notification and destroys the binding, it should notify 304 the next hop for the route that the label binding is no longer 305 needed. If a LSR does not destroy the binding, it may re-use the 306 binding only if it receives a request for the same route with the 307 same hop count as the request that originally caused the binding to 308 be created. 310 When a route changes, the label bindings are re-established from the 311 point where the route diverges from the previous route. LSRs 312 upstream of that point are (with one exception, noted below) 313 oblivious to the change. Whenever a LSR changes its next hop for a 314 particular route, if the new next hop is an ATM-LSR or a member of 315 the edge set reachable via a LC-ATM interface, then for each entry in 316 its LIB associated with the route the LSR should request (via LDP) a 317 binding from the new next hop. 319 When an ATM-LSR receives a label binding from a downstream neighbor, 320 it may already have provided a corresponding label binding for this 321 route to an upstream neighbor, either because it is operating 322 optimistically or because the new binding from downstream is the 323 result of a routing change. In this case, it should extract the hop 324 count from the new binding and increment it by one. If the new hop 325 count is different from that which was previously conveyed to the 326 upstream neighbor (including the case where the upstream neighbor was 327 given the value `unknown') the ATM-LSR must notify the upstream 328 neighbor of the change. Each ATM-LSR in turn increments the hop count 329 and passes it upstream until it reaches the ingress Edge LSR. If at 330 any point the value of the hop count equals MAX_HOP_COUNT, the ATM- 331 LSR should withdraw the binding from the upstream neighbor. 333 Whenever an ATM-LSR originates a label binding request to its next 334 hop LSR as a result of receiving a label binding request from another 335 (upstream) LSR, and the request to the next hop LSR is not satisfied, 336 the ATM-LSR should destroy the binding created in response to the 337 received request, and notify the requester (via LDP). 339 If an ATM-LSR receives a binding request containing a hop count that 340 equals MAX_HOP_COUNT, no binding should be established and an error 341 message should be returned to the requester. 343 When a LSR determines that it has lost its LDP session with another 344 LSR, the following actions are taken. Any binding information 345 learned via this connection must be discarded. For any label 346 bindings that were created as a result of receiving label binding 347 requests from the peer, the LSR may destroy these bindings (and 348 deallocate labels associated with these binding). 350 An ATM-LSR should use `split-horizon' when it satisfies binding 351 requests from its neighbors. That is, if it receives a request for a 352 binding to a particular route and the LSR making that request is, 353 according to this ATM-LSR, the next hop for that route, it should not 354 return a binding for that route. 356 Note that it is not possible for complete label-switched looping 357 paths to be established when VC merge is not supported. The worst 358 case behavior (possible only if optimistic mode is used) is that 359 binding request messages could travel in a loop, setting up a label 360 switched spiral, which would then be torn down when the hop count in 361 the binding request reached MAX_HOP_COUNT. In conservative mode, no 362 label switched path can be set up unless the path exits the ATM-LSR 363 cloud. 365 7.3. VC-merge-capable ATM Switches 367 Relatively minor changes are needed to accommodate ATM-LSRs which 368 support VC-merge. The primary difference is that a VC-merge-capable 369 ATM-LSR needs only one outgoing label per route, even if multiple 370 requests for label bindings to that route are received from upstream 371 neighbors. 373 When a VC-merge-capable ATM-LSR receives a binding request from an 374 upstream LSR for a certain route, and it does not already have an 375 outgoing label binding for that route, it issues a bind request to 376 its next hop just as before. If, however, it already has an outgoing 377 label binding for that route, it does not need to issue a downstream 378 binding request. Instead, it creates a new LIB entry, allocates an 379 incoming label for that entry and returns that label in a binding to 380 the upstream requester, and uses the existing outgoing label for the 381 outgoing label entry in the LIB. It also takes the hop count that was 382 provided with the label binding it received from downstream, 383 increments it by one, and uses this value in the binding that it 384 sends to the upstream requester. 386 Note that, just like conventional ATM-LSRs and members of the edge 387 set of the ATM-LSR cloud, a VC-merge-capable ATM-LSR must issue a new 388 binding every time it receives a request from upstream, since there 389 may be switches upstream which do not support VC-merge. However, it 390 only needs to issue a corresponding binding request downstream if it 391 does not already have a label binding for the appropriate route. 393 When a change in the routing table of a VC-merge-capable ATM-LSR 394 causes it to select a new next hop for one of its routes, it releases 395 the binding for that route from the former next hop and requests a 396 new binding from the new next hop. If the new binding contains a hop 397 count that differs from that which was received in the old binding, 398 then the ATM-LSR must take the new hop count, increment it by one, 399 and notify any upstream neighbors who have label bindings for this 400 route of the new value. Just as with conventional ATM-LSRs, this 401 enables the new hop count to propagate back towards the ingress of 402 the ATM-LSR cloud. If at any point the hop count reaches 403 MAX_HOP_COUNT, then the label bindings for this route must be 404 withdrawn from all upstream neighbors to whom a binding was 405 previously provided. This ensures that any loops caused by routing 406 transients will be detected and broken. 408 While the choice between "conservative" and "optimistic" binding 409 remains for VC-merge capable LSRs, the advantages of the conservative 410 approach are greater in this case. This is because: 412 - the optimistic mode permits the formation of a looping switched 413 path which will not be removed until routing changes to remove the 414 loop; 416 - the conservative mode does not have the same drawbacks when VC 417 merge is supported, since it will often be possible to obtain a 418 binding by merging into an existing path, without waiting for 419 binding requests and responses to propagate across the entire 420 ATM-LSR cloud. 422 The use of conservative mode along with hop counts in the binding 423 requests and responses ensures that stable looping paths cannot be 424 set up. Implementations may choose to support the diffusion 425 algorithm described in [1] for stronger protection against transient 426 loops. 428 7.4. Efficient use of label space 430 The above discussion assumes that an edge LSR will request one label 431 for each prefix in its routing table that has a next hop in the ATM- 432 LSR cloud. In fact, it is possible to significantly reduce the number 433 of labels needed by having the edge LSR request instead one label for 434 several routes. Use of many-to-one mappings between routes (address 435 prefixes) and labels using the notion of Forwarding Equivalence 436 Classes (as described in [1]) provides a mechanism to conserve the 437 number of labels. 439 8. Encapsulation 441 By default, all labelled packets should be transmitted with the 442 generic label encapsulation, as defined in [3]. A packet thus 443 encapsulated is then directly encapsulated within an AAL5 frame. 444 Since the value at the top of the label stack is determined from the 445 VCI and/or VPI fields, the top label in the label encapsulation is 446 ignored. Other fields in the top stack entry, such as TTL and COS, 447 may be used by LSRs at the edges of the ATM-LSR cloud that are able 448 to examine that entry. 450 For systems which are using only one level of labelling, it is 451 theoretically possible to use a null encapsulation. In this case, IP 452 packets are carried directly inside AAL5 frames, as in the null 453 encapsulation of RFC 1483. However, all ATM-LSRs in a cloud must be 454 configured to use this encapsulation to avoid reassembly and re- 455 encapsulation in the middle of the cloud. 457 The initial LDP connection, described in Section 5, uses the LLC/SNAP 458 encapsulation, as defined in Section 4.1 of RFC1483. This same VCI 459 (with the LLC/SNAP encapsulation) may be used to exchange Network 460 Layer routing information as well. 462 LDP may be used to advertise additional VPI/VCIs to carry control 463 information or non-labelled packets. These may use either the null 464 encapsulation, as defined in Section 5.1 of RFC1483, or the LLC/SNAP 465 encapsulation, as defined in Section 4.1 of RFC1483. 467 9. Security Considerations 469 Security considerations are not addressed in this document. 471 10. Intellectual Property Considerations 473 Cisco Systems may seek patent or other intellectual property 474 protection for some or all of the technologies disclosed in this 475 document. If any standards arising from this document are or become 476 protected by one or more patents assigned to Cisco Systems, Cisco 477 intends to disclose those patents and license them under openly 478 specified and non-discriminatory terms, for no fee. 480 11. References 482 [1] Rosen, E. et al. A Proposed Architecture for MPLS, Internet 483 Draft, draft-ietf-mpls-arch-00.txt, August, 1997 485 [2] Doolan, P. et al. Tag Distribution Protocol, Internet Draft, 486 draft-doolan-tdp-spec-01.txt, May, 1997. 488 [3] Rosen, E. et al. Label Switching: Label Stack Encodings, Internet 489 Draft, draft-rosen-tag-stack-03.txt, July, 1997. 491 [4] Feldman, N., and Viswanathan, A. ARIS Specification, Internet 492 Draft, draft-feldman-aris-spec-00.txt, March, 1997. 494 12. Acknowledgments 496 Significant contributions to this work have been made by Anthony 497 Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan 498 Littlewood and Dan Tappan. 500 13. Authors' Addresses 502 Bruce Davie 503 Cisco Systems, Inc. 504 250 Apollo Drive 505 Chelmsford, MA, 01824 507 E-mail: bsd@cisco.com 508 Paul Doolan 509 Ennovate Networks Inc. 510 330 Codman Hill Rd 511 Boxborough, MA 01719 513 E-mail: pdoolan@ennovatenetworks.com 515 Jeremy Lawrence 516 Cisco Systems, Inc. 517 1400 Parkmoor Ave. 518 San Jose, CA, 95126 520 E-mail: jlawrenc@cisco.com 522 Keith McCloghrie 523 Cisco Systems, Inc. 524 170 Tasman Drive 525 San Jose, CA, 95134 527 E-mail: kzm@cisco.com 529 Yakov Rekhter 530 Cisco Systems, Inc. 531 170 Tasman Drive 532 San Jose, CA, 95134 534 E-mail: yakov@cisco.com 536 Eric Rosen 537 Cisco Systems, Inc. 538 250 Apollo Drive 539 Chelmsford, MA, 01824 541 E-mail: erosen@cisco.com 543 George Swallow 544 Cisco Systems, Inc. 545 250 Apollo Drive 546 Chelmsford, MA, 01824 548 E-mail: swallow@cisco.com