draft-ietf-l2vpn-vpls-ldp-09.txt   rfc4762.txt 
Internet Draft Document Marc Lasserre Network Working Group M. Lasserre, Ed.
L2VPN Working Group Vach Kompella Request for Comments: 4762 V. Kompella, Ed.
draft-ietf-l2vpn-vpls-ldp-09.txt (Editors) Category: Standards Track Alcatel-Lucent
Virtual Private LAN Services Using LDP January 2007
Status of this Memo Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP) Signaling
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document specifies an Internet standards track protocol for the
months and may be updated, replaced, or obsoleted by other Internet community, and requests discussion and suggestions for
documents at any time. It is inappropriate to use Internet-Drafts improvements. Please refer to the current edition of the "Internet
as reference material or to cite them other than as "work in Official Protocol Standards" (STD 1) for the standardization state
progress." and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement IESG Note
By submitting this Internet-Draft, each author represents that any The L2VPN Working Group produced two separate documents, RFC 4761 and
applicable patent or other IPR claims of which he or she is aware this document, that perform similar functions using different
have been or will be disclosed, and any of which he or she becomes signaling protocols. Be aware that each method is commonly referred
aware will be disclosed, in accordance with Section 6 of BCP 79. to as "VPLS" even though they are distinct and incompatible with one
another.
Abstract Abstract
This document describes a Virtual Private LAN Service (VPLS) This document describes a Virtual Private LAN Service (VPLS) solution
solution using pseudo-wires, a service previously implemented over using pseudowires, a service previously implemented over other
other tunneling technologies and known as Transparent LAN Services tunneling technologies and known as Transparent LAN Services (TLS).
(TLS). A VPLS creates an emulated LAN segment for a given set of A VPLS creates an emulated LAN segment for a given set of users;
users, i.e., it creates a Layer 2 broadcast domain that is fully i.e., it creates a Layer 2 broadcast domain that is fully capable of
capable of learning and forwarding on Ethernet MAC addresses that learning and forwarding on Ethernet MAC addresses and that is closed
is closed to a given set of users. Multiple VPLS services can be to a given set of users. Multiple VPLS services can be supported
supported from a single PE node. from a single Provider Edge (PE) node.
This document describes the control plane functions of signaling This document describes the control plane functions of signaling
pseudo-wire labels using LDP [RFC3036], extending [RFC4447]. It is pseudowire labels using Label Distribution Protocol (LDP), extending
agnostic to discovery protocols. The data plane functions of RFC 4447. It is agnostic to discovery protocols. The data plane
forwarding are also described, focusing, in particular, on the functions of forwarding are also described, focusing in particular on
learning of MAC addresses. The encapsulation of VPLS packets is the learning of MAC addresses. The encapsulation of VPLS packets is
described by [RFC4448]. described by RFC 4448.
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
2. Table of Contents Table of Contents
1. Conventions.....................................................2 1. Introduction ....................................................3
2. Table of Contents...............................................2 2. Terminology .....................................................3
3. Introduction....................................................3 2.1. Conventions ................................................4
3.1. Terminology...................................................3 3. Acronyms ........................................................4
3.2. Acronyms......................................................4
4. Topological Model for VPLS......................................5 4. Topological Model for VPLS......................................5
4.1. Flooding and Forwarding.......................................5 4.1. Flooding and Forwarding ....................................6
4.2. Address Learning..............................................6 4.2. Address Learning ...........................................6
4.3. Tunnel Topology...............................................6 4.3. Tunnel Topology ............................................7
4.4. Loop free VPLS................................................6 4.4. Loop free VPLS .............................................7
5. Discovery.......................................................7 5. Discovery.......................................................7
6. Control Plane...................................................7 6. Control Plane...................................................7
6.1. LDP Based Signaling of Demultiplexers.........................7 6.1. LDP-Based Signaling of Demultiplexers ......................8
6.1.1. Using the Generalized PWid FEC Element......................8 6.1.1. Using the Generalized PWid FEC Element ..............8
6.2. MAC Address Withdrawal........................................8 6.2. MAC Address Withdrawal .....................................9
6.2.1. MAC List TLV................................................9 6.2.1. MAC List TLV ........................................9
6.2.2. Address Withdraw Message Containing MAC List TLV...........10 6.2.2. Address Withdraw Message Containing MAC List TLV ...11
7. Data Forwarding on an Ethernet PW..............................10 7. Data Forwarding on an Ethernet PW ..............................11
7.1. VPLS Encapsulation actions...................................10 7.1. VPLS Encapsulation Actions ................................11
7.2. VPLS Learning actions........................................11 7.2. VPLS Learning Actions .....................................12
8. Data Forwarding on an Ethernet VLAN PW.........................12 8. Data Forwarding on an Ethernet VLAN PW .........................13
8.1. VPLS Encapsulation actions...................................12 8.1. VPLS Encapsulation Actions ................................13
9. Operation of a VPLS............................................13 9. Operation of a VPLS ............................................14
9.1. MAC Address Aging............................................14 9.1. MAC Address Aging .........................................15
10. A Hierarchical VPLS Model.....................................14 10. A Hierarchical VPLS Model .....................................16
10.1. Hierarchical connectivity...................................15 10.1. Hierarchical Connectivity ................................16
10.1.1. Spoke connectivity for bridging-capable devices...........15 10.1.1. Spoke Connectivity for Bridging-Capable Devices ...17
10.1.2. Advantages of spoke connectivity..........................17 10.1.2. Advantages of Spoke Connectivity ..................18
10.1.3. Spoke connectivity for non-bridging devices...............17 10.1.3. Spoke Connectivity for Non-Bridging Devices .......19
10.2. Redundant Spoke Connections.................................19 10.2. Redundant Spoke Connections ..............................21
10.2.1. Dual-homed MTU-s..........................................19 10.2.1. Dual-Homed MTU-s ..................................21
10.2.2. Failure detection and recovery............................20 10.2.2. Failure Detection and Recovery ....................22
10.3. Multi-domain VPLS service...................................21 10.3. Multi-domain VPLS Service ................................23
11. Hierarchical VPLS model using Ethernet Access Network.........21 11. Hierarchical VPLS Model Using Ethernet Access Network .........23
11.1. Scalability.................................................22 11.1. Scalability ..............................................24
11.2. Dual Homing and Failure Recovery............................22 11.2. Dual Homing and Failure Recovery .........................24
12. Contributors..................................................22 12. Contributors ..................................................25
13. Acknowledgments...............................................23 13. Acknowledgements ..............................................25
14. Security Considerations.......................................23 14. Security Considerations .......................................26
15. IANA Considerations...........................................24 15. IANA Considerations ...........................................26
16. References....................................................24 16. References ....................................................27
16.1. Normative References........................................24 16.1. Normative References .....................................27
16.2. Informative References......................................25 16.2. Informative References ...................................27
17. Appendix: VPLS Signaling using the PWid FEC Element...........25 Appendix A. VPLS Signaling using the PWid FEC Element .............29
18. Authors' Addresses............................................26
3. Introduction 1. Introduction
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area Network
Network (LAN) connectivity and is gaining acceptance as an access (LAN) connectivity and is gaining acceptance as an access technology,
technology, specifically in Metropolitan and Wide Area Networks specifically in Metropolitan and Wide Area Networks (MAN and WAN,
(MAN and WAN, respectively). The primary motivation behind Virtual respectively). The primary motivation behind Virtual Private LAN
Private LAN Services (VPLS) is to provide connectivity between Services (VPLS) is to provide connectivity between geographically
geographically dispersed customer sites across MANs and WANs, as if dispersed customer sites across MANs and WANs, as if they were
they were connected using a LAN. The intended application for the connected using a LAN. The intended application for the end-user can
end-user can be divided into the following two categories: 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.
LANs. Sites that belong to the same broadcast domain and that are Sites that belong to the same broadcast domain and that are connected
connected via an MPLS network expect broadcast, multicast and via an MPLS network expect broadcast, multicast, and unicast traffic
unicast traffic to be forwarded to the proper location(s). This to be forwarded to the proper location(s). This requires MAC address
requires MAC address learning/aging on a per pseudo-wire basis, learning/aging on a per-pseudowire basis, and packet replication
packet replication across pseudo-wires for multicast/broadcast across pseudowires for multicast/broadcast traffic and for flooding
traffic and for flooding of unknown unicast destination traffic. of unknown unicast destination traffic.
[RFC4448] defines how to carry Layer 2 (L2) frames over point-to- [RFC4448] defines how to carry Layer 2 (L2) frames over point-to-
point pseudo-wires (PW). This document describes extensions to point pseudowires (PW). This document describes extensions to
[RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic [RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic
across multiple sites that belong to the same L2 broadcast domain across multiple sites that belong to the same L2 broadcast domain or
or VPLS. Note that the same model can be applied to other 802.1 VPLS. Note that the same model can be applied to other 802.1
technologies. It describes a simple and scalable way to offer technologies. It describes a simple and scalable way to offer
Virtual LAN services, including the appropriate flooding of Virtual LAN services, including the appropriate flooding of
broadcast, multicast and unknown unicast destination traffic over broadcast, multicast, and unknown unicast destination traffic over
MPLS, without the need for address resolution servers or other MPLS, without the need for address resolution servers 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
and have a means of tunneling labeled packets amongst each other. have a means of tunneling labeled packets amongst each other. The
The resulting set of interconnected devices forms a private MPLS resulting set of interconnected devices forms a private MPLS VPN.
VPN.
2. Terminology
3.1. Terminology
Q-in-Q 802.1ad Provider Bridge extensions also known Q-in-Q 802.1ad Provider Bridge extensions also known
as stackable VLANs or Q-in-Q. as stackable VLANs or Q-in-Q.
Qualified learning Learning mode in which each customer VLAN is Qualified learning Learning mode in which each customer VLAN is
mapped to its own VPLS instance. mapped to its own VPLS instance.
Service delimitor Information used to identify a specific customer Service delimiter Information used to identify a specific customer
service instance. This is typically encoded in service instance. This is typically encoded in
the encapsulation header of customer frames the encapsulation header of customer frames
(e.g. VLAN Id). (e.g., VLAN Id).
Tagged frame Frame with an 802.1Q VLAN identifier. Tagged frame Frame with an 802.1Q VLAN identifier.
Unqualified learning Learning mode where all the VLANs of a single Unqualified learning Learning mode where all the VLANs of a single
customer are mapped to a single VPLS. customer are mapped to a single VPLS.
Untagged frame Frame without an 802.1Q VLAN identifier Untagged frame Frame without an 802.1Q VLAN identifier.
3.2. Acronyms 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Acronyms
AC Attachment Circuit AC Attachment Circuit
BPDU Bridge Protocol Data Unit BPDU Bridge Protocol Data Unit
CE Customer Edge device CE Customer Edge device
FEC Forwarding Equivalence Class FEC Forwarding Equivalence Class
FIB Forwarding Information Base FIB Forwarding Information Base
GRE Generic Routing Encapsulation GRE Generic Routing Encapsulation
IPsec IP secutity IPsec IP security
L2TP Layer Two Tunneling Protocol L2TP Layer Two Tunneling Protocol
LAN Local Area Network LAN Local Area Network
LDP Label Distribution Protocol LDP Label Distribution Protocol
MTU-s Multi-Tenant Unit switch MTU-s Multi-Tenant Unit switch
PE Provider Edge device PE Provider Edge device
PW Pseudo-wire PW Pseudowire
STP Spanning Tree Protocol STP Spanning Tree Protocol
VLAN Virtual LAN VLAN Virtual LAN
VLAN tag VLAN Identifier VLAN tag VLAN Identifier
4. Topological Model for VPLS 4. Topological Model for VPLS
An interface participating in a VPLS must be able to flood, An interface participating in a VPLS must be able to flood, forward,
forward, and filter Ethernet frames. Figure 1 below shows the and filter Ethernet frames. Figure 1, below, shows the topological
topological model of a VPLS. The set of PE devices interconnected model of a VPLS. The set of PE devices interconnected via PWs
via PWs appears as a single emulated LAN to customer X. Each PE appears as a single emulated LAN to customer X. Each PE will form
will form remote MAC address to PW associations and associate remote MAC address to PW associations and associate directly attached
directly attached MAC addresses to local customer facing ports. MAC addresses to local customer facing ports. This is modeled on
This is modeled on standard IEEE 802.1 MAC address learning. standard IEEE 802.1 MAC address learning.
+-----+ +-----+ +-----+ +-----+
| CE1 +---+ ........................... +---| CE2 | | CE1 +---+ ........................... +---| CE2 |
+-----+ | . . | +-----+ +-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2 Site 1 | +----+ +----+ | Site 2
+---| PE | Cloud | PE |---+ +---| PE | Cloud | PE |---+
+----+ +----+ +----+ +----+
. . . .
. +----+ . . +----+ .
..........| PE |........... ..........| PE |...........
+----+ ^ +----+ ^
| | | |
| +-- Emulated LAN | +-- Emulated LAN
+-----+ +-----+
| CE3 | | CE3 |
+-----+ +-----+
Site 3 Site 3
Figure 1: Topological Model of a VPLS for Customer X Figure 1: Topological Model of a VPLS for
With three sites Customer X with three sites
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
(as mentioned in [RFC4447]), e.g., GRE, L2TP, IPsec, etc., can also (as mentioned in [RFC4447]) -- e.g., GRE, L2TP, IPsec -- can also be
be used, as long as the originating PE can be identified, since used, as long as the originating PE can be identified, since this is
this is used in the MAC learning process. 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
to the VPLS [L2VPN-REQ]. In other words, the attachment circuit the VPLS [L2VPN-REQ]. In other words, the attachment circuit (AC)
(AC) connected to the customer could be a physical Ethernet port, a connected to the customer could be a physical Ethernet port, a
logical (tagged) Ethernet port, an ATM PVC carrying Ethernet logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames,
frames, etc., or even an Ethernet PW. etc., or even an Ethernet PW.
The PE 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. In signaling protocol and/or routing protocols to set up PWs. In
addition, it is capable of setting up transport tunnels to other addition, it is capable of setting up transport tunnels to other PEs
PEs and delivering traffic over PWs. and delivering traffic over PWs.
4.1. Flooding and Forwarding 4.1. Flooding and Forwarding
One of attributes of an Ethernet service is that frames sent to One of attributes of an Ethernet service is that frames sent to
broadcast addresses and to unknown destination MAC addresses are 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 unknown unicast, broadcast and multicast provider network, all unknown unicast, broadcast and multicast frames
frames are flooded over the corresponding PWs to all PE nodes are flooded over the corresponding PWs to all PE nodes participating
participating in the VPLS, as well as to all ACs. in the VPLS, as well as to all ACs.
Note that multicast frames are a special case and do not Note that multicast frames are a special case and do not necessarily
necessarily have to be sent to all VPN members. For simplicity, have to be sent to all VPN members. For simplicity, the default
the default approach of broadcasting multicast frames is used. approach of broadcasting multicast frames is used.
To forward a frame, a PE MUST be able to associate a destination To forward a frame, a PE MUST be able to associate a destination MAC
MAC address with a PW. It is unreasonable and perhaps impossible address with a PW. It is unreasonable and perhaps impossible to
to require PEs to statically configure an association of every require that PEs statically configure an association of every
possible destination MAC address with a PW. Therefore, VPLS- possible destination MAC address with a PW. Therefore, VPLS-capable
capable PEs SHOULD have the capability to dynamically learn MAC PEs SHOULD have the capability to dynamically learn MAC addresses on
addresses on both ACs and PWs and to forward and replicate packets both ACs and PWs and to forward and replicate packets across both ACs
across both ACs and PWs. and PWs.
4.2. Address Learning 4.2. Address Learning
Unlike BGP VPNs [BGP-VPN], reachability information is not Unlike BGP VPNs [RFC4364], reachability information is not advertised
advertised and distributed via a control plane. Reachability is and distributed via a control plane. Reachability is obtained by
obtained by standard learning bridge functions in the data plane. standard learning bridge functions in the data plane.
When a packet arrives on a PW, if the source MAC address is When a packet arrives on a PW, if the source MAC address is unknown,
unknown, it needs to be associated with the PW, so that outbound it needs to be associated with the PW, so that outbound packets to
packets to that MAC address can be delivered over the associated that MAC address can be delivered over the associated PW. Likewise,
PW. Likewise, when a packet arrives on an AC, if the source MAC when a packet arrives on an AC, if the source MAC address is unknown,
address is unknown, it needs to be associated with the AC, so that it needs to be associated with the AC, so that outbound packets to
outbound packets to that MAC address can be delivered over the that MAC address can be delivered over the associated AC.
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 PW or [802.1D-ORIG], [802.1D-REV], and [802.1Q], are required when a PW or
AC state changes. AC state changes.
4.3. Tunnel Topology 4.3. Tunnel Topology
PE routers are assumed to have the capability to establish PE routers are assumed to have the capability to establish transport
transport tunnels. Tunnels are set up between PEs to aggregate tunnels. Tunnels are set up between PEs to aggregate traffic. PWs
traffic. PWs are signaled to demultiplex encapsulated Ethernet are signaled to demultiplex encapsulated Ethernet frames from
frames from multiple VPLS instances that traverse the transport multiple VPLS instances that traverse the transport tunnels.
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
PWs. PWs.
4.4. Loop free VPLS 4.4. Loop free VPLS
If the topology of the VPLS is not restricted to a full mesh, then
it may be that for two PEs not directly connected via PWs, they
would have to use an intermediary PE to relay packets. This
topology would require the use of some loop-breaking protocol, like
a spanning tree protocol.
Instead, a full mesh of PWs is established between PEs. Since If the topology of the VPLS is not restricted to a full mesh, then it
every PE is now directly connected to every other PE in the VPLS may be that for two PEs not directly connected via PWs, they would
via a PW, there is no longer any need to relay packets, and we can have to use an intermediary PE to relay packets. This topology would
instantiate a simpler loop-breaking rule - the "split horizon" require the use of some loop-breaking protocol, like a spanning tree
rule: a PE MUST NOT forward traffic from one PW to another in the protocol.
same VPLS mesh.
Note that customers are allowed to run a Spanning Tree Protocol Instead, a full mesh of PWs is established between PEs. Since every
(STP) (e.g., as defined in [802.1D-REV]), such as when a customer PE is now directly connected to every other PE in the VPLS via a PW,
has "back door" links used to provide redundancy in the case of a there is no longer any need to relay packets, and we can instantiate
failure within the VPLS. In such a case, STP Bridge PDUs (BPDUs) a simpler loop-breaking rule: the "split horizon" rule, whereby a PE
are simply tunneled through the provider cloud. MUST NOT forward traffic from one PW to another in the same VPLS
mesh.
Note that customers are allowed to run a Spanning Tree Protocol (STP)
(e.g., as defined in [802.1D-REV]), such as when a customer has "back
door" links used to provide redundancy in the case of a failure
within the VPLS. In such a case, STP Bridge PDUs (BPDUs) are simply
tunneled through the provider cloud.
5. Discovery 5. Discovery
The capability to manually configure the addresses of the remote The capability to manually configure the addresses of the remote PEs
PEs is REQUIRED. However, the use of manual configuration is not is REQUIRED. However, the use of manual configuration is not
necessary if an auto-discovery procedure is used. A number of necessary if an auto-discovery procedure is used. A number of auto-
auto-discovery procedures are compatible with this document discovery procedures are compatible with this document
([RADIUS-DISC], [BGP-DISC]). ([RADIUS-DISC], [BGP-DISC]).
6. Control Plane 6. Control Plane
This document describes the control plane functions of signaling of This document describes the control plane functions of signaling of
PW labels. Some foundational work in the area of support for PW labels. Some foundational work in the area of support for multi-
multi-homing is laid. The extensions to provide multi-homing homing is laid. The extensions to provide multi-homing support
support should work independently of the basic VPLS operation, and should work independently of the basic VPLS operation, and they are
are not described here. not described here.
6.1. LDP Based Signaling of Demultiplexers 6.1. LDP-Based Signaling of Demultiplexers
A full mesh of LDP sessions is used to establish the mesh of PWs. A full mesh of LDP sessions is used to establish the mesh of PWs.
The requirement for a full mesh of PWs may result in a large number The requirement for a full mesh of PWs may result in a large number
of targeted LDP sessions. Section 8 discusses the option of of targeted LDP sessions. Section 10 discusses the option of setting
setting up hierarchical topologies in order to minimize the size of up hierarchical topologies in order to minimize the size of the VPLS
the VPLS full mesh. full mesh.
Once an LDP session has been formed between two PEs, all PWs Once an LDP session has been formed between two PEs, all PWs between
between these two PEs are signaled over this session. these two PEs are signaled over this session.
In [RFC4447], two types of FECs are described, the PWid FEC Element In [RFC4447], two types of FECs are described: the PWid FEC Element
(FEC type 128) and the Generalized PWid FEC Element (FEC type 129). (FEC type 128) and the Generalized PWid FEC Element (FEC type 129).
The original FEC element used for VPLS was compatible with the PWid The original FEC element used for VPLS was compatible with the PWid
FEC Element. The text for signaling using PWid FEC Element has FEC Element. The text for signaling using the PWid FEC Element has
been moved to Appendix 1. What we describe below replaces that been moved to Appendix A. What we describe below replaces that with
with a more generalized L2VPN descriptor, the Generalized PWid FEC a more generalized L2VPN descriptor, the Generalized PWid FEC
Element. Element.
6.1.1. Using the Generalized PWid FEC Element 6.1.1. Using the Generalized PWid FEC Element
[RFC4447] describes a generalized FEC structure that is be used for [RFC4447] describes a generalized FEC structure that is be used for
VPLS signaling in the following manner. We describe the assignment VPLS signaling in the following manner. We describe the assignment
of the Generalized PWid FEC Element fields in the context of VPLS of the Generalized PWid FEC Element fields in the context of VPLS
signaling. signaling.
Control bit (C): This bit is used to signal the use of the control Control bit (C): This bit is used to signal the use of the control
word as specified in [RFC4447]. word as specified in [RFC4447].
PW type: The allowed PW types are Ethernet (0x0005) and Ethernet PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
tagged mode (0x004) as specified in [IANA]. tagged mode (0x004), as specified in [RFC4446].
PW info length: As specified in [RFC4447]. PW info length: As specified in [RFC4447].
Attachment Group Identifier (AGI), Length, Value: The unique name Attachment Group Identifier (AGI), Length, Value: The unique name of
of this VPLS. The AGI identifies a type of name, Length denotes this VPLS. The AGI identifies a type of name, and Length denotes the
the length of Value, which is the name of the VPLS. We use the length of Value, which is the name of the VPLS. We use the term AGI
term AGI interchangeably with VPLS identifier. interchangeably with VPLS identifier.
Target Attachment Individual Identifier (TAII), Source Attachment Target Attachment Individual Identifier (TAII), Source Attachment
Individual Identifier (SAII): These are null because the mesh of Individual Identifier (SAII): These are null because the mesh of PWs
PWs in a VPLS terminate on MAC learning tables, rather than on in a VPLS terminates on MAC learning tables, rather than on
individual attachment circuits. The use of non-null TAII and SAII individual attachment circuits. The use of non-null TAII and SAII is
is reserved for future enhancements. reserved for future enhancements.
Interface Parameters: The relevant interface parameters are: Interface Parameters: The relevant interface parameters are:
- MTU: the MTU (Maximum Transmission Unit) of the VPLS MUST be - MTU: The MTU (Maximum Transmission Unit) of the VPLS MUST be the
the same across all the PWs in the mesh. same across all the PWs in the mesh.
- Optional Description String: same as [RFC4447]. - Optional Description String: Same as [RFC4447].
- Requested VLAN ID: If the PW type is Ethernet tagged mode, - Requested VLAN ID: If the PW type is Ethernet tagged mode, this
this parameter may be used to signal the insertion of the parameter may be used to signal the insertion of the appropriate
appropriate VLAN ID, as defined in [RFC4448]. VLAN ID, as defined in [RFC4448].
6.2. MAC Address Withdrawal 6.2. MAC Address Withdrawal
It MAY be desirable to remove or unlearn MAC addresses that have It MAY be desirable to remove or unlearn MAC addresses that have been
been dynamically learned for faster convergence. This is dynamically learned for faster convergence. This is accomplished by
accomplished by sending an LDP Address Withdraw Message with the sending an LDP Address Withdraw Message with the list of MAC
list of MAC addresses to be removed to all other PEs over the addresses to be removed to all other PEs over the corresponding LDP
corresponding LDP sessions. sessions.
We introduce an optional MAC List TLV in LDP to specify a list of We introduce an optional MAC List TLV in LDP to specify a list of MAC
MAC addresses that can be removed or unlearned using the LDP addresses that can be removed or unlearned using the LDP Address
Address Withdraw Message. Withdraw Message.
The Address Withdraw message with MAC List TLVs MAY be supported in The Address Withdraw message with MAC List TLVs MAY be supported in
order to expedite removal of MAC addresses as the result of a 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 topology change (e.g., failure of the primary link for a dual-homed
VPLS-capable switch). VPLS-capable switch).
In order to minimize the impact on LDP convergence time, when the In order to minimize the impact on LDP convergence time, when the MAC
MAC list TLV contains a large number of MAC addresses, it may be list TLV contains a large number of MAC addresses, it may be
preferable to send a MAC address withdrawal message with an empty preferable to send a MAC address withdrawal message with an empty
list. list.
6.2.1. MAC List TLV 6.2.1. MAC List TLV
MAC addresses to be unlearned 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 format is described below. The encoding of a MAC List TLV address is
is the 6-octet MAC address specified by IEEE 802 documents [g-ORIG] the 6-octet MAC address specified by IEEE 802 documents [802.1D-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 #1 | MAC Address #2 |
skipping to change at page 9, line 39 skipping to change at page 10, line 24
| MAC address #2 | | MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | | 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
be ignored. 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 Type: Type field. This field MUST be set to 0x0404. This identifies
IANA approval). This identifies the TLV type as MAC List TLV. the TLV type as MAC List TLV.
Length: Length field. This field specifies the total length in Length: Length field. This field specifies the total length in
octets of the MAC addresses in the TLV. The length MUST be a octets of the MAC addresses in the TLV. The length MUST be a
multiple of 6. multiple of 6.
MAC Address: The MAC address(es) being removed. MAC Address: The MAC address(es) being removed.
The MAC Address Withdraw Message contains a FEC TLV (to identify The MAC Address Withdraw Message contains a FEC TLV (to identify the
the VPLS affected), a MAC Address TLV and optional parameters. No VPLS affected), a MAC Address TLV, and optional parameters. No
optional parameters have been defined for the MAC Address Withdraw optional parameters have been defined for the MAC Address Withdraw
signaling. Note that if a PE receives a MAC Address Withdraw signaling. Note that if a PE receives a MAC Address Withdraw Message
Message and does not understand it, it MUST ignore the message. In and does not understand it, it MUST ignore the message. In this
this case, instead of flushing its MAC address table, it will case, instead of flushing its MAC address table, it will continue to
continue to use stale information, unless: use stale information, unless:
- it receives a packet with a known MAC address association, - it receives a packet with a known MAC address association, but
but from a different PW, in which case it replaces the old from a different PW, in which case it replaces the old
association, or association; or
- it ages out the old association
The MAC Address Withdraw message only helps to speed up - it ages out the old association.
convergence, so PEs that do not understand the message can continue
to participate in the VPLS. The MAC Address Withdraw message only helps 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 List TLV 6.2.2. Address Withdraw Message Containing MAC List TLV
The processing for MAC List TLV received in an Address Withdraw The processing for MAC List TLV received in an Address Withdraw
Message is: Message is:
For each MAC address in the TLV: 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 - 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: 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 - Remove all the MAC addresses associated with the VPLS instance
learned over the PW associated with this signaling session (specified by the FEC TLV) except the MAC addresses learned over
over which the message was received 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 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 the MAC Address Withdraw Message. The number of MAC addresses can be
be deduced from the length field in the TLV. deduced from the length field in the TLV.
7. Data Forwarding on an Ethernet PW 7. Data Forwarding on an Ethernet PW
This section describes the data plane behavior on an Ethernet This section describes the data plane behavior on an Ethernet PW used
PW used in a VPLS. While the encapsulation is similar to that in a VPLS. While the encapsulation is similar to that described in
described in [RFC4448], the functions of stripping the service- [RFC4448], the functions of stripping the service-delimiting tag and
delimiting tag and using a "normalized" Ethernet frame are using a "normalized" Ethernet frame are described.
described.
7.1. VPLS Encapsulation actions 7.1. VPLS Encapsulation Actions
In a VPLS, a customer Ethernet frame without preamble is In a VPLS, a customer Ethernet frame without preamble is encapsulated
encapsulated with a header as defined in [RFC4448]. A customer with a header as defined in [RFC4448]. A customer Ethernet frame is
Ethernet frame is defined as follows: defined as follows:
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation that
that is used by the local PE as a service delimiter, i.e., to is used by the local PE as a service delimiter, i.e., to identify
identify the customer and/or the particular service of that the customer and/or the particular service of that customer, then
customer, then that encapsulation may be stripped before the that encapsulation may be stripped before the frame is sent into
frame is sent into the VPLS. As the frame exits the VPLS, the VPLS. As the frame exits the VPLS, the frame may have a
the frame may have a service-delimiting encapsulation service-delimiting encapsulation inserted.
inserted.
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation that
that is not service delimiting, then it is a customer frame is not service delimiting, then it is a customer frame whose
whose encapsulation should not be modified by the VPLS. This encapsulation should not be modified by the VPLS. This covers,
covers, for example, a frame that carries customer-specific for example, a frame that carries customer-specific VLAN tags that
VLAN tags that the service provider neither knows about nor the service provider neither knows about nor wants to modify.
wants to modify.
As an application of these rules, a customer frame 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 VPLS instance. That tag would be stripped before it is encapsulated
encapsulated in the VPLS. At egress, the frame may be tagged in the VPLS. At egress, the frame may be tagged again, if a
again, if a service-delimiting tag is used, or it may be untagged service-delimiting tag is used, or it may be untagged if none is
if none is used. used.
Likewise, if a customer frame arrives at a customer-facing port Likewise, if a customer frame arrives at a customer-facing port over
over an ATM or Frame Relay VC that identifies the customer's VPLS 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
frame is passed into the VPLS. frame is passed into the VPLS.
Contrariwise, if a customer frame 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
with the rest of the customer frame. the rest of the customer frame.
By following the above rules, the Ethernet frame that traverses a By following the above rules, the Ethernet frame that traverses a
VPLS is always a customer Ethernet frame. Note that the two VPLS is always a customer Ethernet frame. Note that the two actions,
actions, at ingress and egress, of dealing with service delimiters at ingress and egress, of dealing with service delimiters are local
are local actions that neither PE has to signal to the other. They actions that neither PE has to signal to the other. They allow, for
allow, for example, a mix-and-match of VLAN tagged and untagged example, a mix-and-match of VLAN tagged and untagged services at
services at either end, and do not carry across a VPLS a VLAN tag either end, and they do not carry across a VPLS a VLAN tag that has
that has local significance only. The service delimiter may be an local significance only. The service delimiter may be an MPLS label
MPLS label also, whereby an Ethernet PW given by [RFC4448] can also, whereby an Ethernet PW given by [RFC4448] can serve as the
serve as the access side connection into a PE. An RFC1483 Bridged access side connection into a PE. An RFC1483 Bridged PVC
PVC encapsulation could also serve as a service delimiter. By encapsulation could also serve as a service delimiter. By limiting
limiting the scope of locally significant encapsulations to the the scope of locally significant encapsulations to the edge,
edge, hierarchical VPLS models can be developed that provide the hierarchical VPLS models can be developed that provide the capability
capability to network-engineer scalable VPLS deployments, as to network-engineer scalable VPLS deployments, as described below.
described below.
7.2. VPLS Learning actions 7.2. VPLS Learning Actions
Learning is done based on the customer Ethernet frame 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 frame addressing and the appropriate mapping of customer Ethernet frame addressing and the appropriate PW
PW to use. We define two modes of learning: qualified and to use. We define two modes of learning: qualified and unqualified
unqualified learning. Qualified learning is the default mode and learning. Qualified learning is the default mode and MUST be
MUST be supported. Support of unqualified learning is OPTIONAL. supported. Support of unqualified learning is OPTIONAL.
In unqualified learning, all the VLANs of a single customer are In unqualified learning, all the VLANs of a single customer are
handled by a single VPLS, which means they all share a single handled by a single VPLS, which means they all share a single
broadcast domain and a single MAC address space. This means that broadcast domain and a single MAC address space. This means that MAC
MAC addresses need to be unique and non-overlapping among customer addresses need to be unique and non-overlapping among customer VLANs,
VLANs or else they cannot be differentiated within the VPLS or else they cannot be differentiated within the VPLS instance, and
instance and this can result in loss of customer frames. An this can result in loss of customer frames. An application of
application of unqualified learning is port-based VPLS service for unqualified learning is port-based VPLS service for a given customer
a given customer (e.g., customer with non-multiplexed AC where all (e.g., customer with non-multiplexed AC where all the traffic on a
the traffic on a physical port, which may include multiple customer physical port, which may include multiple customer VLANs, is mapped
VLANs, is mapped to a single VPLS instance). 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
VPLS instance, which means each customer VLAN has its own broadcast instance, which means each customer VLAN has its own broadcast domain
domain and MAC address space. Therefore, in qualified learning, and MAC address space. Therefore, in qualified learning, MAC
MAC addresses among customer VLANs may overlap with each other, but addresses among customer VLANs may overlap with each other, but they
they will be handled correctly since each customer VLAN has its own will be handled correctly since each customer VLAN has its own FIB;
FIB, i.e., each customer VLAN has its own MAC address space. Since i.e., each customer VLAN has its own MAC address space. Since VPLS
VPLS broadcasts multicast frames by default, qualified learning broadcasts multicast frames by default, qualified learning offers the
offers the advantage of limiting the broadcast scope to a given advantage of limiting the broadcast scope to a given customer VLAN.
customer VLAN. Qualified learning can result in large FIB table Qualified learning can result in large FIB table sizes, because the
sizes, because the logical MAC address is now a VLAN tag + MAC logical MAC address is now a VLAN tag + MAC address.
address.
For STP to work in qualified learning mode, a VPLS PE must be able For STP to work in qualified learning mode, a VPLS PE must be able to
to forward STP BPDUs over the proper VPLS instance. In a forward STP BPDUs over the proper VPLS instance. In a hierarchical
hierarchical VPLS case (see details in Section 10), service VPLS case (see details in Section 10), service delimiting tags
delimiting tags (Q-in-Q or [RFC4448]) can be added such that PEs (Q-in-Q or [RFC4448]) can be added such that PEs can unambiguously
can unambiguously identify all customer traffic, including STP identify all customer traffic, including STP BPDUs. In a basic VPLS
BPDUs. In a basic VPLS case, upstream switches must insert such case, upstream switches must insert such service delimiting tags.
service delimiting tags. When an access port is shared among When an access port is shared among multiple customers, a reserved
multiple customers, a reserved VLAN per customer domain must be VLAN per customer domain must be used to carry STP traffic. The STP
used to carry STP traffic. The STP frames are encapsulated with a frames are encapsulated with a unique provider tag per customer (as
unique provider tag per customer (as the regular customer traffic), the regular customer traffic), and a PEs looks up the provider tag to
and a PEs looks up the provider tag to send such frames across the send such frames across the proper VPLS instance.
proper VPLS instance.
8. Data Forwarding on an Ethernet VLAN PW 8. Data Forwarding on an Ethernet VLAN PW
This section describes the data plane behavior on an Ethernet VLAN This section describes the data plane behavior on an Ethernet VLAN PW
PW in a VPLS. While the encapsulation is similar to that described in a VPLS. While the encapsulation is similar to that described in
in [RFC4448], the functions of imposing tags and using a [RFC4448], the functions of imposing tags and using a "normalized"
"normalized" Ethernet frame are described. The learning behavior Ethernet frame are described. The learning behavior is the same as
is the same as for Ethernet PWs. for Ethernet PWs.
8.1. VPLS Encapsulation actions 8.1. VPLS Encapsulation Actions
In a VPLS, a customer Ethernet frame without preamble is In a VPLS, a customer Ethernet frame without preamble is encapsulated
encapsulated with a header as defined in [RFC4448]. A customer with a header as defined in [RFC4448]. A customer Ethernet frame is
Ethernet frame is defined as follows: defined as follows:
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation that
that is part of the customer frame, and is also used by the is part of the customer frame and is also used by the local PE as
local PE as a service delimiter, i.e., to identify the a service delimiter, i.e., to identify the customer and/or the
customer and/or the particular service of that customer, then particular service of that customer, then that encapsulation is
that encapsulation is preserved as the frame is sent into the preserved as the frame is sent into the VPLS, unless the Requested
VPLS, unless the Requested VLAN ID optional parameter was VLAN ID optional parameter was signaled. In that case, the VLAN
signaled. In that case, the VLAN tag is overwritten before tag is overwritten before the frame is sent out on the PW.
the frame is sent out on the PW.
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation that
that does not have the required VLAN tag, a null tag is does not have the required VLAN tag, a null tag is imposed if the
imposed if the Requested VLAN ID optional parameter was not Requested VLAN ID optional parameter was not signaled.
signaled.
As an application of these rules, a customer frame 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 VPLS instance and also identifies a customer VLAN. That tag would be
be preserved as it is encapsulated in the VPLS. preserved as it is encapsulated in the VPLS.
The Ethernet VLAN PW provides a simple way to preserve customer The Ethernet VLAN PW provides a simple way to preserve customer
802.1p 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 SHOULD 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
status code "Unknown FEC" as given in [RFC3036]. code "Unknown FEC" as given in [RFC3036].
9. Operation of a VPLS 9. Operation of a VPLS
We show here, in Figure 2 below, an example of how a VPLS works. We show here, in Figure 2, below, an example of how a VPLS works.
The following discussion uses the figure below, where a VPLS has The following discussion uses the figure below, where a VPLS has been
been set up between PE1, PE2 and PE3. The VPLS connects a customer set up between PE1, PE2, and PE3. The VPLS connects a customer with
with 4 sites labeled A1, A2, A3 and A4 through CE1, CE2, CE3 and 4 sites labeled A1, A2, A3, and A4 through CE1, CE2, CE3, and CE4,
CE4, respectively. respectively.
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full Initially, the VPLS is set up so that PE1, PE2, and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned an identifier mesh of Ethernet PWs. The VPLS instance is assigned an identifier
(AGI). For the above example, say PE1 signals PW label 102 to PE2 (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. and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
----- -----
/ A1 \ / A1 \
---- ----CE1 | ---- ----CE1 |
/ \ -------- ------- / | | / \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ ----- \ / \ / \---/ \ -----
skipping to change at page 14, line 25 skipping to change at page 15, line 25
|Agg|_/ -------- ------- |Agg|_/ -------- -------
-| | -| |
---- / ----- ---- ---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router / \/ \ / \ CE = Customer Edge Router
| A3 CE3 -CE4 A4 | PE = Provider Edge Router | A3 CE3 -CE4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation \ / \ / Agg = Layer 2 Aggregation
---- ---- ---- ----
Figure 2: Example of a VPLS Figure 2: Example of a VPLS
Assume a packet from A1 is bound for A2. When it leaves CE1, say Assume a packet from A1 is bound for A2. When it leaves CE1, say it
it has a source MAC address of M1 and a destination MAC of M2. If has a source MAC address of M1 and a destination MAC of M2. If PE1
PE1 does not know where M2 is, it will flood the packet, i.e., send does not know where M2 is, it will flood the packet; i.e., send it to
it to PE2 and PE3. When PE2 receives the packet, it will have a PW PE2 and PE3. When PE2 receives the packet, it will have a PW label
label of 201. PE2 can conclude that the source MAC address M1 is of 201. PE2 can conclude that the source MAC address M1 is behind
behind PE1, since it distributed the label 201 to PE1. It can PE1, since it distributed the label 201 to PE1. It can therefore
therefore associate MAC address M1 with PW label 102. associate MAC address M1 with PW label 102.
9.1. MAC Address Aging 9.1. MAC Address Aging
PEs that learn remote MAC addresses SHOULD have an aging mechanism PEs that learn remote MAC addresses SHOULD have an aging mechanism to
to remove unused entries associated with a PW label. This is remove unused entries associated with a PW label. This is important
important both for conservation of memory as well as for both for conservation of memory and for administrative purposes. For
administrative purposes. For example, if a customer site A is shut example, if a customer site A, is shut down, eventually the other PEs
down, eventually, the other PEs should unlearn A's MAC address. should unlearn A's MAC address.
The aging timer for MAC address M SHOULD be reset when a packet The aging timer for MAC address M SHOULD be reset when a packet with
with source MAC address M is received. source MAC address M is received.
10. 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
For each VPLS service, n*(n-1)/2 PWs must be setup between the PE each VPLS service, n*(n-1)/2 PWs must be set up 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 to large scale deployment is the packet replication requirements for
for each provisioned PWs on a PE router. Hierarchical each provisioned PWs on a PE router. Hierarchical connectivity,
connectivity, described in this document reduces signaling and described in this document, reduces signaling and replication
replication overhead to allow large scale deployment. 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 in a large multi-tenant buildings and aggregate them into a PE in a 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 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping
mapping CE interfaces to VPLS access circuits at a PE. 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 access switch domain. This can be accomplished techniques into the access switch domain. This can be accomplished
by treating the access device as a PE and provisioning PWs between by treating the access device as a PE and provisioning PWs between it
it and every other edge, as a basic VPLS. An alternative is to and every other edge, as a basic VPLS. An alternative is to utilize
utilize [RFC4448] PWs or Q-in-Q logical interfaces between the [RFC4448] PWs or Q-in-Q logical interfaces between the access device
access device and selected VPLS enabled PE routers. Q-in-Q and selected VPLS enabled PE routers. Q-in-Q encapsulation is
encapsulation is another form of L2 tunneling technique, which can another form of L2 tunneling technique, which can be used in
be used in conjunction with MPLS signaling as will be described conjunction with MPLS signaling, as will be described later. The
later. The following two sections focus on this alternative following two sections focus on this alternative approach. The VPLS
approach. The VPLS core PWs (hub) are augmented with access PWs core PWs (hub) are augmented with access PWs (spoke) to form a two-
(spoke) to form a two-tier hierarchical VPLS (H-VPLS). 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, and by
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
PE routers. The non-bridging PE router would extend a spoke PW routers. The non-bridging PE router would extend a spoke PW from a
from a Layer-2 switch that connects to it, through the service core Layer-2 switch that connects to it, through the service core network,
network, to a bridging VPLS PE router supporting hub PWs. We also to a bridging VPLS PE router supporting hub PWs. We also describe
describe how VPLS-challenged nodes and low-end CEs without MPLS how VPLS-challenged nodes and low-end CEs without MPLS capabilities
capabilities may participate in a hierarchical VPLS. may participate in a hierarchical VPLS.
For rest of this discussion we refer to a bridging capable access For rest of this discussion we refer to a bridging capable access
device as MTU-s and a non-bridging capable PE as PE-r. We refer to device as MTU-s and a non-bridging capable PE as PE-r. We refer to a
a routing and bridging capable device as PE-rs. routing and bridging capable device as PE-rs.
10.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-s devices for supporting the spoke connections. MTU-s devices for supporting the spoke connections.
10.1.1. Spoke connectivity for bridging-capable devices 10.1.1. Spoke Connectivity for Bridging-Capable Devices
In Figure 3 below, three customer sites are connected to an MTU-s In Figure 3, below, three customer sites are connected to an MTU-s
through CE-1, CE-2, and CE-3. The MTU-s has a single connection through CE-1, CE-2, and CE-3. The MTU-s has a single connection
(PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS (PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS
full mesh. For each VPLS service, a single spoke PW is set up full mesh. For each VPLS service, a single spoke PW is set up
between the MTU-s and the PE-rs based on [RFC4447]. Unlike between the MTU-s and the PE-rs based on [RFC4447]. Unlike
traditional PWs that terminate on a physical (or a VLAN-tagged traditional PWs that terminate on a physical (or a VLAN-tagged
logical) port, a spoke PW terminates on a virtual switch instance logical) port, a spoke PW terminates on a virtual switch instance
(VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices. (VSI; see [L2FRAME]) on the MTU-s and the PE-rs devices.
PE2-rs PE2-rs
+--------+ +--------+
| | | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
\ | -- | \ | -- |
\ +--------+ \ +--------+
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
skipping to change at page 16, line 38 skipping to change at page 17, line 49
+--------+ +--------+
PE3-rs PE3-rs
Agg = Layer-2 Aggregation Agg = Layer-2 Aggregation
-- --
/ \ / \
\S / = Virtual Switch Instance \S / = Virtual Switch Instance
-- --
Figure 3: An example of a hierarchical VPLS model Figure 3: An example of a hierarchical VPLS model
The MTU-s and the PE-rs treat each spoke connection like an AC of The MTU-s and the PE-rs treat each spoke connection like an AC of the
the VPLS service. The PW label is used to associate the traffic VPLS service. The PW label is used to associate the traffic from the
from the spoke to a VPLS instance. spoke to a VPLS instance.
10.1.1.1. MTU-s Operation 10.1.1.1. MTU-s Operation
An MTU-s is defined as a device that supports layer-2 switching An MTU-s is defined as a device that supports layer-2 switching
functionality and does all the normal bridging functions of functionality and does all the normal bridging functions of learning
learning and replication on all its ports, including the spoke, and replication on all its ports, including the spoke, which is
which is treated as a virtual port. Packets to unknown treated as a virtual port. Packets to unknown destinations are
destinations are replicated to all ports in the service including replicated to all ports in the service including the spoke. Once the
the spoke. Once the MAC address is learned, traffic between CE1 MAC address is learned, traffic between CE1 and CE2 will be switched
and CE2 will be switched locally by the MTU-s saving the capacity locally by the MTU-s, saving the capacity of the spoke to the PE-rs.
of the spoke to the PE-rs. Similarly traffic between CE1 or CE2 Similarly traffic between CE1 or CE2 and any remote destination is
and any remote destination is switched directly on to the spoke and switched directly onto the spoke and sent to the PE-rs over the
sent to the PE-rs over the point-to-point PW. 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
per VPLS instance for any number of access connections in the same VPLS instance for any number of access connections in the same VPLS
VPLS service. This further reduces the signaling overhead between service. This further reduces the signaling overhead between the
the MTU-s and PE-rs. MTU-s and PE-rs.
If the MTU-s is directly connected to the PE-rs, other If the MTU-s is directly connected to the PE-rs, other encapsulation
encapsulation techniques such as Q-in-Q can be used for the spoke. techniques, such as Q-in-Q, can be used for the spoke.
10.1.1.2. PE-rs Operation 10.1.1.2. PE-rs Operation
A PE-rs is a device that supports all the bridging functions for A PE-rs is a device that supports all the bridging functions for VPLS
VPLS service and supports the routing and MPLS encapsulation, i.e., service and supports the routing and MPLS encapsulation; i.e., it
it supports all the functions described for a basic VPLS as supports all the functions described for a basic VPLS, as described
described above. 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. Thus, the spoke from the MTU-s is treated other end of the spoke. Thus, the spoke from the MTU-s is treated as
as a virtual port and the PE-rs will switch traffic between the a virtual port, and the PE-rs will switch traffic between the spoke
spoke PW, hub PWs, and ACs once it has learned the MAC addresses. PW, hub PWs, and ACs once it has learned the MAC addresses.
10.1.2. Advantages of spoke connectivity 10.1.2. Advantages of Spoke Connectivity
Spoke connectivity offers several scaling and operational Spoke connectivity offers several scaling and operational advantages
advantages for creating large scale VPLS implementations, while for creating large-scale VPLS implementations, while retaining the
retaining the ability to offer all the functionality of the VPLS ability to offer all the functionality of the VPLS 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. service.
- Eliminates the need for a full mesh of tunnels and full mesh
of PWs per service between all devices participating in the - Minimizes signaling overhead, since fewer PWs are required for the
VPLS service. VPLS service.
- Minimizes signaling overhead since fewer PWs are required for
the VPLS service. - Segments VPLS nodal discovery. MTU-s needs to be aware of only
- Segments VPLS nodal discovery. MTU-s needs to be aware of the PE-rs node, although it is participating in the VPLS service
only the PE-rs node although it is participating in the VPLS that spans multiple devices. On the other hand, every VPLS PE-rs
service that spans multiple devices. On the other hand, must be aware of every other VPLS PE-rs and all of its locally
every VPLS PE-rs must be aware of every other VPLS PE-rs and connected MTU-s and PE-r devices.
all of its locally connected MTU-s and PE-r devices.
- Addition of other sites requires configuration of the new - Addition of other sites requires configuration of the new MTU-s
MTU-s but does not require any provisioning of the existing but does not require any provisioning of the existing MTU-s
MTU-s devices on that service. devices on that service.
- Hierarchical connections can be used to create VPLS service
that spans multiple service provider domains. This is - Hierarchical connections can be used to create VPLS service that
explained in a later section. spans multiple service provider domains. This is explained in a
later section.
Note that as more devices participate in the VPLS, there are more Note that as more devices participate in the VPLS, there are more
devices that require the capability for learning and replication. devices that require the capability for learning and replication.
10.1.3. Spoke connectivity for non-bridging devices 10.1.3. Spoke Connectivity for Non-Bridging Devices
In some cases, a bridging PE-rs may not be deployed, or a PE-r In some cases, a bridging PE-rs may not be deployed, or a PE-r might
might already have been deployed. In this section, we explain how already have been deployed. In this section, we explain how a PE-r
a PE-r that does not support any of the VPLS bridging functionality that does not support any of the VPLS bridging functionality can
can participate in the VPLS service. participate in the VPLS service.
In Figure 4, three customer sites are connected through CE-1, CE-2 In Figure 4, three customer sites are connected through CE-1, CE-2,
and CE-3 to the VPLS through PE-r. For every attachment circuit and CE-3 to the VPLS through PE-r. For every attachment circuit that
that participates in the VPLS service, PE-r creates a point-to- participates in the VPLS service, PE-r creates a point-to-point PW
point PW that terminates on the VSI of PE1-rs. that terminates on the VSI of PE1-rs.
PE2-rs PE2-rs
+--------+ +--------+
| | | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
\ | -- | \ | -- |
\ +--------+ \ +--------+
\ PE-r PE1-rs / | \ PE-r PE1-rs / |
skipping to change at page 18, line 40 skipping to change at page 20, line 35
/ \ | / \ | / \ | / \ |
CE-2 CE-3 | \S / | CE-2 CE-3 | \S / |
| -- | | -- |
+--------+ +--------+
PE3-rs PE3-rs
Figure 4: An example of a hierarchical VPLS Figure 4: An example of a hierarchical VPLS
with non-bridging spokes with non-bridging spokes
The PE-r is defined as a device that supports routing but does not The PE-r is defined as a device that supports routing but does not
support any bridging functions. However, it is capable of setting support any bridging functions. However, it is capable of setting up
up PWs between itself and the PE-rs. For every port that is PWs between itself and the PE-rs. For every port that is supported
supported in the VPLS service, a PW is setup from the PE-r to the in the VPLS service, a PW is set up from the PE-r to the PE-rs. Once
PE-rs. Once the PWs are setup, there is no learning or replication the PWs are set up, there is no learning or replication function
function required on the part of the PE-r. All traffic received on required on the part of the PE-r. All traffic received on any of the
any of the ACs is transmitted on the PW. Similarly all traffic ACs is transmitted on the PW. Similarly, all traffic received on a
received on a PW is transmitted to the AC where the PW terminates. PW is transmitted to the AC where the PW terminates. Thus, traffic
Thus traffic from CE1 destined for CE2 is switched at PE1-rs and from CE1 destined for CE2 is switched at PE1-rs and not at PE-r.
not at PE-r.
Note that in the case where PE-r devices use Provider VLANs (P- Note that in the case where PE-r devices use Provider VLANs (P-VLAN)
VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as as demultiplexers instead of PWs, PE1-rs can treat them as such and
such and map these "circuits" into a VPLS domain to provide map these "circuits" into a VPLS domain to provide bridging support
bridging support between them. 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 AC that spoke approach, since a PW is required for every AC that participates
participates in the service versus a single PW required per service in the service versus a single PW required per service (regardless of
(regardless of ACs) when an MTU-s is used. However, this approach ACs) when an MTU-s is used. However, this approach offers the
offers the advantage of offering a VPLS service in conjunction with advantage of offering a VPLS service in conjunction with a routed
a routed internet service without requiring the addition of new internet service without requiring the addition of new MTU-s.
MTU-s.
10.2. Redundant Spoke Connections 10.2. Redundant Spoke Connections
An obvious weakness of the hub and spoke approach described thus An obvious weakness of the hub and spoke approach described thus far
far is that the MTU-s has a single connection to the PE-rs. In is that the MTU-s has a single connection to the PE-rs. In case of
case of failure of the connection or the PE-rs, the MTU-s suffers failure of the connection or the PE-rs, the MTU-s suffers total loss
total loss of connectivity. 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-s. The provided to avoid total loss of connectivity from the MTU-s. The
mechanism described is identical for both, MTU-s and PE-r devices. mechanism described is identical for both, MTU-s and PE-r devices.
10.2.1. Dual-homed MTU-s 10.2.1. Dual-Homed MTU-s
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, the MTU-s or the PE-r is dual-homed into two PE-rs devices. PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices.
The PE-rs devices must be part of the same VPLS service instance. The PE-rs devices must be part of the same VPLS service instance.
In Figure 5, two customer sites are connected through CE-1 and CE-2 In Figure 5, two customer sites are connected through CE-1 and CE-2
to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and PE3- to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and
rs) for each VPLS instance. One of the two PWs is designated as PE3-rs) for each VPLS instance. One of the two PWs is designated as
primary and is the one that is actively used under normal primary and is the one that is actively used under normal conditions,
conditions, while the second PW is designated as secondary and is whereas the second PW is designated as secondary and is held in a
held in a standby state. The MTU-s negotiates the PW labels for standby state. The MTU-s negotiates the PW labels for both the
both the primary and secondary PWs, but does not use the secondary primary and secondary PWs, but does not use the secondary PW unless
PW unless the primary PW fails. How a spoke is designated primary the primary PW fails. How a spoke is designated primary or secondary
or secondary is outside of the scope of this document. For is outside the scope of this document. For example, a spanning tree
example, a spanning tree instance running between only the MTU-s instance running between only the MTU-s and the two PE-rs nodes is
and the two PE-rs nodes is one possible method. Another method one possible method. Another method could be configuration.
could be configuration.
PE2-rs PE2-rs
+--------+ +--------+
| | | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
\ | -- | \ | -- |
\ +--------+ \ +--------+
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
skipping to change at page 20, line 32 skipping to change at page 22, line 32
/ \ +--------+ / \ +--------+
/ \ | | / \ | |
CE-2 \ | -- | CE-2 \ | -- |
\ Secondary PW | / \ | \ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / | - - - - - - - - - - - - - - - - - | \S / |
| -- | | -- |
+--------+ +--------+
PE3-rs PE3-rs
Figure 5: An example of a dual-homed MTU-s Figure 5: An example of a dual-homed MTU-s
10.2.2. Failure detection and recovery 10.2.2. Failure Detection and Recovery
The MTU-s should control the usage of the spokes to the PE-rs The MTU-s should control the usage of the spokes to the PE-rs
devices. If the spokes are PWs, then LDP signaling is used to devices. If the spokes are PWs, then LDP signaling is used to
negotiate the PW labels, and the hello messages used for the LDP negotiate the PW labels, and the hello messages used for the LDP
session could be used to detect failure of the primary PW. The use session could be used to detect failure of the primary PW. The use
of other mechanisms which could provide faster detection failures of other mechanisms that could provide faster detection failures is
is outside the scope of this document. outside the scope of this document.
Upon failure of the primary PW, MTU-s immediately switches to the Upon failure of the primary PW, MTU-s immediately switches to the
secondary PW. At this point the PE3-rs that terminates the secondary PW. At this point, the PE3-rs that terminates 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 other PE-rs nodes in the network think that CE-1 and CE-2 are behind
behind PE1-rs and may continue to send traffic to PE1-rs until they PE1-rs and may continue to send traffic to PE1-rs until they learn
learn that the devices are now behind PE3-rs. The unlearning that the devices are now behind PE3-rs. The unlearning process can
process can take a long time and may adversely affect the take a long time and may adversely affect the connectivity of
connectivity of higher level protocols from CE1 and CE2. To enable higher-level protocols from CE1 and CE2. To enable faster
faster convergence, the PE3-rs where the secondary PW got activated convergence, the PE3-rs where the secondary PW got activated may send
may send out a flush message (as explained in section 4.2), using out a flush message (as explained in Section 6.2), using the MAC List
the MAC List TLV as defined in Section 6, to all PE-rs nodes. Upon TLV, as defined in Section 6, to all PE-rs nodes. Upon receiving the
receiving the message, PE-rs nodes flush the MAC addresses message, PE-rs nodes flush the MAC addresses associated with that
associated with that VPLS instance. VPLS instance.
10.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 devices. Two fully meshed VPLS networks are connected together using
using a single LSP tunnel between the VPLS "border" devices. A a single LSP tunnel between the VPLS "border" devices. A single
single spoke PW per VPLS service is set up to connect the two spoke PW per VPLS service is set up to connect the two domains
domains together. 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 inter-domain spokes is created between border PEs. Forwarding rules
rules over this mesh are identical to the rules defined in section over this mesh are identical to the rules defined in Section 4.
5.
This creates a three-tier hierarchical model that consists of a This creates a three-tier hierarchical model that consists of a hub-
hub-and-spoke topology between MTU-s and PE-rs devices, a full-mesh 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.
11. 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- architecture discussed previously in that it leverages the full-mesh
mesh topology among PE-rs devices; however, no restriction is topology among PE-rs devices; however, no restriction is imposed on
imposed on the topology of the Ethernet access network (e.g., the the topology of the Ethernet access network (e.g., the topology
topology between MTU-s and PE-rs devices is not restricted to hub between MTU-s and PE-rs devices is not restricted to hub and spoke).
and spoke).
The motivation for an Ethernet access network is that Ethernet- The motivation for an Ethernet access network is that Ethernet-based
based networks are currently deployed by some service providers to networks are currently deployed by some service providers to offer
offer VPLS services to their customers. Therefore, it is important VPLS services to their customers. Therefore, it is important to
to provide a mechanism that allows these networks to integrate with provide a mechanism that allows these networks to integrate with an
an IP or MPLS core to provide scalable VPLS services. 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 specifically a VPLS instance for that customer. Therefore, there is
is a one-to-one correspondence between a P-VLAN and a VPLS a one-to-one correspondence between a P-VLAN and a VPLS instance. In
instance. In this model, the MTU-s needs to have the capability of this model, the MTU-s needs to have the capability of adding the
adding the additional P-VLAN tag to non-multiplexed ACs where additional P-VLAN tag to non-multiplexed ACs where customer VLANs are
customer VLANs are not used as service delimiters. This not used as service delimiters. This functionality is described in
functionality is described in [802.1ad]. [802.1ad].
If customer VLANs need to be treated as service delimiters (e.g., If customer VLANs need to be treated as service delimiters (e.g., the
the AC is a multiplexed port), then the MTU-s needs to have 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, or push an additional P-VLAN tag, in order to resolve P-VLAN, or to push an additional P-VLAN tag, in order to resolve
overlapping VLAN tags used by different customers. Therefore, the overlapping VLAN tags used by different customers. Therefore, the
MTU-s in this model can be considered as a typical bridge with this MTU-s in this model can be considered a typical bridge with this
additional capability. This functionality is described in additional capability. This functionality is described in [802.1ad].
[802.1ad].
The PE-rs needs to be able to perform bridging functionality over The PE-rs needs to be able to perform bridging functionality over the
the standard Ethernet ports toward the access network as well as standard Ethernet ports toward the access network, as well as over
over the PWs toward the network core. In this model, the PE-rs may the PWs toward the network core. In this model, the PE-rs may need
need to run STP towards the access network, in addition to split- to run STP towards the access network, in addition to split-horizon
horizon over the MPLS core. The PE-rs needs to map a P-VLAN to a over the MPLS core. The PE-rs needs to map a P-VLAN to a VPLS-
VPLS-instance and its associated PWs and vice versa. instance and its associated PWs, and vice 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 Q-in-Q messages, customer's Ethernet encapsulation format for Q-in-Q messages, customer's Ethernet control
control protocol handling, etc.) are outside of the scope of this protocol handling, etc.) are outside the scope of this document and
document and they are covered in [802.1ad]. However, the relevant are covered in [802.1ad]. However, the relevant part is the
part is the interaction between the bridge module and the MPLS/IP interaction between the bridge module and the MPLS/IP PWs in the
PWs in the PE-rs, which behaves just as in a regular VPLS. PE-rs, which behaves just as in a regular VPLS.
11.1. Scalability 11.1. Scalability
Since each P-VLAN corresponds to a VPLS instance, the total number Since each P-VLAN corresponds to a VPLS instance, the total number of
of VPLS instances supported is limited to 4K. The P-VLAN serves as VPLS instances supported is limited to 4K. The P-VLAN serves as a
a local service delimiter within the provider's network that is local service delimiter within the provider's network that is
stripped as it gets mapped to a PW in a VPLS instance. Therefore, stripped as it gets mapped to a PW in a VPLS instance. Therefore,
the 4K limit applies only within an Ethernet access network the 4K limit applies only within an Ethernet access network (Ethernet
(Ethernet island) and not to the entire network. The SP network island) and not to the entire network. The SP network consists of a
consists of a core MPLS/IP network that connects many Ethernet core MPLS/IP network that connects many Ethernet islands. Therefore,
islands. Therefore, the number of VPLS instances can scale the number of VPLS instances can scale accordingly with the number of
accordingly with the number of Ethernet islands (a metro region can Ethernet islands (a metro region can be represented by one or more
be represented by one or more islands). islands).
11.2. Dual Homing and Failure Recovery 11.2. Dual Homing and Failure Recovery
In this model, an MTU-s can be dual homed to different devices In this model, an MTU-s can be dual homed to different devices
(aggregators and/or PE-rs devices). The failure protection for (aggregators and/or PE-rs devices). The failure protection for
access network nodes and links can be provided through running STP access network nodes and links can be provided through running STP in
in each island. The STP of each island is independent from other each island. The STP of each island is independent of other islands
islands and do not interact with each other. If an island has more and do not interact with others. If an island has more than one
than one PE-rs, then a dedicated full-mesh of PWs is used among PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs
these PE-rs devices for carrying the SP BPDU packets for that devices for carrying the SP BPDU packets for that island. On a
island. On a per P-VLAN basis, STP will designate a single PE-rs per-P-VLAN basis, STP will designate a single PE-rs to be used for
to be used for carrying the traffic across the core. The loop-free carrying the traffic across the core. The loop-free protection
protection through the core is performed using split-horizon and through the core is performed using split-horizon, and the failure
the failure protection in the core is performed through standard protection in the core is performed through standard IP/MPLS re-
IP/MPLS re-routing. routing.
12. Contributors 12. Contributors
Loa Andersson, TLA Loa Andersson, TLA
Ron Haberman, Alcatel Ron Haberman, Alcatel-Lucent
Juha Heinanen, Independent Juha Heinanen, Independent
Giles Heron, Tellabs Giles Heron, Tellabs
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel-Lucent
Luca Martini, Cisco Luca Martini, Cisco
Pascal Menezes, Independent Pascal Menezes, Independent
Rob Nath, Lucent Rob Nath, Alcatel-Lucent
Eric Puetz, SBC Eric Puetz, AT&T
Vasile Radoaca, Independent Vasile Radoaca, Independent
Ali Sajassi, Cisco Ali Sajassi, Cisco
Yetik Serbest, SBC Yetik Serbest, AT&T
Nick Slabakov, Juniper Nick Slabakov, Juniper
Andrew Smith, Consultant Andrew Smith, Consultant
Tom Soon, SBC Tom Soon, AT&T
Nick Tingle, Alcatel Nick Tingle, Alcatel-Lucent
13. Acknowledgments 13. Acknowledgments
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm
Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen,
Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable
feedback. 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 for identifying issues with the draft (Ixia), and Charlie Hundall for identifying issues with the draft in
in the course of the interoperability tests. the course of the interoperability tests.
We would also like to thank Ina Minei, Bob Thomas, Eric Gray and We would also like to thank Ina Minei, Bob Thomas, Eric Gray and
Dimitri Papadimitriou for their thorough technical review of the Dimitri Papadimitriou for their thorough technical review of the
document. document.
14. Security Considerations 14. 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 [RFC4111]. An unguarded VPLS service is
vulnerable to some security issues which pose risks to the customer vulnerable to some security issues that 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 use of per VPLS L2 FIB table and the use of per VPLS - Traffic isolation between VPLS domains is guaranteed by the
PWs use of per VPLS L2 FIB table and the use of per VPLS PWs.
- The customer traffic, which consists of Ethernet frames,
is carried unchanged over VPLS. If security is - The customer traffic, which consists of Ethernet frames, is
required, the customer traffic SHOULD be encrypted carried unchanged over VPLS. If security is required, the
and/or authenticated before entering the service customer traffic SHOULD be encrypted and/or authenticated
provider network before entering the service provider network.
- Preventing broadcast storms can be achieved by using
routers as CPE devices or by rate policing the amount of - Preventing broadcast storms can be achieved by using routers
broadcast traffic that customers can send as CPE devices or by rate policing the amount of broadcast
traffic that customers can send.
- Control plane aspects - Control plane aspects
- LDP security (authentication) methods as described in - LDP security (authentication) methods as described in
[RFC3036] SHOULD be applied. This would prevent [RFC3036] SHOULD be applied. This would prevent
unauthenticated messages from disrupting 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
per VPLS) that a PE can learn SHOULD be implemented - Some means to limit the number of MAC addresses (per site per
VPLS) that a PE can learn SHOULD be implemented.
15. IANA Considerations 15. IANA Considerations
The type field in the MAC List TLV is defined as 0x404 in section The type field in the MAC List TLV is defined as 0x404 in Section
6.2.1 and is subject to IANA approval. 6.2.1.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC4447] "Pseudowire Setup and Maintenance Using the Label [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
Distribution Protocol (LDP)", L. Martini, et al., April 2006. G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RFC4448] "Encapsulation Methods for Transport of Ethernet over [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
MPLS Networks", L. Martini, et al., RFC 4448, April 2006. "Encapsulation Methods for Transport of Ethernet over
MPLS Networks", RFC 4448, April 2006.
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std
802.1D-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
area networks - Common specifications - Part 3: Media Access metropolitan area networks - Common specifications -
Control (MAC) Bridges: Revision. This is a revision of ISO/IEC Part 3: Media Access Control (MAC) Bridges: Revision.
10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. and 802.6k-1992. It incorporates 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:
Local Area Networks", July 1998. Virtual Bridged Local Area Networks", July 1998.
[RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036, [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
January 2001. and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
(PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt, Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
Work in progress, February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References 16.2. Informative References
[BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
in Progress, October 2004. Networks (VPNs)", RFC 4364, February 2006.
[RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft- [RADIUS-DISC] Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S.,
ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February and W. Luo, "Using Radius for PE-Based VPN Discovery",
2005. Work in Progress, October 2005.
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- [BGP-DISC] Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter,
based VPNs", draft-ietf-l3vpn-bgpvpn-auto-06.txt, Work in Progress, Ed., "Using BGP as an Auto-Discovery Mechanism for
June 2005. Network-based VPNs", Work in Progress, September 2006.
[L2FRAME] "Framework for Layer 2 Virtual Private Networks [L2FRAME] Andersson, L. and E. Rosen, "Framework for Layer 2
(L2VPNs)", draft-ietf-l2vpn-l2-framework-05, Work in Progress, June Virtual Private Networks (L2VPNs)", RFC 4664,
2004. September 2006.
[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned [L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for
Virtual Private Networks", draft-ietf-l2vpn-requirements-04.txt, Layer 2 Provider-Provisioned Virtual Private
Work in Progress, October 2005. Networks", RFC 4665, September 2006.
[VPN-SEC] "Security Framework for Provider Provisioned Virtual [RFC4111] Fang, L., "Security Framework for Provider-Provisioned
Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work Virtual Private Networks (PPVPNs)", RFC 4111, July
in Progress, November 2004. 2005.
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, [802.1ad] "IEEE standard for Provider Bridges", Work in
December 2002. Progress, December 2002.
17. Appendix: VPLS Signaling using the PWid FEC Element Appendix A. 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 The VPLS signaling information is carried in a Label Mapping message
message sent in downstream unsolicited mode, which contains the sent in downstream unsolicited mode, which contains the following
following PWid FEC TLV. PWid FEC TLV.
PW, C, PW Info Length, Group ID, Interface parameters are as PW, C, PW Info Length, Group ID, and Interface parameters are as
defined in [RFC4447]. defined in [RFC4447].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW TLV |C| PW Type |PW info Length | | PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWID | | PWID |
skipping to change at page 26, line 4 skipping to change at page 29, line 30
| PW TLV |C| PW Type |PW info Length | | PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWID | | PWID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters | | Interface parameters |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet We use the Ethernet PW type to identify PWs that carry Ethernet
traffic for multipoint connectivity. traffic for multipoint connectivity.
In a VPLS, we use a VCID (which, when using the PWid FEC, has been In a VPLS, we use a VCID (which, when using the PWid FEC, has been
substituted with a more general identifier (AGI), to address substituted with a more general identifier (AGI), to address
extending the scope of a VPLS) to identify an emulated LAN segment. extending the scope of a VPLS) to identify an emulated LAN segment.
Note that the VCID as specified in [RFC4447] is a service Note that the VCID as specified in [RFC4447] is a service identifier,
identifier, identifying a service emulating a point-to-point identifying a service emulating a point-to-point virtual circuit. In
virtual circuit. In a VPLS, the VCID is a single service a VPLS, the VCID is a single service identifier, so it has global
identifier, so it has global significance across all PEs involved significance across all PEs involved in the VPLS instance.
in the VPLS instance.
18. Authors' Addresses Authors' Addresses
Marc Lasserre Marc Lasserre
Lucent Technologies Alcatel-Lucent
Email: mlasserre@lucent.com EMail: mlasserre@alcatel-lucent.com
Vach Kompella Vach Kompella
Alcatel Alcatel-Lucent
Email: vach.kompella@alcatel.com EMail: vach.kompella@alcatel-lucent.com
IPR Disclosure Acknowledgement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2006). 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 Acknowledgement
This document and the information contained herein are provided on Funding for the RFC Editor function is currently provided by the
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Internet Society.
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. 190 change blocks. 
677 lines changed or deleted 682 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/