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