Himanshu Shah
Consultant
K.Arvind
Consultant
PPVPN Working Group
Internet Draft
Draft-shah-ppvpn-ipls-01.txt Eric Rosen
Francois Le Faucheur
March 2003 Cisco Systems
Expires: September 2003
Giles Heron
PacketExchange,Ltd
Vasile Radoaca
Nortel Networks
IP over LAN Service (IPLS)
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.
Abstract
A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect
systems across a wide-area or metropolitan-area network, making it
appear to those systems as if they are interconnected on a private
LAN. The systems which are interconnected in this way may
themselves be LAN switches. If, however, the interconnected systems
are NOT LAN switches, but rather are IP hosts or IP routers, certain
simplifications are possible. We call this simplified type of
virtual private LAN service an ôIP over LAN Serviceö (IPLS). In
Shah, et al. Expires September 2003 1
Internet Draft draft-shah-ppvpn-IPLS-01.txt
IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and
frames are forwarded based on their MAC Destination Addresses.
However, the maintenance of the MAC forwarded tables is done via
signaling, rather than via the ôMAC Address Learningö procedures of
IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages
are proxied, rather than being carried transparently. This draft
specifies the protocols and procedures for support of the IPLS
service.
1.0 Boiler Plate for Sub-IP Area Drafts
RELATED DOCUMENTS
draft-ietf-ppvpn-l2-framework-01.txt
draft-lasserre-vkompella-ppvpn-vpls-02.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
This document provides a detailed description for IP over LAN
Service (IPLS), which is discussed in the L2 PPVPN Framework [PPVPN-
FWK]. The VPLS [VPLS] services of L2VPN require PE devices to
function as MAC learning bridges. IPLS is a solution for a specific
topology where MAC learning capabilities are not required for VPLS
services, because user data traffic is restricted to IP, and the CE
devices are not LAN switches.
2.0 Overview
As emphasized in [VPLS], Ethernet has become popular as an access
technology in Metropolitan and Wide Area Networks. [VPLS] describes
how geographically dispersed customer LANs can be interconnected
over a service providerÆs network using Layer 2 VPNs. The VPLS
service is provided by Provider Edge (PE) devices, and it is
provided to Customer Edge (CE) devices. The VPLS architecture
provides such services by incorporating bridging functions such as
MAC address learning in the PE devices.
There are Provider Edge platforms, both existing and forthcoming,
which have been designed primarily to be IP routers, rather than to
be LAN switches. It can be fairly straightforward to add a MAC
Shah, et al. Expires September 2003 2
Internet Draft draft-shah-ppvpn-IPLS-01.txt
address lookup capability to these platforms, and to run their LAN
interfaces in promiscuous mode, so that they can forward frames
based on the MAC Destination Address of the frame. It is less
straightforward to add the IEEE 802.1D MAC Address learning
capability to these platforms. However, as discussed in [L2VPN-
FWK], in scenarios where the CE devices are NOT LAN switches, but
rather are IP hosts or IP routers, it is possible to provide the
virtual private LAN service without requiring IEEE 802.1D MAC
address learning/aging on the PE. Due to these restrictions, such a
service is referred to as an "IP LAN Service", or IPLS. Requirements
for such an IPLS service are presented in [L2VPN-REQTS]. The purpose
of this draft is to specify a solution optimized for this IPLS
service.
Consequently, IPLS allows a service provider to provide a VPLS-like
service by using PE routers that are not designed to perform general
LAN bridging functions. However one must be willing to accept the
restriction that the Virtual LAN service be used for IP traffic
only, and not used to interconnect CE devices that are themselves
LAN switches. This seems like an acceptable restriction in many
environments, given that IP is the predominant type of traffic in
today's networks.
In IPLS, a PE device implements multi-point LAN connectivity for IP
traffic using the following key functions:
1. Discovery: Each Provider Edge (PE) device discovers IP/MAC
address associations for the locally attached Customer Edge
(CE) devices, for each IPLS instance configured on the PE
device.
2. Pseudowires (PW) for Unicast Traffic: For each locally attached
CE device in a given IPLS instance, a PE device sets up a
pseudo-wire (VC-LSP) to each of the other PEs that supports the
same IPLS instance.
For instance, if PEx and PEy both support IPLS I, and PEy is
locally attached to CEw and CEz, PEy will initiate the setup of
two pseudowires between itself and PEx. One of these will be
used to carry unicast traffic from any of PExÆs CE devices to
CEw. The other will be used to carry unicast traffic from any
of PExÆs CE devices to CEz.
Note that these pseudowires carry traffic only in one
direction. Further, while the pseudowire implicitly identifies
the destination CE of the traffic, it does not identify the
source CE; packets from many CEs may be freely intermixed on a
given pseudowire.
3. Pseudowires for Multicast Traffic: In addition, every PE
supporting a given IPLS instance will set up a special
ômulticast pseudowireö to every other PE in that IPLS instance.
If, in the above example, one of PExÆs CE devices sends a
Shah, et al. Expires September 2003 3
Internet Draft draft-shah-ppvpn-IPLS-01.txt
multicast packet, PEx would forward the multicast packet to PEy
on the special multicast pseudowire. PEy would then send a
copy of that packet to CEw and a copy to CEz.
Thus when a PE sends a multicast packet across the network, it
sends one copy to each remote PE (supporting the given IPLS
instance). If a particular remote PE has more than one CE
device in that IPLS instance, the remote PE must replicate the
packet and send one copy to each of its local CEs.
As with the pseudowires that are used for unicast traffic,
packets travel in only one direction on these pseudowires, and
packets from different sources may be freely intermixed.
4. Signaling: The necessary pseudowires can be set up and
maintained using the LDP-based signaling procedures described
in [PWE3-CONTROL] and/or [ROSEN-SIG]. Use of other signaling
procedures is for further study.
A PE may assign the same label to each of the unicast
pseudowires that leads to a given CE device, in effect creating
a multipoint-to-point pseudowire.
Similarly, a PE may assign the same label to each of the
multicast pseudowires for a given IPLS instances, in effect
creating a multipoint-to-point pseudowire.
When setting up a pseudowire to be used for unicast traffic,
the PE must also signal the IP address and the MAC address of
the corresponding CE device.
5. Proxy ARP: Distribution of IP/MAC address associations to
remote PE devices via PW signaling enables each PE device to
function as a proxy ARP server for CE devices attached to other
PE devices. This makes it possible for any CE device to ARP for
the MAC addresses of remote CE devices.
6. Forwarding: A PE device programs its Forwarding Information
Base using the CE MAC addresses and VC labels signaled through
the PW signaling. Unicast IP traffic from the local CEs is then
switched to the proper VC-LSP based on the destination MAC
address. Multicast IP traffic from the local CEs is replicated
by the local PE over all the multicast VC-LSPs for that IPLS
instance and is then replicated by each remote PE onto all its
Attachment Circuits for that IPLS instance.
Both VPLS [VPLS] and IPLS require the ingress PE to forward a frame
based on its destination MAC address. However, two key differences
between VPLS and IPLS can already be noted from the above
description:
Shah, et al. Expires September 2003 4
Internet Draft draft-shah-ppvpn-IPLS-01.txt
. In VPLS, MAC entries are placed in the FIB of the ingress PE as
a result of IEEE 802.1D MAC address learning (which occurs in
the data plane) while in IPLS MAC entries are placed in the FIB
as a result of pseudowire signaling operations (control plane).
. In VPLS, the egress PE looks up a frameÆs MAC destination
address to determine the customer-facing interface out which
the frame must be sent; in IPLS, the choice of interface is
based entirely on the VC-label.
The following sections describe the details of the IPLS scheme.
2.1 Terminology
IPLS IP over LAN service (class of VPLS for IP
only).
IPLS network A collection of PE nodes supporting the IPLS
service and the mechanisms described in this
document, including the Extended LDP based PW
signaling between them.
IPLS Service A single service instance of IPLS emulating a
LAN segment for IP data traffic.
MPt-Pt PW Multipoint-to-Point Pseudowire. A pseudowire
that carries traffic from remote PE devices to
a PE device that signals the pseudowire. The
signaling PE device advertises the same VC-
label to all remote PE devices that participate
in the IPLS service instance. In IPLS, for a
given IPLS instance, a MPt-Pt PW used for IP
unicast traffic is established by a PE for each
CE device locally attached to that PE. It is a
unidirectional tree whose leaves consist of the
remote PE peers (which connect at least one
Attachment Circuit associated with the same
IPLS instance) and whose root is the signaling
PE. Traffic flows from the leaves towards the
root.
Multicast PW Multicast Pseudowire. A special kind of MPt-Pt
PW that carries only IP multicast/broadcast
traffic. In the IPLS architecture, for each
IPLS instance supported by a PE, that PE device
establishes exactly one Multicast PW.
CE Customer Edge device. In this document, a CE is
any IP node (host or router) connected to the
IPLS LAN service.
Replication Tree The collection of all pseudowires and
attachment circuits that are members of an IPLS
Shah, et al. Expires September 2003 5
Internet Draft draft-shah-ppvpn-IPLS-01.txt
service instance on a given PE. When a
multicast/broadcast packet is received by the
PE on an attachment circuit, the PE device
sends a copy of the packet to every pseudowire
and attachment circuit of the replication tree,
excluding the attachment circuit on which the
packet was received.
3.0 Topology
The Customer Edge (CE) devices are IP nodes (hosts or routers) that are
connected to PE devices either directly, or via an Ethernet network. We
assume that the PE/CE connection may be regarded by the PE as an
ôinterfaceö to which one or more CEs are attached. This interface may
be the physical LAN interface or a VLAN. The Provider Edge (PE)
routers are MPLS Label Edge Routers (LERs) that serve as pseudowire
endpoints.
+----+ +----+
+ S1 +---+ ........................... +---| S2 |
+----+ | | . . | +----+
IPa | | +----+ +----+ | IPe
+ +---| PE1|---MPLS and/or IP---| PE2|---+
/ \ +----+ |Network +----+ |
+----+ +---+ . | . | +----+
+ S1 + | S1| . +----+ . +---| S2 |
+----+ +---+ ..........| PE3|........... +----+
IPb IPc +----+ IPf
|
|
+----+
| S3 |
+----+
IPd
In the above diagram, an IPLS instance is shown with three sites:
site S1, site S2 and site S3. In site S3, the CE device is directly
connected to its PE. In the other two sites, there are multiple CEs
connected to a single PE. More precisely, the CEs at these sites are
on an Ethernet network (or VLAN), and the PE is attached to that
same Ethernet network or VLAN). We impose the following
restriction: if one or more CEs attach to a PE by virtue of being
on a common LAN or VLAN, there MUST NOT be more than one PE on that
LAN or VLAN.
PE1, PE2 and PE3 are shown to be connected via an MPLS network;
however, other tunneling technologies, such as GRE, L2TP, etc.,
could also be used to carry the pseudowires.
An IPLS instance is a single broadcast domain, such that each IP end
station (e.g., IPa) appears to be co-located with other IP end
Shah, et al. Expires September 2003 6
Internet Draft draft-shah-ppvpn-IPLS-01.txt
stations (e.g., IPb though IPf) on the same subnet. The IPLS service
is transparent to the CE devices and requires no changes to them.
4.0 Configuration
Each PE router is configured with one or more IPLS service
instances, and each IPLS service instance is associated with a
unique VPN-Id. For a given IPLS service instance, a set of
Attachment Circuits is identified. Each Attachment Circuit can be
associated with only one IPLS instance. An Attachment Circuit, in
this document, is either a customer-facing Ethernet port, or a
particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a
customer-facing Ethernet port.
The PE router can optionally be configured with a local MAC address
to be used as source MAC address when packets are forwarded from a
pseudowire to an Attachment Circuit. By default, a PE uses the MAC
address of the customer-facing Ethernet interface for this purpose.
5.0 Discovery
The discovery process includes:
. Remote PE discovery
. VPN (i.e., IPLS) membership discovery
. IP CE end station discovery
This draft does not discuss the remote PE discovery or VPN
membership discovery. This information can either be user configured
or can be obtained using auto-discovery techniques described in
[DNS-Discovery] or [BGP-Discovery]. However, the discovery of the CE
is an important operational step in the IPLS model and is described
below.
5.1 CE discovery
Each PE actively detects the presence of local CEs by snooping IP
and ARP frames received over the Attachment Circuits. During the
discovery phase, the PE examines each broadcast/multicast Ethernet
frame. For IP frames (for example IGP discovery/multicast/broadcast
packets), the CEÆs (source) MAC address is extracted from the
Ethernet header and the (source) IP address is obtained from the IP
header. For ARP frames, the source MAC and IP address are determined
from the ARP PDU.
For each CE, the PE maintains a <Attachment Circuit identification
info, VPN-Id, IP address, MAC address> tuple.
Once discovered, the presence/liveness of a CE is monitored
continuously by examining the received ARP frames and by
periodically generating ARP requests. The absence of an ARP response
from a CE after a configurable number of such ARP requests, is
interpreted as a loss of connectivity with the CE.
Shah, et al. Expires September 2003 7
Internet Draft draft-shah-ppvpn-IPLS-01.txt
6.0 Pseudowire Creation
6.1 Receive Unicast Multipoint-to-point Pseudowire
As the PE discovers each locally attached CE, a unicast Multipoint-
to-point Pseudowire (MPt-Pt PW) associated exclusively with that CE
is created by distributing the CEÆs IP address and MAC address along
with a VC-Label to all the remote PE peers that participate in the
same IPLS instance. Note that the same value of a VC-label should be
distributed to all the remote PE peers for a given CE. The MP-Pt PW
thus created is used by remote PEs to send unicast IP traffic to a
specific CE.
(The same functionality can be provided by a set of point-to-point
PWs, so the PE is not required to send the same VC-label to all the
other PEs. For convenience however, we will speak in the following
only of multipoint-to-point PWs, without pointing out each time that
a set of point-to-point PWs could be used instead.)
The PE forwards a frame received over this MPt-Pt PW to the
associated attachment circuit.
6.2 Receive Replication Multipoint-to-point PseudoWire
When a PE is configured to participate in an IPLS instance, it
advertises a "multicast" VC-label to every other PE that is a member
of the same IPLS. The advertised VC-label value is the same for each
PE, which creates a multipoint-to-point pseudowire for IP multicast
traffic. There is only one multicast MPt-Pt PW per PE for each IPLS
instance and this pseudowire is used exclusively to carry
multicast/broadcast IP traffic from the remote PEs to this PE for
this IPLS instance.
Note that no special functionality is expected from this pseudowire.
We sometimes call it a ômulticast pseudowireö because we use it only
to carry multicast traffic. The pseudowire itself need not provide
any different service than any of the unicast pseudowires.
In particular, the Receive multicast MPt-PT PW does not perform any
replication of frames itself. Rather, it is there to signify to the
PE that the PE needs to replicate a copy of a frame received over
this MPt-Pt PW onto all the attachment circuits that are associated
with the IPLS instance of the MPt-Pt PW.
The use of pseudowires, which are specially optimized for multicast,
is for further study.
6.3 Send Multicast Replication tree
The PE creates a send replication tree for each IPLS instance, which
consists of the collection of all attachment circuits and all the
ômulticastö pseudowires of this IPLS instance.
Shah, et al. Expires September 2003 8
Internet Draft draft-shah-ppvpn-IPLS-01.txt
Any broadcast/multicast frame received over an attachment circuit is
replicated to all the other attachment circuits and all pseudowires
of the send replication tree of the IPLS instance of the incoming
Attachment Circuit.
7.0 Proxy ARP
As part of the signaling of the unicast multipoint-to-point pseudo-
wire (See Section 8), each PE distributes to its remote PE peers the
CE IP address/MAC address associations that it has discovered. The
remote PE peers then build and maintain a database of these
associations.
When a PE receives an ARP request from a local CE for a remote CE,
it searches for the destination IP address in the database
associated with the CEÆs IPLS instance. If a match is found, the PE
sends an ARP response with the MAC address of the remote CE. This
enables the local CE to send unicast IP frames addressed directly to
the MAC address of the remote CE.
8.0 Signaling
IPLS uses PW signaling based on LDP as specified in [PWE3-CONTROL]
and [ROSEN-SIG] to exchange layer-2 cross-connect information for a
given VPN. The cross-connect information is represented as a new LDP
FEC element (VC-FEC in [PWE3-CONTROL] with a FEC element type of
128, new FEC element in [ROSEN-SIG] with a FEC element type of 129),
which LDP then distributes to remote peers in downstream-unsolicited
mode. This document proposes extensions to the new FEC element to
support the IPLS as a new circuit type and to include the IP address
and MAC address information.
8.1 IPLS PW Signaling
The IPLS VPN type is advertised in the VC-Type field of the VC FEC
as the value 0x000D.
The ôinterface parameterö field in the VC FEC is defined in [PWE3-
CONTROL] and [ROSEN-SIG] 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 following parameters of the VC FEC are already defined:
Parameter ID Length Description
Shah, et al. Expires September 2003 9
Internet Draft draft-shah-ppvpn-IPLS-01.txt
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 the following additional parameters for the VC FEC:
0x06 4 IP address of CE
0x07 6 MAC address of CE
0x08 1 Multicast Label Flag
These parameters are used to transport CE IP address/MAC address
associations when establishing the MPt-Pt unicast PWs and to
establish the multicast multipoint-to-point pseudowire label. The IP
address and MAC address interface parameter denotes the IP and MAC
address of a CE. The Multicast Label Flag value of 1 indicates that
the advertised VC-Label represents a ômulticastö PW. The Multicast
Label Flag value of 0 indicates that advertised VC-label represents
a ôunicastö PW. As explained earlier, the term ômulticast PWö only
means that the PW carries IP broadcast/multicast traffic and does
not refer to a multicast LSP in the traditional sense.
The Multicast Label flag must be zero, if present, when the IP and
MAC address parameters are present (and their value is non-zero).
We recommend two options that are currently present as the interface
parameter field in the VC FEC, for signaling such ôVC associated
informationö.
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-SIG] 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.
The new FEC specified in [ROSEN-SIG] contains an Attachment Group
Identifier (AGI) field, a Source Attachment Individual Identifier
field (SAII) and a Target Attachment Individual Identifier field
(TAII). The VPN-Id configured on the advertising PE to identify the
IPLS instance is advertised in the AGI field. The SAII and TAAI
fields are set to the null value.
Shah, et al. Expires September 2003 10
Internet Draft draft-shah-ppvpn-IPLS-01.txt
8.2 Signaling Advertisement Processing
A PE should process a received [PWE3-CONTROL] advertisement with VC-
type of IPLS as follows,
- Verify the IPLS VPN membership by matching the VPN-Id
signaled in the AGI field with the all the VPN-Ids configured
on the PE. Discard and release the VC label if VPN-Id is not
found.
- Distribute the received IP address-to-MAC address binding by
sending a gratuitous ARP response on all the attachment
circuits associated with the VPN-Id.
- Program the Forwarding Information Base (FIB) such that when
a packet is received from an attachment circuit with its
destination MAC address matching the advertised MAC address,
the packet is forwarded out over the tunnel to the
advertising PE with the advertised VC-label as the inner
label.
- When the advertised VC-label is ômulticastö, add the VC-label
to the multicast replication tree for the VPN-Id. This
enables sending a copy of a multicast/broadcast IP frame from
the attachment circuit to this Pseudowire.
8.3 Requesting for IP to MAC binding
It is possible that in some cases, some CEs may remain undetected in
the absence of any multicast/broadcast IP or ARP packet generation.
If another CE needs to converse with a CE in this undetected set, it
will proceed to generate ARP requests. The Proxy ARP scheme
described so far will be unable to resolve the ARP request, since
the address to be resolved would not have been discovered yet.
In order to address such situations, an optional Address Resolution
Request TLV is included in the Label Mapping message. This TLV
contains an IP address parameter that represents the destination IP
address that needs to be resolved. The PE may use some intelligent
mechanisms (e.g., the number of ARP requests received for unknown IP
destination within a certain interval exceeds a threshold) to detect
the need for such advertisement. When the need is detected, the PE
generates Label Mapping Messages to all remote PEs in the IPLS, with
the IP address parameter in the Address Resolution Request TLV set
to the destination IP address to be resolved.
A PE that supports the Address Resolution Request TLV must, on
receiving a Label Mapping message with this TLV, generate an ARP
request message using the received IP address as the destination,
and some already known IP and MAC address as the source (in the ARP
PDU) on all Attachment Circuits associated with the IPLS instance.
In essence, this is a request to remote PEs to generate an ARP
request on their Attachment Circuits to locate a specific CE and
advertise a Label Mapping message back to the requesting PE. This
Shah, et al. Expires September 2003 11
Internet Draft draft-shah-ppvpn-IPLS-01.txt
can be seen as reverting to the usual full broadcasting of ARP
messages throughout the Emulated LAN in case Proxy ARP fails.
8.4 CE MAC Address
Throughout this document we have referenced remote CEÆs MAC address
to be the 48-bit physical MAC address of a remote CE. The MAC
address is learned and signaled by the remote PE while local PE uses
the signaled MAC address to proxy ARP request for remote CEÆs IP
address, program the address in the FIB and use it as a key to
forward packet from the Attachment Circuit to the Pseudowire.
Alternatively, it is also desirable to allow local PE to generate a
unique 48-bit MAC address for the remote CE instead of using the
signaled MAC address by the remote PE. The local PE would then use
the generated MAC address for ARP proxy, programming the FIB and as
a key to forward packets from the Attachment Circuit to the
Pseudowire. By permitting address generation to represent each
remote CE, local PE can use a key lookup algorithm that is most
suitable for its architecture. For example, PE could use only 32-
bits of the 48-bit MAC DA as the key for fast table lookup.
Which mechanism local PE uses to represent remote CE (i.e. using
signaled MAC address or locally generated MAC address), is of local
matter to the PE and has no bearing on the IPLS functionality.
9 Forwarding
9.1 Non-IP traffic
In an IPLS VPN, only IP traffic is forwarded by a PE. ARP frames are
directed to the control plane in the PE and the rest of the frames
are dropped silently. If the CEs must pass non-IP traffic to each
other, they must do so through IP tunnels that terminate at the CEs
themselves.
9.2 Unicast IP Traffic
In IPLS, IP traffic is forwarded based on the destination MAC
address of the layer 2 frame (and not based on the IP Header).
To do so, the PE uses a Forwarding Information Base (FIB), which is
programmed for the considered IPLS instance, in the following
manner:
- Whenever a CE (and its MAC address) is discovered locally by
the PE on an Attachment Circuit, the PE programs its FIB such
that frames received on other attachment circuits with a
destination address equal to the CE MAC address, are
forwarded onto the corresponding attachment circuit.
- When advertising the corresponding unicast PW, the PE
programs the FIB such that packets received onto the
advertised unicast pseudo-wire are forwarded onto the
Shah, et al. Expires September 2003 12
Internet Draft draft-shah-ppvpn-IPLS-01.txt
attachment circuit associated with the CE corresponding to
the advertised MAC and IP addresses.
- As discussed in section 8.2, on receipt of a PW signaling
advertisement, the FIB is programmed by the PE receiving the
advertisement such that frames received on an Attachment
Circuit with a destination address equal to the advertised
MAC address, are forwarded onto the advertised unicast
pseudowire.
Using the FIB of the IPLS instance to which the attachment circuit
belongs, the PE forwards a unicast IP frame to the Attachment
Circuit or pseudowire based on the destination MAC address
information, if received from an Attachment Circuit, or to the
Attachment Circuit based on the VC label, if received from a
pseudowire.
When a unicast destination MAC address is not recognized in the FIB,
the IP frame is dropped.
9.3 Broadcasts and Multicast forwarding
When the destination MAC address is either a broadcast or multicast,
a copy of the frame is sent to the control plane for CE discovery
purposes (see section 5.1).
When a multicast/broadcast IP frame is received from an Attachment
Circuit, a PE replicates it onto the Send Multicast Replication Tree
(See section 6.3). When a multicast/broadcast IP frame is received
from a pseudowire, the PE forwards it to all attachment circuits
associated with the IPLS VPN instance involved.
It is important to note that PEs participating in an IPLS VPN are
responsible for translating a multicast IP address to a multicast
Ethernet MAC address when forwarding frames from a ômulticastö
pseudowire to the Attachment Circuits. (The translation consists of
recognizing the multicast IP address (224.x1.x2.x3) and appending
the least significant three bytes of the IP address to 0x01-00-05 to
construct the MAC address, e.g., 0x01-00-5E-x1-x2-x3 [RFC-1112]).
All other IP packets received over the ômulticastö MPt-Pt PW (such
as directed broadcasts, subnet broadcasts, etc) are forwarded over
Attachment Circuits using a broadcast MAC address.
9.4 Encapsulation
The Ethernet MAC header of a frame received from an Attachment
Circuit is stripped before forwarding the frame to the appropriate
pseudowire. However, the MAC header is retained when a unicast or
broadcast IP frame is directed to one or more Attachment Circuit(s).
An IP frame received over a pseudowire is prepended with a MAC
header before transmitting it on the appropriate Attachment
Circuit(s). The fields in the MAC header are filled in as follows:
Shah, et al. Expires September 2003 13
Internet Draft draft-shah-ppvpn-IPLS-01.txt
- The destination MAC address is the MAC address associated
with the VC label in the FIB when the pseudowire is unicast
- The destination MAC address is a multicast MAC address
derived from the IP multicast address or the broadcast MAC
address when the VC label is ômulticastö
- The source MAC address is the PEÆs own local MAC address or a
MAC address which has been specially configured on the PE for
this use.
- The Ethernet Type field is 0x0800
- The frame may get IEEE802.1Q tagged based on the VLAN
information associated with the Attachment Circuit.
An FCS field is appended to the frame.
10.0 Attaching to IPLS via ATM or FR
In addition to (i) an Ethernet port and a (ii) combination of
Ethernet port and a VLAN ID, an Attachment Circuit to IPLS may also
be (iii) an ATM or FR VC carrying encapsulated bridged Ethernet
frames or (iv) the combination of an ATM or FR VC and a VLAN ID.
The ATM/FR VC is just used as a way to transport Ethernet frames
between a customer site and the PE. The PE terminates the ATM/FR VC
and operates on the encapsulated Ethernet frames exactly as if those
were received on a local Ethernet interface. Operation of an IPLS
over ATM/FR VC is exactly as described above, with the exception
that the attachment circuit is then identified via the ATM VCI/VPI
or Frame Relay DLCI (instead of via a local Ethernet port ID), or a
combination of those with a VLAN ID.
11.0 VPLS vs IPLS
The VPLS approach proposed in [VPLS] provides VPN services for IP as
well as other protocols. The IPLS approach described in this draft
is similar to VPLS in many respects:
- It provides a Provider Provisioned Virtual LAN service with
multipoint capability where a CE connected via a single
attachment circuit can reach many remote CEs
- It appears as a broadcast domain and a single subnet
- forwarding is based on destination MAC addresses
However, unlike VPLS, IPLS is restricted to IP traffic only. By
restricting the scope of the service to the predominant type of
traffic in today's environment, IPLS eliminates the need for service
provider edge routers to implement some bridging functions such as
MAC address learning in the data path (by, instead, distributing MAC
information in the control plane). Thus this solution offers a
number of benefits:
- Facilitates Virtual LAN services in instances where PE
devices cannot or cannot efficiently (or are specifically
configured not to) perform MAC address learning.
- Does not require flooding of ARP frames.
Shah, et al. Expires September 2003 14
Internet Draft draft-shah-ppvpn-IPLS-01.txt
- Encapsulation is more efficient (MAC header is stripped)
while traversing the backbone network.
- PE devices are not burdened with the processing overhead
associated with traditional bridging (e.g., STP processing,
etc.). Note however that some of these overheads (e.g., STP
processing) could optionally be turned-off with a VPLS
solution in the case where it is known that only IP devices
are interconnected.
- Loops (perhaps through backdoor links) are minimized since a
PE could easily reject (via label release) a duplicate IP to
MAC address advertisement.
12.0 IP Protocols
The solution described in this document offers IPLS service for IPv4
traffic only. For this reason, the MAC Header is not carried over
the pseudowire. It is reconstructed by the PE when receiving a
packet from a pseudowire and the Ethertype 0x0800 is used in the MAC
Header since IPv4 is assumed.
However, this solution may be extended to carry other types of
important traffic such as ISIS and IPv6 which are not encapsulated
in Etherent with the use of Ethertype 0x0800. In order to permit the
propagation of such packets correctly, one may create a separate set
of Pseudowires, or pass protocol information in the "control word"
of a "multiprotocol" Pseudowire, or encapsulate the Ethernet MAC
Header in the pseudowire. The selection of appropriate
multiplexing/demultiplexing scheme is the subject of future study.
The current document focuses on IPLS service for IPv4 traffic.
13.0 Acknowledgements
Authors would like to thank Nigel Burmeister and others at Tenor
Networks for their valuable comments.
14.0 Security Considerations
The security aspects of this solution will be discussed at a later
time.
15.0 References
[L2VPN-REQ] Augustyn, W. et.al "Requirements for Layer 2 Virtual
Private Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn-
requirements-02.txt, Work in Progress, Internet Draft, February
2003.
[L2VPN-FMWK] Andersson, draft-ietf-ppvpn-l2-framework-01.txt, PPVPN
L2 Framework, August 2002, (work in progress).
Shah, et al. Expires September 2003 15
Internet Draft draft-shah-ppvpn-IPLS-01.txt
[PWE3-CONTROL] Martini et. Al., ôTransport of Layer 2 Frames Over
MPLSö, draft-ietf-pwe3-control-protocol-00.txt, August 2002 (work in
progress)
[PWE3-ETH-ENCAP] Martini et. Al., ôEncapsulation Methods for
Transport of Ethernet Frames over IP/MPLS Networksö, draft-ietf-
pwe3-ethernet-encap-00.txt, August 2002 (work in progress)
[ROSEN-SIG] Rosen, ôLDP-based Signaling for L2VPNsö, draft-rosen-
ppvpn-l2-signaling-02.txt. September 2002. (work in progress).
[VPLS] Lasserre et al, ôVirtual Private LN Service over MPLSö,
draft-lasserre-vkompella-ppvpn-vpls-02.txt, June 2002 (work in
progress).
[DNS-Discovery] "DNS/LDP Based VPLS", Heinanen, draft-heinanen-dns-
ldp-vpls-00.txt, June 2002
[BGP-Discovery] ôUsing BGP as an Auto-Discovery Mechanism for
Network Based VPNsö, Ould-Brahim et al., draft-ietf-ppvpn-bgpvpn-
auto-02.txt, February 2002, (work in progress).
[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.
[RFC-1112] Deering, S., ôHost Extensions for IP Multicastingö, RFC
1112, August, 1989.
16.0. Intellectual Property Considerations
Tenor Networks may seek patent or other intellectual property
protection for some or 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
K.Arvind
Email: hshah@rcn.com
Email: k_arvind@yahoo.com
Eric Rosen
Shah, et al. Expires September 2003 16
Internet Draft draft-shah-ppvpn-IPLS-01.txt
Cisco Systems
300 Apollo Drive,
Chelmsford, MA 01824
Email: erosen@cisco.com
Giles Heron
PacketExchange Ltd.
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
Email: giles@packetexchange.net
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Email: flefauch@cisco.com
Vasile Radoaca
Nortel Networks
Email: vasile@nortelnetworks.com
Shah, et al. Expires September 2003 17