idnits 2.17.1 draft-shah-ppvpn-arp-mediation-01.txt: ** The Abstract section seems to be numbered -(170): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(329): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(359): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(407): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(446): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(448): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(449): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(452): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(463): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(478): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(694): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(697): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(698): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(701): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(702): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(705): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(714): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 59 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 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. ** There are 2 instances of too long lines in the document, the longest one being 38 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 183 has weird spacing: '...ty with disc...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L2VPN-KOMPELLA' is mentioned on line 229, but not defined == Missing Reference: 'RFC 1256' is mentioned on line 241, but not defined == Missing Reference: 'PWE3-Control' is mentioned on line 456, but not defined -- Looks like a reference, but probably isn't: '8' on line 428 == Missing Reference: 'MARTINI-ENCAP' is mentioned on line 555, but not defined == Unused Reference: 'L2VPN-ENCAP' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'L2VPN-Signaling' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'L2VPN-TERM' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'PROXY-ARP' is defined on line 722, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-01 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-Kompella' == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-04 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. 'L2VPN-ENCAP') == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-00 == Outdated reference: A later version (-03) exists of draft-rosen-ppvpn-l2-signaling-02 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-Signaling' -- No information found for draft-ietf-ppvpn-l2-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L2VPN-FW' == Outdated reference: A later version (-04) exists of draft-andersson-ppvpn-terminology-01 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-TERM' ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. 'PROXY-ARP') Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Himanshu Shah 3 Prabhu Kavi 4 PPVPN Working Group Tenor Networks 5 Internet Draft 6 Draft-shah-ppvpn-arp-mediation-01.txt Eric Rosen 7 Cisco Systems 8 October 2002 9 Expires: April 2003 Waldemar Augustyn 10 Consultant 12 Sunil Khandekar Giles Heron 13 Vach Kompella PacketExchange,Ltd 14 TiMetra Networks 15 Arun Vishwanathan 16 Toby Smith Force10 Networks 17 Laurel Networks 18 Ashwin Moranganti 19 Steven Wright Appian Communication 20 Bell South 21 Andrew Malis 22 Vasile Radoaca Vivace Networks 23 Nortel Networks 25 ARP Mediation for IP Interworking of Layer 2 VPN 27 1.0 Status of this Memo 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 49 2.0 Abstract 51 This draft addresses an issue in a particular kind of Layer 2 VPN, 52 which provides point-to-point connectivity for IP traffic only. In 53 this kind of VPN it is possible to form heterogeneous point-to-point 54 links, where the two ends of the link use different technologies, 55 e.g., one end is Ethernet and the other is Frame Relay or ATM. If 56 two IP systems are connected via a heterogeneous point-to-point link, 57 each may be using different address learning techniques, for 58 instance, one using ARP on Ethernet and the other using Inverse ARP 59 on Frame Relay. It is up to the Provider Edge routers to make these 60 different techniques inter-work. This draft specifies the procedures 61 which the Provider Edge (PE) routers should perform in order to allow 62 correct operation across heterogeneous point-to-point links. 64 2.1 ID Summary 66 SUMMARY 68 This ID describes a mechanism by which PE devices learn the IP 69 address of each locally attached CE device and distributes these to 70 other PEs in order to mediate between the address resolution 71 mechanisms used by the Customer Edge (CE) devices. The ID also 72 points out difficulties, and in some cases, the inoperability of 73 IGPs on the CE devices when interconnected by PE devices using IP L2 74 interworking VPN solution. 76 RELATED DOCUMENTS 77 Draft-kompella-ppvpn-l2vpn-01.txt 78 draft-ietf-ppvpn-l2vpn-arch-00.txt 79 draft-rosen-ppvpn-l2-signaling-02.txt 80 draft-ietf-pwe3-control-protocol-00.txt 81 draft-heinanen-inarp-uni-01.txt 83 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 85 Belongs in PPVPN 87 WHY IS IT TARGETED AT THIS WG 89 This document describes a mechanism to assist in Provider- 90 Provisioned Layer 2 VPNs. 92 JUSTIFICATION 94 The IP L2 Interworking VPN solution described in [L2VPN-Kompella] 95 introduces the concept of Layer 2 IP Interworking between disparate 96 Layer 2 media (e.g., Ethernet and Frame Relay). However, it does not 97 address how address resolution protocols should be handled between 98 these disparate media types. This document describes how the PEs 99 should mediate between the different address resolution protocols 100 that each CE device uses. Also, there are issues when IGP on a 101 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 103 point-to-point link CE is interconnected with IGP on a multi- 104 access/broadcast link CE. This document outlines these issues. 106 3.0 Overview 108 A heterogeneous circuit is defined as a virtual circuit between two 109 CE devices that consists of two disparate Attachment Circuits (AC) 110 as the endpoints of a pseudowire. For example, a CE device on 111 Ethernet is attached to a pseudowire whose other end point is a CE 112 device on Frame Relay. The Attachment Circuit in this example could 113 then be a VLAN tag on Ethernet interface emulated to the Attachment 114 Circuit of a Frame Relay DLCI on the other end. Any attempt to make 115 use of such heterogeneous circuits faces the following problems: 117 1. Different encapsulations may be used on the two Attachment 118 Circuits. Frames from one Attachment Circuit can not just be 119 forwarded unchanged on the other; rather the frames must be 120 processed by some sort of interworking function. 121 2. A CE device may execute procedures which are specific to a 122 particular type of Attachment Circuit (AC), and it may 123 presuppose that the CE at the other end of the CE-CE circuit is 124 executing those same procedures. Therefore, if the two CEs are 125 attached via different types of Attachment Circuits, and are 126 executing different AC-specific procedures, some means of 127 mediating between those different procedures is needed. 129 The [L2VPN-Kompella] specifies procedures for dealing with problem 130 1, above. In the proposed scheme, the interworking functions strip 131 the Layer 2 header of the data packet at ingress and prepend the 132 appropriate Layer 2 header at the egress. 134 However, [L2VPN-Kompella] draft does not specify any procedures for 135 dealing with the problem 2 above. For example, if a CE1 is an 136 Ethernet-attached router, it expects to learn the IP address of its 137 neighbor from a multicast routing control packet, and then expects to 138 do ARP to learn the MAC address. However, if CE2 is attached via 139 Frame Relay or ATM, it may use Inverse ARP to learn the IP address of 140 its neighbor. Similarly, if CE2 is attached to PPP, it may seek the 141 IP address of its neighbor during IPCP negotiations. Note that in 142 either case, CE2 is seeking the IP address of its neighbor (i.e., 143 CE1) while CE1 is seeking MAC address of its neighbor (i.e., CE2) for 144 the IP address learned via other means. For CE1 and CE2 to interwork 145 correctly, PE1 and PE2 must mediate the address-learning and 146 resolution process. 148 One option is to require each CE to have a static configuration of 149 the IP addresses of all remote CEs. However, this is unwieldy and 150 should be avoided whenever possible. A better approach is to have 151 the service provider network automatically mediate between the 152 various address resolution messages. In this document, we propose 153 that the PE devices capture the address resolution protocol messages 154 sent by the CE, and use this information to perform a mediation 155 function between different address resolution procedures. The 156 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 158 methods of performing this mediation function are described in this 159 document. In some cases, this mediation may not be possible, and 160 these situations are also detailed in this document. 162 Note that the PEs are capturing the CE�s IP address information so 163 that address resolution information can be passed to the CE. Under 164 no circumstances does the PE make forwarding decision based on the 165 Layer 3 addressing information. 167 4.0 Introduction 169 In the traditional Layer 2 VPNs, the customer-facing links are 170 required to be of the same data link type for each ��circuit��. The PE 171 device is only responsible for shuttling the data traffic from the 172 link connecting to the local CE, over an MPLS core, and to the link 173 connecting to the remote CE. This requirement of homogenous data 174 link type is somewhat restrictive in building various network 175 topologies. In [L2VPN-Kompella], it is observed that if all the 176 traffic is known to be IP traffic, it is possible to relax this 177 restriction by decapsulating the IP packet from one data link 178 encapsulation, and simply reencapsulating it in the other. 179 However, [L2VPN-Kompella] does not address all the issues. For 180 example, consider a situation in which the service provider network 181 creates a ��circuit�� between an Ethernet VLAN tag and a Frame Relay 182 DLCI. Unless static ARP is used, the CE router connected to the 183 Frame Relay interface precedes its IP activity with discovery of 184 its neighbor�s IP address using the inverse ARP protocol [INVARP]. 185 Similarly, the CE router on an Ethernet precedes its direct IP 186 communication by binding its neighbor�s MAC address to its IP 187 address via the ARP protocol [ARP]. However, the Inverse ARP on a 188 point-to-point link is seeking disjoint information from an ARP on a 189 broadcast link. 191 The PE router is a logical place to perform a mediation function 192 between these related, but incompatible, address resolution 193 protocols. Performing this function in the PE simplifies the 194 operation of the CE, and keeps pseudowire interworking transparent 195 to the CE. 197 For each IP Layer 2 interworking circuit, there are three logical 198 steps to performing this address mediation: 200 1. Have the PE discover the attached CE�s IP address (details in 201 section 5.0). 202 2. Distribute this IP address to the PE at the remote end of the 203 circuit (details in section 6.0). 204 3. Notify the attached CE about the remote CE�s IP address 205 (details in section 7.0). 207 It is important to note that the dynamic learning and distribution 208 of the attached CE�s IP address is possible only for some data link 209 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 211 technologies. For other data links, static configuration cannot be 212 avoided. However, ARP Mediation addresses the most common methods 213 of creating Layer 2 VPNs, and therefore should be widely useful. 215 5.0 How the PE Discovers the Address of the Local CE Device 217 For each Layer 2 IP interworking circuit, the PE creates and fills 218 in a tuple consisting of the following: 220 1. Attached CE�s IP address 221 2. Circuit Information 222 3. Remote CE�s IP address 224 This information is gathered using the mechanisms described below. 226 The rest of this section describes how the IP address of the locally 227 attached CE is learned. Section 6 describes how the learned IP 228 address may be distributed to the remote PE using the signaling 229 mechanisms of either [L2VPN-KOMPELLA] or [PWE3-CONTROL]. Section 7 230 describes how the remote PE processes the received cross-connect 231 information for IP address resolution. 233 5.1 Ethernet Data Link 235 We are assuming a Virtual Private Wire Service (VPWS) as described 236 in [L2VPN-FW] for the CE/PE Attachment Circuit as an Ethernet 237 containing only that CE and that PE. 239 In order to learn the IP address of the CE device for a given 240 Ethernet Attachment Circuit, the PE device may execute Router 241 Discovery Protocol [RFC 1256] whereby a Router Discovery Request 242 (ICMP - - router solicitation) message is sent using a source IP 243 address of zero. The IP address of the CE device is extracted from 244 the Router Discovery Response (ICMP - - router advertisement) message 245 from the CE. 247 The use of the router discovery mechanism by the PE is optional. The 248 alternatives could include gleaning the source address field of any 249 broadcasts to IP multicast/broadcast address and making sure that 250 only one router on the local LAN is sending such broadcasts. It is 251 also possible to simply wait for the CE to generate the ARP request 252 for its neighbor or send gratuitous ARP on startup. The Ethernet 253 address and protocol address can then be gleaned from the request. 254 Once the PE learns the IP address of the CE, the CE�s address is 255 signaled to remote PE (section 6.0). 257 The PE could periodically generate the ARP request message to the 258 CE�s IP address as a means to verify the continued existence of the 259 CE�s IP address and its binding to the Ethernet MAC address. The 260 absence of a response from the CE device for a given number of 261 retries could be used as a cause for a withdrawal of the IP address 262 advertisement to the remote PE and entering into the address 263 resolution phase to rediscover the attached CE�s IP address. Note 264 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 266 that such ��heartbeat�� scheme is needed only for broadcast links such 267 as Ethernet, as a loss of CE may otherwise be undetectable. 269 5.2 Frame Relay Data Link 271 A Frame Relay attached CE device generates an Inverse ARP request to 272 obtain the IP address of the neighbor when the associated DLCI 273 becomes active. Traditionally, a DLCI becomes active when the DCE 274 signals LMI status active message as a result of the associated PVC 275 path becoming operational. 277 A PE device attached to a CE, connected either directly or through a 278 set of Frame Relay switches, plays the role of an intermediate 279 network node for cross-connect purposes. To a Frame Relay endnode 280 (i.e. a CE), the presence of any intermediate Frame Relay switches, 281 a pair of PEs and the fact that the remote CE may be Ethernet- 282 attached, is all transparent. As far as Frame Relay CE is concerned, 283 the Ethernet CE appears as the remote end point of the Frame Relay 284 PVC path. 286 However, for IP L2 interworking VPN purposes, the Ethernet CE and 287 the Frame Relay CE are two IP end stations and it becomes necessary 288 for the PE to play a role in address resolution to keep both end 289 stations unaware of data link address resolution inconsistencies. 291 When a PE processes the Frame Relay Inverse ARP request for a DLCI, 292 it responds with an Inverse ARP reply containing the remote CE�s IP 293 address, if the address is known. If the PE does not yet have the 294 remote CE�s IP address, it does not respond, but notes the IP 295 address of the local CE and the DLCI information. Subsequently, when 296 the IP address of the remote CE becomes available, the PE may 297 initiate the Inverse ARP request as a means to notify the local CE, 298 the IP address of the remote CE. 300 Also, note that the PE continues to learn the IP address of the CE 301 from any multicast/broadcast IP packet that CE may generate 302 irrespective of Inverse ARP protocol execution. 304 5.3 ATM Data Link 306 A CE device attached to ATM data link can be configured to treat 307 each PVC as an IP subnet. The PE participates in RFC 2225 defined 308 inverse ATM ARP. When processing an Inverse ATM ARP request for a 309 PVC, if the PE does not have the IP address associated with the 310 cross-connect from the remote PE, it does not respond, but notes the 311 IP address of the ATM attached CE and the PVC information. If the 312 remote IP address is available, it responds with the Inverse ATM ARP 313 reply. Subsequently, when the IP address of the remote CE becomes 314 available, the PE may initiate the Inverse ATM ARP request as a 315 means to notify the local CE the IP address of the remote CE. 317 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 319 Also note that the PE continues to learn the IP address of the CE 320 from any multicast/broadcast IP packet that the CE may generate 321 irrespective of Inverse ARP protocol execution. 323 5.4 PPP Data Link 325 A CE device attached to a PPP data link participates in IPCP [RFC 326 1332] to obtain the neighbor�s IP address. If the PE device has the 327 cross-connect and the IP address of the remote CE, it responds to 328 the IPCP Configure-Request. However, if the PE does not have the 329 remote CE�s IP address, it does not respond to the local CE�s IPCP 330 request but simply notes its IP address. Subsequently, when the IP 331 address of the remote CE becomes available, the PE generates IPCP 332 Configure-Request to the local CE. 334 Also, the PE must deny configurations such as header compression and 335 encryptions in the NCP packets with such options. 337 6.0 IP Address Distribution Between PE 339 There are two cross-connect information distribution mechanisms 340 defined in [L2VPN-Kompella] and [PWE3-Control] respectively. The 341 following sections discuss how these signaling protocols are 342 extended to distribute the associated IP address information. 344 6.1 When To Distribute IP Address 346 A PE device advertises the IP address of the attached CE only when 347 the encapsulation type of the VPN is IP L2 interworking. It is quite 348 possible that the IP address of a CE device is not available at the 349 time the VC labels are advertised. For example, in Frame Relay the 350 CE device dispatches inverse ARP request only when the DLCI is 351 active; if the PE signals the DLCI to be active only when it has 352 received the cross-connect information from the remote PE, a chicken 353 and egg situation arises. In order to avoid such problems, the PE 354 must be prepared to advertise the cross-connect information before 355 the CE�s IP address is known. When the IP address of the CE device 356 does become available, the PE re-advertises the cross-connect 357 information with an updated IP address field value. 359 Similarly, if the PE detects invalidation of the CE�s IP address (by 360 methods described above) the PE must re-advertise the cross-connect 361 information with a CE IP address field of zero to denote the 362 withdrawal of the CE�s IP address. The receiving PE may then wait 363 for the IP address information from the remote PE before enabling 364 the unicast IP traffic flow. 366 If two CE devices are locally attached to the PE where, one CE is 367 connected to an Ethernet data link and the other to a Frame Relay 368 interface, for example, the IP addresses are learned in the same 369 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 371 manner described above. However, since the CE devices are local, the 372 distribution of IP addresses for these CE devices is a local step. 374 6.2 BGP Based Distribution [L2VPN-Kompella] 376 The [L2VPN-Kompella] draft defines the MP-BGP NLRI for the L2VPN 377 cross-connect information. The NLRI contains the label block offset, 378 the label base and the size (i.e., the length of the circuit status 379 vector sub-TLV) tuple that provides a set of contiguous labels 380 starting from the label base to correspond to a set of remote CE-IDs 381 starting from the label block offset. 383 We propose an IP address sub-TLV for this NLRI that accompanies this 384 tuple. The type value is TBD. The length is the same as the length 385 of the circuit status vector sub-TLV. The value field contains the 386 length number of 4-byte fields where each field is an IP address 387 that corresponds one-to-one with the labels represented by the label 388 base and the length field. The PE device should note the label to IP 389 address association by iterating through each IP field value in 390 order. 392 6.3 LDP Based Distribution [PWE3-CONTROL] 394 The [PWE3-CONTROL] uses LDP transport to exchange Layer-2 cross- 395 connect information for a given VPN. The cross-connect information 396 is represented as a VC FEC element that the LDP protocol distributes 397 to the remote peer in downstream-unsolicited mode. This document 398 proposes extensions to VC FEC element to support the IP L2 399 interworking as a new VPN type and to include the IP address 400 information. 402 6.3.1 IP L2 Interworking Signaling 404 The IP L2 interworking VPN type is advertised in the VC-Type field 405 of the VC FEC as the value 0x000C. 407 The ��interface parameter�� field in the VC FEC is defined in [PWE3- 408 CONTROL] as follows. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Parameter ID | Length | Variable Length Value | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Variable Length Value | 416 | " | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 The parameter ID is defined as follows: 421 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 423 Parameter ID Length Description 425 0x01 4 Interface MTU in octets. 426 0x02 4 Maximum Number of concatenated ATM cells. 427 0x03 up to 82 Optional Interface Description string. 428 0x04 4 CEM [8] Payload Bytes. 429 0x05 4 CEM options. 431 The Length field is defined as the length of the interface parameter 432 including the parameter ID and the length field itself. 434 We propose an additional parameter for the parameter ID. 436 0x06 4 IP address of CE 438 The IP address interface parameter contains the IP address 439 associated with the advertised VC-ID. If the IP address is not 440 known, this interface parameter may not be present in the 441 advertisement. If present, it may contain the IP address value as 442 0.0.0.0. In either case, the receiving PE processes the information 443 as IP address association unknown for the advertised VC-ID. 445 We recommend two options for signaling such ��VC associated 446 information�� that are currently present as the interface parameter 447 field in the VC FEC. 448 1. The entire ��interface parameter�� field is either removed or 449 duplicated from the VC FEC to the ��optional parameter�� field of 450 the LDP�s Label Mapping Message. 451 2. A new VC Status FEC is introduced that accompanies the VC FEC 452 in the LDP�s Label Mapping Message. The ��interface parameter�� 453 field of the VC FEC is then either removed or duplicated from 454 the VC FEC to the VC Status FEC. 456 We intend to work with authors of [PWE3-Control] and [Rosen- 457 Signaling] to find the most suitable solution for extensions (such 458 as IP address, IP address and MAC address, interface status, etc.) 459 that are generic, in a backward compatible fashion. 461 7.0 How CE Learns The Remote CE�s IP address 463 Once the PE has received the remote CE�s IP address information from 464 the remote PE, it will either initiate an address resolution request 465 or respond to an outstanding request from the attached CE device. 467 7.1 Ethernet Data Link 469 When the PE learns the remote CE�s IP address from the Layer 2 VPN 470 advertisement (as described above), it may or may not know the local 471 CE�s IP address. If the local CE�s IP address is not known, the PE 472 must wait for the arrival of an IGP broadcast packet, a RDP response 473 packet or an ARP request packet from the local CE. If, however, 474 local CE�s IP address is already known, the PE may choose to 475 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 477 generate an unsolicited ARP message to notify the local CE about the 478 binding of the remote CE�s IP address with the PE�s own MAC address. 480 In either case, whenever an ARP request is generated by the local 481 CE, the PE must proxy ARP response using its own MAC address as the 482 source hardware address and remote CE�s IP address as the source 483 protocol address. The PE must respond only to those ARP requests 484 whose destination protocol address matches the remote CE�s IP 485 address. 487 7.2 Frame Relay Data Link 489 If a PE has received new cross-connect information from the remote 490 PE, the corresponding local DLCI may not yet be active. The PE 491 should use the cross-connect information to activate the DLCI via 492 LMI and schedule an inverse ARP request. The PE may choose to delay 493 the generation of the Inverse ARP request in order to allow the 494 attached CE to generate the request first. However, it is possible 495 that the PE may never receive the Inverse ARP request, nor the 496 response to its own request. This could occur for a number of 497 reasons, 498 1. The IP protocol is not enabled on the CE device at the time 499 when the DLCI was activated. This is not an issue since the 500 cross connect information exchange is not predicated on 501 learning of the CE�s IP address. When the IP protocol is 502 enabled on the CE device, an inverse ARP request will be 503 generated. 504 2. No Inverse ARP request is generated if the CE is already 505 configured with the remote CE�s IP address, hence there is no 506 need to generate the request. Since the PE does not know of 507 this situation, it must generate an Inverse ARP request using 508 the remote CE�s IP address. The response from the CE enables 509 the PE to learn its IP address. 510 3. The CE router does not support the Inverse ARP protocol or the 511 Inverse ARP protocol is disabled. We have found through 512 experimentations that most implementations do respond to the 513 Inverse ARP Request even when Inverse ARP protocol is disabled 514 (it seems that disabling of protocol only means that request 515 generation is disabled). However, if the Inverse ARP Protocol 516 is not supported, the PE needs to be configured with the IP 517 address of the attached CE. This facilitates distribution of 518 the IP address to the remote PE. 520 7.3 ATM Data Link 522 The PE device should generate an Inverse ATM ARP request when the IP 523 address of the remote cross-connected CE device becomes available. 524 The role of the PE device in handling address resolution for the IP 525 L2 interworking cross-connect for ATM VCs is similar to the behavior 526 described above for Frame Relay VCs. 528 As always, static configuration of the local CE�s IP address is an 529 available option, when all else fails. 531 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 533 7.4 PPP 535 The PE device should respond to the local CE�s IPCP Configure- 536 Request with the remote CE�s IP address. However, if the IP address 537 is not available, the PE should postpone the response. When the 538 remote CE�s IP address becomes available, the PE must initiate the 539 Configure-Request using the remote CE�s IP address. As noted 540 earlier, all other configuration options related to compression, 541 encryptions, etc., should be rejected. 543 8.0 Data Forwarding 545 The IP L2 Interworking permits only IP data packets to be exchanged 546 over the pseudowire. The following description from [L2VPN-Kompella] 547 shows how data packets are handled by the ingress and egress PE. 549 At the ingress PE, an L2 frame's L2 header is completely stripped off 550 and is carried over as an IP packet through a tunnel to the egress 551 PE. The forwarding decision is still based on the L2 circuit 552 information of the incoming IP frame. At the egress PE, the IP 553 packet is encapsulated back in an L2 frame and transported over to 554 the destination CE. The forwarding decision at the egress PE is 555 based on the VC label as discussed in [MARTINI-ENCAP]. The L2 556 technology between egress PE and CE is independent of the L2 557 technology between ingress PE and CE. 559 The PE should observe the following forwarding rules when processing 560 IP data packets for interworking circuits. 562 1. If the PE has not learned the IP address of the local CE and the 563 IP packet received from the local CE is multicast or a 564 broadcast, the PE should learn the source IP address and forward 565 the packet to the corresponding pseudowire. If the Attached 566 Circuit is Ethernet, it should also learn the MAC address of the 567 CE device. The PE must forward multicast/broadcast IP packet 568 from the Attachment Circuit to the pseudowire irrespective of 569 the status of the remote CE�s IP address. 570 2. If the PE has not learned the IP address of the local CE, the PE 571 should forward the multicast/broadcast IP packet from the 572 pseudowire to the local Attachment Circuit. If the Attachment 573 Circuit is Ethernet, PE must translate IP multicast/broadcast 574 destination to appropriate MAC DA. 575 3. If a PE has the local and the remote CEs� IP addresses, all IP 576 packets are forwarded in both directions between the Attachment 577 Circuit and the pseudowire. When the Attachment Circuit is 578 Ethernet, a unicast IP packet from the pseudowire is prepended 579 with the Ethernet MAC header using the MAC DA of the CE 580 (obtained during the learning phase) and the MAC SA of the PE. 581 4. All Unicast IP packets received from the Attachement Circuit and 582 the pseudowire are dropped until the local and remote CEs� IP 583 addresses are known. 585 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 587 9.0 Use of IGPs with IP L2 Interworking VPNs 589 In an IP L2 interworking VPN, when an IGP on a CE connected to a 590 broadcast link is cross-connected with an IGP on a CE connected to a 591 point-to-point link, there are routing protocol related issues that 592 must be addressed. The link state routing protocols are cognizant of 593 the underlying link characteristics and behave accordingly when 594 establishing neighbor adjacencies, representing the network 595 topology, and passing protocol packets. 597 9.1 OSPF 599 The OSPF protocol treats broadcast link type with a special 600 procedure that engages in neighbor discovery to elect a designated 601 and a backup designated router (DR and BDR respectively) with which 602 it forms adjacencies. However, these procedures are neither 603 applicable nor understood by OSPF running on a point-to-point link. 604 By cross-connecting two neighbors with disparate link types, an IP 605 L2 interworking VPN has the potential to experience connectivity 606 issues. 608 Additionally, the link type specified in the router LSA will not 609 match for two routers that are supposedly sharing the same link 610 type. Finally, each OSPF router generates network LSAs when 611 connected to a broadcast link such as Ethernet, receipt of which by 612 an OSPF router on the point-to-point link further adds to the 613 confusion. 615 Fortunately, the OSPF protocol provides a configuration option 616 (ospfIfType), whereby OSPF will treat the underlying physical 617 broadcast link as a point-to-point link. 619 It is strongly recommended that all OSPF protocols on CE devices 620 connected to Ethernet interfaces use this configuration option when 621 attached to a PE that is participating in an IP L2 Interworking VPN. 623 9.2 IS-IS 625 The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC 626 address and the IP address of the intermediate system (i.e., CE 627 device) when attached to Ethernet links. The CE device expects its 628 neighbor to insert its own MAC and IP address in the response. If 629 the neighbor is connected via a point-to-point link type, the LAN 630 Hello PDU will be silently discarded. Similarly, Hello PDUs on the 631 point-to-point link do not contain any MAC address, which will 632 confuse a neighbor on an Ethernet link, if these two neighbors were 633 cross-connected via above described mechanisms. 635 Thus, use of the IS-IS protocol on CE devices presents problems when 636 interconnected by disparate data link types in an IP L2 interworking 637 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 639 VPN environment. There are some mechanisms defined in draft-ietf- 640 isis-igp-p2p-over-lan-00.txt to accommodate point-to-point behavior 641 over broadcast networks. The feasibility of such techniques to solve 642 this problem is under review. 644 It is important to note that the use of the IS-IS protocol in 645 enterprise networks (i.e., CE routers) is less common. The IS-IS 646 related difficulties for IP L2 Interworking VPNs, hence are 647 minimized. 649 9.3 RIP 651 RIP protocol broadcasts RIP advertisements every 30 seconds. If the 652 group/broadcast address snooping mechanism is used as described 653 above, the attached PE can learn the advertising (CE) router�s IP 654 address from the IP header of the advertisement. No special 655 configuration is required for RIP in this type of Layer 2 IP 656 interworking VPN. 658 10.0 Conclusion 660 The three step procedure of discovering the IP address of a local CE 661 device, distributing the CE�s IP address to the remote PE and 662 notifying the local CE of the remote CE�s IP address, as described 663 in this document provides for reduced configuration of the PE 664 devices used for IP L2 Interworking VPNs. 666 There are cases where the manual configuration of the CE�s IP 667 address is unavoidable. These cases include the use of interfaces 668 that support address resolution but do not have address resolution 669 enabled, such as unnumbered interfaces on the CE device. 671 It is also important to note that IP address changes on the CE 672 devices may require manual intervention (e.g., soft reset of the 673 attached port) on the PE device. 675 For most common interface types, however, the procedures described 676 in this document enhance the IP interworking solution of [L2VPN- 677 Kompella] by reducing the amount of configuration required on the PE 678 devices. 680 11.0 Acknowledgements 682 Authors would like to thank Bruce Lasley and other folks within 683 Tenor who participated in discussions related to this draft. 685 12.0 Security Considerations 687 The security aspects of this solution will be discussed at a later 688 time. 690 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 692 13.0 References 694 [L2VPN-Kompella] Kompella et al., ��MPLS based Layer 2 VPNs��, draft- 695 kompella-ppvpn-l2vpn-01.txt, November 2001. 697 [L2VPN-ENCAP] Martini et al., ��Encapsulation Methods for Transport 698 of Layer 2 Frames over MPLS��, draft-martini-l2circuit-encap-mpls- 699 04.txt, November 2001, (work in progress). 701 [PWE3-CONTROL] Martini et. Al., ��Transport of Layer 2 Frames Over 702 MPLS��, draft-ietf-pwe3-control-protocol-00.txt, August 2002 (work in 703 progress) 705 [L2VPN-Signaling] Rosen et al., ��LDP-based Signaling for L2VPNs��, 706 draft-rosen-ppvpn-l2-signaling-02.txt, September 2002 708 [L2VPN-FW] "PPVPN L2 Framework", Andersson et. al., draft-ietf- 709 ppvpn-l2-framework-00.txt, August 2002 711 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft- 712 andersson-ppvpn-terminology-01.txt, June 2002 714 [INVARP] T.Bradley et al., ��Inverse Address Resolution Protocol��, 715 RFC2390, September 1998. 717 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol: Or 718 Converting Network Protocol Addresses to 48.bit Ethernet 719 Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, 720 November 1982. 722 [PROXY-ARP] Postel, J., "Multi-LAN Address Resolution", RFC 925, 723 October 1984. 725 14. Intellectual Property Considerations 727 Tenor Networks may seek patent or other intellectual property 728 protection for some of all of the technologies disclosed in this 729 document. If any standards arising from this document are or become 730 protected by one or more patents assigned to Tenor Networks, 731 Tenor intends to disclose those patents and license them on 732 reasonable and non-discriminatory terms. 734 Author's Address 736 Himanshu Shah 737 Tenor Networks 738 100 Nagog Park 739 Acton, MA 01720 740 Email: hshah@tenornetworks.com 742 Prabhu Kavi 743 Tenor Networks 744 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 746 100 Nagog Park 747 Acton, MA 01720 748 Email: Prabhu_kavi@tenornetworks.com 750 Eric Rosen 751 Cisco Systems 752 300 Apollo Drive, 753 Chelmsford, MA 01824 754 Email: erosen@cisco.com 756 Waldemar Augustyn 757 Email: waldemar@nxp.com 759 Giles Heron 760 PacketExchange Ltd. 761 The Truman Brewery 762 91 Brick Lane 763 LONDON E1 6QL 764 United Kingdom 765 Email: giles@packetexchange.net 767 Sunil Khandekar and Vach Kompella 768 TiMetra Networks 769 274 Ferguson Dr. 770 Mountain View, CA 94043 771 Email: sunil@timetra.com 772 Email: vkompella@timetra.com 774 Toby Smith 775 Laurel Networks 776 Omega Corporate Center 777 1300 Omega drive 778 Pittsburgh, PA 15205 779 Email: jsmith@laurelnetworks.com 781 Arun Vishwanathan 782 Force10 Networks 783 1440 McCarthy Blvd., 784 Milpitas, CA 95035 785 Email: arun@force10networks.com 787 Ashwin Moranganti 788 Appian Communications 789 35 Nagog Park, 790 Acton, MA 01720 791 Email: amoranganti@appiancom.com 793 Andrew G. Malis 794 Vivace Networks, Inc. 795 2730 Orchard Parkway 796 San Jose, CA 95134 797 Email: Andy.Malis@vivacenetworks.com 798 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 800 Steven Wright 801 Bell South Corp 802 Email: steven.wright@bellsouth.com 804 Vasile Radoaca 805 Nortel Networks 806 Email: vasile@nortelnetworks.com