idnits 2.17.1 draft-shah-ppvpn-arp-mediation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8.0 Security Considerations' ) ** 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 an Authors' Addresses Section. ** The abstract seems to contain references ([L2VPN-FRM], [PWE3-CONTROL], [RFC1256], [L2VPN-Signaling], [L2VPN-Kompella], [INVARP], [PROXY-ARP], [L2VPN-REQ], [SHAH-CONTROL], [PPP-IPCP], [PWE3-Control], [ARP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'PWE3-Control' on line 277 looks like a reference -- Missing reference section? 'PPP-IPCP' on line 463 looks like a reference -- Missing reference section? 'RFC 1256' on line 222 looks like a reference -- Missing reference section? 'PWE3-CONTROL' on line 469 looks like a reference -- Missing reference section? 'SHAH-CONTROL' on line 477 looks like a reference -- Missing reference section? 'ARP' on line 448 looks like a reference -- Missing reference section? 'INVARP' on line 452 looks like a reference -- Missing reference section? 'L2VPN-REQ' on line 456 looks like a reference -- Missing reference section? 'L2VPN-FRM' on line 460 looks like a reference -- Missing reference section? 'L2VPN-Kompella' on line 466 looks like a reference -- Missing reference section? 'L2VPN-Signaling' on line 472 looks like a reference -- Missing reference section? 'PROXY-ARP' on line 475 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPVPN Working Group H. Shah Ciena Networks 2 Internet Draft E. Rosen Cisco Systems 3 W. Augustyn consultant 4 June 2003 G. Heron PacketExchange,Ltd 5 Expires: December 2003 T. Smith Laurel Networks 6 A. Moranganti ADC Telecom 7 S. Khandekar Timetra Networks 8 V. Kompella Timetra Networks 9 A. Malis Vivace Networks 10 S. Wright Bell South 11 V. Radoaca Nortel Networks 12 A. Vishwanathan Force10 Networks 14 ARP Mediation for IP Interworking of Layer 2 VPN 16 draft-shah-ppvpn-arp-mediation-02.txt 18 Status of this memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 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 The VPWS service [L2VPN Framework] provides point-to-point 41 connections between pairs of Customer Edge (CE) devices. It does so 42 by binding two Attachment Circuits (each connecting a CE device with 43 a Provider Edge, PE, device) to a Pseudowire (connecting the two 44 PEs). In general, the Attachment Circuits must be of the same 45 technology (e.g., both ethernet, both ATM), and the Pseudowire must 46 carry the frames of that technology. However, if it is known that 47 the frames' payload consists solely of IP datagrams, it is possible 48 to provide a point-to-point connection in which the Pseudowire 49 connects Attachment Circuits of different technologies. This 50 requires the PEs to perform a function known as "ARP Mediation". 51 This document specifies the ARP Mediation function, and specifies 52 the encapsulation used to carry the IP datagrams on the Pseudowires 53 when ARP mediation is used. 55 1.0 Introduction 57 Layer 2 Virtual Private Networks (L2VPN) are constructed with the 58 use of a Service Provider IP backbone but are presented to the 59 Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs 60 can carry any Layer 3 protocol, but in many cases, the only Layer 3 61 protocol is IP. Thus it makes sense to consider procedures that are 62 either optimized for IP or are outright dedicated to IP traffic 63 only. 65 In a typical implementation, illustrated in the diagram below, the 66 CE devices are connected to the Provider Edge (PE) devices via 67 Attachment Circuits (AC). The ACs are Layer 2 links. In a pure 68 L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both 69 ACs would have to be of the same type (i.e., both ethernet, both FR, 70 etc.). However, if it is known that only IP traffic will be carried, 71 the ACs can be of different technologies, provided that the PEs 72 provide the appropriate procedures to allow the proper transfer of 73 IP packets. 75 +-----+ 76 +--------------------| CE3 | 77 | +-----+ 78 +-----+ 79 ........| PE3 |......... 80 . +-----+ . 81 . | . 82 . | . 83 +-----+ AC1 +-----+ Service +-----+ AC2 +-----+ 84 | CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 | 85 +-----+ +-----+ Backbone +-----+ +-----+ 86 . . 87 ........................ 89 A CE, which is connected via a given type of AC, may use an IP 90 Address Resolution procedure that is specific to that type of AC. 91 For example, an ethernet-attached CE would use ARP, a FR-attached CE 92 might use Inverse ARP. If we are to allow the two CEs to have a 93 layer 2 connection between them, even though each AC uses a 94 different layer 2 technology, the PEs must intercept and "mediate" 95 the technology-specific address resolution procedures. 97 In this draft, we specify the procedures which the PEs must 98 implement in order to mediate the IP address resolution mechanism. 99 We call these procedures "ARP Mediation". 101 Consider a Virtual Private Wire Service (VPWS) constructed between 102 CE1 and CE2 in the diagram above. If AC1 and AC2 are of different 103 technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), then 104 ARP requests coming from CE1 cannot be passed transparently to CE2. 105 PE1 must interpret the meaning of the ARP requests and mediate the 106 necessary information with PE2 before responding. 108 2.0 ARP Mediation (AM) function 110 The ARP Mediation (AM) function is an element of a PE node operation 111 that deals with the IP address resolution for CE devices connected 112 via a L2VPN. By placing this function in the PE node, ARP Mediation 113 can be made completely transparent to the CE devices. 115 For a given point-to-point connection between a pair of CEs, a PE 116 must perform three logical steps as part of the ARP Mediation 117 procedure: 119 1. Discover the IP addresses of the locally attached CE device 120 2. Distribute those IP Addresses to the remote PE 121 3. Notify the locally attached CE of the remote CE's IP address. 123 This information is gathered using the mechanisms described in the 124 following sections. 126 3.0 IP Layer 2 Interworking Circuits 128 The IP Layer 2 Interworking Circuits refer to Pseudowires that carry 129 IP datagram as the payload. At ingress, data link header of an IP 130 frame is removed and dispatched over the Pseudowire with or without 131 the optional control word. At the egress, PE encapsulates the IP 132 packet with the data link header used on the local Attachment 133 Circuit. 135 The use of this encapsulation is determined by the exchange of value 136 0x000B as the VC type during Pseudowire establishment as described 137 in [PWE3-Control]. 139 4.0 Discovery of IP Addresses of Locally Attached CE Device 141 An IP Layer 2 Interworking Circuit enters monitoring state right 142 after the configuration. During this state it performs two 143 functions. 144 . Discovery of locally attached CE IP device 145 . Establishment of the PW 147 The establishment of PW occurs independently from local CE IP 148 address discovery. During the period when (bi-directional) PW has 149 been established but local CE IP device has not been detected, only 150 datagrams inside of broadcast/multicast frames are propagated; IP 151 datagrams inside unicast frames are dropped. The IP datagrams from 152 unicast frames flow only when IP end systems on both Attachment 153 Circuits have been discovered, notified and proxy functions have 154 completed. 156 4.1 Monitoring Local Traffic 158 The PE devices may learn the IP addresses of the locally attached 159 CEs from any IP traffic, such as multicast/broadcast packets, that 160 CE may generate irrespective of reacting to specific address 161 resolution queries described below. 163 4.2 CE Devices Using ARP 165 If a CE device uses ARP to determine the IP address of its neighbor, 166 the PE processes the ARP requests for the stated locally attached 167 circuit and responds with ARP replies containing the remote CE's IP 168 address, if the address is known. If the PE does not yet have the 169 remote CE's IP address, it does not respond, but notes the IP 170 address of the local CE and the circuit information, including 171 related MAC address. Subsequently, when the IP address of the remote 172 CE becomes available, the PE may initiate the ARP response as a 173 means to notify the local CE, the IP address of the remote CE. 175 This is a typical operation for Ethernet attachment circuits. It is 176 important to note that IP L2 Interworking circuit function is 177 restricted to only one end station per Ethernet Attachment Circuit. 179 The PE may periodically generate ARP request messages to the CE's IP 180 address as a means to verify the continued existence of the address 181 and its binding to the stated MAC address. The absence of a response 182 from the CE device for a given number of retries could be used as a 183 cause for a withdrawal of the IP address advertisement to the remote 184 PE and entering into the address resolution phase to rediscover the 185 attached CE's IP address. Note that such "heartbeat" scheme is 186 needed only for broadcast links, as a loss of CE may otherwise be 187 undetectable. 189 4.3 CE Devices Using Inverse ARP 191 If a CE device uses Inverse ARP to determine the IP address of its 192 neighbor, the attached PE processes the Inverse ARP request for 193 stated circuit and responds with an Inverse ARP reply containing the 194 remote CE's IP address, if the address is known. If the PE does not 195 yet have the remote CE's IP address, it does not respond, but notes 196 the IP address of the local CE and the circuit information. 197 Subsequently, when the IP address of the remote CE becomes 198 available, the PE may initiate the Inverse ARP request as a means to 199 notify the local CE, the IP address of the remote CE. 201 This is a typical operation for Frame Relay and ATM attachment 202 circuits. In the cases where the CE does not use Inverse ARP, PE 203 could still discover the CE as described in section 4.1 and 4.5. 205 4.4 CE Devices Using PPP 207 If a CE device uses PPP to determine the IP address of its neighbor, 208 a PE takes part in the IPCP [PPP-IPCP] exchange and supplies the IP 209 address of the remote CE if the address is known. If the PE does not 210 have the remote CE's IP address, it does not respond to the local 211 CE's IPCP request but simply notes its IP address. Subsequently, 212 when the IP address of the remote CE becomes available, the PE 213 generates IPCP Configure-Request to the local CE. 215 The PE must deny configurations such as header compression and 216 encryptions in the NCP packets with such options. 218 4.5 Proactive method 220 In order to learn the IP address of the CE device for a given 221 Attachment Circuit, the PE device may execute Router Discovery 222 Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - 223 router solicitation) message is sent using a source IP address of 224 zero. The IP address of the CE device is extracted from the Router 225 Discovery Response (ICMP - router advertisement) message from the 226 CE. 228 The use of the router discovery mechanism by the PE is optional. 230 5.0 IP Address Distribution Between PE 232 5.1 When To Distribute IP Address 234 A PE device advertises the IP address of the attached CE only when 235 the encapsulation type of the Pseudowire is IP L2 interworking. It 236 is quite possible that the IP address of a CE device is not 237 available at the time the PW labels are advertised. For example, in 238 Frame Relay the CE device dispatches inverse ARP request only when 239 the DLCI is active; if the PE signals the DLCI to be active only 240 when it has received the IP address along with the VC-FEC from the 241 remote PE, a chicken and egg situation arises. In order to avoid 242 such problems, the PE must be prepared to advertise the VC-FEC 243 before the CE's IP address is known. When the IP address of the CE 244 device does become available, the PE re-advertises the VC-FEC along 245 with the IP. 247 Similarly, if the PE detects invalidation of the CE's IP address (by 248 methods described above) the PE must re-advertise the VC-FEC with 249 null IP address to denote the withdrawal of the CE's IP address. The 250 receiving PE then waits for the notification of remote IP address. 251 During this period, propagation of unicast IP traffic is suspended 252 while continuing to let multicast IP traffic flow. 254 If two CE devices are locally attached to the PE where, one CE is 255 connected to an Ethernet data link and the other to a Frame Relay 256 interface, for example, the IP addresses are learned in the same 257 manner described above. However, since the CE devices are local, the 258 distribution of IP addresses for these CE devices is a local step. 260 5.2 LDP Based Distribution 262 The [PWE3-CONTROL] uses Label Distribution Protocol (LDP) transport 263 to exchange VC-FEC in the Label Mapping message in a downstream 264 unsolicited mode. The VC-FEC comes in two flavors; Pwid and 265 Generalized ID FEC elements and shares some fields that are common 266 between them. The discussions below refer to these common fields for 267 IP L2 Interworking Circuits. 269 The IP L2 Interworking uses IP datagram as payload over the 270 Pseduowire. The use of such encapsulation is identified by VC type 271 field of the VC-FEC as the value 0x000B [PWE3-Control]. 273 In addition, this document defines an IP address TLV that must be 274 included in the optional TLV field of the Label Mapping message when 275 advertising VC-FEC for the IP L2 Interworking Circuit. Such use of 276 optional TLV in the Label Mapping message to extend the attributes 277 of the VC-FEC has also been specified in the [PWE3-Control]. 279 When processing a received VC-FEC, the PE matches the VC-Id and VC- 280 type with the locally configured VC-Id to determine if the VC-FEC is 281 of type IP L2 Interworking. If matched, it further checks the 282 presence of IP address TLV. If an IP address TLV is absent, a Label 283 Release message is issued to reject the PW establishment. 285 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |1|0| IP address TLV (TBD) | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | IP Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The Length field is defined as the length of the IP address and is 294 set to value 4. 296 The IP address field is set to value null to denote that advertising 297 PE has not learned the IP address of his local CE device. The non- 298 zero value of the IP address field denotes IP address of advertising 299 PE�s attached CE device. 301 The IP address TLV is also used in the LDP notification message 302 along with the VC-FEC. The IP address TLV in Notification message is 303 used as an update mechanism to notify the changes in the IP address 304 of the local CE device as described in [SHAH-CONTROL]. 306 5.3 Out-of-band Distribution, Manual Configuration 308 In some cases, it may not be possible to deduce the IP addresses 309 from the VPN traffic nor induce remote PEs to supply the necessary 310 information on demand. For those cases, out-of-band methods, such 311 as manual configuration, could be used. The use of these types of 312 methods is useful only to handle corner cases. 314 6.0 How CE Learns The Remote CE's IP address 316 Once the PE has received the remote CE's IP address information from 317 the remote PE, it will either initiate an address resolution request 318 or respond to an outstanding request from the attached CE device. 320 6.1 CE Devices Using ARP 322 When the PE learns the remote CE's IP address as described in 323 section 5.1 and 5.2, it may or may not know the local CE's IP 324 address. If the local CE's IP address is not known, the PE must wait 325 until it is acquired through one of the methods described in 326 sections 4.1, 4.3 and 4.5. If the IP address of the local CE is 327 known, the PE may choose to generate an unsolicited ARP message to 328 notify the local CE about the binding of the remote CE's IP address 329 with the PE's own MAC address. 331 When the local CE generates an ARP request, the PE must proxy the 332 ARP response using its own MAC address as the source hardware 333 address and remote CE's IP address as the source protocol address. 334 The PE must respond only to those ARP requests whose destination 335 protocol address matches the remote CE's IP address. 337 6.2 CE Devices Using Inverse ARP 339 When the PE learns the remote CE's IP address, it should generate an 340 Inverse ARP request. In case, the local circuit requires activation 341 e.g. Frame Relay, PE should activate it first before sending Inverse 342 ARP request. It should be noted, that PE might never receive the 343 response to its own request, nor see any CE's Inverse ARP request in 344 cases where CE is pre-configured with remote CE IP address or the 345 use of Inverse ARP is not enabled. In either case CE has used other 346 means to learn the IP address of his neighbor. 348 6.3 CE Devices Using PPP 350 When the PE learns the remote CE's IP address, it must initiate the 351 Configure-Request using the remote CE's IP address or respond to 352 pending Configure-Request from the local CE. As noted earlier, all 353 other configuration options related to compression, encryptions, 354 etc., should be rejected. 356 7.0 Use of IGPs with IP L2 Interworking L2VPNs 358 In an IP L2 interworking L2VPN, when an IGP on a CE connected to a 359 broadcast link is cross-connected with an IGP on a CE connected to a 360 point-to-point link, there are routing protocol related issues that 361 must be addressed. The link state routing protocols are cognizant of 362 the underlying link characteristics and behave accordingly when 363 establishing neighbor adjacencies, representing the network 364 topology, and passing protocol packets. 366 7.1 OSPF 368 The OSPF protocol treats broadcast link type with a special 369 procedure that engages in neighbor discovery to elect a designated 370 and a backup designated router (DR and BDR respectively) with which 371 it forms adjacencies. However, these procedures are neither 372 applicable nor understood by OSPF running on a point-to-point link. 373 By cross-connecting two neighbors with disparate link types, an IP 374 L2 interworking L2VPN has the potential to experience connectivity 375 issues. 377 Additionally, the link type specified in the router LSA will not 378 match for two routers that are supposedly sharing the same link 379 type. Finally, each OSPF router generates network LSAs when 380 connected to a broadcast link such as Ethernet, receipt of which by 381 an OSPF router on the point-to-point link further adds to the 382 confusion. 384 Fortunately, the OSPF protocol provides a configuration option 385 (ospfIfType), whereby OSPF will treat the underlying physical 386 broadcast link as a point-to-point link. 388 It is strongly recommended that all OSPF protocols on CE devices 389 connected to Ethernet interfaces use this configuration option when 390 attached to a PE that is participating in an IP L2 Interworking VPN. 392 7.2 IS-IS 394 The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC 395 address and the IP address of the intermediate system (i.e., CE 396 device) when attached to Ethernet links. The CE device expects its 397 neighbor to insert its own MAC and IP address in the response. If 398 the neighbor is connected via a point-to-point link type, the LAN 399 Hello PDU will be silently discarded. Similarly, Hello PDUs on the 400 point-to-point link do not contain any MAC address, which will 401 confuse a neighbor on an Ethernet link, if these two neighbors were 402 cross-connected via above described mechanisms. 404 Thus, use of the IS-IS protocol on CE devices presents problems when 405 interconnected by disparate data link types in an IP L2 Interworking 406 VPN environment. There are some mechanisms defined in draft-ietf- 407 isis-igp-p2p-over-lan-00.txt to accommodate point-to-point behavior 408 over broadcast networks. The feasibility of such techniques to solve 409 this problem is under review. 411 It is important to note that the use of the IS-IS protocol in 412 enterprise networks (i.e., CE routers) is less common. The IS-IS 413 related difficulties for IP L2 Interworking VPNs, hence are 414 minimized. 416 7.3 RIP 418 RIP protocol broadcasts RIP advertisements every 30 seconds. If the 419 group/broadcast address snooping mechanism is used as described 420 above, the attached PE can learn the advertising (CE) router's IP 421 address from the IP header of the advertisement. No special 422 configuration is required for RIP in this type of Layer 2 IP 423 Interworking L2VPN. 425 8.0 Security Considerations 427 The security aspects of this solution will be discussed at a later 428 time. 430 9.0 Acknowledgements 432 The authors would like to thank Prabhu Kavi, Bruce Lasley and other 433 folks who participated in the discussions related to this draft. 435 10.0 Intellectual Property Considerations 437 Tenor/Enterasys Networks may seek patent or other intellectual 438 property protection for some of all of the technologies disclosed in 439 this document. If any standards arising from this document are or 440 become protected by one or more patents assigned to Tenor/Enterasys 441 Networks, Tenor/Enterasys intends to disclose those patents and 442 license them on reasonable and non-discriminatory terms. 444 11.0 References 446 11.1 Normative References 448 [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution 449 Protocol: Or Converting Network Protocol Addresses to 48.bit 450 Ethernet Addresses for Transmission on Ethernet Hardware". 452 [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution 453 Protocol". 454 11.2 Informative References 456 [L2VPN-REQ] W. Augustyn et al., "Service Requirements for Layer 2 457 Provider Provisioned Virtual Private Networks", February 2003, work 458 in progress. 460 [L2VPN-FRM] L. Andersson et al., "L2VPN Framework", January 2003, 461 work in progress. 463 [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol Control 464 Protocol (IPCP)". 466 [L2VPN-Kompella] K. Kompella et al., "Layer 2 VPNs Over Tunnels", 467 June 2002, work in progress. 469 [PWE3-CONTROL] L. Martini et al., "Transport of Layer 2 Frames Over 470 MPLS", November 2002, work in progress. 472 [L2VPN-Signaling] E. Rosen et al., "LDP-based Signaling for L2VPNs", 473 September 2002, work in progress. 475 [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". 477 [SHAH-CONTROL] H. Shah et al., "Dynamic Parameters Signaling for 478 MPLS-based Pseudowires", June 2003, work in progress 480 12.0 Authors' Addresses 482 Himanshu Shah 483 35 Nagog Park, 484 Acton, MA 01720 485 Email: hshah@ciena.com 487 Eric Rosen 488 Cisco Systems 489 1414 Massachusetts Avenue, 490 Boxborough, MA 01719 491 Email: erosen@cisco.com 493 Waldemar Augustyn 494 Email: waldemar@nxp.com 496 Giles Heron 497 PacketExchange Ltd. 498 The Truman Brewery 499 91 Brick Lane 500 LONDON E1 6QL 501 United Kingdom 502 Email: giles@packetexchange.net 503 Sunil Khandekar and Vach Kompella 504 TiMetra Networks 505 274 Ferguson Dr. 506 Mountain View, CA 94043 507 Email: sunil@timetra.com 508 Email: vkompella@timetra.com 510 Toby Smith 511 Laurel Networks 512 Omega Corporate Center 513 1300 Omega drive 514 Pittsburgh, PA 15205 515 Email: jsmith@laurelnetworks.com 517 Arun Vishwanathan 518 Force10 Networks 519 1440 McCarthy Blvd., 520 Milpitas, CA 95035 521 Email: arun@force10networks.com 523 Ashwin Moranganti 524 Appian Communications 525 35 Nagog Park, 526 Acton, MA 01720 527 Email: amoranganti@appiancom.com 529 Andrew G. Malis 530 Vivace Networks, Inc. 531 2730 Orchard Parkway 532 San Jose, CA 95134 533 Email: Andy.Malis@vivacenetworks.com 535 Steven Wright 536 Bell South Corp 537 Email: steven.wright@bellsouth.com 539 Vasile Radoaca 540 Nortel Networks 541 Email: vasile@nortelnetworks.com 543 Full Copyright Statement 545 "Copyright (C) The Internet Society (2001). All Rights Reserved. 546 This document and translations of it may be copied and furnished to 547 others, and derivative works that comment on or otherwise explain it 548 or assist in its implementation may be prepared, copied, published 549 and distributed, in whole or in part, without restriction of any 550 kind, provided that the above copyright notice and this paragraph 551 are included on all such copies and derivative works. However, this 552 document itself may not be modified in any way, such as by removing 553 the copyright notice or references to the Internet Society or other 554 Internet organizations, except as needed for the purpose of 555 developing Internet standards in which case the procedures for 556 copyrights defined in the Internet Standards process must be 557 followed, or as required to translate it into languages other than 558 English. 560 The limited permissions granted above are perpetual and will not be 561 revoked by the Internet Society or its successors or assigns. 563 This document and the information contained herein is provided on an 564 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 565 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 566 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 567 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 568 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."