draft-ietf-l2vpn-vpls-ldp-07.txt   draft-ietf-l2vpn-vpls-ldp-08.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
L2VPN Working Group Vach Kompella L2VPN Working Group Vach Kompella
draft-ietf-l2vpn-vpls-ldp-07.txt (Editors) draft-ietf-l2vpn-vpls-ldp-08.txt (Editors)
Expires: January 2006 July 2005 Expires: May 2006 November 2005
Virtual Private LAN Services over MPLS Virtual Private LAN Services over MPLS
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
skipping to change at page 2, line 8 skipping to change at page 1, line 48
This document describes a Virtual Private LAN Service (VPLS) This document describes a Virtual Private LAN Service (VPLS)
solution using pseudo-wires, a service previously implemented over solution using pseudo-wires, a service previously implemented over
other tunneling technologies and known as Transparent LAN Services other tunneling technologies and known as Transparent LAN Services
(TLS). A VPLS creates an emulated LAN segment for a given set of (TLS). A VPLS creates an emulated LAN segment for a given set of
users, i.e., it creates a Layer 2 broadcast domain that is fully users, i.e., it creates a Layer 2 broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses that capable of learning and forwarding on Ethernet MAC addresses that
is closed to a given set of users. Multiple VPLS services can be is closed to a given set of users. Multiple VPLS services can be
supported from a single PE node. supported from a single PE node.
This document describes the control plane functions of signaling This document describes the control plane functions of signaling
pseudo-wire labels, extending [PWE3-CTRL]. It is agnostic to pseudo-wire labels using LDP [RFC3036], extending [PWE3-CTRL]. It
discovery protocols. The data plane functions of forwarding are is agnostic to discovery protocols. The data plane functions of
also described, focusing, in particular, on the learning of MAC forwarding are also described, focusing, in particular, on the
addresses. The encapsulation of VPLS packets is described by learning of MAC addresses. The encapsulation of VPLS packets is
[PWE3-ETHERNET]. described by [PWE3-ETHERNET].
1. Conventions 1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
2. Table of Contents 2. Table of Contents
1. Conventions.....................................................2 1. Conventions.....................................................2
2. Table of Contents...............................................2 2. Table of Contents...............................................2
3. Introduction....................................................3 3. Introduction....................................................3
3.1. Terminology...................................................3
3.2. Acronyms......................................................4
4. Topological Model for VPLS......................................4 4. Topological Model for VPLS......................................4
4.1. Flooding and Forwarding.......................................4 4.1. Flooding and Forwarding.......................................5
4.2. Address Learning..............................................5 4.2. Address Learning..............................................6
4.3. Tunnel Topology...............................................5 4.3. Tunnel Topology...............................................6
4.4. Loop free VPLS................................................6 4.4. Loop free VPLS................................................6
5. Discovery.......................................................6 5. Discovery.......................................................7
6. Control Plane...................................................6 6. Control Plane...................................................7
6.1. LDP Based Signaling of Demultiplexers.........................6 6.1. LDP Based Signaling of Demultiplexers.........................7
6.1.1. Using the Generalized PWid FEC Element......................7 6.1.1. Using the Generalized PWid FEC Element......................7
6.2. MAC Address Withdrawal........................................7 6.2. MAC Address Withdrawal........................................8
6.2.1. MAC List TLV................................................8 6.2.1. MAC List TLV................................................9
6.2.2. Address Withdraw Message Containing MAC TLV.................9 6.2.2. Address Withdraw Message Containing MAC List TLV...........10
7. Data Forwarding on an Ethernet PW...............................9 7. Data Forwarding on an Ethernet PW..............................10
7.1. VPLS Encapsulation actions....................................9 7.1. VPLS Encapsulation actions...................................10
7.2. VPLS Learning actions........................................10 7.2. VPLS Learning actions........................................11
8. Data Forwarding on an Ethernet VLAN PW.........................11 8. Data Forwarding on an Ethernet VLAN PW.........................12
8.1. VPLS Encapsulation actions...................................11 8.1. VPLS Encapsulation actions...................................12
9. Operation of a VPLS............................................12 9. Operation of a VPLS............................................13
9.1. MAC Address Aging............................................13 9.1. MAC Address Aging............................................14
10. A Hierarchical VPLS Model.....................................13 10. A Hierarchical VPLS Model.....................................14
10.1. Hierarchical connectivity...................................14 10.1. Hierarchical connectivity...................................15
10.1.1. Spoke connectivity for bridging-capable devices...........14 10.1.1. Spoke connectivity for bridging-capable devices...........15
10.1.2. Advantages of spoke connectivity..........................15 10.1.2. Advantages of spoke connectivity..........................17
10.1.3. Spoke connectivity for non-bridging devices...............16 10.1.3. Spoke connectivity for non-bridging devices...............17
10.2. Redundant Spoke Connections.................................17 10.2. Redundant Spoke Connections.................................19
10.2.1. Dual-homed MTU............................................17 10.2.1. Dual-homed MTU-s..........................................19
10.2.2. Failure detection and recovery............................18 10.2.2. Failure detection and recovery............................20
10.3. Multi-domain VPLS service...................................19 10.3. Multi-domain VPLS service...................................20
11. Hierarchical VPLS model using Ethernet Access Network.........19 11. Hierarchical VPLS model using Ethernet Access Network.........21
11.1. Scalability.................................................20 11.1. Scalability.................................................22
11.2. Dual Homing and Failure Recovery............................20 11.2. Dual Homing and Failure Recovery............................22
12. Significant Modifications.....................................21 12. Contributors..................................................22
13. Contributors..................................................21 13. Acknowledgments...............................................22
14. Acknowledgments...............................................21 14. Security Considerations.......................................23
15. Security Considerations.......................................21 15. IANA Considerations...........................................23
16. IANA Considerations...........................................22 16. References....................................................24
17. References....................................................22 16.1. Normative References........................................24
17.1. Normative References........................................22 16.2. Informative References......................................24
17.2. Informative References......................................23 17. Appendix: VPLS Signaling using the PWid FEC Element...........25
18. Appendix: VPLS Signaling using the PWid FEC Element...........23 18. Authors' Addresses............................................25
19. Authors' Addresses............................................24
3. Introduction 3. Introduction
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area
Network (LAN) connectivity and is gaining acceptance as an access Network (LAN) connectivity and is gaining acceptance as an access
technology, specifically in Metropolitan and Wide Area Networks technology, specifically in Metropolitan and Wide Area Networks
(MAN and WAN, respectively). The primary motivation behind Virtual (MAN and WAN, respectively). The primary motivation behind Virtual
Private LAN Services (VPLS) is to provide connectivity between Private LAN Services (VPLS) is to provide connectivity between
geographically dispersed customer sites across MANs and WANs, as if geographically dispersed customer sites across MANs and WANs, as if
they were connected using a LAN. The intended application for the they were connected using a LAN. The intended application for the
skipping to change at page 4, line 4 skipping to change at page 3, line 49
[802.1Q] traffic across multiple sites that belong to the same L2 [802.1Q] traffic across multiple sites that belong to the same L2
broadcast domain or VPLS. Note that the same model can be applied broadcast domain or VPLS. Note that the same model can be applied
to other 802.1 technologies. It describes a simple and scalable to other 802.1 technologies. It describes a simple and scalable
way to offer Virtual LAN services, including the appropriate way to offer Virtual LAN services, including the appropriate
flooding of broadcast, multicast and unknown unicast destination flooding of broadcast, multicast and unknown unicast destination
traffic over MPLS, without the need for address resolution servers traffic over MPLS, without the need for address resolution servers
or other external servers, as discussed in [L2VPN-REQ]. or other external servers, as discussed in [L2VPN-REQ].
The following discussion applies to devices that are VPLS capable The following discussion applies to devices that are VPLS capable
and have a means of tunneling labeled packets amongst each other. and have a means of tunneling labeled packets amongst each other.
The resulting set of interconnected devices forms a private MPLS The resulting set of interconnected devices forms a private MPLS
VPN. VPN.
3.1. Terminology
Q-in-Q 802.1ad Provider Bridge extensions also known
as stackable VLANs or Q-in-Q.
Qualified learning Learning mode in which each customer VLAN is
mapped to its own VPLS instance.
Service delimiter Information used to identify a specific customer
service instance. This is typically encoded in
the encapsulation header of customer frames
(e.g. VLAN Id).
Tagged frame Frame with an 802.1Q VLAN identifier.
Unqualified learning Learning mode where all the VLANs of a single
customer are mapped to a single VPLS.
Untagged frame Frame without an 802.1Q VLAN identifier
3.2. Acronyms
AC Attachment Circuit
BPDU Bridge Protocol Data Unit
CE Customer Edge device
FEC Forwarding Equivalence Class
FIB Forwarding Information Base
LAN Local Area Network
LDP Label Distribution Protocol
MTU-s Multi-Tenant Unit switch
PE Provider Edge device
PW Pseudo-wire
STP Spanning Tree Protocol
VLAN Virtual LAN
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, and filter Ethernet frames. The set of PE devices forward, and filter Ethernet frames. Figure 1 below shows the
interconnected via PWs appears as a single emulated LAN to customer topological model of a VPLS. The set of PE devices interconnected
C1. Each PE will form remote MAC address to PW associations and via PWs appears as a single emulated LAN to customer X. Each PE
associate directly attached MAC addresses to local customer facing will form remote MAC address to PW associations and associate
ports. This is modeled on standard IEEE 802.1 MAC address directly attached MAC addresses to local customer facing ports.
learning. This is modeled on standard IEEE 802.1 MAC address learning.
+----+ +----+ +-----+ +-----+
+ C1 +---+ ........................... +---| C1 | | CE1 +---+ ........................... +---| CE2 |
+----+ | . . | +----+ +-----+ | . . | +-----+
Site A | +----+ +----+ | Site B Site 1 | +----+ +----+ | Site 2
+---| PE | Cloud | PE |---+ +---| PE | Cloud | PE |---+
+----+ +----+ +----+ +----+
. . . .
. +----+ . . +----+ .
..........| PE |........... ..........| PE |...........
+----+ ^ +----+ ^
| | | |
| +-- Emulated LAN | +-- Emulated LAN
+----+ +-----+
| C1 | | CE3 |
+----+ +-----+
Site C Site 3
Figure 1: Topological Model of a VPLS for 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 [PWE-CTRL]), e.g., GRE, L2TP, IPSEC, etc., can (as mentioned in [PWE-CTRL]), e.g., GRE, L2TP, IPSEC, etc., can
also be used, as long as the originating PE can be identified, also be used, as long as the originating PE can be identified,
since this is used in the MAC learning process. since this is used in the MAC learning process.
The scope of the VPLS lies within the PEs in the service provider The scope of the VPLS lies within the PEs in the service provider
network, highlighting the fact that apart from customer service network, highlighting the fact that apart from customer service
delineation, the form of access to a customer site is not relevant delineation, the form of access to a customer site is not relevant
to the VPLS [L2VPN-REQ]. In other words, the access circuit (AC) to the VPLS [L2VPN-REQ]. In other words, the attachment circuit
connected to the customer could be a physical Ethernet port, a (AC) 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, etc., or even an Ethernet PW. frames, 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 and delivering traffic over PWs. PEs and delivering traffic over PWs.
4.1. Flooding and Forwarding 4.1. Flooding and Forwarding
skipping to change at page 6, line 20 skipping to change at page 7, line 12
topology would require the use of some loop-breaking protocol, like topology would require the use of some loop-breaking protocol, like
a spanning tree protocol. a spanning tree protocol.
Instead, a full mesh of PWs is established between PEs. Since Instead, a full mesh of PWs is established between PEs. Since
every PE is now directly connected to every other PE in the VPLS every PE is now directly connected to every other PE in the VPLS
via a PW, there is no longer any need to relay packets, and we can via a PW, there is no longer any need to relay packets, and we can
instantiate a simpler loop-breaking rule - the "split horizon" instantiate a simpler loop-breaking rule - the "split horizon"
rule: a PE MUST NOT forward traffic from one PW to another in the rule: a PE MUST NOT forward traffic from one PW to another in the
same VPLS mesh. same VPLS mesh.
Note that customers are allowed to run the Spanning Tree Protocol Note that customers are allowed to run a Spanning Tree Protocol
(STP) such as when a customer has "back door" links used to provide (STP) (e.g., as defined in [802.1D-REV]), such as when a customer
redundancy in the case of a failure within the VPLS. In such a has "back door" links used to provide redundancy in the case of a
case, STP Bridge PDUs (BPDUs) are simply tunneled through the failure within the VPLS. In such a case, STP Bridge PDUs (BPDUs)
provider cloud. 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 is REQUIRED. However, the use of manual configuration is not PEs is REQUIRED. However, the use of manual configuration is not
necessary if an auto-discovery procedure is used. A number of necessary if an auto-discovery procedure is used. A number of
auto-discovery procedures are compatible with this document auto-discovery procedures are compatible with this document
([RADIUS-DISC], [BGP-DISC]). ([RADIUS-DISC], [BGP-DISC]).
6. Control Plane 6. Control Plane
skipping to change at page 7, line 20 skipping to change at page 8, line 13
for VPLS signaling in the following manner. We describe the for VPLS signaling in the following manner. We describe the
assignment of the Generalized PWid FEC Element fields in the assignment of the Generalized PWid FEC Element fields in the
context of VPLS signaling. context of VPLS signaling.
Control bit (C): 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 [PWE3-CTRL]. word as specified in [PWE3-CTRL].
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 [IANA].
VC info length: As specified in [PWE3-CTRL]. PW info length: As specified in [PWE3-CTRL].
AGI, Length, Value: The unique name of this VPLS. The AGI AGI, Length, Value: The unique name of this VPLS. The AGI
identifies a type of name, Length denotes the length of Value, identifies a type of name, Length denotes the length of Value,
which is the name of the VPLS. We use the term AGI interchangeably which is the name of the VPLS. We use the term AGI interchangeably
with VPLS identifier. with VPLS identifier.
TAII, SAII: These are null because the mesh of PWs in a VPLS TAII, SAII: These are null because the mesh of PWs in a VPLS
terminate on MAC learning tables, rather than on individual terminate on MAC learning tables, rather than on individual
attachment circuits. The use of non-null TAII and SAII is reserved attachment circuits. The use of non-null TAII and SAII is reserved
for future enhancements. for future enhancements.
Interface Parameters: The relevant interface parameters are: Interface Parameters: The relevant interface parameters are:
- MTU: the MTU of the VPLS MUST be the same across all the PWs - MTU: the MTU (Maximum Transmission Unit) of the VPLS MUST be
in the mesh. the same across all the PWs in the mesh.
- Optional Description String: same as [PWE3-CTRL]. - Optional Description String: same as [PWE3-CTRL].
- Requested VLAN ID: If the PW type is Ethernet tagged mode, - Requested VLAN ID: If the PW type is Ethernet tagged mode,
this parameter may be used to signal the insertion of the this parameter may be used to signal the insertion of the
appropriate VLAN ID as specified in section 6.1. appropriate VLAN ID, as defined in [PWE3-ETH].
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 dynamically learned for faster convergence. This is been dynamically learned for faster convergence. This is
accomplished by sending a MAC Address Withdraw Message with the accomplished by sending an LDP Address Withdraw Message with the
list of MAC addresses to be removed to all other PEs over the list of MAC addresses to be removed to all other PEs over the
corresponding LDP sessions. corresponding LDP sessions.
We introduce an optional MAC List TLV that is used to specify a We introduce an optional MAC List TLV in LDP to specify a list of
list of MAC addresses that can be removed or unlearned using the MAC addresses that can be removed or unlearned using the LDP
Address Withdraw Message. Address Withdraw Message.
The Address Withdraw message with MAC 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
MTU-s). 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 list TLV contains a large number of MAC addresses, it may be MAC 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 the 6-byte MAC address specified by IEEE 802 documents [g-ORIG] is the 6-octet MAC address specified by IEEE 802 documents [g-ORIG]
[802.1D-REV]. [802.1D-REV].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | | MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | MAC Address #2 | | MAC address #1 | MAC Address #2 |
skipping to change at page 8, line 48 skipping to change at page 9, line 43
U bit: Unknown bit. This bit MUST be set to 1. If the MAC address U bit: Unknown bit. This bit MUST be set to 1. If the MAC address
format is not understood, then the TLV is not understood, and MUST format is not understood, then the TLV is not understood, and MUST
be ignored. be ignored.
F bit: Forward bit. This bit MUST be set to 0. Since the LDP F bit: Forward bit. This bit MUST be set to 0. Since the LDP
mechanism used here is targeted, the TLV MUST NOT be forwarded. mechanism used here is targeted, the TLV MUST NOT be forwarded.
Type: Type field. This field MUST be set to 0x0404 (subject to Type: Type field. This field MUST be set to 0x0404 (subject to
IANA approval). This identifies the TLV type as MAC List TLV. IANA approval). This identifies the TLV type as MAC List TLV.
Length: Length field. This field specifies the total length of the Length: Length field. This field specifies the total length in
MAC addresses in the TLV. octets of the MAC addresses in the TLV. The length MUST be a
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 VPLS in consideration), a MAC Address TLV and optional the VPLS affected), a MAC Address TLV and optional parameters. No
parameters. No optional parameters have been defined for the MAC optional parameters have been defined for the MAC Address Withdraw
Address Withdraw signaling. Note that if a PE receives a MAC signaling. Note that if a PE receives a MAC Address Withdraw
Address Withdraw Message and does not understand it, it MUST ignore Message and does not understand it, it MUST ignore the message. In
the message. In this case, instead of flushing its MAC address this case, instead of flushing its MAC address table, it will
table, it will continue to use stale information, unless: continue to 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 from a different PW, in which case it replaces the old but from a different PW, in which case it replaces the old
association, or association, or
- it ages out the old association - it ages out the old association
The MAC Address Withdraw message only helps to speed up The MAC Address Withdraw message only helps to speed up
convergence, so PEs that do not understand the message can continue convergence, so PEs that do not understand the message can continue
to participate in the VPLS. to participate in the VPLS.
6.2.2. Address Withdraw Message Containing MAC 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 - Remove the association between the MAC address and the AC or
PW over which this message is received 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 - Remove all the MAC addresses associated with the VPLS
skipping to change at page 9, line 40 skipping to change at page 10, line 37
over which the message was received 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 deduced from the length field in the TLV. be 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 in a VPLS. While the encapsulation is similar to that PW used in a VPLS. While the encapsulation is similar to that
described in [PWE3-ETHERNET], the NSP functions of stripping the described in [PWE3-ETHERNET], the functions of stripping the
service-delimiting tag and using a "normalized" Ethernet frame are service-delimiting tag and 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 with a header as defined in [PWE3-ETHERNET]. A encapsulated with a header as defined in [PWE3-ETHERNET]. A
customer Ethernet frame is defined as follows: customer Ethernet frame is 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
skipping to change at page 11, line 28 skipping to change at page 12, line 22
domain and MAC address space. Therefore, in qualified learning, domain and MAC address space. Therefore, in qualified learning,
MAC addresses among customer VLANs may overlap with each other, but MAC addresses among customer VLANs may overlap with each other, but
they will be handled correctly since each customer VLAN has its own they will be handled correctly since each customer VLAN has its own
FIB, i.e., each customer VLAN has its own MAC address space. Since FIB, i.e., each customer VLAN has its own MAC address space. Since
VPLS broadcasts multicast frames by default, qualified learning VPLS broadcasts multicast frames by default, qualified learning
offers the advantage of limiting the broadcast scope to a given offers the advantage of limiting the broadcast scope to a given
customer VLAN. Qualified learning can result in large FIB table customer VLAN. Qualified learning can result in large FIB table
sizes, because the logical MAC address is now a VLAN tag + MAC sizes, because the logical MAC address is now a VLAN tag + MAC
address. address.
For STP to work in qualified mode, a VPLS PE must be able to For STP to work in qualified learning mode, a VPLS PE must be able
forward STP BPDUs over the proper VPLS instance. In a hierarchical to forward STP BPDUs over the proper VPLS instance. In a
VPLS case (see details in Section 10), service delimiting tags (Q- hierarchical VPLS case (see details in Section 10), service
in-Q or [PWE3-ETHERNET]) can be added by MTU-s nodes such that PEs delimiting tags (Q-in-Q or [PWE3-ETHERNET]) can be added such that
can unambiguously identify all customer traffic, including STP/MSTP PEs can unambiguously identify all customer traffic, including STP
BPDUs. In a basic VPLS case, upstream switches must insert such BPDUs. In a basic VPLS case, upstream switches must insert such
service delimiting tags. When an access port is shared among service delimiting tags. When an access port is shared among
multiple customers, a reserved VLAN per customer domain must be multiple customers, a reserved VLAN per customer domain must be
used to carry STP/MSTP traffic. The STP/MSTP frames are used to carry STP traffic. The STP frames are encapsulated with a
encapsulated with a unique provider tag per customer (as the unique provider tag per customer (as the regular customer traffic),
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 in a VPLS. While the encapsulation is similar to that described PW in a VPLS. While the encapsulation is similar to that described
in [PWE3-ETHERNET], the NSP functions of imposing tags and using a in [PWE3-ETHERNET], the functions of imposing tags and using a
"normalized" Ethernet frame are described. The learning behavior "normalized" Ethernet frame are described. The learning behavior
is the same as for Ethernet PWs. is the same as 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 with a header as defined in [PWE3-ETHERNET]. A encapsulated with a header as defined in [PWE3-ETHERNET]. A
customer Ethernet frame is defined as follows: customer Ethernet frame is 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
skipping to change at page 12, line 31 skipping to change at page 13, line 27
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 code "Unknown FEC" as given in [RFC3036]. status code "Unknown FEC" as given in [RFC3036].
9. Operation of a VPLS 9. Operation of a VPLS
We show here an example of how a VPLS works. The following We show here, in Figure 2 below, an example of how a VPLS works.
discussion uses the figure below, where a VPLS has been set up The following discussion uses the figure below, where a VPLS has
between PE1, PE2 and PE3. been set up between PE1, PE2 and PE3. The VPLS connects a customer
with 4 sites labeled A1, A2, A3 and A4 through CE1, CE2, CE3 and
CE4, respectively.
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned a identifier
(AGI). For the above example, say PE1 signals PW label 102 to PE2
and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
----- -----
/ A1 \ / A1 \
---- ----CE1 | ---- ----CE1 |
/ \ -------- ------- / | | / \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ ----- \ / \ / \---/ \ -----
---- ---PE2 | ---- ---PE2 |
| Service Provider Network | | Service Provider Network |
\ / \ / \ / \ /
----- PE3 / \ / ----- PE3 / \ /
|Agg|_/ -------- ------- |Agg|_/ -------- -------
-| | -| |
---- / ----- ---- ---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router / \/ \ / \ CE = Customer Edge Router
| A3 CE3 --C4 A4 | PE = Provider Edge Router | A3 CE3 -CE4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation \ / \ / Agg = Layer 2 Aggregation
---- ---- ---- ----
Figure 2: Example of a VPLS
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned a identifier
(AGI). For the above example, say PE1 signals PW label 102 to PE2
and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
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 has a source MAC address of M1 and a destination MAC of M2. If it has a source MAC address of M1 and a destination MAC of M2. If
PE1 does not know where M2 is, it will flood the packet, i.e., send PE1 does not know where M2 is, it will flood the packet, i.e., send
it to PE2 and PE3. When PE2 receives the packet, it will have a PW it to PE2 and PE3. When PE2 receives the packet, it will have a PW
label of 201. PE2 can conclude that the source MAC address M1 is label of 201. PE2 can conclude that the source MAC address M1 is
behind PE1, since it distributed the label 201 to PE1. It can behind PE1, since it distributed the label 201 to PE1. It can
therefore associate MAC address M1 with PW label 102. therefore associate MAC address M1 with PW label 102.
9.1. MAC Address Aging 9.1. MAC Address Aging
skipping to change at page 13, line 44 skipping to change at page 14, line 43
connectivity, described in this document reduces signaling and connectivity, described in this document reduces signaling and
replication overhead to allow large scale deployment. replication overhead to allow large scale deployment.
In many cases, service providers place smaller edge devices in In many cases, service providers place smaller edge devices in
multi-tenant buildings and aggregate them into a PE 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 CE interfaces to VPLS access circuits at a PE. mapping CE interfaces to VPLS access circuits at a PE.
It is often beneficial to extend the VPLS service tunneling It is often beneficial to extend the VPLS service tunneling
techniques into the MTU (multi-tenant unit) domain. This can be techniques into the access switch domain. This can be accomplished
accomplished by treating the MTU as a PE and provisioning PWs by treating the access device as a PE and provisioning PWs between
between it and every other edge, as a basic VPLS. An alternative it and every other edge, as a basic VPLS. An alternative is to
is to utilize [PWE3-ETHERNET] PWs or Q-in-Q logical interfaces utilize [PWE3-ETHERNET] PWs or Q-in-Q logical interfaces between
between the MTU and selected VPLS enabled PE routers. Q-in-Q the access device and selected VPLS enabled PE routers. Q-in-Q
encapsulation is another form of L2 tunneling technique, which can encapsulation is another form of L2 tunneling technique, which can
be used in conjunction with MPLS signaling as will be described be used in conjunction with MPLS signaling as will be described
later. The following two sections focus on this alternative later. The following two sections focus on this alternative
approach. The VPLS core PWs (hub) are augmented with access PWs approach. The VPLS core PWs (hub) are augmented with access PWs
(spoke) to form a two-tier hierarchical VPLS (H-VPLS). (spoke) to form a two-tier hierarchical VPLS (H-VPLS).
Spoke PWs may be implemented using any L2 tunneling mechanism, Spoke PWs may be implemented using any L2 tunneling mechanism,
expanding the scope of the first tier to include non-bridging VPLS expanding the scope of the first tier to include non-bridging VPLS
PE routers. The non-bridging PE router would extend a spoke PW PE routers. The non-bridging PE router would extend a spoke PW
from a Layer-2 switch that connects to it, through the service core from a Layer-2 switch that connects to it, through the service core
network, to a bridging VPLS PE router supporting hub PWs. We also network, to a bridging VPLS PE router supporting hub PWs. We also
describe how VPLS-challenged nodes and low-end CEs without MPLS describe how VPLS-challenged nodes and low-end CEs without MPLS
capabilities may participate in a hierarchical VPLS. capabilities may participate in a hierarchical VPLS.
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
a 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 devices for supporting the spoke connections. For rest of this MTU-s devices for supporting the spoke connections.
discussion we refer to a bridging capable MTU as MTU-s and a non-
bridging capable PE as PE-r. We refer to a routing and bridging
capable device as PE-rs.
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
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
full mesh. For each VPLS service, a single spoke PW is set up
between the MTU-s and the PE-rs based on [PWE3-CTRL]. Unlike
traditional PWs that terminate on a physical (or a VLAN-tagged
logical) port, a spoke PW terminates on a virtual switch instance
(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 / |
\ ------ ------ / | +--------+ +--------+ / |
/ \ / \ / | | | | | / |
| \ -- | PW-1 | -- |---/ | | -- | PW-1 | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | | | / \--|- - - - - - - - - - - | / \ | |
| \S / | | \S / | | | \S / | | \S / | |
\ /-- / \ -- / ---\ | | -- | | -- |---\ |
/----- ------ \ | +--------+ +--------+ \ |
/ \ | / \ |
---- \ ------ ---- +--------+
|Agg | / \ |Agg | | |
---- | -- | ---- | -- |
/ \ | / \ | / \ | / \ |
CE-2 CE-3 | \S / | CE-2 CE-3 | \S / |
\ -- / | -- |
MTU-s = Bridging capable MTU ------ +--------+
PE-rs = VPLS capable PE PE3-rs PE3-rs
Agg = Layer-2 Aggregation Agg = Layer-2 Aggregation
-- --
/ \ / \
\S / = Virtual Switch Instance \S / = Virtual Switch Instance
-- --
In the figure above where an MTU-s has a single connection to a PE- Figure 3: An example of a hierarchical VPLS model
rs placed in the CO. The PE-rs devices are connected in a basic
VPLS full mesh. For each VPLS service, a single spoke PW is set up
between the MTU-s and the PE-rs based on [PWE3-CTRL]. Unlike
traditional PWs that terminate on a physical (or a VLAN-tagged
logical) port, a spoke PW terminates on a virtual switch instance
(VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices.
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 VPLS service. The PW label is used to associate the traffic the VPLS service. The PW label is used to associate the traffic
from the spoke to a VPLS instance. from the 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 and replication on all its ports, including the spoke, learning and replication on all its ports, including the spoke,
skipping to change at page 16, line 22 skipping to change at page 17, line 50
MTU-s devices on that service. MTU-s devices on that service.
- Hierarchical connections can be used to create VPLS service - Hierarchical connections can be used to create VPLS service
that spans multiple service provider domains. This is that spans multiple service provider domains. This is
explained in a later section. 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 in a CO or a In some cases, a bridging PE-rs may not be deployed, or a PE-r
multi-tenant building, or a PE-r might already be deployed. In might already have been deployed. In this section, we explain how
this section, we explain how a PE-r that does not support any of a PE-r that does not support any of the VPLS bridging functionality
the VPLS bridging functionality can participate in the VPLS can participate in the VPLS service.
service. As shown in this figure, the PE-r creates a point-to-
point tunnel LSP to a PE-rs. 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
that participates in the VPLS service, PE-r creates a point-to-
point PW 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 / |
\ ------ ------ / | +--------+ +--------+ / |
/ \ / \ / | |\ | | | / |
| \ | VC-1 | -- |---/ | | \ | PW-1 | -- |---/ |
| ------|- - - - - - - - - - - |--/ \ | | | ------|- - - - - - - - - - - | / \ | |
| -----|- - - - - - - - - - - |--\S / | | | -----|- - - - - - - - - - - | \S / | |
\ / / \ -- / ---\ | | / | | -- |---\ |
------ ------ \ | +--------+ +--------+ \ |
/ \ | / \ |
---- \------ ---- +--------+
| Agg| / \ | Agg| | |
---- | -- | ---- | -- |
/ \ | / \ | / \ | / \ |
CE-2 CE-3 | \S / | CE-2 CE-3 | \S / |
\ -- / | -- |
------ +--------+
PE3-rs PE3-rs
Then for every access port that needs to participate in a VPLS
service, the PE-r creates a point-to-point PW that terminates on Figure 4: An example of a hierarchical VPLS
the physical port at the PE-r and terminates on the VSI of the VPLS with non-bridging spokes
service at the PE-rs.
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 PWs between itself and the PE-rs. For every port that is up PWs between itself and the PE-rs. For every port that is
supported in the VPLS service, a PW is setup from the PE-r to the supported in the VPLS service, a PW is setup from the PE-r to the
PE-rs. Once the PWs are setup, there is no learning or replication PE-rs. Once the PWs are setup, there is no learning or replication
function required on the part of the PE-r. All traffic received on function required on the part of the PE-r. All traffic received on
any of the ACs is transmitted on the PW. Similarly all traffic any of the ACs is transmitted on the PW. Similarly all traffic
received on a PW is transmitted to the AC where the PW terminates. received on a PW is transmitted to the AC where the PW terminates.
Thus traffic from CE1 destined for CE2 is switched at PE1-rs and Thus traffic from CE1 destined for CE2 is switched at PE1-rs and
skipping to change at page 17, line 31 skipping to change at page 19, line 8
VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as
such and map these "circuits" into a VPLS domain to provide such and map these "circuits" into a VPLS domain to provide
bridging support between them. bridging support between them.
This approach adds more overhead than the bridging capable (MTU-s) This approach adds more overhead than the bridging capable (MTU-s)
spoke approach since a PW is required for every AC that spoke approach since a PW is required for every AC that
participates in the service versus a single PW required per service participates in the service versus a single PW required per service
(regardless of ACs) when an MTU-s is used. However, this approach (regardless of ACs) when an MTU-s is used. However, this approach
offers the advantage of offering a VPLS service in conjunction with offers the advantage of offering a VPLS service in conjunction with
a routed internet service without requiring the addition of new a routed internet service without requiring the addition of new
MTU. 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 is that the MTU has a single connection to the PE-rs. In case far is that the MTU-s has a single connection to the PE-rs. In
of failure of the connection or the PE-rs, the MTU suffers total case of failure of the connection or the PE-rs, the MTU-s suffers
loss of connectivity. total loss of connectivity.
In this section we describe how the redundant connections can be In this section we describe how the redundant connections can be
provided to avoid total loss of connectivity from the MTU. 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 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.
as shown in figure-3. The PE-rs devices must be part of the same The PE-rs devices must be part of the same VPLS service instance.
VPLS service instance.
An MTU-s can set up two PWs (one each to PE1-rs and 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 conditions, while
the second PW is designated as secondary and is held in a standby
state. The MTU negotiates the PW labels for both the primary and
secondary PWs, but does not use the secondary PW unless the primary
PW fails. How a spoke is designated primary or secondary is
outside of the scope of this document. For example, a spanning
tree instance running between only the MTU and the two PE-rs nodes
is one possible method. Another method could be configuration.
PE2-rs PE2-rs
------ +--------+
/ \ | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
\ \ -- / \ | -- |
\ /------ \ +--------+
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
\------ ------ / | +--------+ +--------+ / |
/ \ / \ / | | | | | / |
| -- | Primary PW | -- |---/ | | -- | Primary PW | -- |---/ |
| / \--|- - - - - - - - - - - |--/ \ | | | / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | | | \S / | | \S / | |
\ -- \/ \ -- / ---\ | | -- | | -- |---\ |
------\ ------ \ | +--------+ +--------+ \ |
/ \ \ | / \ \ |
/ \ \ ------ / \ +--------+
/ \ / \ / \ | |
CE-2 \ | -- | CE-2 \ | -- |
\ Secondary PW | / \ | \ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - |-\S / | - - - - - - - - - - - - - - - - - | \S / |
\ -- / | -- |
------ +--------+
PE3-rs PE3-rs
Figure 5: An example of a dual-homed MTU-s
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-
rs) for each VPLS instance. One of the two PWs is designated as
primary and is the one that is actively used under normal
conditions, while the second PW is designated as secondary and is
held in a standby state. The MTU-s negotiates the PW labels for
both the primary and secondary PWs, but does not use the secondary
PW unless the primary PW fails. How a spoke is designated primary
or secondary is outside of the scope of this document. For
example, a spanning tree instance running between only the MTU-s
and the two PE-rs nodes is one possible method. Another method
could be configuration.
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 which could provide faster detection failures
is outside the scope of this document. is 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 PE1-rs and may continue to send traffic to PE1-rs until they behind PE1-rs and may continue to send traffic to PE1-rs until they
learn that the devices are now behind PE3-rs. The unlearning learn that the devices are now behind PE3-rs. The unlearning
process can take a long time and may adversely affect the process can take a long time and may adversely affect the
connectivity of higher level protocols from CE1 and CE2. To enable connectivity of higher level protocols from CE1 and CE2. To enable
faster convergence, the PE3-rs where the secondary PW got activated faster convergence, the PE3-rs where the secondary PW got activated
may send out a flush message (as explained in section 4.2), using may send out a flush message (as explained in section 4.2), using
the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon the MAC List TLV as defined in Section 6, to all PE-rs nodes. Upon
receiving the message, PE-rs nodes flush the MAC addresses receiving the message, PE-rs nodes flush the MAC addresses
associated with that VPLS instance. associated with that 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 a single LSP tunnel between the VPLS "border" devices. A using a single LSP tunnel between the VPLS "border" devices. A
skipping to change at page 20, line 45 skipping to change at page 22, line 22
(Ethernet island) and not to the entire network. The SP network (Ethernet island) and not to the entire network. The SP network
consists of a core MPLS/IP network that connects many Ethernet consists of a core MPLS/IP network that connects many Ethernet
islands. Therefore, the number of VPLS instances can scale islands. Therefore, the number of VPLS instances can scale
accordingly with the number of Ethernet islands (a metro region can accordingly with the number of Ethernet islands (a metro region can
be represented by one or more islands). be represented by one or more 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 MSTP access network nodes and links can be provided through running STP
in each island. The MSTP of each island is independent from other in each island. The STP of each island is independent from other
islands and do not interact with each other. If an island has more islands and do not interact with each other. If an island has more
than one PE-rs, then a dedicated full-mesh of PWs is used among than one PE-rs, then a dedicated full-mesh of PWs is used among
these PE-rs devices for carrying the SP BPDU packets for that these PE-rs devices for carrying the SP BPDU packets for that
island. On a per P-VLAN basis, MSTP will designate a single PE-rs island. On a per P-VLAN basis, STP will designate a single PE-rs
to be used for carrying the traffic across the core. The loop-free to be used for carrying the traffic across the core. The loop-free
protection through the core is performed using split-horizon and protection through the core is performed using split-horizon and
the failure protection in the core is performed through standard the failure protection in the core is performed through standard
IP/MPLS re-routing. IP/MPLS re-routing.
12. Significant Modifications 12. Contributors
Between rev 06 and this one, these are the changes:
- Incorporated comments from technical review team
- Clarifications and edits
- Fixed id-nits
13. Contributors
Loa Andersson, TLA Loa Andersson, TLA
Ron Haberman, Alcatel Ron Haberman, Alcatel
Juha Heinanen, Independent Juha Heinanen, Independent
Giles Heron, Tellabs Giles Heron, Tellabs
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel
Luca Martini, Cisco Luca Martini, Cisco
Pascal Menezes, Independent Pascal Menezes, Independent
Rob Nath, Riverstone Rob Nath, Riverstone
Eric Puetz, SBC Eric Puetz, SBC
Vasile Radoaca, Nortel Vasile Radoaca, Nortel
Ali Sajassi, Cisco Ali Sajassi, Cisco
Yetik Serbest, SBC Yetik Serbest, SBC
Nick Slabakov, Riverstone Nick Slabakov, Riverstone
Andrew Smith, Consultant Andrew Smith, Consultant
Tom Soon, SBC Tom Soon, SBC
Nick Tingle, Alcatel Nick Tingle, Alcatel
14. 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, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt
Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov
Rekhter, and Sasha Vainshtein for their valuable feedback. Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable
feedback.
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu
(Ixia), and Charlie Hundall for identifying issues with the draft (Ixia), and Charlie Hundall for identifying issues with the draft
in the course of the interoperability tests. in 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.
15. 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 [VPN-SEC]. An unguarded VPLS service is
vulnerable to some security issues which pose risks to the customer vulnerable to some security issues which pose risks to the customer
and provider networks. Most of the security issues can be avoided and provider networks. Most of the security issues can be avoided
through implementation of appropriate guards. A couple of them can through implementation of appropriate guards. A couple of them can
be prevented through existing protocols. be prevented through existing protocols.
- Data plane aspects - Data plane aspects
- Traffic isolation between VPLS domains is guaranteed by - Traffic isolation between VPLS domains is guaranteed by
skipping to change at page 22, line 23 skipping to change at page 23, line 45
routers as CPE devices or by rate policing the amount of routers as CPE devices or by rate policing the amount of
broadcast traffic that customers can send broadcast traffic that customers can send
- Control plane aspects - Control plane aspects
- LDP security (authentication) methods as described in - LDP security (authentication) methods as described in
[RFC-3036] SHOULD be applied. This would prevent [RFC-3036] 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 - Some means to limit the number of MAC addresses (per site
per VPLS) that a PE can learn SHOULD be implemented per VPLS) that a PE can learn SHOULD be implemented
16. IANA Considerations 15. IANA Considerations
The type field in the MAC TLV is defined as 0x404 in section 4.2.1 The type field in the MAC List TLV is defined as 0x404 in section
and is subject to IANA approval. 6.2.1 and is subject to IANA approval.
17. References 16. References
17.1. Normative References 16.1. Normative References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
10.txt, Work in progress, June 2005. 10.txt, Work in progress, June 2005.
[PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf- [PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf-
pwe3-control-protocol-17.txt, Work in progress, June 2005. pwe3-control-protocol-17.txt, Work in progress, June 2005.
[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".
skipping to change at page 23, line 12 skipping to change at page 24, line 37
Standards for Local and Metropolitan Area Networks: Virtual Bridged Standards for Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", July 1998. Local Area Networks", July 1998.
[RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036, [RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036,
January 2001. January 2001.
[IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation
(PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt, (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt,
Work in progress, February 2005. Work in progress, February 2005.
17.2. Informative References 16.2. Informative References
[BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work [BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work
in Progress, October 2004. in Progress, October 2004.
[RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft- [RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft-
ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February
2005. 2005.
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", draft-ietf-l3vpn-bgpvpn-auto-06.txt, Work in Progress, based VPNs", draft-ietf-l3vpn-bgpvpn-auto-06.txt, Work in Progress,
skipping to change at page 23, line 40 skipping to change at page 25, line 12
Virtual Private Networks", draft-ietf-l2vpn-requirements-04.txt, Virtual Private Networks", draft-ietf-l2vpn-requirements-04.txt,
Work in Progress, October 2005. Work in Progress, October 2005.
[VPN-SEC] "Security Framework for Provider Provisioned Virtual [VPN-SEC] "Security Framework for Provider Provisioned Virtual
Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work
in Progress, November 2004. in Progress, November 2004.
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, [802.1ad] "IEEE standard for Provider Bridges", Work in Progress,
December 2002. December 2002.
18. Appendix: VPLS Signaling using the PWid FEC Element 17. Appendix: VPLS Signaling using the PWid FEC Element
This section is being retained because live deployments use this This section is being retained because live deployments use this
version of the signaling for VPLS. version of the signaling for VPLS.
The VPLS signaling information is carried in a Label Mapping The VPLS signaling information is carried in a Label Mapping
message sent in downstream unsolicited mode, which contains the message sent in downstream unsolicited mode, which contains the
following VC FEC TLV. following PWid FEC TLV.
VC, C, VC Info Length, Group ID, Interface parameters are as PW, C, PW Info Length, Group ID, Interface parameters are as
defined in [PWE3-CTRL]. defined in [PWE3-CTRL].
We use the Ethernet PW type to identify PWs that carry Ethernet
traffic for multipoint connectivity.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC TLV |C| PW Type |PW info Length | | PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID | | PWID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters | | Interface parameters |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet
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 [PWE3-CTRL] is a service Note that the VCID as specified in [PWE3-CTRL] is a service
identifier, identifying a service emulating a point-to-point identifier, identifying a service emulating a point-to-point
virtual circuit. In a VPLS, the VCID is a single service virtual circuit. In a VPLS, the VCID is a single service
identifier, so it has global significance across all PEs involved identifier, so it has global significance across all PEs involved
in the VPLS instance. in the VPLS instance.
19. Authors' Addresses 18. Authors' Addresses
Marc Lasserre Marc Lasserre
Riverstone Networks Riverstone Networks
Email: marc@riverstonenet.com Email: marc@riverstonenet.com
Vach Kompella Vach Kompella
Alcatel Alcatel
Email: vach.kompella@alcatel.com Email: vach.kompella@alcatel.com
IPR Disclosure Acknowledgement IPR Disclosure Acknowledgement
 End of changes. 83 change blocks. 
235 lines changed or deleted 283 lines changed or added

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