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