idnits 2.17.1 draft-shah-l2vpn-arp-mediation-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: ---------------------------------------------------------------------------- == There are 6 instances 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. 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 305 looks like a reference -- Missing reference section? 'PPP-IPCP' on line 525 looks like a reference -- Missing reference section? 'RFC 1256' on line 255 looks like a reference -- Missing reference section? 'PWE3-CONTROL' on line 531 looks like a reference -- Missing reference section? 'SHAH-CONTROL' on line 539 looks like a reference -- Missing reference section? 'ARP' on line 509 looks like a reference -- Missing reference section? 'INVARP' on line 513 looks like a reference -- Missing reference section? 'L2VPN-REQ' on line 518 looks like a reference -- Missing reference section? 'L2VPN-FRM' on line 522 looks like a reference -- Missing reference section? 'L2VPN-Kompella' on line 528 looks like a reference -- Missing reference section? 'L2VPN-Signaling' on line 534 looks like a reference -- Missing reference section? 'PROXY-ARP' on line 537 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group H. Shah Ciena Networks 2 Internet Draft E. Rosen Cisco Systems 3 W. Augustyn consultant 4 October 2003 G. Heron PacketExchange,Ltd 5 Expires: April 2004 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-l2vpn-arp-mediation-03.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 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The VPWS service [L2VPN Framework] provides point-to-point 42 connections between pairs of Customer Edge (CE) devices. It does 43 so by binding two Attachment Circuits (each connecting a CE device 44 with a Provider Edge, PE, device) to a Pseudowire (connecting the 45 two PEs). In general, the Attachment Circuits must be of the same 46 technology (e.g., both ethernet, both ATM), and the Pseudowire must 47 carry the frames of that technology. However, if it is known that 48 the frames' payload consists solely of IP datagrams, it is possible 49 to provide a point-to-point connection in which the Pseudowire 50 connects Attachment Circuits of different technologies. This 51 requires the PEs to perform a function known as "ARP Mediation". 53 the encapsulation used to carry the IP datagrams on the Pseudowires 54 when ARP mediation is used. 56 Table of Contents 58 1 .0 Introduction..................................................2 59 2 .0 ARP Mediation (AM) function...................................3 60 3 .0 IP Layer 2 Interworking Circuits..............................4 61 4 .0 Discovery of IP Addresses of Locally Attached CE Device.......4 62 4.1 Monitoring Local Traffic.......................................4 63 4.2 CE Devices Using ARP...........................................4 64 4.3 CE Devices Using Inverse ARP...................................5 65 4.4 CE Devices Using PPP...........................................5 66 4.5 Proactive method..............................................65 67 5 .0 IP Address Distribution Between PE............................6 68 5.1 When To Distribute IP Address..................................6 69 5.2 LDP Based Distribution.........................................6 70 5.3 Out-of-band Distribution, Manual Configuration.................7 71 5.4 Single sided ARP mediation....................................87 72 6 .0 How CE Learns The Remote CE's IP address......................8 73 6.1 CE Devices Using ARP...........................................8 74 6.2 CE Devices Using Inverse ARP...................................9 75 6.3 CE Devices Using PPP...........................................9 76 7 .0 Use of IGPs with IP L2 Interworking L2VPNs....................9 77 7.1 OSPF...........................................................9 78 7.2 IS-IS.........................................................10 79 7.3 RIP...........................................................10 80 8 .0 Security Considerations....................................1110 81 9 .0 Acknowledgements...........................................1110 82 10 .0 References..................................................11 83 10.1 Normative References.........................................11 84 10.2 Informative References.......................................11 85 11 .0 Authors' Addresses........................................1211 87 1.0 Introduction 89 Layer 2 Virtual Private Networks (L2VPN) are constructed with the 90 use of a Service Provider IP backbone but are presented to the 91 Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs 92 can carry any Layer 3 protocol, but in many cases, the only Layer 3 93 protocol is IP. Thus it makes sense to consider procedures that 94 are either optimized for IP or are outright dedicated to IP traffic 95 only. 97 In a typical implementation, illustrated in the diagram below, the 98 CE devices are connected to the Provider Edge (PE) devices via 99 Attachment Circuits (AC). The ACs are Layer 2 links. In a pure 100 L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both 101 ACs would have to be of the same type (i.e., both ethernet, both 102 FR, etc.). However, if it is known that only IP traffic will be 103 carried, the ACs can be of different technologies, provided that 104 the PEs provide the appropriate procedures to allow the proper 105 transfer of IP packets. 107 +-----+ 108 +--------------------| CE3 | 109 | +-----+ 110 +-----+ 111 ........| PE3 |......... 112 . +-----+ . 113 . | . 114 . | . 115 +-----+ AC1 +-----+ Service +-----+ AC2 +-----+ 116 | CE1 |-----| PE1 |--- Provider ---| PE2 |-----| CE2 | 117 +-----+ +-----+ Backbone +-----+ +-----+ 118 . . 119 ........................ 121 A CE, which is connected via a given type of AC, may use an IP 122 Address Resolution procedure that is specific to that type of AC. 123 For example, an ethernet-attached CE would use ARP, a FR-attached 124 CE might use Inverse ARP. If we are to allow the two CEs to have a 125 layer 2 connection between them, even though each AC uses a 126 different layer 2 technology, the PEs must intercept and "mediate" 127 the technology-specific address resolution procedures. 129 In this draft, we specify the procedures which the PEs must 130 implement in order to mediate the IP address resolution mechanism. 131 We call these procedures "ARP Mediation". 133 Consider a Virtual Private Wire Service (VPWS) constructed between 134 CE1 and CE2 in the diagram above. If AC1 and AC2 are of different 135 technologies, e.g. AC1 is Ethernet and AC2 is Frame Relay (FR), 136 then ARP requests coming from CE1 cannot be passed transparently to 137 CE2. PE1 must interpret the meaning of the ARP requests and 138 mediate the necessary information with PE2 before responding. 140 2.0 ARP Mediation (AM) function 142 The ARP Mediation (AM) function is an element of a PE node 143 operation that deals with the IP address resolution for CE devices 144 connected via a L2VPN. By placing this function in the PE node, ARP 145 Mediation can be made completely transparent to the CE devices. 147 For a given point-to-point connection between a pair of CEs, a PE 148 must perform three logical steps as part of the ARP Mediation 149 procedure: 151 1. Discover the IP addresses of the locally attached CE device 152 2. Distribute those IP Addresses to the remote PE 153 3. Notify the locally attached CE of the remote CE's IP address. 155 This information is gathered using the mechanisms described in the 156 following sections. 158 3.0 IP Layer 2 Interworking Circuits 160 The IP Layer 2 Interworking Circuits refer to Pseudowires that 161 carry IP datagram as the payload. At ingress, data link header of 162 an IP frame is removed and dispatched over the Pseudowire with or 163 without the optional control word. At the egress, PE encapsulates 164 the IP packet with the data link header used on the local 165 Attachment Circuit. 167 The use of this encapsulation is determined by the exchange of 168 value 0x000B as the VC type during Pseudowire establishment as 169 described in [PWE3-Control]. 171 4.0 Discovery of IP Addresses of Locally Attached CE Device 173 An IP Layer 2 Interworking Circuit enters monitoring state right 174 after the configuration. During this state it performs two 175 functions. 176 . Discovery of locally attached CE IP device 177 . Establishment of the PW 179 The establishment of PW occurs independently from local CE IP 180 address discovery. During the period when (bi-directional) PW has 181 been established but local CE IP device has not been detected, only 182 datagrams inside of broadcast/multicast frames are propagated; IP 183 datagrams inside unicast frames are dropped. The IP datagrams from 184 unicast frames flow only when IP end systems on both Attachment 185 Circuits have been discovered, notified and proxy functions have 186 completed. 188 4.1 Monitoring Local Traffic 190 The PE devices may learn the IP addresses of the locally attached 191 CEs from any IP traffic, such as local multicast (e.g. 224.x.x.x) 192 packets, that CE may generate irrespective of reacting to specific 193 address resolution queries described below. 195 4.2 CE Devices Using ARP 197 If a CE device uses ARP to determine the IP address of its 198 neighbor, the PE processes the ARP requests for the stated locally 199 attached circuit and responds with ARP replies containing the 200 remote CE's IP address, if the address is known. If the PE does not 201 yet have the remote CE's IP address, it does not respond, but notes 202 the IP address of the local CE and the circuit information, 203 including related MAC address. Subsequently, when the IP address of 204 the remote CE becomes available, the PE may initiate the ARP 205 response as a means to notify the local CE, the IP address of the 206 remote CE. 208 This is a typical operation for Ethernet attachment circuits. It is 209 important to note that IP L2 Interworking circuit function is 210 restricted to only one end station per Ethernet Attachment Circuit. 212 The PE may periodically generate ARP request messages to the CE's 213 IP address as a means to verify the continued existence of the 214 address and its binding to the stated MAC address. The absence of a 215 response from the CE device for a given number of retries could be 216 used as a cause for a withdrawal of the IP address advertisement to 217 the remote PE and entering into the address resolution phase to 218 rediscover the attached CE's IP address. Note that such "heartbeat" 219 scheme is needed only for broadcast links, as a loss of CE may 220 otherwise be undetectable. 222 4.3 CE Devices Using Inverse ARP 224 If a CE device uses Inverse ARP to determine the IP address of its 225 neighbor, the attached PE processes the Inverse ARP request for 226 stated circuit and responds with an Inverse ARP reply containing 227 the remote CE's IP address, if the address is known. If the PE does 228 not yet have the remote CE's IP address, it does not respond, but 229 notes the IP address of the local CE and the circuit information. 230 Subsequently, when the IP address of the remote CE becomes 231 available, the PE may initiate the Inverse ARP request as a means 232 to notify the local CE, the IP address of the remote CE. 234 This is a typical operation for Frame Relay and ATM attachment 235 circuits. In the cases where the CE does not use Inverse ARP, PE 236 could still discover the CE as described in section 4.1 and 4.5. 238 4.4 CE Devices Using PPP 240 If a CE device uses PPP to determine the IP address of its 241 neighbor, a PE takes part in the IPCP [PPP-IPCP] exchange and 242 supplies the IP address of the remote CE if the address is known. 243 If the PE does not have the remote CE's IP address, it does not 244 respond to the local CE's IPCP request but simply notes its IP 245 address. Subsequently, when the IP address of the remote CE becomes 246 available, the PE generates IPCP Configure-Request to the local CE. 248 The PE must deny configurations such as header compression and 249 encryptions in the NCP packets with such options. 251 4.5 Proactive method 253 In order to learn the IP address of the CE device for a given 254 Attachment Circuit, the PE device may execute Router Discovery 255 Protocol [RFC 1256] whereby a Router Discovery Request (ICMP � 256 router solicitation) message is sent using a source IP address of 257 zero. The IP address of the CE device is extracted from the Router 258 Discovery Response (ICMP � router advertisement) message from the 259 CE. 261 The use of the router discovery mechanism by the PE is optional. 263 5.0 IP Address Distribution Between PE 265 5.1 When To Distribute IP Address 267 A PE device advertises the IP address of the attached CE only when 268 the encapsulation type of the Pseudowire is IP L2 interworking. It 269 is quite possible that the IP address of a CE device is not 270 available at the time the PW labels are advertised. For example, in 271 Frame Relay the CE device dispatches inverse ARP request only when 272 the DLCI is active; if the PE signals the DLCI to be active only 273 when it has received the IP address along with the VC-FEC from the 274 remote PE, a chicken and egg situation arises. In order to avoid 275 such problems, the PE must be prepared to advertise the VC-FEC 276 before the CE's IP address is known. When the IP address of the CE 277 device does become available, the PE re-advertises the VC-FEC along 278 with the IP. 280 Similarly, if the PE detects invalidation of the CE's IP address 281 (by methods described above) the PE must re-advertise the VC-FEC 282 with null IP address to denote the withdrawal of the CE's IP 283 address. The receiving PE then waits for the notification of remote 284 IP address. During this period, propagation of unicast IP traffic 285 is suspended while continuing to let multicast IP traffic flow. 287 If two CE devices are locally attached to the PE where, one CE is 288 connected to an Ethernet data link and the other to a Frame Relay 289 interface, for example, the IP addresses are learned in the same 290 manner described above. However, since the CE devices are local, 291 the distribution of IP addresses for these CE devices is a local 292 step. 294 5.2 LDP Based Distribution 296 The [PWE3-CONTROL] uses Label Distribution Protocol (LDP) transport 297 to exchange VC-FEC in the Label Mapping message in a downstream 298 unsolicited mode. The VC-FEC comes in two flavors; Pwid and 299 Generalized ID FEC elements and shares some fields that are common 300 between them. The discussions below refer to these common fields 301 for IP L2 Interworking Circuits. 303 The IP L2 Interworking uses IP datagram as payload over the 304 Pseduowire. The use of such encapsulation is identified by VC type 305 field of the VC-FEC as the value 0x000B [PWE3-Control]. 307 In addition, this document defines an IP address TLV that must be 308 included in the optional TLV field of the Label Mapping message 309 when advertising VC-FEC for the IP L2 Interworking Circuit. Such 310 use of optional TLV in the Label Mapping message to extend the 311 attributes of the VC-FEC has also been specified in the [PWE3- 312 Control]. 314 When processing a received VC-FEC, the PE matches the VC-Id and VC- 315 type with the locally configured VC-Id to determine if the VC-FEC 316 is of type IP L2 Interworking. If matched, it further checks the 317 presence of IP address TLV. If an IP address TLV is absent, a Label 318 Release message is issued to reject the PW establishment. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |1|0| IP address TLV (TBD) | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | IP Address | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 The Length field is defined as the length of the IP address and is 329 set to value 4. 331 The IP address field is set to value null to denote that 332 advertising PE has not learned the IP address of his local CE 333 device. The non-zero value of the IP address field denotes IP 334 address of advertising PE�s attached CE device. 336 The IP address TLV is also used in the LDP notification message 337 along with the VC-FEC. The IP address TLV in Notification message 338 is used as an update mechanism to notify the changes in the IP 339 address of the local CE device as described in [SHAH-CONTROL]. 341 5.3 Out-of-band Distribution, Manual Configuration 343 In some cases, it may not be possible to deduce the IP addresses 344 from the VPN traffic nor induce remote PEs to supply the necessary 345 information on demand. For those cases, out-of-band methods, such 346 as manual configuration, could be used. The use of these types of 347 methods is useful only to handle corner cases. 349 5.4 Single sided ARP mediation 351 In this configuration, one PE device treats the Pseudowire as a 352 homogeneous circuit, while the other PE device treats it as a 353 heterogenous circuit. For example, if PE1 is connected to an 354 Ethernet Attachment Circuit and PE2 is connected to an ATM 355 Attachment Circuit, PE1 and PE2 would both treat the Pseudowire as 356 of type Ethernet. From PE1's point of view, the circuit is 357 homogeneous, since the Attachment Circuit and the Pseudowire are 358 both Ethernet. Hence PE1 does no ARP mediation. From PE2's point of 359 view, the circuit is heterogeneous, so PE2 performs ARP mediation. 360 That is, 362 o PE2 signals to PE1 that the PW Type is Ethernet, 363 o PE2 learns the IP address of remote CE from Ethernet 364 frames received over the PW, 365 o PE2 learns the IP address of locally attached ATM CE, 366 o PE2 proxies the IP address of each CE to the other, 367 o PE2 decapsulates the ATM data link header and 368 reencapsulates with an Ethernet header before forwarding 369 the IP data frames from its local CE over the PW. The 370 information used to build the Ethernet data link header 371 is obtained through ARP mediation functions. Similar 372 header manipulation is performed when Ethernet IP frames 373 are forwarded to ATM Attachment Circuit, 374 o Drop all non IP Ethernet frames received over Ethernet 375 PW. 377 In summary, single sided configuration handles ARP mediation as PE 378 would typically when managing two locally attached heterogenous 379 Attachment Circuits. 381 6.0 How CE Learns The Remote CE's IP address 383 Once the PE has received the remote CE's IP address information 384 from the remote PE, it will either initiate an address resolution 385 request or respond to an outstanding request from the attached CE 386 device. 388 6.1 CE Devices Using ARP 390 When the PE learns the remote CE's IP address as described in 391 section 5.1 and 5.2, it may or may not know the local CE's IP 392 address. If the local CE's IP address is not known, the PE must 393 wait until it is acquired through one of the methods described in 394 sections 4.1, 4.3 and 4.5. If the IP address of the local CE is 395 known, the PE may choose to generate an unsolicited ARP message to 396 notify the local CE about the binding of the remote CE's IP address 397 with the PE's own MAC address. 399 When the local CE generates an ARP request, the PE must proxy the 400 ARP response using its own MAC address as the source hardware 401 address and remote CE's IP address as the source protocol address. 402 The PE must respond only to those ARP requests whose destination 403 protocol address matches the remote CE's IP address. 405 6.2 CE Devices Using Inverse ARP 407 When the PE learns the remote CE's IP address, it should generate 408 an Inverse ARP request. In case, the local circuit requires 409 activation e.g. Frame Relay, PE should activate it first before 410 sending Inverse ARP request. It should be noted, that PE might 411 never receive the response to its own request, nor see any CE's 412 Inverse ARP request in cases where CE is pre-configured with remote 413 CE IP address or the use of Inverse ARP is not enabled. In either 414 case CE has used other means to learn the IP address of his 415 neighbor. 417 6.3 CE Devices Using PPP 419 When the PE learns the remote CE's IP address, it must initiate the 420 Configure-Request using the remote CE's IP address or respond to 421 pending Configure-Request from the local CE. As noted earlier, all 422 other configuration options related to compression, encryptions, 423 etc., should be rejected. 425 7.0 Use of IGPs with IP L2 Interworking L2VPNs 427 In an IP L2 interworking L2VPN, when an IGP on a CE connected to a 428 broadcast link is cross-connected with an IGP on a CE connected to 429 a point-to-point link, there are routing protocol related issues 430 that must be addressed. The link state routing protocols are 431 cognizant of the underlying link characteristics and behave 432 accordingly when establishing neighbor adjacencies, representing 433 the network topology, and passing protocol packets. 435 7.1 OSPF 437 The OSPF protocol treats broadcast link type with a special 438 procedure that engages in neighbor discovery to elect a designated 439 and a backup designated router (DR and BDR respectively) with which 440 it forms adjacencies. However, these procedures are neither 441 applicable nor understood by OSPF running on a point-to-point link. 442 By cross-connecting two neighbors with disparate link types, an IP 443 L2 interworking L2VPN has the potential to experience connectivity 444 issues. 446 Additionally, the link type specified in the router LSA will not 447 match for two routers that are supposedly sharing the same link 448 type. Finally, each OSPF router generates network LSAs when 449 connected to a broadcast link such as Ethernet, receipt of which by 450 an OSPF router on the point-to-point link further adds to the 451 confusion. 453 Fortunately, the OSPF protocol provides a configuration option 454 (ospfIfType), whereby OSPF will treat the underlying physical 455 broadcast link as a point-to-point link. 457 It is strongly recommended that all OSPF protocols on CE devices 458 connected to Ethernet interfaces use this configuration option when 459 attached to a PE that is participating in an IP L2 Interworking 460 VPN. 462 7.2 IS-IS 464 The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC 465 address and the IP address of the intermediate system (i.e., CE 466 device) when attached to Ethernet links. The CE device expects its 467 neighbor to insert its own MAC and IP address in the response. If 468 the neighbor is connected via a point-to-point link type, the LAN 469 Hello PDU will be silently discarded. Similarly, Hello PDUs on the 470 point-to-point link do not contain any MAC address, which will 471 confuse a neighbor on an Ethernet link, if these two neighbors were 472 cross-connected via above described mechanisms. 474 Thus, use of the IS-IS protocol on CE devices presents problems 475 when interconnected by disparate data link types in an IP L2 476 Interworking VPN environment. There are some mechanisms defined in 477 draft-ietf-isis-igp-p2p-over-lan-00.txt to accommodate point-to- 478 point behavior over broadcast networks. The feasibility of such 479 techniques to solve this problem is under review. 481 It is important to note that the use of the IS-IS protocol in 482 enterprise networks (i.e., CE routers) is less common. The IS-IS 483 related difficulties for IP L2 Interworking VPNs, hence are 484 minimized. 486 7.3 RIP 488 RIP protocol broadcasts RIP advertisements every 30 seconds. If the 489 group/broadcast address snooping mechanism is used as described 490 above, the attached PE can learn the advertising (CE) router's IP 491 address from the IP header of the advertisement. No special 492 configuration is required for RIP in this type of Layer 2 IP 493 Interworking L2VPN. 495 8.0 Security Considerations 497 The security aspects of this solution will be discussed at a later 498 time. 500 9.0 Acknowledgements 502 The authors would like to thank Prabhu Kavi, Bruce Lasley and other 503 folks who participated in the discussions related to this draft. 505 10.0 References 507 10.1 Normative References 509 [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution 510 Protocol: Or Converting Network Protocol Addresses to 48.bit 511 Ethernet Addresses for Transmission on Ethernet Hardware". 513 [INVARP] RFC 2390, T. Bradley et al., "Inverse Address Resolution 514 Protocol". 516 10.2 Informative References 518 [L2VPN-REQ] W. Augustyn et al., "Service Requirements for Layer 2 519 Provider Provisioned Virtual Private Networks", February 2003, work 520 in progress. 522 [L2VPN-FRM] L. Andersson et al., "L2VPN Framework", January 2003, 523 work in progress. 525 [PPP-IPCP] RFC 1332, G. McGregor, "The PPP Internet Protocol 526 Control Protocol (IPCP)". 528 [L2VPN-Kompella] K. Kompella et al., "Layer 2 VPNs Over Tunnels", 529 June 2002, work in progress. 531 [PWE3-CONTROL] L. Martini et al., "Transport of Layer 2 Frames Over 532 MPLS", November 2002, work in progress. 534 [L2VPN-Signaling] E. Rosen et al., "LDP-based Signaling for 535 L2VPNs", September 2002, work in progress. 537 [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". 539 [SHAH-CONTROL] H. Shah et al., �Dynamic Parameters Signaling for 540 MPLS-based Pseudowires�, June 2003, work in progress 541 11.0 Authors' Addresses 543 Himanshu Shah 544 35 Nagog Park, 545 Acton, MA 01720 546 Email: hshah@ciena.com 548 Eric Rosen 549 Cisco Systems 550 1414 Massachusetts Avenue, 551 Boxborough, MA 01719 552 Email: erosen@cisco.com 554 Waldemar Augustyn 555 Email: waldemar@nxp.com 557 Giles Heron 558 PacketExchange Ltd. 559 The Truman Brewery 560 91 Brick Lane 561 LONDON E1 6QL 562 United Kingdom 563 Email: giles@packetexchange.net 565 Sunil Khandekar and Vach Kompella 566 TiMetra Networks 567 274 Ferguson Dr. 568 Mountain View, CA 94043 569 Email: sunil@timetra.com 570 Email: vkompella@timetra.com 572 Toby Smith 573 Laurel Networks 574 Omega Corporate Center 575 1300 Omega drive 576 Pittsburgh, PA 15205 577 Email: jsmith@laurelnetworks.com 579 Arun Vishwanathan 580 Force10 Networks 581 1440 McCarthy Blvd., 582 Milpitas, CA 95035 583 Email: arun@force10networks.com 585 Ashwin Moranganti 586 Appian Communications 587 35 Nagog Park, 588 Acton, MA 01720 589 Email: amoranganti@appiancom.com 591 Andrew G. Malis 592 Vivace Networks, Inc. 593 2730 Orchard Parkway 594 San Jose, CA 95134 595 Email: Andy.Malis@vivacenetworks.com 597 Steven Wright 598 Bell South Corp 599 Email: steven.wright@bellsouth.com 601 Vasile Radoaca 602 Nortel Networks 603 Email: vasile@nortelnetworks.com 605 IPR Notice 607 The IETF takes no position regarding the validity or scope of any 608 intellectual property or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; neither does it represent that it 612 has made any effort to identify any such rights. Information on the 613 IETF�s procedures with respect to rights in standards-track and 614 standards-related documentation can be found in BCP-11. Copies of 615 claims of rights made available for publication and any assurances 616 of licenses to be made available, or the result of an attempt made 617 to obtain a general license or permission of such proprietary 618 rights by implementers or users of this specification can be 619 obtained from the IETF Secretariat. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights which may cover technology that may be required to practice 624 this standard. Please address the information to the IETF Executive 625 Director. 627 Full Copyright Statement 629 "Copyright (C) The Internet Society (2001). All Rights Reserved. 630 This document and translations of it may be copied and furnished to 631 others, and derivative works that comment on or otherwise explain 632 it or assist in its implementation may be prepared, copied, 633 published and distributed, in whole or in part, without restriction 634 of any kind, provided that the above copyright notice and this 635 paragraph are included on all such copies and derivative works. 636 However, this document itself may not be modified in any way, such 637 as by removing the copyright notice or references to the Internet 638 Society or other Internet organizations, except as needed for the 639 purpose of developing Internet standards in which case the 640 procedures for copyrights defined in the Internet Standards process 641 must be followed, or as required to translate it into languages 642 other than English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on 648 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 650 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 651 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."