Internet DRAFT - draft-balus-l2vpn-vpls-802.1ah
draft-balus-l2vpn-vpls-802.1ah
L2VPN Working Group F. Balus
Internet Draft M. Bocci
Intended Status: Proposed Standard M. Aissaoui
Expires: January 2009 Alcatel-Lucent
John Hoffmans
KPN
Geraldine Calvignac
France Telecom
Raymond Zhang
British Telecom
Nabil Bitar
Verizon
Olen Stokes
Extreme Networks
July 14, 2008
VPLS Extensions for Provider Backbone Bridging
draft-balus-l2vpn-vpls-802.1ah-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2009.
Balus, et. al Expires January 14, 2009 [Page 1]
Internet-Draft VPLS Extensions for PBB July 2008
Abstract
IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider
Backbone Bridges (PBB) defines an architecture and bridge protocols
for interconnection of multiple Provider Bridge Networks (PBNs). PBB
was defined in IEEE as a connectionless technology based on
multipoint VLAN tunnels. MSTP is used as the core control plane for
loop avoidance and load balancing. As a result, the coverage of the
solution is limited by STP scale in the core of large service
provider networks.
Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without running (M)STP across the
backbone. As a result, VPLS has been deployed on a large scale in
service provider networks.
This draft discusses extensions to the VPLS model required to
incorporate desirable PBB components while maintaining the Service
Provider fit of the initial model.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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.
Balus, et al. Expires January 14, 2009 [Page 2]
Internet-Draft VPLS Extensions for PBB July 2008
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................5
3. PBB-VPLS Reference Model.......................................6
3.1. General Description.......................................6
3.2. I-VSI to B-VSI Mapping...................................10
4. Data Plane....................................................12
5. Control Plane.................................................15
5.1. Auto-Discovery...........................................15
5.2. Signaling................................................15
5.2.1. MAC Address Withdraw................................16
5.2.2. NSP Capabilities code points for PBB-VPLS...........18
6. PBB-VPLS Interworking with regular VPLS Instances.............18
7. Multicast Handling............................................20
8. Resiliency....................................................20
9. OAM...........................................................20
10. Security Considerations......................................20
11. IANA Considerations..........................................21
12. Acknowledgments..............................................21
13. References...................................................22
13.1. Normative References....................................22
13.2. Informative References..................................22
Author's Addresses...............................................23
Full Copyright Statement.........................................24
Intellectual Property Statement..................................24
Acknowledgment...................................................25
1. Introduction
The IEEE 802.1ah model for PBB is organized around a B-component
handling the provider backbone MAC layer and an I-component concerned
with the mapping of Customer/Provider Bridge (QinQ) domain (e.g.
MACs, VLANs) to the provider backbone (e.g. BMACs, B-VLANs): i.e. the
I-component contains the boundary between the Customer and Backbone
MAC domains. PBB encapsulates customer frames in a provider backbone
Ethernet header, providing for Customer MAC hiding capabilities.
PBB requires the use of Multiple Spanning Tree Protocol (MSTP) as the
core control plane (B-domain) for loop avoidance and load balancing.
As a result, the coverage of the solution is limited by STP scale in
the core of large service provider networks.
Balus, et al. Expires January 14, 2009 [Page 3]
Internet-Draft VPLS Extensions for PBB July 2008
Virtual Private LAN Service (VPLS) provides a solution for extending
Ethernet LAN services, using MPLS tunneling capabilities, through a
routed MPLS backbone without requiring the use of (M)STP across the
backbone. VPLS use of the structured FEC 129 [RFC4762] also allows
for inter-domain, inter-provider connectivity and enables auto-
discovery options across the network improving the service delivery
options.
VPLS creates an emulated LAN Segment using as building blocks a set
of Virtual Switch Instances (VSIs) interconnected using Virtual Links
- i.e. based on Pseudo Wires (PWs) or native Ethernet.
In a large scale deployment, there might be a need to split the
backbone domain into two or more domains using the Hierarchical-VPLS
(H-VPLS) model described in [RFC4762]. This may be required for
scalability, administrative reasons, or to provide efficient handling
of packet replication. In this context, VPLS scalability may be
improved by hiding the customer MAC addresses at the edge PEs so that
the core PEs (e.g. PE-rs) handle just the Provider MAC addresses.
This document proposes extensions to the VPLS model to allow for
selective inclusion of useful PBB capabilities while continuing to
avoid the use of MSTP in the backbone. The proposed solution
accommodates though the use of native Ethernet model, MSTP-based for
the PBBN [IEEE802.1ah] should a provider choose to deploy it.
Description of the framework and requirements for interoperability
between the IEEE and VPLS components is given in [PBB-VPLS-Interop].
Specific service provider requirements often define the boundaries of
PBB and VPLS domains within their networks. It is not in the scope of
this document to specify how far in the Metro Area Network (MAN) or
the Wide Area Network (WAN) PBB and VPLS boundaries extend. The PBB
VPLS may co-exist in the same PE with non PBB services (i.e., regular
VPWS or VPLS using MPLS PW where PBB Customer MAC hiding and
aggregation functions are not required).
Section 2 defines the terms used to describe the extensions to the
regular VPLS Model. Section 3 covers the reference model for PBB VPLS
and gives examples of its usage to address the use cases described in
[PBB-VPLS-Interop]. Section 4 describes the data plane while section
5 and 6 deal with the auto-discovery and signaling components,
including the required MAC Withdraw extension.
Balus, et al. Expires January 14, 2009 [Page 4]
Internet-Draft VPLS Extensions for PBB July 2008
2. Terminology
[IEEE802.1ah] provides terminology for Provider Backbone Bridging
that is briefly described also in [PBB-VPLS-Interop]. This document
employs specifically the following abbreviations from [IEEE802.1ah]:
CBP: Customer Backbone Port, the B-component port connecting to the
I-component.
PIP: Provider Instance Port, the I-component port connecting to the
B-component.
This document defines the following additional terms:
B-x: a VPLS component of the switching domain handling Backbone MACs
- e.g. B-FEC, B-PW
B-VPLS: a collection of VPLS components that operate in the Backbone
MAC domain, carrying one or multiple I-VPLS instances
B-VSI: A VPLS Service Instance (VSI) that participates in a B-VPLS
I-x: a VPLS component of the switching domain handling customer MACs
- e.g. I-FEC, I-PW
I-VPLS: a collection of VPLS components that participate in the
customer MAC layer - i.e. it uses the customer MAC addresses
(basically the destination address) to switch Ethernet frames
I-VSI: A VPLS Service Instance (VSI) that participates in an I-VPLS
PBB VPLS: an extended VPLS Service that includes PBB components
IB-PE: a PE that contains both I and B components
I-PE: a PE that contains just I component(s)
B-PE: a PE that contains just B component(s) and Customer Backbone
Ports (I-tagged CBPs - see [IEEE802.1ah])
BC-PE: Backbone Core PE, a PE that contains only B component(s) and
Provider Network Port(s) (PNPs - see [IEEE802.1ah])
Balus, et al. Expires January 14, 2009 [Page 5]
Internet-Draft VPLS Extensions for PBB July 2008
3. PBB-VPLS Reference Model
VPLS is defined in [RFC4762] as a collection of Virtual Switch
Instance(s) (VSIs) interconnected via Pseudo-Wires (PW).
The VPLS model described in [RFC4762] is able to accommodate
different types of PWs and Ethernet Attachment Circuits (AC) through
the use of VPLS (PW) Forwarders and a Native Service Processing (NSP)
module that performs AC adaptation and bridging function working with
the outer Ethernet MAC header. In the VPLS case the NSP module is
referred to as Virtual Switching Instance (VSI) [RFC4664].
PBB Service is defined in [IEEE802.1ah] as a collection of two
components: an I-component and a B-component operating on the
Customer and the Backbone MAC layer, respectively.
3.1. General Description
Porting both PBB functionalities to VPLS implies emulating the I and
B components in the VPLS NSP while maintaining the capability to
transport Ethernet frames over Pseudowires.
A PBB VPLS solution may be modeled as an "I-VSI" mapped to a "B-VSI"
operating on the Customer and the Backbone MAC layer, respectively,
as depicted in Figure 1.
Same as in [IEEE802.1ah], the I-VSI and its related B-VSI are
considered for modelling purposes as separate modules interconnected
through a internal or external link.
The I-VSI and its related B-VSI can be associated with the same type
of components as the regular VPLS VSI:
. A VPLS Forwarder identified by L2 FEC in the control plane and PW
service Label(s) in the data plane [RFC4762]
. A collection of Attachment Circuits identified using:
o B-VID and/or I-component Service ID (ISID) tag(s) and/or
port number for B-VSI [IEEE802.1ah]
o S-VID and/or C-VID tag(s) and/or port number for I-VSI
corresponding to different type of interfaces: QinQ,
802.1Q, port mode, same as for regular VPLS.
This representation of the PBB VPLS components is an abstract model
used in this document to help the solution description. It is up to
Balus, et al. Expires January 14, 2009 [Page 6]
Internet-Draft VPLS Extensions for PBB July 2008
the implementations to optimize the functions described in this
document as long as they provide for solution interoperability.
,,.--.,,
,-` `',
- '
' \ ------------
| PBB/VPLS | | Payload |
| transport | ------------
, / |CVID, SVID|
. / ------------
/., _./ | |CMAC DA,SA|
| /`''--''` | | ------------
| | | | |I-tag-ISID|
+-\-\--+ +--\-\-+ ------------
| B-PW | | B-PW | |BMAC DA,SA|
+-----| |----| |-----+ ------------
| +------+ +---.--+ | | PW SL |
| `. ,.., ` | ------------
| ' `-` | |PSN Header|
,.-., | ,.B-VSI | | ------------
,' `+-------+ ,-` . / |
/ | | .'` `/.` |
| Native | B-ETH | ` | IB-PE |
\ PBB | | ,- |
`. ,+-------+ / ` |
`'-'` | ' `. |
| ,' I-VSI . |
| --.--.-----' |
| .` | `. |
| +-----`+ +--\---+ +-'----+ |
| | | | | | | |
------------ +--| I-PW |-| I-ETH|-| I-Q |--+
| Payload | | | | | | |
------------ +--/---+ +--_---+ +------+
|CVID, SVID| / / \ `. `
------------ ,.-., / \ ,.'/,
|CMAC DA,SA| ,' `. - ' ,' `.
------------ / , CE CE / ,
| PW SL | | regular | | Q-in-Q |
------------ \ VPLS / \ `
|PSN Header| `. ,' `. ,'
------------ `'-'` `'-'`
Figure 1: "PBB VPLS" reference model, IB-PE Example
The PBB VPLS Model maintains the flexibility of associating both PWs
or native Ethernet ACs with I-VSI and B-VSI. In Figure 1 the
associated objects are referred to as I-PW/I-ETH and B-PW/B-ETH,
respectively. I-Q represents a QinQ interface [IEEE802.1ad], in fact
Balus, et al. Expires January 14, 2009 [Page 7]
Internet-Draft VPLS Extensions for PBB July 2008
an instantiation of an I-ETH AC used to connect to a QinQ access
network. The I-VPLS and B-VPLS clouds may contain either a VPLS mesh
or HVPLS topology as described in [RFC4762].
PBB Customer MAC hiding and aggregation functions are provided by
encapsulating the Customer MAC frame coming from a PW or AC
terminating into I-VSI into a Provider Backbone Ethernet Header.
Figure 1 describes the example of an Ethernet/PW packet coming on a
regular (I-)PW into the I-VSI. The I-VSI performs the mapping of
Customer MACs to Backbone MACs as the frame is delivered to the B-
VSI. The resulted PBB/PW encapsulation is described in the top right
side of Figure 1.
Same as for [IEEE802.1ah], two different use cases may be considered
based on the location of the I-VSI and its related B-VSI.
Case 1: Co-located I-VSI and B-VSI
Figure 1 describes the case of a PE that contains both I and B-VSIs.
IB-PE terminology is used as the PE performs a similar function with
a PBB IB-BEB - see [IEEE802.1ah]. The link between I-VSI and its
related B-VSI is internal to the PBB PE.
Case 2: Non co-located I-VSI and B-VSI
The I-VSI and its associated B-VSI may be also located in different
PE devices referred to as I-PE and B-PE, respectively, as depicted in
Figure 2.
Balus, et al. Expires January 14, 2009 [Page 8]
Internet-Draft VPLS Extensions for PBB July 2008
,,.--.,,
,-` `',
- '
' \
| MPLS |
| (B-VPLS) |
, /
. /
/., _./ |
| /`''--''` | |
| | | |
+-\-\--+ +--\-\-+
| B-PW | | B-PW |
+-----|(PNP) |----|(PNP) |-----+
| +------+ +---.--+ |
| `. ,..,. ` |
| ' ` |
| ,| B-VSI | |
,'`'-'``+-------+ ,-` \ / |
| PBBN | B-ETH |''''' '.-.' B-PE |
`. ,+-------+ | |
`'-'` | | |
+------------------------------+
|CBP
|
|
|PIP
+------------------------------+
| | |
| ,-. |
| / \ |
| /I-VSI\ I-PE |
| --------' |
| .` | `. |
| +-----`+ +--\---+ +-'----+ |
+--| I-PW |-| I-ETH|-| I-Q |--+
+--/---+ +--_---+ +------+
/ / \ \
,.-., / \ \,..,
,' `. - ' ,' `.
/ , CE CE . ,
| I-VPLS | Q-in-Q .
\ ` . `
`. ,' `. ,'
`'-'` `'-'`
Figure 2: "PBB VPLS" reference model, I-PE, B-PE Example
Balus, et al. Expires January 14, 2009 [Page 9]
Internet-Draft VPLS Extensions for PBB July 2008
In this case, the connection between I-PE and B-PE will be an
external link, where the PBB Service ID (ISID) is still used to
determine which particular I-VSI FIB should be used to determine the
destination for a frame ingressing the PIP port on the I-PE.
3.2. I-VSI to B-VSI Mapping
The I-VSI(s) may be mapped to the B-VSIs using an 1:1 model or many-
to-1 (M:1) model.
. The 1:1 model, see Figure 1 and 2, may be chosen by a service
provider who is content with the level of service multiplexing
provided by the B-PWs.
. The M:1 model may be used in order to provide an additional layer
of aggregation where multiple customer services are transported
through a backbone VPLS.
Figure 3 shows the M:1 reference model applied to one of the most
common HVPLS scenario.
Balus, et al. Expires January 14, 2009 [Page 10]
Internet-Draft VPLS Extensions for PBB July 2008
_,,..--..,,,
,-'` `'-,
.` `'
,' `.
/ IP MPLS Core ,
| (VPLS Mesh) |
\ `
`. `
', _-`
+------`-,, _,-`-------+
| ,-, | ``'''--'''`` | ,-, |
N-PE3 | | B | | | | B | | N-PE4
| | | | BC-PEs | | | |
| `'' | | `'' |
+-,--,,-+ +--,--,,+
,' \ ,' \
/ \ / \
| MPLS | | MPLS |
| Access | | Access |
| B-PWs | | B-PWs |
\ / \ /
`. / `. /
+------`-,,+-------+ +-------+'-'+-------+
| ,-, | | ,-, | | ,-, | | ,-, |
| | B | | | | B | | | | B | | | | B | |
| | | | | | | |IB-PEs | | | | | | | |
| `'' | | `'' | | `'' | | `'' |
| I1 I2 | | I1 I3 | | I1 I2 | | I1 I3 |
+-------+ +-------+ +-------+ +-------+
U-PE1 U-PE2 U-PE6 U-PE5
Figure 3 PBB VPLS model for HVPLS with MPLS Access
The PBB VPLS is enabled in the U-PEs to hide the customer MACs from
the N-PEs. The U-PEs are IB-PEs where multiple I-VSIs are mapped to
one B-VSI. The N-PEs may be seen as playing the role of Backbone Core
Bridges (BCB - see [IEEE802.1ah]) hence the name of Backbone Core PE
(BC-PE). The B-VSI components on the U-PEs are connected to the B-
VSIs/Regular VSIs on the N-PEs using regular Ethernet PWs (B-PWs in
the diagram).
In the (M:1) model, there are use cases where the I-VPLS domains that
share the same B-VPLS overlap but in most practical scenarios that is
not the case. A broadcast and flood containment solution may be
provided using [IEEE802.1ak].
Balus, et al. Expires January 14, 2009 [Page 11]
Internet-Draft VPLS Extensions for PBB July 2008
The reference model described in this section can be used to address
the other scenarios described in [PBB-VPLS-Interop], where an IB-PE
structure may be used wherever an IB-BEB function is required, an I-
PE for I-BEB and a B-PE for a B-BEB.
4. Data Plane
The PW processing function for each I-VSI and B-VSI follows the VPLS
model described in [RFC4762]. This section will focus on the new PBB-
VPLS NSP functions, specifically on the interaction between the I-VSI
and B-VSI Modules.
Figure 5 represents a collection of I-VSI and B-VSI components that
represent the required NSP function for full PBB-VPLS processing in
an IB-PE. In order to describe the packet walkthrough, the I-VSI and
B-VSI should be seen as different switching modules (I and B). Each
of them may have its own set of PWs, Bridge modules and ACs.
------------
| Payload |
| | | | ------> ------------
+-\-\--+ +--\-\-+ |SVID, CVID|
+-----| B-PW |----| B-PW |-----+ ------------
| +------+ +---.--+ | |CMAC DA,SA|
| `. ,.., ` | ------------
| ' `-` | |PBB I-tag |
| ,|B-VSI | | ------------
+-------+ ,-` '.,,.' | |BMAC DA,SA|
--| B-ETH | `''' | | ------------
+-------+ | | | PW SL |
| | | ------------
+-------------------------------+ |PSN Header|
|CBP ------------
|
|PIP ------------
+------------------------------+ | Payload |
| | | ------------
| ,- | |SVID, CVID|
| / ` | ------------
| ' `. | |CMAC DA,SA|
| ,' I-VSI . | ------------
| --.--.-----' | | PW SL |
| .` | `. -------> -----------
| +-----`+ +--\---+ +-'----+ | |PSN Header|
+--| I-Q |-| I-ETH|-| I-PW |--+ ------------
+------+ +------+ +------+
Figure 4 Packet Walkthrough for PBB VPLS
Balus, et al. Expires January 14, 2009 [Page 12]
Internet-Draft VPLS Extensions for PBB July 2008
In order to better understand the data plane walkthrough let us
consider the example of a PBB packet arriving on a B-PW link. The PSN
header is used to carry the PBB encapsulated frame over the backbone
while the B-PW Service Label is used to determine the B-VSI FIB, same
as for regular VPLS. An example of the PBB packet for regular
Ethernet PW type is depicted in Figure 5 next to the B-VSI. Before
handling the packet to the B-VSI the PW and PSN encapsulation are
removed. The destination BMAC address of the packet is then mapped
against the B-VSI FIB to determine the Next Hop (NH) with the
following possible results:
-NH = B-ETH AC: PW encapsulation is removed but the PBB
encapsulation is left untouched. The packet is sent out on the
B-ETH AC. Regular AC processing rules apply - e.g. a B-VID may
be added to the backbone header.
-NH = another B-PW: ingress PW Encapsulation is removed and egress
PW encapsulation is added. The packet is sent out on the B-PW
(Split Horizon rules apply).
-NH = local I-VSI (CBP "port"): PW Encapsulation is removed and the
packet is passed to the I-VSI module for processing. Translation
of the PBB header (e.g. ISID rewrite) may be performed.
-NH = unknown or the destination BMAC is a Group MAC address
(Multicast or Broadcast): the packet is flooded to all the
virtual ports that are part of the B-VSI (e.g. B-PWs, ACs/B-ETH
or internal "link" towards local I-VSI).
For the packets that arrive at the I-VSI module from one of the local
B-VSI (ingressing the PIP "Link") the ISID demultiplexor is used to
determine the specific I-VSI FIB to which the packet belongs. The PBB
header is then removed and the destination Customer MAC (CMAC)
address is used to determine the Next Hop for the packet with the
following possible results:
-NH = I-ETH/I-Q (Ethernet port/Q-taged/QinQ AC): the Customer Frame
is sent out on the I-ETH. Regular AC processing rules apply -
e.g. a C-VID and/or a S-VID may be added to the packet.
-NH = I-PW: the frame containing just the Customer MAC and S-VID
and/or C-VID tags is encapsulated in the PW header before being
sent out on the I-PW. The S-VID and/or C-VID may or may not be
included in the actual encapsulated packet as per regular PW
processing rules. The resulted encapsulation is depicted next to
the I-VSI in Figure 5.
Balus, et al. Expires January 14, 2009 [Page 13]
Internet-Draft VPLS Extensions for PBB July 2008
For a packet ingressing the I-VSI via an I-PW (e.g. via MPLS access),
the I-PW Service Label is used this time to determine the FIB to
which the packet belongs. The PSN and I-PW headers are removed by the
ingress PW function and the packet is handled to the I-VSI. Next the
destination CMAC address of the packet is then mapped against the I-
VSI FIB to determine the Next Hop (NH) with the following possible
results:
-NH = I-ETH/I-Q: the packet is sent out on the corresponding I-ETH
AC. Regular AC processing rules apply - e.g. an S-VID and/or C-
VID tag may be added to the packet. There is no need to add PBB
encapsulation to the packet.
-NH = another I-PW: ingress PW Encapsulation is removed and egress
PW encapsulation is added. The packet is sent out on the I-PW
(Split Horizon rules apply).
-NH = local B-VSI (over the PIP "port"): the PBB header (BMACs and
the corresponding I-TAG) is added and the packet is passed to
the B-VSI module for further processing. This is the case when
the destination CMAC is located behind a remote PBB PE
identified by a destination BMAC.
-NH = unknown or the destination CMAC is a Group MAC (Multicast or
Broadcast): the packet is flooded to all the virtual ports that
are part of the I-VSI, including the local B-VSI context.
For the packets that arrive at the B-VSI module from an I-VSI, the
ISID is used to determine the specific B-VSI FIB to be used to which
the packet belongs. Translation of the PBB header (e.g. ISID) may be
performed. Next the destination BMAC is used to determine the Next Hop
for the packet with the following possible results:
- NH = B-ETH: the PBB Frame is sent out on the B-ETH. Regular AC
processing rules apply - e.g. a B-VID is added to the packet.
- NH = B-PW: the PBB frame is encapsulated in the PW header before
being sent out on the B-PW. The resulted PBB/PW encapsulation is
depicted in Figure 5 next to the B-VSI.
It is important to highlight in this context that the core PEs (N-PE3
and N-PE4 in Figure 3) do not have to be aware about the PBB
encapsulation. Just the regular Backbone Ethernet header (i.e. BMAC
DA) is used to forward the Ethernet frames. Existing VPLS and PWE3
procedures, including Multi-Segment PWs (MS-PW) apply for the PW
infrastructure between them. Regular Ethernet PW types (Ethernet and
Ethernet VLAN) may be also used to signal the B-PWs (Backbone PWs)
Balus, et al. Expires January 14, 2009 [Page 14]
Internet-Draft VPLS Extensions for PBB July 2008
interconnecting the B-VSIs in the U-PEs and N-PEs or the I-VSIs in
the U-PE with other I-VSIs.
5. Control Plane
PBB introduces a hierarchy where a Customer (CMAC) domain is
separated from the Service Provider (BMAC) domain from both data
plane (e.g. CMAC versus respectively BMAC switching) and control
plane (e.g. xSTP, 802.1ak MRP) perspective. For example a CMAC should
never be learned in the Backbone context/FIB.
When porting the PBB hierarchy in PBB VPLS, the strict separation
between the two domains must be maintained in both the VPLS data and
control plane. In VPLS the control plane controls the setup of the
data plane so it is possible to achieve this separation by proper
separation of addressing and control plane procedures. Specifically
in the example from Figure 1 the I-VPLS control plane must stay
separate from the related B-VPLS control plane. This will ensure that
control plane procedures (e.g. VPLS MAC Flush, OAM) destined for one
domain will not leak into the other domain. Also PWs in one domain
will not try to connect to the other domain: e.g. I-PW, destined for
an I-VPLS will not try to connect to a B-VPLS instance.
The simplest way to achieve this kind of separation is to assign for
I-VPLS and B-VPLS separate addressing schemes. The following sections
describe how this applies for BGP auto-discovery or for T-LDP
signaling. Optionally usage of NSP capabilities sub-TLV [GE-PW] can
guarantee additional protection against operational mistakes.
5.1. Auto-Discovery
When BGP Auto-discovery is used address separation can be achieved by
assigning for each I-VPLS and B-VPLS domains a separate set of
identifiers and attributes: i.e. VPLS-Id, VSI-Id (RD, Prefix), RT(s)
as described in [L2VPN-Sig]). Separate addressing schemes will be
automatically generated for LDP signaling as per [L2VPN-Sig].
5.2. Signaling
When BGP-Auto-discovery is not used separate L2 FEC addressing
structures [L2VPN-Sig] must be configured to identify each B-VPLS
and/or I-VPLS domain accordingly.The setup of the PWs between B-VSIs
(B-PWs) and/or between the I-VSIs (I-PWs) may be achieved using the
existing PWE3 procedures - see [RFC4762]. This allows porting the
existing control plane procedures (PW setup, VPLS MAC Flush,OAM) for
each the two domains.
Balus, et al. Expires January 14, 2009 [Page 15]
Internet-Draft VPLS Extensions for PBB July 2008
5.2.1. MAC Address Withdraw
The use of Address Withdraw message with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result
of a topology change (e.g. failure of a primary link of a VPLS PE and
implicitly the activation of an alternate link in a dual-homing use
case). These existing procedures apply to B-VPLS and I-VPLS domains.
When it comes to reflecting topology changes in access networks
connected to I-VSI across the B-VPLS domain certain additions should
be considered as described below.
MAC Switching in PBB is based on the mapping of Customer MACs (CMACs)
to Backbone MAC(s) (BMACs). A topology change in the access (I-
domain) should just invoke the flushing of CMAC entries in PBB PEs'
FIB(s) associated with the I-VPLS(s) impacted by the failure. There
is a need to indicate the PBB PE (BMAC source) that originated the
MAC Flush message.
These goals can be achieved by adding a PBB TLV in the Address
Withdraw message to indicate the particular domain(s) requiring MAC
flush. At the other end, the receiving PBB PEs may use the
information from the PBB TLV to flush only the related FIB
entry/entries in the I-VSI(s).
A suggested PBB TLV structure is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| PBB TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Sub-TLV Length | Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Balus, et al. Expires January 14, 2009 [Page 16]
Internet-Draft VPLS Extensions for PBB July 2008
The UF bits are set to forward unknown so that the intermediate VPLS
PEs that are unaware of PBB can just forward the TLV towards the PBB
aware IB-PEs. The PBB TLV type values are to be assigned by IANA. The
Length field is used to define the length of the PBB TLV including
the type and the length itself. Processing of the sub-TLVs should
continue when unknown ones are encountered, and they MUST be silently
ignored.
The following sub-TLVs MUST be included in the PBB TLV:
- PBB BMAC List sub-TLV:
Type: 0x0001
Length: value length in octets. At least one BMAC address must be
present in the list. .
Value: one or a list of 48 bits (B-)MAC address(es). These are the
source BMAC addresses associated with the B-VSI(s) that originated
the MAC Withdraw message. The CMAC(s) mapped to the BMACs listed
in the sub-TLV should not be flushed ("Flush all but the CMACs
associated with the BMAC(s) in the list").
- PBB ISID List sub-TLV:
Type: 0x0002
Length: value length in octets. Zero indicates an empty ISID list.
An empty ISID list means that the flush applies to all the ISIDs
mapped to the B-VPLS indicated by the FEC TLV.
Value: one or a list of 24 bits ISIDs that represent the I-VSI
FIB(s) where the MAC Flush needs to take place.
The following steps describe the details of the processing for the
related LDP Address Withdraw message:
. The LDP MAC Withdraw Message, including the PBB TLV is initiated
by the PBB PE(s) experiencing a Topology Change event.
. On reception of the LDP message, the B-VSI instances related to
the FEC TLV from the LDP Address Withdraw message must interpret
the presence of the PBB TLV as an indication of a PBB Flush
message. As a result they should not flush their BMAC FIBs.
. Next the B-VPLS control plane must propagate the MAC Flush
indication following the split-horizon grouping and the
established B-PW topology.
Balus, et al. Expires January 14, 2009 [Page 17]
Internet-Draft VPLS Extensions for PBB July 2008
. The receiving IB-PE uses the PBB ISID List from the PBB TLV to
determine the particular ISID FIBs that need to be flushed. If the
ISID List is empty all the ISID FIBs associated with the receiving
B-VSI are flushed. The PBB BMAC List from the PBB TLV is used to
flush from the ISID FIBs just the entries that map CMACs to the
BMACs that are not listed in the sub-TLV.
5.2.2. NSP Capabilities code points for PBB-VPLS
The optional NSP capabilities sub-TLV described in [GE-PW] may be
used to provide additional protection against operational mistakes or
to detect the type of capabilities supported by the remote NSP.
The following NSP capabilities code points are required for PBB-VPLS:
-003 B-VSI
-004 I-VSI
-005 PBB MAC Flush
The above code points are included in the NSP capabilities sub-TLV to
indicate the supported features and to ensure the right type of NSPs
or NSP features are connected via Ethernet PW following the
procedures described in [GE-PW].
6. PBB-VPLS Interworking with regular VPLS Instances
The PBB VPLS model described in this document may interoperate with
regular VPLS PEs on the I-VSI and/or B-VSI side(s) as long as no PBB
functions or optimizations are required on these PEs.
Balus, et al. Expires January 14, 2009 [Page 18]
Internet-Draft VPLS Extensions for PBB July 2008
_,,..--..,,,
,-'` `'-,
.` `'
,' `.
/ IP MPLS Core ,
| (VPLS Mesh) |
\ `
`. `
', _-`
+------`-,, _,-`-------+
| ,-, | ``'''--'''`` | ,-, |
N-PE3 | | V | | | | B | | N-PE4
| | | | BC-PEs | | | |
| `'' | | `'' |
+-,--,,-+ +--,--,,+
,' \ ,' \
/ \ / \
| MPLS | | MPLS |
| Access | | Access |
| B-PWs | | B-PWs |
\ / \ /
`. / `. /
+------`-,,+-------+ +-------+'-'-
| ,-, | | ,-, | | ,-, |
| | B | | | | B | | | | B | |
| | | | | | | |IB-PEs | | | |
| `'' | | `'' | | `'' |
| I1 I2 | | I1 I3 | | I1 I2-|-------|
+-------+ +-------+ +-------+ |
U-PE1 U-PE2 U-PE5 PE6|
+---|---+
| ,-, |
| | V'| |
| `'' |
+-------+
Figure 5 Interworking to regular VPLS
Some of the interworking scenarios are depicted in Figure 4 where:
. N-PE3 is running a regular VPLS VSI marked with V which operates
only on the Backbone MAC header, switching performed by the PBB
BCBs. No PBB awareness (e.g. I-component functions) is required
on this PE which connects to the B-VSIs in U-PE1, U-PE2 and N-
PE4. In both cases a HVPLS spoke or a VPLS Mesh may be used.
. PE6 is running a regular VPLS VSI marked with V' which operates
only on the Customer MAC header. No PBB awareness (B-component
Balus, et al. Expires January 14, 2009 [Page 19]
Internet-Draft VPLS Extensions for PBB July 2008
functions, linkage) is required on PE5 which connects to the I-
VSI on U-PE5 via an HVPLS spoke PW or a VPLS mesh.
7. Multicast Handling
PBB MAC hiding may create difficulties for identifying customer
Multicast exchanges in the B-VSIs. It is important to be able to
support both regular and PBB VPLSes. That way the customer VPNs
requiring large volume of Multicast may be addressed using regular
VPLS, allowing for easy multicast snooping throughout the VPLS
infrastructure.
Alternatively, the IEEE 802.1ak MMRP protocol defined in
[IEEE802.1ak] may be used to allow for efficient Multicast handling
in the B-VPLS infrastructure: i.e. Group BMAC addresses may be
assigned per Customer Multicast tree to ensure efficient Multicast
distribution.
8. Resiliency
[IEEE802.1ah] recommends the use of Provider MSTP (P-MSTP) to ensure
loop free topology for connectionless forwarding throughout PBBN.
Using B-VPLS infrastructure instead of native Ethernet core
eliminates the need for backbone P-MSTP through the use of a full
mesh of PWs with split-horizon and/or via the H-VPLS scheme
(Primary/Standby PWs) - see [RFC4762].
On the access side, for a PB network or a CE device dually connected
to PBB PEs, a loop spanning both I and B domains may occur. An STP-
based or a local mechanism may be used to break this loop.
A solution that does not imply running MSTP end-to-end should involve
the MAC Withdraw scheme described in the signaling section to speed-
up data plane convergence upon topology changes.
9. OAM
Existing VPLS OAM tools may be used in each I-VPLS and B-VPLS domain.
Details of the correlation between these two domains are out of scope
of this draft.
10. Security Considerations
This section will be added in a future version.
Balus, et al. Expires January 14, 2009 [Page 20]
Internet-Draft VPLS Extensions for PBB July 2008
11. IANA Considerations
This document proposes the use of a new LDP TLV, the PBB TLV and
related sub-TLVs. Suggested values TBD.
12. Acknowledgments
The authors gratefully acknowledge the contributions of Wim
Henderickx, Dimitri Papadimitriou, Dutta Pranjal, Jorge Rabadan and
Maarten Vissers.
Balus, et al. Expires January 14, 2009 [Page 21]
Internet-Draft VPLS Extensions for PBB July 2008
13. References
13.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and
Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt,
May 2006 ( work in progress )
[IEEE802.1ah] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area
Networks, Amendment 6: Provider Backbone Bridges", Work in
Progress, March 26, 2008
[GE-PW] V. Kompella and F. Balus "Generic Ethernet Pseudowire",
draft-vkompella-pwe3-ethernet-pw-bis-00.txt, July 2008 (
work in progress ).
13.2. Informative References
[PBB-VPLS-Interop] A. Sajassi, et Al. "VPLS Interoperability with
Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-
interop-03.txt, November 2007 ( work in progress ).
[RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, September
2006.
[IEEE802.1ak] IEEE Draft P802.1ak/D8.0 "Virtual Bridged Local Area
Networks, Amendment 7: Multiple Registration Protocol",
Work in Progress, November 29, 2006
[IEEE802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area
Networks, Amendment 4: Provider Bridges", December 7, 2005
Balus, et al. Expires January 14, 2009 [Page 22]
Internet-Draft VPLS Extensions for PBB July 2008
Author's Addresses
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-Lucent
600 March Road
Kanata, ON
Canada
e-mail: mustapha.aissaoui@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel-lucent.co.uk
Geraldine Calvignac
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange-ftgroup.com
John Hoffmans
KPN
Regulusweg 1
2516 AC Den Haag
Nederland
Email: john.hoffmans@kpn.com
Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 900245 USA
EMail: raymond.zhang@bt.com
Balus, et al. Expires January 14, 2009 [Page 23]
Internet-Draft VPLS Extensions for PBB July 2008
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
Email: ostokes@extremenetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
Balus, et al. Expires January 14, 2009 [Page 24]
Internet-Draft VPLS Extensions for PBB July 2008
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Balus, et al. Expires January 14, 2009 [Page 25]
