Himanshu Shah Prabhu Kavi PPVPN Working Group Tenor Networks Internet Draft Draft-shah-ppvpn-arp-mediation-01.txt Eric Rosen Cisco Systems October 2002 Expires: April 2003 Waldemar Augustyn Consultant Sunil Khandekar Giles Heron Vach Kompella PacketExchange,Ltd TiMetra Networks Arun Vishwanathan Toby Smith Force10 Networks Laurel Networks Ashwin Moranganti Steven Wright Appian Communication Bell South Andrew Malis Vasile Radoaca Vivace Networks Nortel Networks ARP Mediation for IP Interworking of Layer 2 VPN 1.0 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Shah, et al. Expires April 2003 1 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 2.0 Abstract This draft addresses an issue in a particular kind of Layer 2 VPN, which provides point-to-point connectivity for IP traffic only. In this kind of VPN it is possible to form heterogeneous point-to-point links, where the two ends of the link use different technologies, e.g., one end is Ethernet and the other is Frame Relay or ATM. If two IP systems are connected via a heterogeneous point-to-point link, each may be using different address learning techniques, for instance, one using ARP on Ethernet and the other using Inverse ARP on Frame Relay. It is up to the Provider Edge routers to make these different techniques inter-work. This draft specifies the procedures which the Provider Edge (PE) routers should perform in order to allow correct operation across heterogeneous point-to-point links. 2.1 ID Summary SUMMARY This ID describes a mechanism by which PE devices learn the IP address of each locally attached CE device and distributes these to other PEs in order to mediate between the address resolution mechanisms used by the Customer Edge (CE) devices. The ID also points out difficulties, and in some cases, the inoperability of IGPs on the CE devices when interconnected by PE devices using IP L2 interworking VPN solution. RELATED DOCUMENTS Draft-kompella-ppvpn-l2vpn-01.txt draft-ietf-ppvpn-l2vpn-arch-00.txt draft-rosen-ppvpn-l2-signaling-02.txt draft-ietf-pwe3-control-protocol-00.txt draft-heinanen-inarp-uni-01.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Belongs in PPVPN WHY IS IT TARGETED AT THIS WG This document describes a mechanism to assist in Provider- Provisioned Layer 2 VPNs. JUSTIFICATION The IP L2 Interworking VPN solution described in [L2VPN-Kompella] introduces the concept of Layer 2 IP Interworking between disparate Layer 2 media (e.g., Ethernet and Frame Relay). However, it does not address how address resolution protocols should be handled between these disparate media types. This document describes how the PEs should mediate between the different address resolution protocols that each CE device uses. Also, there are issues when IGP on a Shah, et al. Expires April 2003 2 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt point-to-point link CE is interconnected with IGP on a multi- access/broadcast link CE. This document outlines these issues. 3.0 Overview A heterogeneous circuit is defined as a virtual circuit between two CE devices that consists of two disparate Attachment Circuits (AC) as the endpoints of a pseudowire. For example, a CE device on Ethernet is attached to a pseudowire whose other end point is a CE device on Frame Relay. The Attachment Circuit in this example could then be a VLAN tag on Ethernet interface emulated to the Attachment Circuit of a Frame Relay DLCI on the other end. Any attempt to make use of such heterogeneous circuits faces the following problems: 1. Different encapsulations may be used on the two Attachment Circuits. Frames from one Attachment Circuit can not just be forwarded unchanged on the other; rather the frames must be processed by some sort of interworking function. 2. A CE device may execute procedures which are specific to a particular type of Attachment Circuit (AC), and it may presuppose that the CE at the other end of the CE-CE circuit is executing those same procedures. Therefore, if the two CEs are attached via different types of Attachment Circuits, and are executing different AC-specific procedures, some means of mediating between those different procedures is needed. The [L2VPN-Kompella] specifies procedures for dealing with problem 1, above. In the proposed scheme, the interworking functions strip the Layer 2 header of the data packet at ingress and prepend the appropriate Layer 2 header at the egress. However, [L2VPN-Kompella] draft does not specify any procedures for dealing with the problem 2 above. For example, if a CE1 is an Ethernet-attached router, it expects to learn the IP address of its neighbor from a multicast routing control packet, and then expects to do ARP to learn the MAC address. However, if CE2 is attached via Frame Relay or ATM, it may use Inverse ARP to learn the IP address of its neighbor. Similarly, if CE2 is attached to PPP, it may seek the IP address of its neighbor during IPCP negotiations. Note that in either case, CE2 is seeking the IP address of its neighbor (i.e., CE1) while CE1 is seeking MAC address of its neighbor (i.e., CE2) for the IP address learned via other means. For CE1 and CE2 to interwork correctly, PE1 and PE2 must mediate the address-learning and resolution process. One option is to require each CE to have a static configuration of the IP addresses of all remote CEs. However, this is unwieldy and should be avoided whenever possible. A better approach is to have the service provider network automatically mediate between the various address resolution messages. In this document, we propose that the PE devices capture the address resolution protocol messages sent by the CE, and use this information to perform a mediation function between different address resolution procedures. The Shah, et al. Expires April 2003 3 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt methods of performing this mediation function are described in this document. In some cases, this mediation may not be possible, and these situations are also detailed in this document. Note that the PEs are capturing the CEÆs IP address information so that address resolution information can be passed to the CE. Under no circumstances does the PE make forwarding decision based on the Layer 3 addressing information. 4.0 Introduction In the traditional Layer 2 VPNs, the customer-facing links are required to be of the same data link type for each ææcircuitÆÆ. The PE device is only responsible for shuttling the data traffic from the link connecting to the local CE, over an MPLS core, and to the link connecting to the remote CE. This requirement of homogenous data link type is somewhat restrictive in building various network topologies. In [L2VPN-Kompella], it is observed that if all the traffic is known to be IP traffic, it is possible to relax this restriction by decapsulating the IP packet from one data link encapsulation, and simply reencapsulating it in the other. However, [L2VPN-Kompella] does not address all the issues. For example, consider a situation in which the service provider network creates a ææcircuitÆÆ between an Ethernet VLAN tag and a Frame Relay DLCI. Unless static ARP is used, the CE router connected to the Frame Relay interface precedes its IP activity with discovery of its neighborÆs IP address using the inverse ARP protocol [INVARP]. Similarly, the CE router on an Ethernet precedes its direct IP communication by binding its neighborÆs MAC address to its IP address via the ARP protocol [ARP]. However, the Inverse ARP on a point-to-point link is seeking disjoint information from an ARP on a broadcast link. The PE router is a logical place to perform a mediation function between these related, but incompatible, address resolution protocols. Performing this function in the PE simplifies the operation of the CE, and keeps pseudowire interworking transparent to the CE. For each IP Layer 2 interworking circuit, there are three logical steps to performing this address mediation: 1. Have the PE discover the attached CEÆs IP address (details in section 5.0). 2. Distribute this IP address to the PE at the remote end of the circuit (details in section 6.0). 3. Notify the attached CE about the remote CEÆs IP address (details in section 7.0). It is important to note that the dynamic learning and distribution of the attached CEÆs IP address is possible only for some data link Shah, et al. Expires April 2003 4 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt technologies. For other data links, static configuration cannot be avoided. However, ARP Mediation addresses the most common methods of creating Layer 2 VPNs, and therefore should be widely useful. 5.0 How the PE Discovers the Address of the Local CE Device For each Layer 2 IP interworking circuit, the PE creates and fills in a tuple consisting of the following: 1. Attached CEÆs IP address 2. Circuit Information 3. Remote CEÆs IP address This information is gathered using the mechanisms described below. The rest of this section describes how the IP address of the locally attached CE is learned. Section 6 describes how the learned IP address may be distributed to the remote PE using the signaling mechanisms of either [L2VPN-KOMPELLA] or [PWE3-CONTROL]. Section 7 describes how the remote PE processes the received cross-connect information for IP address resolution. 5.1 Ethernet Data Link We are assuming a Virtual Private Wire Service (VPWS) as described in [L2VPN-FW] for the CE/PE Attachment Circuit as an Ethernet containing only that CE and that PE. In order to learn the IP address of the CE device for a given Ethernet Attachment Circuit, the PE device may execute Router Discovery Protocol [RFC 1256] whereby a Router Discovery Request (ICMP - - router solicitation) message is sent using a source IP address of zero. The IP address of the CE device is extracted from the Router Discovery Response (ICMP - - router advertisement) message from the CE. The use of the router discovery mechanism by the PE is optional. The alternatives could include gleaning the source address field of any broadcasts to IP multicast/broadcast address and making sure that only one router on the local LAN is sending such broadcasts. It is also possible to simply wait for the CE to generate the ARP request for its neighbor or send gratuitous ARP on startup. The Ethernet address and protocol address can then be gleaned from the request. Once the PE learns the IP address of the CE, the CEÆs address is signaled to remote PE (section 6.0). The PE could periodically generate the ARP request message to the CEÆs IP address as a means to verify the continued existence of the CEÆs IP address and its binding to the Ethernet MAC address. The absence of a response from the CE device for a given number of retries could be used as a cause for a withdrawal of the IP address advertisement to the remote PE and entering into the address resolution phase to rediscover the attached CEÆs IP address. Note Shah, et al. Expires April 2003 5 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt that such ææheartbeatÆÆ scheme is needed only for broadcast links such as Ethernet, as a loss of CE may otherwise be undetectable. 5.2 Frame Relay Data Link A Frame Relay attached CE device generates an Inverse ARP request to obtain the IP address of the neighbor when the associated DLCI becomes active. Traditionally, a DLCI becomes active when the DCE signals LMI status active message as a result of the associated PVC path becoming operational. A PE device attached to a CE, connected either directly or through a set of Frame Relay switches, plays the role of an intermediate network node for cross-connect purposes. To a Frame Relay endnode (i.e. a CE), the presence of any intermediate Frame Relay switches, a pair of PEs and the fact that the remote CE may be Ethernet- attached, is all transparent. As far as Frame Relay CE is concerned, the Ethernet CE appears as the remote end point of the Frame Relay PVC path. However, for IP L2 interworking VPN purposes, the Ethernet CE and the Frame Relay CE are two IP end stations and it becomes necessary for the PE to play a role in address resolution to keep both end stations unaware of data link address resolution inconsistencies. When a PE processes the Frame Relay Inverse ARP request for a DLCI, it responds with an Inverse ARP reply containing the remote CEÆs IP address, if the address is known. If the PE does not yet have the remote CEÆs IP address, it does not respond, but notes the IP address of the local CE and the DLCI information. Subsequently, when the IP address of the remote CE becomes available, the PE may initiate the Inverse ARP request as a means to notify the local CE, the IP address of the remote CE. Also, note that the PE continues to learn the IP address of the CE from any multicast/broadcast IP packet that CE may generate irrespective of Inverse ARP protocol execution. 5.3 ATM Data Link A CE device attached to ATM data link can be configured to treat each PVC as an IP subnet. The PE participates in RFC 2225 defined inverse ATM ARP. When processing an Inverse ATM ARP request for a PVC, if the PE does not have the IP address associated with the cross-connect from the remote PE, it does not respond, but notes the IP address of the ATM attached CE and the PVC information. If the remote IP address is available, it responds with the Inverse ATM ARP reply. Subsequently, when the IP address of the remote CE becomes available, the PE may initiate the Inverse ATM ARP request as a means to notify the local CE the IP address of the remote CE. Shah, et al. Expires April 2003 6 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt Also note that the PE continues to learn the IP address of the CE from any multicast/broadcast IP packet that the CE may generate irrespective of Inverse ARP protocol execution. 5.4 PPP Data Link A CE device attached to a PPP data link participates in IPCP [RFC 1332] to obtain the neighborÆs IP address. If the PE device has the cross-connect and the IP address of the remote CE, it responds to the IPCP Configure-Request. However, if the PE does not have the remote CEÆs IP address, it does not respond to the local CEÆs IPCP request but simply notes its IP address. Subsequently, when the IP address of the remote CE becomes available, the PE generates IPCP Configure-Request to the local CE. Also, the PE must deny configurations such as header compression and encryptions in the NCP packets with such options. 6.0 IP Address Distribution Between PE There are two cross-connect information distribution mechanisms defined in [L2VPN-Kompella] and [PWE3-Control] respectively. The following sections discuss how these signaling protocols are extended to distribute the associated IP address information. 6.1 When To Distribute IP Address A PE device advertises the IP address of the attached CE only when the encapsulation type of the VPN is IP L2 interworking. It is quite possible that the IP address of a CE device is not available at the time the VC labels are advertised. For example, in Frame Relay the CE device dispatches inverse ARP request only when the DLCI is active; if the PE signals the DLCI to be active only when it has received the cross-connect information from the remote PE, a chicken and egg situation arises. In order to avoid such problems, the PE must be prepared to advertise the cross-connect information before the CEÆs IP address is known. When the IP address of the CE device does become available, the PE re-advertises the cross-connect information with an updated IP address field value. Similarly, if the PE detects invalidation of the CEÆs IP address (by methods described above) the PE must re-advertise the cross-connect information with a CE IP address field of zero to denote the withdrawal of the CEÆs IP address. The receiving PE may then wait for the IP address information from the remote PE before enabling the unicast IP traffic flow. If two CE devices are locally attached to the PE where, one CE is connected to an Ethernet data link and the other to a Frame Relay interface, for example, the IP addresses are learned in the same Shah, et al. Expires April 2003 7 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt manner described above. However, since the CE devices are local, the distribution of IP addresses for these CE devices is a local step. 6.2 BGP Based Distribution [L2VPN-Kompella] The [L2VPN-Kompella] draft defines the MP-BGP NLRI for the L2VPN cross-connect information. The NLRI contains the label block offset, the label base and the size (i.e., the length of the circuit status vector sub-TLV) tuple that provides a set of contiguous labels starting from the label base to correspond to a set of remote CE-IDs starting from the label block offset. We propose an IP address sub-TLV for this NLRI that accompanies this tuple. The type value is TBD. The length is the same as the length of the circuit status vector sub-TLV. The value field contains the length number of 4-byte fields where each field is an IP address that corresponds one-to-one with the labels represented by the label base and the length field. The PE device should note the label to IP address association by iterating through each IP field value in order. 6.3 LDP Based Distribution [PWE3-CONTROL] The [PWE3-CONTROL] uses LDP transport to exchange Layer-2 cross- connect information for a given VPN. The cross-connect information is represented as a VC FEC element that the LDP protocol distributes to the remote peer in downstream-unsolicited mode. This document proposes extensions to VC FEC element to support the IP L2 interworking as a new VPN type and to include the IP address information. 6.3.1 IP L2 Interworking Signaling The IP L2 interworking VPN type is advertised in the VC-Type field of the VC FEC as the value 0x000C. The ææinterface parameterÆÆ field in the VC FEC is defined in [PWE3- CONTROL] as follows. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The parameter ID is defined as follows: Shah, et al. Expires April 2003 8 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt Parameter ID Length Description 0x01 4 Interface MTU in octets. 0x02 4 Maximum Number of concatenated ATM cells. 0x03 up to 82 Optional Interface Description string. 0x04 4 CEM [8] Payload Bytes. 0x05 4 CEM options. The Length field is defined as the length of the interface parameter including the parameter ID and the length field itself. We propose an additional parameter for the parameter ID. 0x06 4 IP address of CE The IP address interface parameter contains the IP address associated with the advertised VC-ID. If the IP address is not known, this interface parameter may not be present in the advertisement. If present, it may contain the IP address value as 0.0.0.0. In either case, the receiving PE processes the information as IP address association unknown for the advertised VC-ID. We recommend two options for signaling such ææVC associated informationÆÆ that are currently present as the interface parameter field in the VC FEC. 1. The entire ææinterface parameterÆÆ field is either removed or duplicated from the VC FEC to the ææoptional parameterÆÆ field of the LDPÆs Label Mapping Message. 2. A new VC Status FEC is introduced that accompanies the VC FEC in the LDPÆs Label Mapping Message. The ææinterface parameterÆÆ field of the VC FEC is then either removed or duplicated from the VC FEC to the VC Status FEC. We intend to work with authors of [PWE3-Control] and [Rosen- Signaling] to find the most suitable solution for extensions (such as IP address, IP address and MAC address, interface status, etc.) that are generic, in a backward compatible fashion. 7.0 How CE Learns The Remote CEÆs IP address Once the PE has received the remote CEÆs IP address information from the remote PE, it will either initiate an address resolution request or respond to an outstanding request from the attached CE device. 7.1 Ethernet Data Link When the PE learns the remote CEÆs IP address from the Layer 2 VPN advertisement (as described above), it may or may not know the local CEÆs IP address. If the local CEÆs IP address is not known, the PE must wait for the arrival of an IGP broadcast packet, a RDP response packet or an ARP request packet from the local CE. If, however, local CEÆs IP address is already known, the PE may choose to Shah, et al. Expires April 2003 9 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt generate an unsolicited ARP message to notify the local CE about the binding of the remote CEÆs IP address with the PEÆs own MAC address. In either case, whenever an ARP request is generated by the local CE, the PE must proxy ARP response using its own MAC address as the source hardware address and remote CEÆs IP address as the source protocol address. The PE must respond only to those ARP requests whose destination protocol address matches the remote CEÆs IP address. 7.2 Frame Relay Data Link If a PE has received new cross-connect information from the remote PE, the corresponding local DLCI may not yet be active. The PE should use the cross-connect information to activate the DLCI via LMI and schedule an inverse ARP request. The PE may choose to delay the generation of the Inverse ARP request in order to allow the attached CE to generate the request first. However, it is possible that the PE may never receive the Inverse ARP request, nor the response to its own request. This could occur for a number of reasons, 1. The IP protocol is not enabled on the CE device at the time when the DLCI was activated. This is not an issue since the cross connect information exchange is not predicated on learning of the CEÆs IP address. When the IP protocol is enabled on the CE device, an inverse ARP request will be generated. 2. No Inverse ARP request is generated if the CE is already configured with the remote CEÆs IP address, hence there is no need to generate the request. Since the PE does not know of this situation, it must generate an Inverse ARP request using the remote CEÆs IP address. The response from the CE enables the PE to learn its IP address. 3. The CE router does not support the Inverse ARP protocol or the Inverse ARP protocol is disabled. We have found through experimentations that most implementations do respond to the Inverse ARP Request even when Inverse ARP protocol is disabled (it seems that disabling of protocol only means that request generation is disabled). However, if the Inverse ARP Protocol is not supported, the PE needs to be configured with the IP address of the attached CE. This facilitates distribution of the IP address to the remote PE. 7.3 ATM Data Link The PE device should generate an Inverse ATM ARP request when the IP address of the remote cross-connected CE device becomes available. The role of the PE device in handling address resolution for the IP L2 interworking cross-connect for ATM VCs is similar to the behavior described above for Frame Relay VCs. As always, static configuration of the local CEÆs IP address is an available option, when all else fails. Shah, et al. Expires April 2003 10 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 7.4 PPP The PE device should respond to the local CEÆs IPCP Configure- Request with the remote CEÆs IP address. However, if the IP address is not available, the PE should postpone the response. When the remote CEÆs IP address becomes available, the PE must initiate the Configure-Request using the remote CEÆs IP address. As noted earlier, all other configuration options related to compression, encryptions, etc., should be rejected. 8.0 Data Forwarding The IP L2 Interworking permits only IP data packets to be exchanged over the pseudowire. The following description from [L2VPN-Kompella] shows how data packets are handled by the ingress and egress PE. At the ingress PE, an L2 frame's L2 header is completely stripped off and is carried over as an IP packet through a tunnel to the egress PE. The forwarding decision is still based on the L2 circuit information of the incoming IP frame. At the egress PE, the IP packet is encapsulated back in an L2 frame and transported over to the destination CE. The forwarding decision at the egress PE is based on the VC label as discussed in [MARTINI-ENCAP]. The L2 technology between egress PE and CE is independent of the L2 technology between ingress PE and CE. The PE should observe the following forwarding rules when processing IP data packets for interworking circuits. 1. If the PE has not learned the IP address of the local CE and the IP packet received from the local CE is multicast or a broadcast, the PE should learn the source IP address and forward the packet to the corresponding pseudowire. If the Attached Circuit is Ethernet, it should also learn the MAC address of the CE device. The PE must forward multicast/broadcast IP packet from the Attachment Circuit to the pseudowire irrespective of the status of the remote CEÆs IP address. 2. If the PE has not learned the IP address of the local CE, the PE should forward the multicast/broadcast IP packet from the pseudowire to the local Attachment Circuit. If the Attachment Circuit is Ethernet, PE must translate IP multicast/broadcast destination to appropriate MAC DA. 3. If a PE has the local and the remote CEsÆ IP addresses, all IP packets are forwarded in both directions between the Attachment Circuit and the pseudowire. When the Attachment Circuit is Ethernet, a unicast IP packet from the pseudowire is prepended with the Ethernet MAC header using the MAC DA of the CE (obtained during the learning phase) and the MAC SA of the PE. 4. All Unicast IP packets received from the Attachement Circuit and the pseudowire are dropped until the local and remote CEsÆ IP addresses are known. Shah, et al. Expires April 2003 11 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 9.0 Use of IGPs with IP L2 Interworking VPNs In an IP L2 interworking VPN, when an IGP on a CE connected to a broadcast link is cross-connected with an IGP on a CE connected to a point-to-point link, there are routing protocol related issues that must be addressed. The link state routing protocols are cognizant of the underlying link characteristics and behave accordingly when establishing neighbor adjacencies, representing the network topology, and passing protocol packets. 9.1 OSPF The OSPF protocol treats broadcast link type with a special procedure that engages in neighbor discovery to elect a designated and a backup designated router (DR and BDR respectively) with which it forms adjacencies. However, these procedures are neither applicable nor understood by OSPF running on a point-to-point link. By cross-connecting two neighbors with disparate link types, an IP L2 interworking VPN has the potential to experience connectivity issues. Additionally, the link type specified in the router LSA will not match for two routers that are supposedly sharing the same link type. Finally, each OSPF router generates network LSAs when connected to a broadcast link such as Ethernet, receipt of which by an OSPF router on the point-to-point link further adds to the confusion. Fortunately, the OSPF protocol provides a configuration option (ospfIfType), whereby OSPF will treat the underlying physical broadcast link as a point-to-point link. It is strongly recommended that all OSPF protocols on CE devices connected to Ethernet interfaces use this configuration option when attached to a PE that is participating in an IP L2 Interworking VPN. 9.2 IS-IS The IS-IS protocol sends a LAN Hello PDU (IIH packet) with the MAC address and the IP address of the intermediate system (i.e., CE device) when attached to Ethernet links. The CE device expects its neighbor to insert its own MAC and IP address in the response. If the neighbor is connected via a point-to-point link type, the LAN Hello PDU will be silently discarded. Similarly, Hello PDUs on the point-to-point link do not contain any MAC address, which will confuse a neighbor on an Ethernet link, if these two neighbors were cross-connected via above described mechanisms. Thus, use of the IS-IS protocol on CE devices presents problems when interconnected by disparate data link types in an IP L2 interworking Shah, et al. Expires April 2003 12 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt VPN environment. There are some mechanisms defined in draft-ietf- isis-igp-p2p-over-lan-00.txt to accommodate point-to-point behavior over broadcast networks. The feasibility of such techniques to solve this problem is under review. It is important to note that the use of the IS-IS protocol in enterprise networks (i.e., CE routers) is less common. The IS-IS related difficulties for IP L2 Interworking VPNs, hence are minimized. 9.3 RIP RIP protocol broadcasts RIP advertisements every 30 seconds. If the group/broadcast address snooping mechanism is used as described above, the attached PE can learn the advertising (CE) routerÆs IP address from the IP header of the advertisement. No special configuration is required for RIP in this type of Layer 2 IP interworking VPN. 10.0 Conclusion The three step procedure of discovering the IP address of a local CE device, distributing the CEÆs IP address to the remote PE and notifying the local CE of the remote CEÆs IP address, as described in this document provides for reduced configuration of the PE devices used for IP L2 Interworking VPNs. There are cases where the manual configuration of the CEÆs IP address is unavoidable. These cases include the use of interfaces that support address resolution but do not have address resolution enabled, such as unnumbered interfaces on the CE device. It is also important to note that IP address changes on the CE devices may require manual intervention (e.g., soft reset of the attached port) on the PE device. For most common interface types, however, the procedures described in this document enhance the IP interworking solution of [L2VPN- Kompella] by reducing the amount of configuration required on the PE devices. 11.0 Acknowledgements Authors would like to thank Bruce Lasley and other folks within Tenor who participated in discussions related to this draft. 12.0 Security Considerations The security aspects of this solution will be discussed at a later time. Shah, et al. Expires April 2003 13 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 13.0 References [L2VPN-Kompella] Kompella et al., ææMPLS based Layer 2 VPNsÆÆ, draft- kompella-ppvpn-l2vpn-01.txt, November 2001. [L2VPN-ENCAP] Martini et al., ææEncapsulation Methods for Transport of Layer 2 Frames over MPLSÆÆ, draft-martini-l2circuit-encap-mpls- 04.txt, November 2001, (work in progress). [PWE3-CONTROL] Martini et. Al., ææTransport of Layer 2 Frames Over MPLSÆÆ, draft-ietf-pwe3-control-protocol-00.txt, August 2002 (work in progress) [L2VPN-Signaling] Rosen et al., ææLDP-based Signaling for L2VPNsÆÆ, draft-rosen-ppvpn-l2-signaling-02.txt, September 2002 [L2VPN-FW] "PPVPN L2 Framework", Andersson et. al., draft-ietf- ppvpn-l2-framework-00.txt, August 2002 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft- andersson-ppvpn-terminology-01.txt, June 2002 [INVARP] T.Bradley et al., ææInverse Address Resolution ProtocolÆÆ, RFC2390, September 1998. [ARP] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [PROXY-ARP] Postel, J., "Multi-LAN Address Resolution", RFC 925, October 1984. 14. Intellectual Property Considerations Tenor Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Tenor Networks, Tenor intends to disclose those patents and license them on reasonable and non-discriminatory terms. Author's Address Himanshu Shah Tenor Networks 100 Nagog Park Acton, MA 01720 Email: hshah@tenornetworks.com Prabhu Kavi Tenor Networks Shah, et al. Expires April 2003 14 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt 100 Nagog Park Acton, MA 01720 Email: Prabhu_kavi@tenornetworks.com Eric Rosen Cisco Systems 300 Apollo Drive, Chelmsford, MA 01824 Email: erosen@cisco.com Waldemar Augustyn Email: waldemar@nxp.com Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Email: giles@packetexchange.net Sunil Khandekar and Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Email: sunil@timetra.com Email: vkompella@timetra.com Toby Smith Laurel Networks Omega Corporate Center 1300 Omega drive Pittsburgh, PA 15205 Email: jsmith@laurelnetworks.com Arun Vishwanathan Force10 Networks 1440 McCarthy Blvd., Milpitas, CA 95035 Email: arun@force10networks.com Ashwin Moranganti Appian Communications 35 Nagog Park, Acton, MA 01720 Email: amoranganti@appiancom.com Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com Shah, et al. Expires April 2003 15 Internet Draft draft-shah-ppvpn-arp-mediation-01.txt Steven Wright Bell South Corp Email: steven.wright@bellsouth.com Vasile Radoaca Nortel Networks Email: vasile@nortelnetworks.com Shah, et al. Expires April 2003 16