draft-ietf-l2vpn-vpls-ldp-06.txt   draft-ietf-l2vpn-vpls-ldp-07.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
L2VPN Working Group Vach Kompella L2VPN Working Group Vach Kompella
(Editors) draft-ietf-l2vpn-vpls-ldp-07.txt (Editors)
draft-ietf-l2vpn-vpls-ldp-06.txt Expires: January 2006 July 2005
Expires: August 2005 Feb 2005
Virtual Private LAN Services over MPLS Virtual Private LAN Services over MPLS
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which we are aware have been
or will be disclosed, and any of which I become aware will be disclosed, or will be disclosed, and any of which we become aware
disclosed, in accordance with RFC 3668. will be disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
Sections 5 and 6 of RFC3667 and Section 5 of RFC3668. Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other
at any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract Abstract
This document describes a virtual private LAN service (VPLS) This document describes a Virtual Private LAN Service (VPLS)
solution using pseudo-wires, a service previously implemented over solution using pseudo-wires, a service previously implemented over
other tunneling technologies and known as Transparent LAN Services other tunneling technologies and known as Transparent LAN Services
(TLS). A VPLS creates an emulated LAN segment for a given set of (TLS). A VPLS creates an emulated LAN segment for a given set of
users. It delivers a layer 2 broadcast domain that is fully capable users, i.e., it creates a Layer 2 broadcast domain that is fully
of learning and forwarding on Ethernet MAC addresses that is closed capable of learning and forwarding on Ethernet MAC addresses that
to a given set of users. Multiple VPLS services can be supported is closed to a given set of users. Multiple VPLS services can be
from a single PE node. supported from a single PE node.
This document describes the control plane functions of signaling This document describes the control plane functions of signaling
demultiplexor labels, extending [PWE3-CTRL]. It is agnostic to pseudo-wire labels, extending [PWE3-CTRL]. It is agnostic to
discovery protocols. The data plane functions of forwarding are also discovery protocols. The data plane functions of forwarding are
described, focusing, in particular, on the learning of MAC also described, focusing, in particular, on the learning of MAC
addresses. The encapsulation of VPLS packets is described by [PWE3- addresses. The encapsulation of VPLS packets is described by
ETHERNET]. [PWE3-ETHERNET].
Conventions 1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119.
Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-01.txt
www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-03.txt
www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt
www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt
Table of Contents 2. Table of Contents
1. Introduction....................................................3 1. Conventions.....................................................2
2. Topological Model for VPLS......................................4 2. Table of Contents...............................................2
2.1. Flooding and Forwarding.......................................4 3. Introduction....................................................3
2.2. Address Learning..............................................5 4. Topological Model for VPLS......................................4
2.3. Tunnel Topology...............................................5 4.1. Flooding and Forwarding.......................................4
2.4. Loop free L2 VPN..............................................5 4.2. Address Learning..............................................5
3. Discovery.......................................................6 4.3. Tunnel Topology...............................................5
4. Control Plane...................................................6 4.4. Loop free VPLS................................................6
4.1. LDP Based Signaling of Demultiplexors.........................6 5. Discovery.......................................................6
4.1.1. Using the Generalized PWid FEC Element......................7 6. Control Plane...................................................6
4.1.2. Address Withdraw Message Containing MAC TLV.................7 6.1. LDP Based Signaling of Demultiplexers.........................6
4.2. MAC Address Withdrawal........................................8 6.1.1. Using the Generalized PWid FEC Element......................7
4.2.1. MAC List TLV................................................8 6.2. MAC Address Withdrawal........................................7
5. Data Forwarding on an Ethernet VC PW............................9 6.2.1. MAC List TLV................................................8
5.1. VPLS Encapsulation actions....................................9 6.2.2. Address Withdraw Message Containing MAC TLV.................9
5.2. VPLS Learning actions........................................10 7. Data Forwarding on an Ethernet PW...............................9
6. Data Forwarding on an Ethernet VLAN PW.........................11 7.1. VPLS Encapsulation actions....................................9
6.1. VPLS Encapsulation actions...................................11 7.2. VPLS Learning actions........................................10
7. Operation of a VPLS............................................12 8. Data Forwarding on an Ethernet VLAN PW.........................11
7.1. MAC Address Aging............................................13 8.1. VPLS Encapsulation actions...................................11
8. A Hierarchical VPLS Model......................................13 9. Operation of a VPLS............................................12
8.1. Hierarchical connectivity....................................14 9.1. MAC Address Aging............................................13
8.1.1. Spoke connectivity for bridging-capable devices............14 10. A Hierarchical VPLS Model.....................................13
8.1.2. Advantages of spoke connectivity...........................15 10.1. Hierarchical connectivity...................................14
8.1.3. Spoke connectivity for non-bridging devices................16 10.1.1. Spoke connectivity for bridging-capable devices...........14
8.2. Redundant Spoke Connections..................................17 10.1.2. Advantages of spoke connectivity..........................15
8.2.1. Dual-homed MTU device......................................18 10.1.3. Spoke connectivity for non-bridging devices...............16
8.2.2. Failure detection and recovery.............................18 10.2. Redundant Spoke Connections.................................17
8.3. Multi-domain VPLS service....................................19 10.2.1. Dual-homed MTU............................................17
9. Hierarchical VPLS model using Ethernet Access Network..........19 10.2.2. Failure detection and recovery............................18
9.1. Scalability..................................................20 10.3. Multi-domain VPLS service...................................19
9.2. Dual Homing and Failure Recovery.............................21 11. Hierarchical VPLS model using Ethernet Access Network.........19
10. Significant Modifications.....................................21 11.1. Scalability.................................................20
11. Contributors..................................................21 11.2. Dual Homing and Failure Recovery............................20
12. Acknowledgments...............................................21 12. Significant Modifications.....................................21
13. Security Considerations.......................................22 13. Contributors..................................................21
14. Acknowledgments...............................................21
15. Security Considerations.......................................21
16. IANA Considerations...........................................22
17. References....................................................22
17.1. Normative References........................................22
17.2. Informative References......................................23
18. Appendix: VPLS Signaling using the PWid FEC Element...........23
19. Authors' Addresses............................................24
1. Introduction 3. Introduction
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area
Networks (LANs) connectivity and is gaining acceptance as an access Network (LAN) connectivity and is gaining acceptance as an access
technology, specifically in Metropolitan and Wide Area Networks (MAN technology, specifically in Metropolitan and Wide Area Networks
and WAN respectively). The primary motivation behind Virtual Private (MAN and WAN, respectively). The primary motivation behind Virtual
LAN Services (VPLS) is to provide connectivity between Private LAN Services (VPLS) is to provide connectivity between
geographically dispersed customer sites across MAN/WAN network(s), geographically dispersed customer sites across MANs and WANs, as if
as if they were connected using a LAN. The intended application for they were connected using a LAN. The intended application for the
the end-user can be divided into the following two categories: end-user can be divided into the following two categories:
- Connectivity between customer routers: LAN routing application - Connectivity between customer routers: LAN routing application
- Connectivity between customer Ethernet switches: LAN switching - Connectivity between customer Ethernet switches: LAN switching
application application
Broadcast and multicast services are available over traditional Broadcast and multicast services are available over traditional
LANs. Sites that belong to the same broadcast domain and that are LANs. Sites that belong to the same broadcast domain and that are
connected via an MPLS network expect broadcast, multicast and connected via an MPLS network expect broadcast, multicast and
unicast traffic to be forwarded to the proper location(s). This unicast traffic to be forwarded to the proper location(s). This
requires MAC address learning/aging on a per LSP basis, packet requires MAC address learning/aging on a per pseudo-wire basis,
replication across LSPs for multicast/broadcast traffic and for packet replication across pseudo-wires for multicast/broadcast
flooding of unknown unicast destination traffic. traffic and for flooding of unknown unicast destination traffic.
[PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point [PWE3-ETHERNET] defines how to carry Layer 2 (L2) frames over
MPLS LSPs, called Pseudo-Wires (PW). Such PWs can be carried over point-to-point pseudo-wires (PW). This document describes
MPLS or GRE tunnels. This document describes extensions to [PWE3- extensions to [PWE3-CTRL] for transporting Ethernet/802.3 and VLAN
CTRL] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic [802.1Q] traffic across multiple sites that belong to the same L2
across multiple sites that belong to the same L2 broadcast domain or broadcast domain or VPLS. Note that the same model can be applied
VPLS. Note that the same model can be applied to other 802.1 to other 802.1 technologies. It describes a simple and scalable
technologies. It describes a simple and scalable way to offer way to offer Virtual LAN services, including the appropriate
Virtual LAN services, including the appropriate flooding of flooding of broadcast, multicast and unknown unicast destination
broadcast, multicast and unknown unicast destination traffic over traffic over MPLS, without the need for address resolution servers
MPLS, without the need for address resolution servers or other or other external servers, as discussed in [L2VPN-REQ].
external servers, as discussed in [L2VPN-REQ].
The following discussion applies to devices that are VPLS capable The following discussion applies to devices that are VPLS capable
and have a means of tunneling labeled packets amongst each other. and have a means of tunneling labeled packets amongst each other.
While MPLS LSPs may be used to tunnel these labeled packets, other
technologies may be used as well, e.g., GRE [MPLS-GRE]. The
resulting set of interconnected devices forms a private MPLS VPN.
2. Topological Model for VPLS The resulting set of interconnected devices forms a private MPLS
VPN.
An interface participating in a VPLS must be able to flood, forward, 4. Topological Model for VPLS
and filter Ethernet frames.
An interface participating in a VPLS must be able to flood,
forward, and filter Ethernet frames. The set of PE devices
interconnected via PWs appears as a single emulated LAN to customer
C1. Each PE will form remote MAC address to PW associations and
associate directly attached MAC addresses to local customer facing
ports. This is modeled on standard IEEE 802.1 MAC address
learning.
+----+ +----+ +----+ +----+
+ C1 +---+ ........................... +---| C1 | + C1 +---+ ........................... +---| C1 |
+----+ | . . | +----+ +----+ | . . | +----+
Site A | +----+ +----+ | Site B Site A | +----+ +----+ | Site B
+---| PE |------ Cloud -------| PE |---+ +---| PE | Cloud | PE |---+
+----+ | +----+ +----+ +----+
. | . . .
. +----+ . . +----+ .
..........| PE |........... ..........| PE |...........
+----+ ^ +----+ ^
| | | |
| +-- Emulated LAN | +-- Emulated LAN
+----+ +----+
| C1 | | C1 |
+----+ +----+
Site C Site C
The set of PE devices interconnected via PWs appears as a single
emulated LAN to customer C1. Each PE device will learn remote MAC
address to PW associations and will also learn directly attached MAC
addresses on customer facing ports.
We note here again that while this document shows specific examples We note here again that while this document shows specific examples
using MPLS transport tunnels, other tunnels that can be used by PWs, using MPLS transport tunnels, other tunnels that can be used by PWs
e.g., GRE, L2TP, IPSEC, etc., can also be used, as long as the (as mentioned in [PWE-CTRL]), e.g., GRE, L2TP, IPSEC, etc., can
originating PE can be identified, since this is used in the MAC also be used, as long as the originating PE can be identified,
learning process. since this is used in the MAC learning process.
The scope of the VPLS lies within the PEs in the service provider The scope of the VPLS lies within the PEs in the service provider
network, highlighting the fact that apart from customer service network, highlighting the fact that apart from customer service
delineation, the form of access to a customer site is not relevant delineation, the form of access to a customer site is not relevant
to the VPLS [L2VPN-REQ]. to the VPLS [L2VPN-REQ]. In other words, the access circuit (AC)
connected to the customer could be a physical Ethernet port, a
logical (tagged) Ethernet port, an ATM PVC carrying Ethernet
frames, etc., or even an Ethernet PW.
The PE device is typically an edge router capable of running the LDP The PE is typically an edge router capable of running the LDP
signaling protocol and/or routing protocols to set up PWs. signaling protocol and/or routing protocols to set up PWs. In
In addition, it is capable of setting up transport tunnels to other addition, it is capable of setting up transport tunnels to other
PEs and of delivering traffic over a PW. PEs and delivering traffic over PWs.
2.1. Flooding and Forwarding
One of attributes of an Ethernet service is that packets to 4.1. Flooding and Forwarding
broadcast packets and to unknown destination MAC addresses are
One of attributes of an Ethernet service is that frames sent to
broadcast addresses and to unknown destination MAC addresses are
flooded to all ports. To achieve flooding within the service flooded to all ports. To achieve flooding within the service
provider network, all address unknown unicast, broadcast and provider network, all unknown unicast, broadcast and multicast
multicast frames are flooded over the corresponding PWs to all frames are flooded over the corresponding PWs to all PE nodes
relevant PE nodes participating in the VPLS. participating in the VPLS, as well as to all ACs.
Note that multicast frames are a special case and do not necessarily Note that multicast frames are a special case and do not
have to be sent to all VPN members. For simplicity, the default necessarily have to be sent to all VPN members. For simplicity,
approach of broadcasting multicast frames can be used. The use of the default approach of broadcasting multicast frames can be used.
IGMP snooping and PIM snooping techniques should be used to improve The use of IGMP snooping and PIM snooping techniques should be used
multicast efficiency. to improve multicast efficiency. A description of these techniques
is beyond the scope of this document.
To forward a frame, a PE MUST be able to associate a destination MAC To forward a frame, a PE MUST be able to associate a destination
address with a PW. It is unreasonable and perhaps impossible to MAC address with a PW. It is unreasonable and perhaps impossible
require PEs to statically configure an association of every possible to require PEs to statically configure an association of every
destination MAC address with a PW. Therefore, VPLS-capable PEs possible destination MAC address with a PW. Therefore, VPLS-
SHOULD have the capability to dynamically learn MAC addresses on capable PEs SHOULD have the capability to dynamically learn MAC
both physical ports and virtual circuits and to forward and addresses on both ACs and PWs and to forward and replicate packets
replicate packets across both physical ports and PWs. across both ACs and PWs.
2.2. Address Learning 4.2. Address Learning
Unlike BGP VPNs [BGP-VPN], reachability information does not need to Unlike BGP VPNs [BGP-VPN], reachability information is not
be advertised and distributed via a control plane. Reachability is advertised and distributed via a control plane. Reachability is
obtained by standard learning bridge functions in the data plane. obtained by standard learning bridge functions in the data plane.
A PW consists of a pair of uni-directional VC LSPs. The state of When a packet arrives on a PW, if the source MAC address is
this PW is considered operationally up when both incoming and unknown, it needs to be associated with the PW, so that outbound
outgoing VC LSPs are established. Similarly, it is considered packets to that MAC address can be delivered over the associated
operationally down when one of these two VC LSPs is torn down. When PW. Likewise, when a packet arrives on an AC, if the source MAC
a previously unknown MAC address is learned on an inbound VC LSP, it address is unknown, it needs to be associated with the AC, so that
needs to be associated with the its counterpart outbound VC LSP in outbound packets to that MAC address can be delivered over the
that PW. associated AC.
Standard learning, filtering and forwarding actions, as defined in Standard learning, filtering and forwarding actions, as defined in
[802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a PW or
logical link state changes. AC state changes.
2.3. Tunnel Topology 4.3. Tunnel Topology
PE routers are assumed to have the capability to establish transport PE routers are assumed to have the capability to establish
tunnels. Tunnels are set up between PEs to aggregate traffic. PWs transport tunnels. Tunnels are set up between PEs to aggregate
are signaled to demultiplex the L2 encapsulated packets that traffic. PWs are signaled to demultiplex encapsulated Ethernet
traverse the tunnels. frames from multiple VPLS instances that traverse the transport
tunnels.
In an Ethernet L2VPN, it becomes the responsibility of the service In an Ethernet L2VPN, it becomes the responsibility of the service
provider to create the loop free topology. For the sake of provider to create the loop free topology. For the sake of
simplicity, we define that the topology of a VPLS is a full mesh of simplicity, we define that the topology of a VPLS is a full mesh of
tunnels and PWs. PWs.
2.4. Loop free L2 VPN
For simplicity, a full mesh of PWs is established between PEs. 4.4. Loop free VPLS
Ethernet bridges, unlike Frame Relay or ATM where the termination
point becomes the CE node, have to examine the layer 2 fields of the
packets to make a switching decision. If the frame is directed to an
unknown destination, or is a broadcast or multicast frame, the frame
must be flooded.
Therefore, if the topology isn't a full mesh, the PE devices may If the topology of the VPLS is not restricted to a full mesh, then
need to forward these frames to other PEs. However, this would it may be that for two PEs not directly connected via PWs, they
require the use of spanning tree protocol to form a loop free would have to use an intermediary PE to relay packets. This
topology that may have characteristics that are undesirable to the topology would require the use of some loop-breaking protocol, like
provider. The use of a full mesh and split-horizon forwarding a spanning tree protocol.
obviates the need for a spanning tree protocol.
Each PE MUST create a rooted tree to every other PE router that Instead, a full mesh of PWs is established between PEs. Since
serves the same VPLS. Each PE MUST support a "split-horizon" scheme every PE is now directly connected to every other PE in the VPLS
in order to prevent loops, that is, a PE MUST NOT forward traffic via a PW, there is no longer any need to relay packets, and we can
from one PW to another in the same VPLS mesh (since each PE has instantiate a simpler loop-breaking rule - the "split horizon"
direct connectivity to all other PEs in the same VPLS). rule: a PE MUST NOT forward traffic from one PW to another in the
same VPLS mesh.
Note that customers are allowed to run STP such as when a customer Note that customers are allowed to run the Spanning Tree Protocol
has "back door" links used to provide redundancy in the case of a (STP) such as when a customer has "back door" links used to provide
failure within the VPLS. In such a case, STP BPDUs are simply redundancy in the case of a failure within the VPLS. In such a
tunneled through the provider cloud. case, STP Bridge PDUs (BPDUs) are simply tunneled through the
provider cloud.
3. Discovery 5. Discovery
The capability to manually configure the addresses of the remote PEs The capability to manually configure the addresses of the remote
is REQUIRED. However, the use of manual configuration is not PEs is REQUIRED. However, the use of manual configuration is not
necessary if an auto-discovery procedure is used. A number of auto- necessary if an auto-discovery procedure is used. A number of
discovery procedures are compatible with this document ([RADIUS- auto-discovery procedures are compatible with this document
DISC], [BGP-DISC]). ([RADIUS-DISC], [BGP-DISC]).
4. Control Plane 6. Control Plane
This document describes the control plane functions of Demultiplexor This document describes the control plane functions of signaling of
Exchange (signaling of VC labels). Some foundational work in the PW labels. Some foundational work in the area of support for
area of support for multi-homing is laid. The extensions to provide multi-homing is laid. The extensions to provide multi-homing
multi-homing support should work independently of the basic VPLS support should work independently of the basic VPLS operation, and
operation, and are not described here. are not described here.
4.1. LDP Based Signaling of Demultiplexors 6.1. LDP Based Signaling of Demultiplexers
In order to establish a full mesh of PWs, all PEs in a VPLS must A full mesh of LDP sessions is used to establish the mesh of PWs.
have a full mesh of LDP sessions. The requirement for a full mesh of PWs may result in a large number
of targeted LDP sessions. Section 8 discusses the option of
setting up hierarchical topologies in order to minimize the size of
the VPLS full mesh.
Once an LDP session has been formed between two PEs, all PWs are Once an LDP session has been formed between two PEs, all PWs
signaled over this session. between these two PEs are signaled over this session.
In [PWE3-CTRL], two types of FECs are described, the FEC type 128 In [PWE3-CTRL], two types of FECs are described, the PWid FEC
PWid FEC Element and the FEC type 129 Generalized PWid FEC Element. Element (FEC type 128) and the Generalized PWid FEC Element (FEC
The original FEC element used for VPLS was compatible with the PWid type 129). The original FEC element used for VPLS was compatible
FEC Element. The text for signaling using PWid FEC Element has been with the PWid FEC Element. The text for signaling using PWid FEC
moved to Appendix 1. What we describe below replaces that with a Element has been moved to Appendix 1. What we describe below
more generalized L2VPN descriptor through the Generalized PWid FEC replaces that with a more generalized L2VPN descriptor, the
Element. Generalized PWid FEC Element.
4.1.1. Using the Generalized PWid FEC Element 6.1.1. Using the Generalized PWid FEC Element
[PWE3-CTRL] describes a generalized FEC structure that is be used [PWE3-CTRL] describes a generalized FEC structure that is be used
for VPLS signaling in the following manner. The following describes for VPLS signaling in the following manner. We describe the
the assignment of the Generalized PWid FEC Element fields in the assignment of the Generalized PWid FEC Element fields in the
context of VPLS signaling. context of VPLS signaling.
Control bit (C): Depending on whether, on that particular PW, the Control bit (C): This bit is used to signal the use of the control
control word is desired or not, the control bit may be specified. word as specified in [PWE3-CTRL].
PW type: The allowed PW types in this version are Ethernet and PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
Ethernet VLAN. tagged mode (0x004) as specified in [IANA].
VC info length: Same as in [PWE3-CTRL]. VC info length: As specified in [PWE3-CTRL].
AGI, Length, Value: The unique name of this VPLS. The AGI identifies AGI, Length, Value: The unique name of this VPLS. The AGI
a type of name, the length denotes the length of Value, which is the identifies a type of name, Length denotes the length of Value,
name of the VPLS. We will use the term AGI interchangeably with VPLS which is the name of the VPLS. We use the term AGI interchangeably
identifier. with VPLS identifier.
TAII, SAII: These are null because the mesh of PWs in a VPLS TAII, SAII: These are null because the mesh of PWs in a VPLS
terminate on MAC learning tables, rather than on individual terminate on MAC learning tables, rather than on individual
attachment circuits. attachment circuits. The use of non-null TAII and SAII is reserved
for future enhancements.
Interface Parameters: The relevant interface parameters are: Interface Parameters: The relevant interface parameters are:
- MTU: the MTU of the VPLS MUST be the same across all the PWs in - MTU: the MTU of the VPLS MUST be the same across all the PWs
the mesh. in the mesh.
- Optional Description String: same as [PWE3-CTRL]. - Optional Description String: same as [PWE3-CTRL].
- Requested VLAN ID: If the PW type is Ethernet VLAN, this - Requested VLAN ID: If the PW type is Ethernet tagged mode,
parameter may be used to signal the insertion of the this parameter may be used to signal the insertion of the
appropriate VLAN ID. appropriate VLAN ID as specified in section 6.1.
4.1.2. Address Withdraw Message Containing MAC TLV
When MAC addresses are being removed or relearned explicitly, e.g.,
the primary link of a dual-homed MTU-s (Multi-Tenant Unit switch)
has failed, an MAC Address Withdraw Message with the list of MAC
addresses to be relearned can be sent to all other PEs over the
corresponding directed LDP sessions.
The processing for MAC List TLVs received in an Address Withdraw
Message is:
For each MAC address in the TLV:
- Relearn the association between the MAC address and the
interface/PW over which this message is received
For a MAC Address Withdraw message with empty list:
- Remove all the MAC addresses associated with the VPLS instance
(specified by the FEC TLV) except the MAC addresses learned
over this link (over the PW associated with the signaling link
over which the message is received)
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
the MAC Address Withdraw Message. The number of MAC addresses can be
deduced from the length field in the TLV.
4.2. MAC Address Withdrawal 6.2. MAC Address Withdrawal
It MAY be desirable to remove or relearn MAC addresses that have It MAY be desirable to remove or unlearn MAC addresses that have
been dynamically learned for faster convergence. been dynamically learned for faster convergence. This is
accomplished by sending a MAC Address Withdraw Message with the
list of MAC addresses to be removed to all other PEs over the
corresponding LDP sessions.
We introduce an optional MAC List TLV that is used to specify a list We introduce an optional MAC List TLV that is used to specify a
of MAC addresses that can be removed or relearned using the LDP list of MAC addresses that can be removed or unlearned using the
Address Withdraw Message. Address Withdraw Message.
The Address Withdraw message with MAC TLVs MAY be supported in
order to expedite removal of MAC addresses as the result of a
topology change (e.g., failure of the primary link for a dual-homed
MTU-s).
The Address Withdraw message with MAC TLVs MAY be supported in order In order to minimize the impact on LDP convergence time, when the
to expedite removal of MAC addresses as the result of a topology MAC list TLV contains a large number of MAC addresses, it may be
change (e.g., failure of the primary link for a dual-homed MTU-s). preferable to send a MAC address withdrawal message with an empty
If a notification message is sent on the backup link (blocked link), list.
which has transitioned into an active state (e.g., similar to
Topology Change Notification message of 802.1w RSTP), with a list of
MAC entries to be relearned, the PE will update the MAC entries in
its FIB for that VPLS instance and send the message to other PEs
over the corresponding directed LDP sessions.
If the notification message contains an empty list, this tells the
receiving PE to remove all the MAC addresses learned for the
specified VPLS instance except the ones it learned from the sending
PE (MAC address removal is required for all VPLS instances that are
affected). Note that the definition of such a notification message
is outside the scope of the document, unless it happens to come from
an MTU connected to the PE as a spoke. In such a scenario, the
message will be just an Address Withdraw message as noted above.
4.2.1. MAC List TLV 6.2.1. MAC List TLV
MAC addresses to be relearned can be signaled using an LDP Address MAC addresses to be unlearned can be signaled using an LDP Address
Withdraw Message that contains a new TLV, the MAC List TLV. Its Withdraw Message that contains a new TLV, the MAC List TLV. Its
format is described below. The encoding of a MAC List TLV address is format is described below. The encoding of a MAC List TLV address
the 6-byte MAC address specified by IEEE 802 documents [g-ORIG] is the 6-byte MAC address specified by IEEE 802 documents [g-ORIG]
[802.1D-REV]. [802.1D-REV].
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | | MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | MAC Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | | MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit: Unknown bit. This bit MUST be set to 1. If the MAC address U bit: Unknown bit. This bit MUST be set to 1. If the MAC address
format is not understood, then the TLV is not understood, and MUST format is not understood, then the TLV is not understood, and MUST
be ignored. be ignored.
F bit: Forward bit. This bit MUST be set to 0. Since the LDP F bit: Forward bit. This bit MUST be set to 0. Since the LDP
mechanism used here is Targeted, the TLV MUST NOT be forwarded. mechanism used here is targeted, the TLV MUST NOT be forwarded.
Type: Type field. This field MUST be set to 0x0404 (subject to IANA Type: Type field. This field MUST be set to 0x0404 (subject to
approval). This identifies the TLV type as MAC List TLV. IANA approval). This identifies the TLV type as MAC List TLV.
Length: Length field. This field specifies the total length of the Length: Length field. This field specifies the total length of the
MAC addresses in the TLV. MAC addresses in the TLV.
MAC Address: The MAC address(es) being removed. MAC Address: The MAC address(es) being removed.
The LDP Address Withdraw Message contains a FEC TLV (to identify the The MAC Address Withdraw Message contains a FEC TLV (to identify
VPLS in consideration), a MAC Address TLV and optional parameters. the VPLS in consideration), a MAC Address TLV and optional
No optional parameters have been defined for the MAC Address parameters. No optional parameters have been defined for the MAC
Withdraw signaling. Address Withdraw signaling. Note that if a PE receives a MAC
Address Withdraw Message and does not understand it, it MUST ignore
the message. In this case, instead of flushing its MAC address
table, it will continue to use stale information, unless:
5. Data Forwarding on an Ethernet VC PW - it receives a packet with a known MAC address association,
but from a different PW, in which case it replaces the old
association, or
- it ages out the old association
The MAC Address Withdraw message only helps to speed up
convergence, so PEs that do not understand the message can continue
to participate in the VPLS.
6.2.2. Address Withdraw Message Containing MAC TLV
The processing for MAC List TLV received in an Address Withdraw
Message is:
For each MAC address in the TLV:
- Remove the association between the MAC address and the AC or
PW over which this message is received
For a MAC Address Withdraw message with empty list:
- Remove all the MAC addresses associated with the VPLS
instance (specified by the FEC TLV) except the MAC addresses
learned over the PW associated with this signaling session
over which the message was received
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
the MAC Address Withdraw Message. The number of MAC addresses can
be deduced from the length field in the TLV.
7. Data Forwarding on an Ethernet PW
This section describes the dataplane behavior on an Ethernet This section describes the dataplane behavior on an Ethernet
PW used in a VPLS. While the encapsulation is similar to that PW used in a VPLS. While the encapsulation is similar to that
described in [PWE3-ETHERNET], the NSP functions of stripping the described in [PWE3-ETHERNET], the NSP functions of stripping the
service-delimiting tag and using a "normalized" Ethernet packet are service-delimiting tag and using a "normalized" Ethernet frame are
described. described.
5.1. VPLS Encapsulation actions 7.1. VPLS Encapsulation actions
In a VPLS, a customer Ethernet packet without preamble is In a VPLS, a customer Ethernet frame without preamble is
encapsulated with a header as defined in [PWE3-ETHERNET]. A customer encapsulated with a header as defined in [PWE3-ETHERNET]. A
Ethernet packet is defined as follows: customer Ethernet frame is defined as follows:
- If the packet, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that is used by the local PE as a service delimiter, i.e., to that is used by the local PE as a service delimiter, i.e., to
identify the customer and/or the particular service of that identify the customer and/or the particular service of that
customer, then that encapsulation is stripped before the packet customer, then that encapsulation may be stripped before the
is sent into the VPLS. As the packet exits the VPLS, the packet frame is sent into the VPLS. As the frame exits the VPLS,
may have a service-delimiting encapsulation inserted. the frame may have a service-delimiting encapsulation
inserted.
- If the packet, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that is not service delimiting, then it is a customer packet that is not service delimiting, then it is a customer frame
whose encapsulation should not be modified by the VPLS. This whose encapsulation should not be modified by the VPLS. This
covers, for example, a packet that carries customer-specific covers, for example, a frame that carries customer-specific
VLAN-Ids that the service provider neither knows about nor VLAN tags that the service provider neither knows about nor
wants to modify. wants to modify.
As an application of these rules, a customer packet may arrive at a As an application of these rules, a customer frame may arrive at a
customer-facing port with a VLAN tag that identifies the customer's customer-facing port with a VLAN tag that identifies the customer's
VPLS instance. That tag would be stripped before it is encapsulated VPLS instance. That tag would be stripped before it is
in the VPLS. At egress, the packet may be tagged again, if a encapsulated in the VPLS. At egress, the frame may be tagged
service-delimiting tag is used, or it may be untagged if none is again, if a service-delimiting tag is used, or it may be untagged
used. if none is used.
Likewise, if a customer packet arrives at a customer-facing port Likewise, if a customer frame arrives at a customer-facing port
over an ATM or Frame Relay VC that identifies the customer's VPLS over an ATM or Frame Relay VC that identifies the customer's VPLS
instance, then the ATM or FR encapsulation is removed before the instance, then the ATM or FR encapsulation is removed before the
packet is passed into the VPLS. frame is passed into the VPLS.
Contrariwise, if a customer packet arrives at a customer-facing port Contrariwise, if a customer frame arrives at a customer-facing port
with a VLAN tag that identifies a VLAN domain in the customer L2 with a VLAN tag that identifies a VLAN domain in the customer L2
network, then the tag is not modified or stripped, as it belongs network, then the tag is not modified or stripped, as it belongs
with the rest of the customer frame. with the rest of the customer frame.
By following the above rules, the Ethernet packet that traverses a By following the above rules, the Ethernet frame that traverses a
VPLS is always a customer Ethernet packet. Note that the two VPLS is always a customer Ethernet frame. Note that the two
actions, at ingress and egress, of dealing with service delimiters actions, at ingress and egress, of dealing with service delimiters
are local actions that neither PE has to signal to the other. They are local actions that neither PE has to signal to the other. They
allow, for example, a mix-and-match of VLAN tagged and untagged allow, for example, a mix-and-match of VLAN tagged and untagged
services at either end, and do not carry across a VPLS a VLAN tag services at either end, and do not carry across a VPLS a VLAN tag
that has local significance only. The service delimiter may be an that has local significance only. The service delimiter may be an
MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] can MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET]
serve as the access side connection into a PE. An RFC1483 PVC can serve as the access side connection into a PE. An RFC1483
encapsulation could be another service delimiter. By limiting the Bridged PVC encapsulation could also serve as a service delimiter.
scope of locally significant encapsulations to the edge, By limiting the scope of locally significant encapsulations to the
hierarchical VPLS models can be developed that provide the edge, hierarchical VPLS models can be developed that provide the
capability to network-engineer VPLS deployments, as described below. capability to network-engineer scalable VPLS deployments, as
described below.
5.2. VPLS Learning actions 7.2. VPLS Learning actions
Learning is done based on the customer Ethernet packet, as defined Learning is done based on the customer Ethernet frame as defined
above. The Forwarding Information Base (FIB) keeps track of the above. The Forwarding Information Base (FIB) keeps track of the
mapping of customer Ethernet packet addressing and the appropriate mapping of customer Ethernet frame addressing and the appropriate
PW to use. We define two modes of learning: qualified and PW to use. We define two modes of learning: qualified and
unqualified learning. unqualified learning.
In unqualified learning, all the customer VLANs are handled by a In unqualified learning, all the VLANs of a single customer are
single VPLS, which means they all share a single broadcast domain handled by a single VPLS, which means they all share a single
and a single MAC address space. This means that MAC addresses need broadcast domain and a single MAC address space. This means that
to be unique and non-overlapping among customer VLANs or else they MAC addresses need to be unique and non-overlapping among customer
cannot be differentiated within the VPLS instance and this can VLANs or else they cannot be differentiated within the VPLS
result in loss of customer frames. An application of unqualified instance and this can result in loss of customer frames. An
learning is port-based VPLS service for a given customer (e.g., application of unqualified learning is port-based VPLS service for
customer with non-multiplexed UNI interface where all the traffic on a given customer (e.g., customer with non-multiplexed AC where all
a physical port, which may include multiple customer VLANs, is the traffic on a physical port, which may include multiple customer
mapped to a single VPLS instance). VLANs, is mapped to a single VPLS instance).
In qualified learning, each customer VLAN is assigned to its own In qualified learning, each customer VLAN is assigned to its own
VPLS instance, which means each customer VLAN has its own broadcast VPLS instance, which means each customer VLAN has its own broadcast
domain and MAC address space. Therefore, in qualified learning, MAC domain and MAC address space. Therefore, in qualified learning,
addresses among customer VLANs may overlap with each other, but they MAC addresses among customer VLANs may overlap with each other, but
will be handled correctly since each customer VLAN has its own FIB, they will be handled correctly since each customer VLAN has its own
i.e., each customer VLAN has its own MAC address space. Since VPLS FIB, i.e., each customer VLAN has its own MAC address space. Since
broadcasts multicast frames by default, qualified learning offers VPLS broadcasts multicast frames by default, qualified learning
the advantage of limiting the broadcast scope to a given customer offers the advantage of limiting the broadcast scope to a given
VLAN. customer VLAN. Qualified learning can result in large FIB table
sizes, because the logical MAC address is now a VLAN tag + MAC
address.
For STP to work in qualified mode, a VPLS PE must be able to forward For STP to work in qualified mode, a VPLS PE must be able to
STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case forward STP BPDUs over the proper VPLS instance. In a hierarchical
(see details in Section 10), service delimiting tags (Q-in-Q or VPLS case (see details in Section 10), service delimiting tags (Q-
Martini) can be added by MTU-s nodes such that PEs can unambiguously in-Q or [PWE3-ETHERNET]) can be added by MTU-s nodes such that PEs
identify all customer traffic, including STP/MSTP BPDUs. In a basic can unambiguously identify all customer traffic, including STP/MSTP
VPLS case, upstream switches must insert such service delimiting BPDUs. In a basic VPLS case, upstream switches must insert such
tags. When an access port is shared among multiple customers, a service delimiting tags. When an access port is shared among
reserved VLAN per customer domain must be used to carry STP/MSTP multiple customers, a reserved VLAN per customer domain must be
traffic. The STP/MSTP frames are encapsulated with a unique provider used to carry STP/MSTP traffic. The STP/MSTP frames are
tag per customer (as the regular customer traffic), and a PEs looks encapsulated with a unique provider tag per customer (as the
up the provider tag to send such frames across the proper VPLS regular customer traffic), and a PEs looks up the provider tag to
instance. send such frames across the proper VPLS instance.
6. Data Forwarding on an Ethernet VLAN PW 8. Data Forwarding on an Ethernet VLAN PW
This section describes the dataplane behavior on an Ethernet VLAN PW This section describes the data plane behavior on an Ethernet VLAN
in a VPLS. While the encapsulation is similar to that described in PW in a VPLS. While the encapsulation is similar to that described
[PWE3-ETHERNET], the NSP functions of imposing tags, and using a in [PWE3-ETHERNET], the NSP functions of imposing tags and using a
"normalized" Ethernet packet are described. The learning behavior is "normalized" Ethernet frame are described. The learning behavior
the same as for Ethernet PWs. is the same as for Ethernet PWs.
6.1. VPLS Encapsulation actions 8.1. VPLS Encapsulation actions
In a VPLS, a customer Ethernet packet without preamble is In a VPLS, a customer Ethernet frame without preamble is
encapsulated with a header as defined in [PWE3-ETHERNET]. A customer encapsulated with a header as defined in [PWE3-ETHERNET]. A
Ethernet packet is defined as follows: customer Ethernet frame is defined as follows:
- If the packet, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that is part of the customer frame, and is also used by the that is part of the customer frame, and is also used by the
local PE as a service delimiter, i.e., to identify the customer local PE as a service delimiter, i.e., to identify the
and/or the particular service of that customer, then that customer and/or the particular service of that customer, then
encapsulation is preserved as the packet is sent into the VPLS, that encapsulation is preserved as the frame is sent into the
unless the Requested VLAN ID optional parameter was signaled. VPLS, unless the Requested VLAN ID optional parameter was
signaled. In that case, the VLAN tag is overwritten before
In that case, the VLAN tag is overwritten before the packet is the frame is sent out on the PW.
sent out on the PW.
- If the packet, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that does not have the required VLAN tag, a null tag is imposed that does not have the required VLAN tag, a null tag is
if the Requested VLAN ID optional parameter was not signaled. imposed if the Requested VLAN ID optional parameter was not
signaled.
As an application of these rules, a customer packet may arrive at a As an application of these rules, a customer frame may arrive at a
customer-facing port with a VLAN tag that identifies the customer's customer-facing port with a VLAN tag that identifies the customer's
VPLS instance and also identifies a customer VLAN. That tag would be VPLS instance and also identifies a customer VLAN. That tag would
preserved as it is encapsulated in the VPLS. be preserved as it is encapsulated in the VPLS.
The Ethernet VLAN PW is a simple way to preserve customer 802.1p The Ethernet VLAN PW provides a simple way to preserve customer
bits. 802.1p bits.
A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a
PE is not able to support both PWs simultaneously, it can send a PE is not able to support both PWs simultaneously, it SHOULD send a
Label Release on the PW messages that it cannot support with a Label Release on the PW messages that it cannot support with a
status code "Unknown FEC" as given in [RFC3036]. status code "Unknown FEC" as given in [RFC3036].
7. Operation of a VPLS 9. Operation of a VPLS
We show here an example of how a VPLS works. The following We show here an example of how a VPLS works. The following
discussion uses the figure below, where a VPLS has been set up discussion uses the figure below, where a VPLS has been set up
between PE1, PE2 and PE3. between PE1, PE2 and PE3.
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned a unique VCID.
For the above example, say PE1 signals VC Label 102 to PE2 and 103
to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3.
Assume a packet from A1 is bound for A2. When it leaves CE1, say it
has a source MAC address of M1 and a destination MAC of M2. If PE1
does not know where M2 is, it will multicast the packet to PE2 and
PE3. When PE2 receives the packet, it will have an inner label of
201. PE2 can conclude that the source MAC address M1 is behind PE1,
since it distributed the label 201 to PE1. It can therefore
associate MAC address M1 with VC Label 102.
----- -----
/ A1 \ / A1 \
---- ----CE1 | ---- ----CE1 |
/ \ -------- ------- / | | / \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ ----- \ / \ / \---/ \ -----
---- ---PE2 | ---- ---PE2 |
| Service Provider Network | | Service Provider Network |
\ / \ / \ / \ /
----- PE3 / \ / ----- PE3 / \ /
|Agg|_/ -------- ------- |Agg|_/ -------- -------
-| | -| |
---- / ----- ---- ---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router / \/ \ / \ CE = Customer Edge Router
| A3 CE3 --C4 A4 | PE = Provider Edge Router | A3 CE3 --C4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation \ / \ / Agg = Layer 2 Aggregation
---- ---- ---- ----
7.1. MAC Address Aging Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned a identifier
(AGI). For the above example, say PE1 signals PW label 102 to PE2
and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
PEs that learn remote MAC addresses need to have an aging mechanism Assume a packet from A1 is bound for A2. When it leaves CE1, say
to remove unused entries associated with a VC Label. This is it has a source MAC address of M1 and a destination MAC of M2. If
PE1 does not know where M2 is, it will flood the packet, i.e., send
it to PE2 and PE3. When PE2 receives the packet, it will have a PW
label of 201. PE2 can conclude that the source MAC address M1 is
behind PE1, since it distributed the label 201 to PE1. It can
therefore associate MAC address M1 with PW label 102.
9.1. MAC Address Aging
PEs that learn remote MAC addresses SHOULD have an aging mechanism
to remove unused entries associated with a PW label. This is
important both for conservation of memory as well as for important both for conservation of memory as well as for
administrative purposes. For example, if a customer site A is shut administrative purposes. For example, if a customer site A is shut
down, eventually, the other PEs should unlearn A's MAC address. down, eventually, the other PEs should unlearn A's MAC address.
As packets arrive, MAC addresses are remembered. The aging timer for The aging timer for MAC address M SHOULD be reset when a packet
MAC address M SHOULD be reset when a packet is received with source with source MAC address M is received.
MAC address M.
8. A Hierarchical VPLS Model 10. A Hierarchical VPLS Model
The solution described above requires a full mesh of tunnel LSPs The solution described above requires a full mesh of tunnel LSPs
between all the PE routers that participate in the VPLS service. between all the PE routers that participate in the VPLS service.
For each VPLS service, n*(n-1)/2 PWs must be setup between the PE For each VPLS service, n*(n-1)/2 PWs must be setup between the PE
routers. While this creates signaling overhead, the real detriment routers. While this creates signaling overhead, the real detriment
to large scale deployment is the packet replication requirements for to large scale deployment is the packet replication requirements
each provisioned VCs on a PE router. Hierarchical connectivity, for each provisioned PWs on a PE router. Hierarchical
described in this document reduces signaling and replication connectivity, described in this document reduces signaling and
overhead to allow large scale deployment. replication overhead to allow large scale deployment.
In many cases, service providers place smaller edge devices in In many cases, service providers place smaller edge devices in
multi-tenant buildings and aggregate them into a PE device in a multi-tenant buildings and aggregate them into a PE in a large
large Central Office (CO) facility. In some instances, standard IEEE Central Office (CO) facility. In some instances, standard IEEE
802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping 802.1q (Dot 1Q) tagging techniques may be used to facilitate
CE interfaces to PE VPLS access points. mapping CE interfaces to VPLS access circuits at a PE.
It is often beneficial to extend the VPLS service tunneling It is often beneficial to extend the VPLS service tunneling
techniques into the MTU (multi-tenant unit) domain. This can be techniques into the MTU (multi-tenant unit) domain. This can be
accomplished by treating the MTU device as a PE device and accomplished by treating the MTU as a PE and provisioning PWs
provisioning PWs between it and every other edge, as an basic VPLS. between it and every other edge, as a basic VPLS. An alternative
An alternative is to utilize [PWE3-ETHERNET] PWs or Q-in-Q logical is to utilize [PWE3-ETHERNET] PWs or Q-in-Q logical interfaces
interfaces between the MTU and selected VPLS enabled PE routers. Q- between the MTU and selected VPLS enabled PE routers. Q-in-Q
in-Q encapsulation is another form of L2 tunneling technique, which encapsulation is another form of L2 tunneling technique, which can
can be used in conjunction with MPLS signaling as will be described be used in conjunction with MPLS signaling as will be described
later. The following two sections focus on this alternative later. The following two sections focus on this alternative
approach. The VPLS core PWs (Hub) are augmented with access PWs approach. The VPLS core PWs (hub) are augmented with access PWs
(Spoke) to form a two-tier hierarchical VPLS (H-VPLS). (spoke) to form a two-tier hierarchical VPLS (H-VPLS).
Spoke PWs may be implemented using any L2 tunneling mechanism, Spoke PWs may be implemented using any L2 tunneling mechanism,
expanding the scope of the first tier to include non-bridging VPLS expanding the scope of the first tier to include non-bridging VPLS
PE routers. The non-bridging PE router would extend a Spoke PW from PE routers. The non-bridging PE router would extend a spoke PW
a Layer-2 switch that connects to it, through the service core from a Layer-2 switch that connects to it, through the service core
network, to a bridging VPLS PE router supporting Hub PWs. We also network, to a bridging VPLS PE router supporting hub PWs. We also
describe how VPLS-challenged nodes and low-end CEs without MPLS describe how VPLS-challenged nodes and low-end CEs without MPLS
capabilities may participate in a hierarchical VPLS. capabilities may participate in a hierarchical VPLS.
8.1. Hierarchical connectivity 10.1. Hierarchical connectivity
This section describes the hub and spoke connectivity model and This section describes the hub and spoke connectivity model and
describes the requirements of the bridging capable and non-bridging describes the requirements of the bridging capable and non-bridging
MTU devices for supporting the spoke connections. MTU devices for supporting the spoke connections. For rest of this
discussion we refer to a bridging capable MTU as MTU-s and a non-
For rest of this discussion we will refer to a bridging capable MTU bridging capable PE as PE-r. We refer to a routing and bridging
device as MTU-s and a non-bridging capable PE device as PE-r. A capable device as PE-rs.
routing and bridging capable device will be referred to as PE-rs.
8.1.1. Spoke connectivity for bridging-capable devices
As shown in the figure below, consider the case where an MTU-s 10.1.1. Spoke connectivity for bridging-capable devices
device has a single connection to the PE-rs device placed in the CO.
The PE-rs devices are connected in a basic VPLS full mesh. For each
VPLS service, a single spoke PW is set up between the MTU-s and the
PE-rs based on [PWE3-CTRL]. Unlike traditional PWs that terminate on
a physical (or a VLAN-tagged logical) port at each end, the spoke PW
terminates on a virtual bridge instance on the MTU-s and the PE-rs
devices.
PE2-rs PE2-rs
------ ------
/ \ / \
| -- | | -- |
| / \ | | / \ |
CE-1 | \B / | CE-1 | \S / |
\ \ -- / \ \ -- /
\ /------ \ /------
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
\ ------ ------ / | \ ------ ------ / |
/ \ / \ / | / \ / \ / |
| \ -- | VC-1 | -- |---/ | | \ -- | PW-1 | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | | | / \--|- - - - - - - - - - - |--/ \ | |
| \B / | | \B / | | | \S / | | \S / | |
\ /-- / \ -- / ---\ | \ /-- / \ -- / ---\ |
/----- ------ \ | /----- ------ \ |
/ \ | / \ |
---- \ ------ ---- \ ------
|Agg | / \ |Agg | / \
---- | -- | ---- | -- |
/ \ | / \ | / \ | / \ |
CE-2 CE-3 | \B / | CE-2 CE-3 | \S / |
\ -- / \ -- /
MTU-s = Bridging capable MTU ------ MTU-s = Bridging capable MTU ------
PE-rs = VPLS capable PE PE3-rs PE-rs = VPLS capable PE PE3-rs
Agg = Layer-2 Aggregation
-- --
/ \ / \
\B / = Virtual VPLS(Bridge)Instance \S / = Virtual Switch Instance
-- --
Agg = Layer-2 Aggregation
The MTU-s device and the PE-rs device treat each spoke connection In the figure above where an MTU-s has a single connection to a PE-
like an access port of the VPLS service. On access ports, the rs placed in the CO. The PE-rs devices are connected in a basic
combination of the physical port and/or the VLAN tag is used to VPLS full mesh. For each VPLS service, a single spoke PW is set up
associate the traffic to a VPLS instance while the PW tag (e.g., VC between the MTU-s and the PE-rs based on [PWE3-CTRL]. Unlike
label) is used to associate the traffic from the virtual spoke port traditional PWs that terminate on a physical (or a VLAN-tagged
with a VPLS instance, followed by a standard L2 lookup to identify logical) port, a spoke PW terminates on a virtual switch instance
which customer port the frame needs to be sent to. (VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices.
8.1.1.1. MTU-s Operation The MTU-s and the PE-rs treat each spoke connection like an AC of
the VPLS service. The PW label is used to associate the traffic
from the spoke to a VPLS instance.
MTU-s device is defined as a device that supports layer-2 switching 10.1.1.1. MTU-s Operation
functionality and does all the normal bridging functions of learning
and replication on all its ports, including the virtual spoke port. An MTU-s is defined as a device that supports layer-2 switching
Packets to unknown destination are replicated to all ports in the functionality and does all the normal bridging functions of
service including the virtual spoke port. Once the MAC address is learning and replication on all its ports, including the spoke,
learned, traffic between CE1 and CE2 will be switched locally by the which is treated as a virtual port. Packets to unknown
MTU-s device saving the link capacity of the connection to the PE- destinations are replicated to all ports in the service including
rs. Similarly traffic between CE1 or CE2 and any remote destination the spoke. Once the MAC address is learned, traffic between CE1
is switched directly on to the spoke connection and sent to the PE- and CE2 will be switched locally by the MTU-s saving the capacity
rs over the point-to-point PW. of the spoke to the PE-rs. Similarly traffic between CE1 or CE2
and any remote destination is switched directly on to the spoke and
sent to the PE-rs over the point-to-point PW.
Since the MTU-s is bridging capable, only a single PW is required Since the MTU-s is bridging capable, only a single PW is required
per VPLS instance for any number of access connections in the same per VPLS instance for any number of access connections in the same
VPLS service. This further reduces the signaling overhead between VPLS service. This further reduces the signaling overhead between
the MTU-s and PE-rs. the MTU-s and PE-rs.
If the MTU-s is directly connected to the PE-rs, other encapsulation If the MTU-s is directly connected to the PE-rs, other
techniques such as Q-in-Q can be used for the spoke connection PW. encapsulation techniques such as Q-in-Q can be used for the spoke.
8.1.1.2. PE-rs Operation 10.1.1.2. PE-rs Operation
The PE-rs device is a device that supports all the bridging A PE-rs is a device that supports all the bridging functions for
functions for VPLS service and supports the routing and MPLS VPLS service and supports the routing and MPLS encapsulation, i.e.,
encapsulation, i.e. it supports all the functions described for a it supports all the functions described for a basic VPLS as
basic VPLS as described above. described above.
The operation of PE-rs is independent of the type of device at the The operation of PE-rs is independent of the type of device at the
other end of the spoke PW. Thus, the spoke PW from the PE-r is other end of the spoke. Thus, the spoke from the MTU-s is treated
treated as a virtual port and the PE-rs device will switch traffic as a virtual port and the PE-rs will switch traffic between the
between the spoke PW, hub PWs, and access ports once it has learned spoke PW, hub PWs, and ACs once it has learned the MAC addresses.
the MAC addresses.
8.1.2. Advantages of spoke connectivity 10.1.2. Advantages of spoke connectivity
Spoke connectivity offers several scaling and operational advantages
for creating large scale VPLS implementations, while retaining the
ability to offer all the functionality of the VPLS service.
- Eliminates the need for a full mesh of tunnels and full mesh of Spoke connectivity offers several scaling and operational
PWs per service between all devices participating in the VPLS advantages for creating large scale VPLS implementations, while
retaining the ability to offer all the functionality of the VPLS
service. service.
- Eliminates the need for a full mesh of tunnels and full mesh
of PWs per service between all devices participating in the
VPLS service.
- Minimizes signaling overhead since fewer PWs are required for - Minimizes signaling overhead since fewer PWs are required for
the VPLS service. the VPLS service.
- Segments VPLS nodal discovery. MTU-s needs to be aware of only
the PE-rs node although it is participating in the VPLS service - Segments VPLS nodal discovery. MTU-s needs to be aware of
that spans multiple devices. On the other hand, every VPLS PE- only the PE-rs node although it is participating in the VPLS
rs must be aware of every other VPLS PE-rs device and all of service that spans multiple devices. On the other hand,
it's locally connected MTU-s and PE-r. every VPLS PE-rs must be aware of every other VPLS PE-rs and
- Addition of other sites requires configuration of the new MTU-s all of its locally connected MTU-s and PE-r devices.
device but does not require any provisioning of the existing - Addition of other sites requires configuration of the new
MTU-s but does not require any provisioning of the existing
MTU-s devices on that service. MTU-s devices on that service.
- Hierarchical connections can be used to create VPLS service - Hierarchical connections can be used to create VPLS service
that spans multiple service provider domains. This is explained that spans multiple service provider domains. This is
in a later section. explained in a later section.
8.1.3. Spoke connectivity for non-bridging devices Note that as more devices participate in the VPLS, there are more
devices that require the capability for learning and replication.
In some cases, a bridging PE-rs device may not be deployed in a CO 10.1.3. Spoke connectivity for non-bridging devices
or a multi-tenant building while a PE-r might already be deployed.
If there is a need to provide VPLS service from the CO where the PE-
rs device is not available, the service provider may prefer to use
the PE-r device in the interim. In this section, we explain how a
PE-r device that does not support any of the VPLS bridging
functionality can participate in the VPLS service.
As shown in this figure, the PE-r device creates a point-to-point In some cases, a bridging PE-rs may not be deployed in a CO or a
tunnel LSP to a PE-rs device. multi-tenant building, or a PE-r might already be deployed. In
this section, we explain how a PE-r that does not support any of
the VPLS bridging functionality can participate in the VPLS
service. As shown in this figure, the PE-r creates a point-to-
point tunnel LSP to a PE-rs.
PE2-rs PE2-rs
------ ------
/ \ / \
| -- | | -- |
| / \ | | / \ |
CE-1 | \B / | CE-1 | \S / |
\ \ -- / \ \ -- /
\ /------ \ /------
\ PE-r PE1-rs / | \ PE-r PE1-rs / |
\ ------ ------ / | \ ------ ------ / |
/ \ / \ / | / \ / \ / |
| \ | VC-1 | -- |---/ | | \ | VC-1 | -- |---/ |
| ------|- - - - - - - - - - - |--/ \ | | | ------|- - - - - - - - - - - |--/ \ | |
| -----|- - - - - - - - - - - |--\B / | | | -----|- - - - - - - - - - - |--\S / | |
\ / / \ -- / ---\ | \ / / \ -- / ---\ |
------ ------ \ | ------ ------ \ |
/ \ | / \ |
---- \------ ---- \------
| Agg| / \ | Agg| / \
---- | -- | ---- | -- |
/ \ | / \ | / \ | / \ |
CE-2 CE-3 | \B / | CE-2 CE-3 | \S / |
\ -- / \ -- /
------ ------
PE3-rs PE3-rs
Then for every access port that needs to participate in a VPLS Then for every access port that needs to participate in a VPLS
service, the PE-r device creates a point-to-point [PWE3-ETHERNET] PW service, the PE-r creates a point-to-point PW that terminates on
that terminates on the physical port at the PE-r and terminates on the physical port at the PE-r and terminates on the VSI of the VPLS
the virtual bridge instance of the VPLS service at the PE-rs. service at the PE-rs.
The PE-r device is defined as a device that supports routing but The PE-r is defined as a device that supports routing but does not
does not support any bridging functions. However, it is capable of support any bridging functions. However, it is capable of setting
setting up [PWE3-ETHERNET] PWs between itself and the PE-rs. For up PWs between itself and the PE-rs. For every port that is
every port that is supported in the VPLS service, a [PWE3-ETHERNET] supported in the VPLS service, a PW is setup from the PE-r to the
PW is setup from the PE-r to the PE-rs. Once the PWs are setup, PE-rs. Once the PWs are setup, there is no learning or replication
there is no learning or replication function required on part of the function required on the part of the PE-r. All traffic received on
PE-r. All traffic received on any of the access ports is transmitted any of the ACs is transmitted on the PW. Similarly all traffic
on the PW. Similarly all traffic received on a PW is transmitted to received on a PW is transmitted to the AC where the PW terminates.
the access port where the PW terminates. Thus traffic from CE1 Thus traffic from CE1 destined for CE2 is switched at PE1-rs and
destined for CE2 is switched at PE-rs and not at PE-r. not at PE-r.
Note that in the case where PE-r devices use Provider VLANs (P-VLAN) Note that in the case where PE-r devices use Provider VLANs (P-
as demultiplexors instead of PWs, and PE-rs can treat them as such, VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as
PE-rs can map these "circuits" into a VPLS domain and provide such and map these "circuits" into a VPLS domain to provide
bridging support between them. bridging support between them.
This approach adds more overhead than the bridging capable (MTU-s) This approach adds more overhead than the bridging capable (MTU-s)
spoke approach since a PW is required for every access port that spoke approach since a PW is required for every AC that
participates in the service versus a single PW required per service participates in the service versus a single PW required per service
(regardless of access ports) when a MTU-s type device is used. (regardless of ACs) when an MTU-s is used. However, this approach
However, this approach offers the advantage of offering a VPLS offers the advantage of offering a VPLS service in conjunction with
service in conjunction with a routed internet service without a routed internet service without requiring the addition of new
requiring the addition of new MTU device. MTU.
8.2. Redundant Spoke Connections 10.2. Redundant Spoke Connections
An obvious weakness of the hub and spoke approach described thus far An obvious weakness of the hub and spoke approach described thus
is that the MTU device has a single connection to the PE-rs device. far is that the MTU has a single connection to the PE-rs. In case
In case of failure of the connection or the PE-rs device, the MTU of failure of the connection or the PE-rs, the MTU suffers total
device suffers total loss of connectivity. loss of connectivity.
In this section we describe how the redundant connections can be In this section we describe how the redundant connections can be
provided to avoid total loss of connectivity from the MTU device. provided to avoid total loss of connectivity from the MTU. The
The mechanism described is identical for both, MTU-s and PE-r type mechanism described is identical for both, MTU-s and PE-r devices.
of devices
8.2.1. Dual-homed MTU device 10.2.1. Dual-homed MTU
To protect from connection failure of the PW or the failure of the To protect from connection failure of the PW or the failure of the
PE-rs device, the MTU-s device or the PE-r is dual-homed into two PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices,
PE-rs devices, as shown in figure-3. The PE-rs devices must be part as shown in figure-3. The PE-rs devices must be part of the same
of the same VPLS service instance. VPLS service instance.
An MTU-s device will setup two [PWE3-ETHERNET] PWs (one each to PE- An MTU-s can set up two PWs (one each to PE1-rs and PE3-rs) for
rs1 and PE-rs2) for each VPLS instance. One of the two PWs is each VPLS instance. One of the two PWs is designated as primary
designated as primary and is the one that is actively used under and is the one that is actively used under normal conditions, while
normal conditions, while the second PW is designated as secondary the second PW is designated as secondary and is held in a standby
and is held in a standby state. The MTU device negotiates the PW state. The MTU negotiates the PW labels for both the primary and
labels for both the primary and secondary PWs, but does not use the secondary PWs, but does not use the secondary PW unless the primary
secondary PW unless the primary PW fails. Since only one link is PW fails. How a spoke is designated primary or secondary is
active at a given time, a loop does not exist and hence 802.1D outside of the scope of this document. For example, a spanning
spanning tree is not required. tree instance running between only the MTU and the two PE-rs nodes
is one possible method. Another method could be configuration.
PE2-rs PE2-rs
------ ------
/ \ / \
| -- | | -- |
| / \ | | / \ |
CE-1 | \B / | CE-1 | \S / |
\ \ -- / \ \ -- /
\ /------ \ /------
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
\------ ------ / | \------ ------ / |
/ \ / \ / | / \ / \ / |
| -- | Primary PW | -- |---/ | | -- | Primary PW | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | | | / \--|- - - - - - - - - - - |--/ \ | |
| \B / | | \B / | | | \S / | | \S / | |
\ -- \/ \ -- / ---\ | \ -- \/ \ -- / ---\ |
------\ ------ \ | ------\ ------ \ |
/ \ \ | / \ \ |
/ \ \ ------ / \ \ ------
/ \ / \ / \ / \
CE-2 \ | -- | CE-2 \ | -- |
\ Secondary PW | / \ | \ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - |-\B / | - - - - - - - - - - - - - - - - - |-\S / |
\ -- / \ -- /
------ ------
PE3-rs PE3-rs
8.2.2. Failure detection and recovery 10.2.2. Failure detection and recovery
The MTU-s device controls the usage of the PWs to the PE-rs nodes. The MTU-s should control the usage of the spokes to the PE-rs
Since LDP signaling is used to negotiate the PW labels, the hello devices. If the spokes are PWs, then LDP signaling is used to
messages used for the LDP session can be used to detect failure of negotiate the PW labels, and the hello messages used for the LDP
the primary PW. session could be used to detect failure of the primary PW. The use
of other mechanisms which could provide faster detection failures
is outside the scope of this document.
Upon failure of the primary PW, MTU-s device immediately switches to Upon failure of the primary PW, MTU-s immediately switches to the
the secondary PW. At this point the PE3-rs device that terminates secondary PW. At this point the PE3-rs that terminates the
the secondary PW starts learning MAC addresses on the spoke PW. All secondary PW starts learning MAC addresses on the spoke PW. All
other PE-rs nodes in the network think that CE-1 and CE-2 are behind other PE-rs nodes in the network think that CE-1 and CE-2 are
PE1-rs and may continue to send traffic to PE1-rs until they learn behind PE1-rs and may continue to send traffic to PE1-rs until they
that the devices are now behind PE3-rs. The relearning process can learn that the devices are now behind PE3-rs. The unlearning
take a long time and may adversely affect the connectivity of higher process can take a long time and may adversely affect the
level protocols from CE1 and CE2. To enable faster convergence, the connectivity of higher level protocols from CE1 and CE2. To enable
PE3-rs device where the secondary PW got activated may send out a faster convergence, the PE3-rs where the secondary PW got activated
flush message (as explained in section 4.2), using the MAC TLV as may send out a flush message (as explained in section 4.2), using
defined in Section 6, to all PE-rs nodes. Upon receiving the the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon
message, PE-rs nodes flush the MAC addresses associated with that receiving the message, PE-rs nodes flush the MAC addresses
VPLS instance. associated with that VPLS instance.
8.3. Multi-domain VPLS service 10.3. Multi-domain VPLS service
Hierarchy can also be used to create a large scale VPLS service Hierarchy can also be used to create a large scale VPLS service
within a single domain or a service that spans multiple domains within a single domain or a service that spans multiple domains
without requiring full mesh connectivity between all VPLS capable without requiring full mesh connectivity between all VPLS capable
devices. Two fully meshed VPLS networks are connected together using devices. Two fully meshed VPLS networks are connected together
a single LSP tunnel between the VPLS "border" devices. A single using a single LSP tunnel between the VPLS "border" devices. A
spoke PW per VPLS service is set up to connect the two domains single spoke PW per VPLS service is set up to connect the two
together. domains together.
When more than two domains need to be connected, a full mesh of When more than two domains need to be connected, a full mesh of
inter-domain spokes is created between border PEs. Forwarding rules inter-domain spokes is created between border PEs. Forwarding
over this mesh are identical to the rules defined in section 5. rules over this mesh are identical to the rules defined in section
5.
This creates a three-tier hierarchical model that consists of a hub- This creates a three-tier hierarchical model that consists of a
and-spoke topology between MTU-s and PE-rs devices, a full-mesh hub-and-spoke topology between MTU-s and PE-rs devices, a full-mesh
topology between PE-rs, and a full mesh of inter-domain spokes topology between PE-rs, and a full mesh of inter-domain spokes
between border PE-rs devices. between border PE-rs devices.
This document does not specify how redundant border PEs per domain This document does not specify how redundant border PEs per domain
per VPLS instance can be supported. per VPLS instance can be supported.
9. Hierarchical VPLS model using Ethernet Access Network 11. Hierarchical VPLS model using Ethernet Access Network
In this section the hierarchical model is expanded to include an In this section the hierarchical model is expanded to include an
Ethernet access network. This model retains the hierarchical Ethernet access network. This model retains the hierarchical
architecture discussed previously in that it leverages the full-mesh architecture discussed previously in that it leverages the full-
topology among PE-rs devices; however, no restriction is imposed on mesh topology among PE-rs devices; however, no restriction is
the topology of the Ethernet access network (e.g., the topology imposed on the topology of the Ethernet access network (e.g., the
between MTU-s and PE-rs devices are not restricted to hub and topology between MTU-s and PE-rs devices is not restricted to hub
spoke). and spoke).
The motivation for an Ethernet access network is that Ethernet-based The motivation for an Ethernet access network is that Ethernet-
networks are currently deployed by some service providers to offer based networks are currently deployed by some service providers to
VPLS services to their customers. Therefore, it is important to offer VPLS services to their customers. Therefore, it is important
provide a mechanism that allows these networks to integrate with an to provide a mechanism that allows these networks to integrate with
IP or MPLS core to provide scalable VPLS services. an IP or MPLS core to provide scalable VPLS services.
One approach of tunneling a customer's Ethernet traffic via an One approach of tunneling a customer's Ethernet traffic via an
Ethernet access network is to add an additional VLAN tag to the Ethernet access network is to add an additional VLAN tag to the
customer's data (which may be either tagged or untagged). The customer's data (which may be either tagged or untagged). The
additional tag is referred to as Provider's VLAN (P-VLAN). Inside additional tag is referred to as Provider's VLAN (P-VLAN). Inside
the provider's network each P-VLAN designates a customer or more the provider's network each P-VLAN designates a customer or more
specifically a VPLS instance for that customer. Therefore, there is specifically a VPLS instance for that customer. Therefore, there
a one to one correspondence between a P-VLAN and a VPLS instance. In is a one-to-one correspondence between a P-VLAN and a VPLS
this model, the MTU-S device needs to have the capability of adding instance. In this model, the MTU-s needs to have the capability of
the additional P-VLAN tag for non-multiplexed customer UNI port adding the additional P-VLAN tag to non-multiplexed ACs where
where customer VLANs are not used as service delimiter. If customer customer VLANs are not used as service delimiters. This
VLANs need to be treated as service delimiter (e.g., customer UNI functionality is described in [802.1ad].
port is a multiplexed port), then the MTU-s needs to have the
If customer VLANs need to be treated as service delimiters (e.g.,
the AC is a multiplexed port), then the MTU-s needs to have the
additional capability of translating a customer VLAN (C-VLAN) to a additional capability of translating a customer VLAN (C-VLAN) to a
P-VLAN in order to resolve overlapping VLAN-ids used by different P-VLAN, or push an additional P-VLAN tag, in order to resolve
customers. Therefore, the MTU-s device in this model can be overlapping VLAN tags used by different customers. Therefore, the
considered as a typical bridge with this additional UNI capability. MTU-s in this model can be considered as a typical bridge with this
additional capability. This functionality is described in
[802.1ad].
The PE-rs device needs to be able to perform bridging functionality The PE-rs needs to be able to perform bridging functionality over
over the standard Ethernet ports toward the access network as well the standard Ethernet ports toward the access network as well as
as over the PWs toward the network core. The set of PWs that over the PWs toward the network core. In this model, the PE-rs may
corresponds to a VPLS instance would look just like a P-VLAN to the need to run STP towards the access network, in addition to split-
bridge portion of the PE-rs and that is why sometimes it is referred horizon over the MPLS core. The PE-rs needs to map a P-VLAN to a
to as Emulated VLAN. In this model the PE-rs may need to run STP VPLS-instance and its associated PWs and vice versa.
protocol in addition to split-horizon. Split horizon is run over
MPLS-core; whereas, STP is run over the access network to
accommodate any arbitrary access topology. In this model, the PE-rs
needs to map a P-VLAN to a VPLS-instance and its associated PWs and
vise versa.
The details regarding bridge operation for MTU-s and PE-rs (e.g., The details regarding bridge operation for MTU-s and PE-rs (e.g.,
encapsulation format for QinQ messages, customer's Ethernet control encapsulation format for Q-in-Q messages, customer's Ethernet
protocol handling, etc.) are outside of the scope of this document control protocol handling, etc.) are outside of the scope of this
and they are covered in [802.1ad]. However, the relevant part is the document and they are covered in [802.1ad]. However, the relevant
interaction between the bridge module and the MPLS/IP PWs in the PE- part is the interaction between the bridge module and the MPLS/IP
rs device. PWs in the PE-rs, which behaves just as in a regular VPLS.
9.1. Scalability 11.1. Scalability
Given that each P-VLAN corresponds to a VPLS instance, one may think Since each P-VLAN corresponds to a VPLS instance, the total number
that the total number of VPLS instances supported is limited to 4K. of VPLS instances supported is limited to 4K. The P-VLAN serves as
However, the 4K limit applies only to each Ethernet access network a local service delimiter within the provider's network that is
(Ethernet island) and not to the entire network. The SP network, in stripped as it gets mapped to a PW in a VPLS instance. Therefore,
this model, consists of a core MPLS/IP network that connects many the 4K limit applies only within an Ethernet access network
Ethernet islands. Therefore, the number of VPLS instances can scale (Ethernet island) and not to the entire network. The SP network
consists of a core MPLS/IP network that connects many Ethernet
islands. Therefore, the number of VPLS instances can scale
accordingly with the number of Ethernet islands (a metro region can accordingly with the number of Ethernet islands (a metro region can
be represented by one or more islands). Each island may consist of be represented by one or more islands).
many MTU-s devices, several aggregators, and one or more PE-rs
devices. The PE-rs devices enable a P-VLAN to be extended from one
island to others using a set of PWs (associated with that VPLS
instance) and providing a loop free mechanism across the core
network through split-horizon. Since a P-VLAN serves as a service
delimiter within the provider's network, it does not get carried
over the PWs and furthermore the mapping between P-VLAN and the PWs
is a local matter. This means a VPLS instance can be represented by
different P-VLAN in different Ethernet islands and furthermore each
island can support 4K VPLS instances independent from one another.
9.2. Dual Homing and Failure Recovery 11.2. Dual Homing and Failure Recovery
In this model, an MTU-s can be dual or triple homed to different In this model, an MTU-s can be dual homed to different devices
devices (aggregators and/or PE-rs devices). The failure protection (aggregators and/or PE-rs devices). The failure protection for
for access network nodes and links can be provided through running access network nodes and links can be provided through running MSTP
MSTP in each island. The MSTP of each island is independent from in each island. The MSTP of each island is independent from other
other islands and do not interact with each other. If an island has islands and do not interact with each other. If an island has more
more than one PE-rs, then a dedicated full-mesh of PWs is used among than one PE-rs, then a dedicated full-mesh of PWs is used among
these PE-rs devices for carrying the SP BPDU packets for that these PE-rs devices for carrying the SP BPDU packets for that
island. On a per P-VLAN basis, the MSTP will designate a single PE- island. On a per P-VLAN basis, MSTP will designate a single PE-rs
rs to be used for carrying the traffic across the core. The loop- to be used for carrying the traffic across the core. The loop-free
free protection through the core is performed using split-horizon protection through the core is performed using split-horizon and
and the failure protection in the core is performed through standard the failure protection in the core is performed through standard
IP/MPLS re-routing. IP/MPLS re-routing.
10. Significant Modifications 12. Significant Modifications
Between rev 05 and this one, these are the changes: Between rev 06 and this one, these are the changes:
- Incorporated comments from WG last call - Incorporated comments from technical review team
- Fixed idnits - Clarifications and edits
- Fixed id-nits
11. Contributors 13. Contributors
Loa Andersson, TLA Loa Andersson, TLA
Ron Haberman, Masergy Ron Haberman, Alcatel
Juha Heinanen, Independent Juha Heinanen, Independent
Giles Heron, Tellabs Giles Heron, Tellabs
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel
Luca Martini, Cisco Luca Martini, Cisco
Pascal Menezes, Terabeam Pascal Menezes, Independent
Rob Nath, Riverstone Rob Nath, Riverstone
Eric Puetz, SBC Eric Puetz, SBC
Vasile Radoaca, Nortel Vasile Radoaca, Nortel
Ali Sajassi, Cisco Ali Sajassi, Cisco
Yetik Serbest, SBC Yetik Serbest, SBC
Nick Slabakov, Riverstone Nick Slabakov, Riverstone
Andrew Smith, Consultant Andrew Smith, Consultant
Tom Soon, SBC Tom Soon, SBC
Nick Tingle, Alcatel Nick Tingle, Alcatel
12. Acknowledgments 14. Acknowledgments
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt
Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov
Rekhter, and Sasha Vainshtein for their valuable feedback. Rekhter, and Sasha Vainshtein for their valuable feedback.
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu
(Ixia), and Charlie Hundall (Extreme) for identifying issues with (Ixia), and Charlie Hundall for identifying issues with the draft
the draft in the course of the interoperability tests. in the course of the interoperability tests.
13. Security Considerations We would also like to thank Ina Minei, Bob Thomas, Eric Gray and
Dimitri Papadimitriou for their thorough technical review of the
document.
15. Security Considerations
A more comprehensive description of the security issues involved in A more comprehensive description of the security issues involved in
L2VPNs is covered in [VPN-SEC]. An unguarded VPLS service is L2VPNs is covered in [VPN-SEC]. An unguarded VPLS service is
vulnerable to some security issues which pose risks to the customer vulnerable to some security issues which pose risks to the customer
and provider networks. Most of the security issues can be avoided and provider networks. Most of the security issues can be avoided
through implementation of appropriate guards. A couple of them can through implementation of appropriate guards. A couple of them can
be prevented through existing protocols. be prevented through existing protocols.
- Data plane aspects - Data plane aspects
- Traffic isolation between VPLS domains is guaranteed by the - Traffic isolation between VPLS domains is guaranteed by
use of per VPLS L2 FIB table and the use of per VPLS PWs the use of per VPLS L2 FIB table and the use of per VPLS
- The customer traffic, which consists of Ethernet frames, is PWs
carried unchanged over VPLS. If security is required, - The customer traffic, which consists of Ethernet frames,
the customer traffic SHOULD be encrypted and/or is carried unchanged over VPLS. If security is
authenticated before entering the service provider network required, the customer traffic SHOULD be encrypted
and/or authenticated before entering the service
provider network
- Preventing broadcast storms can be achieved by using - Preventing broadcast storms can be achieved by using
routers as CPE devices or by rate policing the amount of routers as CPE devices or by rate policing the amount of
broadcast traffic that customers can send. broadcast traffic that customers can send
- Control plane aspects - Control plane aspects
- LDP security (authentication) methods as described in [RFC- - LDP security (authentication) methods as described in
3036] SHOULD be applied. This would prevent [RFC-3036] SHOULD be applied. This would prevent
unauthorized participation by a PE in a VPLS. unauthenticated messages from disrupting a PE in a VPLS
- Denial of service attacks - Denial of service attacks
- Some means to limit the number of MAC addresses (per site - Some means to limit the number of MAC addresses (per site
per VPLS) that a PE can learn SHOULD be implemented. per VPLS) that a PE can learn SHOULD be implemented
IANA Considerations 16. IANA Considerations
The type field in the Mac TLV is defined as 0x404 in section 4.2.1 The type field in the MAC TLV is defined as 0x404 in section 4.2.1
and is subject to IANA approval. and is subject to IANA approval.
Copyright Notice 17. References
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Release Statement
By submitting this Internet-Draft, the authors accept the provisions 17.1. Normative References
of Section 4 of RFC 3667.
Normative References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
08.txt, Work in progress, September 2004. 10.txt, Work in progress, June 2005.
[PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf- [PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf-
pwe3-control-protocol-06.txt, Work in progress, March 2004. pwe3-control-protocol-17.txt, Work in progress, June 2005.
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std
1993 "MAC Bridges". 802.1D-1993 "MAC Bridges".
[802.1D-REV] 802.1D - "Information technology - Telecommunications [802.1D-REV] 802.1D - "Information technology - Telecommunications
and information exchange between systems - Local and metropolitan and information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access Control area networks - Common specifications - Part 3: Media Access
(MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, Control (MAC) Bridges: Revision. This is a revision of ISO/IEC
802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates
P802.12e." ISO/IEC 15802-3: 1998. P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
[802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE
Standards for Local and Metropolitan Area Networks: Virtual Bridged Standards for Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", July 1998. Local Area Networks", July 1998.
[RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. [RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036,
January 2001. January 2001.
Informative References [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation
(PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt,
Work in progress, February 2005.
[BGP-VPN] "BGP/MPLS VPNs". draft-ietf-l3vpn-rfc2547bis-03.txt, Work 17.2. Informative References
[BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work
in Progress, October 2004. in Progress, October 2004.
[RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft-ietf- [RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft-
l2vpn-radius-pe-discovery-00.txt, Work in Progress, February 2004. ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February
2005.
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", draft-ietf-l3vpn-bgpvpn-auto-04.txt, Work in Progress, based VPNs", draft-ietf-l3vpn-bgpvpn-auto-06.txt, Work in Progress,
November 2004. June 2005.
[L2FRAME] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", [L2FRAME] "Framework for Layer 2 Virtual Private Networks
draft-ietf-l2vpn-l2-framework-05, Work in Progress, June 2004. (L2VPNs)", draft-ietf-l2vpn-l2-framework-05, Work in Progress, June
2004.
[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned
Virtual Private Networks", draft-ietf-l2vpn-requirements-03.txt, Virtual Private Networks", draft-ietf-l2vpn-requirements-04.txt,
Work in Progress, October 2005. Work in Progress, October 2005.
[VPN-SEC] "Security Framework for Provider Provisioned Virtual [VPN-SEC] "Security Framework for Provider Provisioned Virtual
Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work
in Progress, November 2004. in Progress, November 2004.
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, [802.1ad] "IEEE standard for Provider Bridges", Work in Progress,
December 2002. December 2002.
Appendix: VPLS Signaling using the PWid FEC Element 18. Appendix: VPLS Signaling using the PWid FEC Element
This section is being retained because live deployments use this This section is being retained because live deployments use this
version of the signaling for VPLS. version of the signaling for VPLS.
The VPLS signaling information is carried in a Label Mapping message The VPLS signaling information is carried in a Label Mapping
sent in downstream unsolicited mode, which contains the following VC message sent in downstream unsolicited mode, which contains the
FEC TLV. following VC FEC TLV.
VC, C, VC Info Length, Group ID, Interface parameters are as defined VC, C, VC Info Length, Group ID, Interface parameters are as
in [PWE3-CTRL]. defined in [PWE3-CTRL].
We use the Ethernet PW type to identify PWs that carry Ethernet
traffic for multipoint connectivity.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv |C| VC Type |VC info Length | | VC TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID | | VCID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters | | Interface parameters |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet In a VPLS, we use a VCID (which, when using the PWid FEC, has been
traffic for multipoint connectivity. substituted with a more general identifier (AGI), to address
extending the scope of a VPLS) to identify an emulated LAN segment.
In a VPLS, we use a VCID (which has been substituted with a more Note that the VCID as specified in [PWE3-CTRL] is a service
general identifier, to address extending the scope of a VPLS) to identifier, identifying a service emulating a point-to-point
identify an emulated LAN segment. Note that the VCID as specified in virtual circuit. In a VPLS, the VCID is a single service
[PWE3-CTRL] is a service identifier, identifying a service emulating identifier, so it has global significance across all PEs involved
a point-to-point virtual circuit. In a VPLS, the VCID is a single in the VPLS instance.
service identifier.
Authors' Addresses 19. Authors' Addresses
Marc Lasserre Marc Lasserre
Riverstone Networks Riverstone Networks
Email: marc@riverstonenet.com Email: marc@riverstonenet.com
Vach Kompella Vach Kompella
Alcatel Alcatel
Email: vach.kompella@alcatel.com Email: vach.kompella@alcatel.com
IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/