Himanshu Shah Prabhu Kavi PPVPN Working Group Tenor Networks Internet Draft draft-shah-ppvpn-arp-mediation-00.txt Eric Rosen Cisco Systems February 2002 Expires: August 2002 Waldemar Augustyn Consultant Giles Heron PacketExchange,Ltd Sunil Khandekar Vach Kompella TiMetra Networks Vijay Aggarwal Gotham Networks Jeremy Brayley Rafael Francis Laurel Networks Arun Vishwanathan Force10 Networks Ashwin Moranganti Appian Communications 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 Shah, et al. Expires August 2002 1 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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, e.g., one is using ARP and the other Inverse ARP. It is up to the Provider Edge routers to make these different techniques interwork. This draft specifies the procedures, which the Provider Edge 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 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-00.txt draft-martini-l2circuit-trans-mpls-08.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 Shah, et al. Expires August 2002 2 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 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 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 VCs as the endpoints of an Emulated VC. For example, a CE device on Ethernet is attached to an emulated VC whose other end point is a CE device on frame relay. The attachment VC in this example could then be a VLAN tag on Ethernet interface emulated to the attachment VC of a frame relay DLCI on the other end. While such heterogeneous circuits do not work in general, they can be made to work on the assumption that all their traffic is IP traffic and the Emulated VC performs inter- working function for the IP data frames. The [L2VPN-Kompella] ID describes methodologies that allow heterogeneous layer 2 circuits to be mapped through MPLS tunnels to remote sites that belong to the same VPN. In this "IP L2 interworking" scheme the inter-working functions consist of stripping layer 2 header (e.g. Ethernet MAC header) of the data packet at ingress, dispatching the raw IP packets to the egress, and prepending the appropriate Layer 2 header (e.g. RFC 2427 header for frame relay) before sending it to the attached CE device. The problem in such IP L2 Interworking scheme is that, 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, it expects to use Inverse ARP to learn the IP address of its neighbor, and it does not send, nor may it respond to ARP messages over the frame relay interface. For CE1 and CE2 to inter-work correctly, PE1 and PE2 will need to mediate the address learning and resolution process. One option would be 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 would be to have the service provider network automatically mediate between the various ARP 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 ARP message formats. The 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 addresses information solely for the purpose of mediating between different ARP formats. Shah, et al. Expires August 2002 3 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt The end-to-end service remains a point-to-point layer 2 service where forwarding decisions are solely based upon the circuit identifier (e.g. DLCI). 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 where 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 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 pseudo-wire 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 PEs discover the attached CEÆs IP addresses. 2. Distribute this IP address to the PE at the remote end of the circuit. 3. Notify the attached CE about the remote CEÆs IP address. In some cases these steps are disjoint while in other cases they could be part of a single step based on whether the IP address of the remote CE device was received along with the cross-connect information. It is important to note that the dynamic learning and distribution of the attached CEÆs IP addresses is possible only for some data link technologies. For other data links, static configuration cannot be avoided. However, this ARP mediation addresses the most common Shah, et al. Expires August 2002 4 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt methods of creating Layer 2 VPNs, and therefore should be widely useful. 5.0 IP address discovery of 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 Info 3. Remote CEÆs IP address This information is gathered using the mechanisms described below. The rest of this section describes how 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 either of [L2VPN-KOMPELLA] or [MARTINI-TRANS]. Section 7 describes how remote PEs process the received cross-connect information with or without IP address for IP address resolution purposes with local CE. 5.1 Ethernet data link PE device attached to Ethernet data link is either cognizant or noncognizant of IEEE802.1Q based VLAN tagging. When practicing 802.1Q based VLAN tagging, each VLAN tag could represent a circuit or a pseudo virtual wire that connects to exactly one remote endpoint through a pair of PE devices. Alternatively, the entire Ethernet port may be treated as a single endpoint that is connected to a single remote endpoint via a pair of PE devices. In either case, only one Ethernet IP end station (CE device) is presumed to be present for participation within the IP interworking based Layer 2 VPN. In order to learn the IP address of the CE device for a given Ethernet circuit (i.e. Ethernet port or Ethernet port + VLAN), PE device may execute router discovery protocol [RFC 1256] whereby a router discovery request (ICMP - router solicitation) message is sent on each circuit using source IP address as zero. The IP address of the CE device is extracted from the router discovery response (ICMP - router advertisement) message from the CE and associated with the circuit. The use of router discovery mechanism by the PE is optional. The alternatives could include gleaning source address field of any broadcasts to IP multicast or 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 local router to generate ARP Shah, et al. Expires August 2002 5 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt request for its neighbor. The Ethernet address and protocol address can then be gleaned from the request. Once IP address of the CE device is learned, PE periodically generates ARP request message as a mean to verify the existence of CEÆs IP address and itÆs binding to the Ethernet MAC address. The absence of response from the CE device for a given number of retries is used as a cause for a withdrawal of IP address advertisement to the remote PE and entering into the address resolution phase to rediscover the attached CEÆs IP address. 5.2 Frame Relay data link A frame relay attached CE device generates 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 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. CE), presence of intermediate frame relay switches and pair of PE separated by MPLS cloud along with a remote CE on perhaps Ethernet, is transparent and appear as though Ethernet based CE is remote end point of frame relay PVC path. However, for IP L2 interworking VPN purposes, Ethernet CE and frame relay CE are two IP end stations and it becomes necessary for PE to play a role in address resolution to keep each end stations unaware of data link inconsistency. When processing frame relay inverse ARP request for a DLCI, if the PE does not have IP address associated with the cross-connect from the remote PE, it does not respond, but notes the IP address of the frame relay attached CE and the DLCI information. If the remote IP address were available, it responds with inverse ARP reply. Subsequently, when the IP address of the remote CE becomes available, PE may initiate the inverse ARP request as a mean to notify the neighbor of the IP address. 5.3 ATM data link A CE device attached to ATM data link treats each PVC as an IP subnet. PE participates in RFC 2225 defined inverse ATM ARP. When processing inATMARP request for a PVC, if the PE does not have 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 were available it would respond with inATMARP reply. Subsequently, when the IP address of the remote CE becomes available, PE may initiate the inATMARP request as a mean to notify the neighbor of the IP address. Shah, et al. Expires August 2002 6 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 6.0 IP address distribution between PE There are two cross-connect information distribution mechanisms defined each in [L2VPN-Kompella] and [MARTINI-TRAN]. Following sections discusses how these signaling protocols are extended to distribute the associated IP address information. 6.1 BGP based distribution [L2VPN-Kompella] The [L2VPN-Kompella] draft has defined the MP-BGP NLRI for the L2VPN cross-connect information. The NLRI contains label block offset, label base and the size (i.e. length of circuit status vector sub- TLV) tuple that provides a set of contiguous labels starting from label base to correspond to a set of remote CE-Ids starting from label block offset. We propose an IP address sub-TLV for this NLRI that accompany this tuple. The type value is TBD. The length is same as length of 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 length field. The PE device should note the label to IP address association by iterating through each IP field value in order. 6.2 LDP based distribution [MARTINI-TRANS] The [MARTINI-TRANS] 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 LDP protocol distributes to remote peer in downstream-unsolicited mode. This document proposes extensions to VC FEC element to support the IP L2 inteworking as a new VPN type and to include the IP address information. 6.2.1 IP L2 Interworking encapsulation 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 [MARTINI-TRANS] 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 | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shah, et al. Expires August 2002 7 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt The parameter ID is defined as follows: 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 length field itself. We propose 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 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, receiving PE processes the information as IP address association unknown for the advertised VC-ID. 6.2.2 Data forwarding When participating in IP L2 interworking VPN, the receiving PE must check the received access VC type against the local access (or attachment) VC type for the matching cross-connect. When the access VC types are identical, IP L2 interworking aspects of the cross- connect should be ignored and revert to traditional data forwarding mechanisms as defined for such VC type in [MARTINI-ENCAP]. However, when access VC types are different and the VC type field is IP L2 Interworking, the mechanisms defined in this document should be followed. The IP L2 Interworking permits only IP data packets to be exchanged over the emulated VC. 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. Shah, et al. Expires August 2002 8 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 6.3 IP address distribution operation 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 of advertisements. For example, in frame relay the CE device dispatches inverse ARP request only when the DLCI is active and if the PE signals 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 advertise the cross-connect information with or without (i.e. no IP TLV or 0.0.0.0) the corresponding IP address. When the IP address of the CE device does become available, a new advertisement is generated with updated IP address field value. Similarly, If PE detects invalidation of CEÆs IP address (by methods described above), PE may re-advertise the cross-connect information without IP address or with IP address as zero to denote the withdrawal of IP address. The receiving PE may then wait for the IP address information from the remote PE before enabling the unicast IP traffic flow. 7.0 How CE learns IP address of remote CE Once the PE has learned IP address to label association from the remote PEÆs cross-connect advertisement, it can either initiate the address resolution request or respond to the request from the attached CE device. 7.1 Ethernet data link When PE learns about remote CEÆs IP address from the layer 2 VPN advertisement (as described above), it may or may not know local CEÆs IP address. If local CEÆs IP address is not known, it must wait for the arrival of either IGP broadcast packet or RDP response or an ARP request from the local CE. If, however, local CEÆs IP address is already known, PE may choose to generate unsolicited ARP (gratuitous) message to notify the local CE about the association of remote CEÆs IP address and the PEÆs own MAC address. In either case, as and when an ARP request is generated by the local CE, PE must proxy ARP response using his own MAC address as the source hardware address and remote CEÆs IP address as source protocol address. PE must respond only to those ARP requests whose destination protocol address matches to remote CEÆs IP address. If two CE devices are locally attached to PE where one CE is connected to Ethernet data link and other to Frame relay data link for example, the IP addresses are learned in the same manner as described above. However, since the CE devices are local, the distribution of IP addresses for these CE devices is a local step. Shah, et al. Expires August 2002 9 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 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 be active. PE should use the cross-connect information to activate the DLCI via LMI and schedule the inverse ARP request. The PE may choose to delay generation of inverse ARP request in order for attached CE to generate the request first. However, it is possible that PE may never get inverse ARP request nor may it get the response to its own request. This may be the result of IP protocol not being enabled on CE device at the time when DLCI was activated. This is not an issue since cross connect information exchange is not predicated on learning of CEÆs IP address. As and when the IP protocol is enabled on the CE device, an inverse ARP request would be forthcoming. It is also possible that CE router may never generate inverse ARP request as it may already be configured with IP address of the remote end point and/or inverse ARP is disabled or not supported. If inverse ARP protocol is supported (disabled or not), CE router would still respond to inverse ARP request even when it already knows the IP address of the remote end station. However, if inverse ARP protocol is not supported, PE is required to be configured with the IP address of the attached CE router in order for the PE to distribute the IP address as part of the cross-connect information to the remote PE. 7.3 ATM data link The PE device should generate the inAtmARP request when the IP address of the remote cross-connected CE device becomes available. The role of PE device in handling address resolution for the IP L2 interworking cross-connect for local ATM PVC is similar to that of local frame relay PVC. It is also possible that ATM end station is participating in RFC 1577 style dynamic ARP mechanisms using the ATM ARP server. This document leaves the option of participation with ATM ARP server to vendorÆs implementation. As always, static configuration of the local CEÆs IP address is another option that PE may use. 8.0 Multipoint IGP to point-to-point IGP issues In IP L2 interworking VPN, when an IGP on CE connected to a broadcast link is cross-connected with an IGP on 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. 8.1 OSPF Shah, et al. Expires August 2002 10 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt OSPF protocol treats broadcast link type with a special procedure that engages in neighbor discovery to elect a designated and a backup designated (DR and BDR respectively) router to form adjacency with. 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 in IP L2 interworking VPN causes this confusion that must be avoided. Additionally, link type specified in router LSA would appear different for two routers that are supposedly to be present on the same link. Also, OSPF router generates network LSAs when connected to broadcast link such as Ethernet, receipt of which by an OSPF router on the point-to-point link adds to the confusion. Fortunately, OSPF protocol provides a configuration option (ospfIfType), whereby OSPF would 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 data link must use this configuration when attached PE that is participating in IP L2 Interworking VPN. 8.2 IS-IS IS-IS protocol sends LAN Hello PDU (IIH packet) on Ethernet link with MAC address and IP address of the CE device. It expects neighbor to insert his own MAC and IP address in the response. If the neighbor is cross-connected to a point-to-point remote CE device, the LAN Hello PDU would be silently discarded. Similarly, Hello PDU on the point-to-point link does not contain any MAC address, which confuses the cross-connected neighbor on Ethernet link. Thus, IS-IS protocol on the CE devices presents problem when interconnected by disparate data link types in IP L2 interworking 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 network. The feasibility of such technique to solve this problem is under review. 8.3 RIP RIP protocol broadcasts RIP advertisements every 30 seconds. If multicast snooping mechanism is used, PE can learn the advertising 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. 9.0 Conclusion The three step procedure; discovering IP address of local CE device, distribution of the IP address to remote PE and notifying the IP Shah, et al. Expires August 2002 11 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt address to the attached CE device; described in this document provides for reduced configuration of the PE devices used for IP- interworking solution. There are cases where the manual configuration of the IP address is not avoidable. These cases relate to either some of the data links like, Cisco HDLC, that do not support the address resolution protocol or that address resolution is disabled by, for example, use of unnumbered interface in the CE device. It is also important to note that IP address changes on the CE devices may require manual interventions (e.g. soft reset of the attached port) on the PE device. For most common cases, the procedure described in this document enhances the IP interworking solution of [L2VPN-Kompella]. 10.0 Acknowledgements Authors would like to thank Tim Mancour, Bruce Lasley, Bill Townsend, Arnold Sodder and other folks within Tenor who participated in discussions related to this draft. 11.0 Security Considerations The security aspects of this solution will be discussed at a later time. 11.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). [L2VPN-TRANS] Martini et al., "Transport of Layer 2 frames over MPLS", draft-martini-l2circuit-trans-mpls-08.txt. November 2001, (work in progress) [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. Shah, et al. Expires August 2002 12 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt Author's Address Himanshu Shah Tenor Networks 100 Nagog Park Acton, MA 01720 Email: hshah@tenornetworks.com Prabhu Kavi Tenor Networks 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 Vijay Aggarwal Gotham Networks 15 Discovery Way Acton, MA 01720 Email: vaggarwal@gothamnetworks.com Jeremy Brayley and Rafael Francis Laurel Networks Omega Corporate Center 1300 Omega drive Pittsburgh, PA 15205 Email: jbrayley@laurelnetworks.com Email: rfrancis@laurelnetworks.com Shah, et al. Expires August 2002 13 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt Arun Vishwanathan Force10 Networks 1440 McCarthy Blvd., Milpitas, CA 95035 Email: arun@force10networks.com Ashwin Mornaganti Appian Communications 35 Nagog Park Acton, MA 01720 Email: amoranganti@appiancom.com Shah, et al. Expires August 2002 14