Internet-Draft Ali Sajassi
L2VPN Working Group Samer Salam
Intended status: Standards Cisco
Nabil Bitar
Verizon
Dinesh Mohan
Nortel
Expires: January 2009 July 2008
Provider Backbone Bridges in H-VPLS with MPLS Access
draft-sajassi-l2vpn-pbb-vpls-mpls-access-00.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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in May 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Sajassi, et. al. Expires: January 2009 [Page 1]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
Abstract
Provider Backbone Bridge (PBB) functionality, under standardization
in IEEE 802.1ah, can be employed to enhance the scalability of H-
VPLS with MPLS access. This document describes how PBB technology
can be used in H-VPLS with MPLS access networks to improve the
scalability of customer MAC addresses and number of service
instances that can be supported. The document also describes the
migration mechanisms and scenarios by which PBB functionality can be
incorporated into H-VPLS with existing MPLS access.
Conventions used in this document
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.
Table of Contents
Status of this Memo................................................1
Conventions used in this document..................................2
1. Introduction.........................Error! Bookmark not defined.
2. Terminology..........................Error! Bookmark not defined.
3. H-VPLS with MPLS Access..............Error! Bookmark not defined.
3.1 H-VPLS with MPLS Access: PBB U-PE..............................5
3.1.1 PBB U-PEs in Single I-SID Domain.............................7
3.1.2 PBB U-PEs in Multiple I-SID Domains..........................8
3.2 H-VPLS with MPLS Access: PBB N-PE..............................8
3.2.1 PBB N-PEs in Single I-SID Domain.............................9
3.2.2 PBB N-PEs in Multiple I-SID Domains..........................9
4. Migration Scenarios..................Error! Bookmark not defined.
4.1 802.1ad Service Frames over VPLS Core....................10
4.2 PBB Service Frames over VPLS Core........................11
4.3 Mixed 802.1ad and PBB over VPLS Core.....................12
6. IANA Considerations............................................13
7. Security Considerations..............Error! Bookmark not defined.
8. References...........................Error! Bookmark not defined.
8.1 Normative References..........................................13
8.2 Informative References........................................14
Appendix A: Provider Backbone Bridges - Primer....................14
A.1 S-Tagged Service Interface....................................16
A.2 I-Tagged Service Interface....................................16
A.3 B-Tagged Service Interface....................................17
Authors' Addresses................................................17
Full Copyright Statement..........................................17
Intellectual Property.............................................18
Sajassi, et. al. Expires: January 2009 [Page 2]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
1.
Introduction
The scalability of H-VPLS (with either MPLS or Ethernet access
network) can be improved by incorporating Provider Backbone Bridge
(PBB) functionality in the VPLS access. PBB is under standardization
as IEEE 802.1ah, which is an amendment to IEEE 802.1Q to address
large-scale Ethernet provider network requirements.
[VPLS-PBB] explores the interoperability of PBB with H-VPLS in the
case of native Ethernet access network. Whereas, this document
focuses on PBB interoperability with H-VPLS in the case of MPLS
access network. It describes how IEEE 802.1ah functionality can be
used in the H-VPLS MPLS access network to attain better scalability
in terms of number of customer MAC addresses and number of service
instances that can be supported. The document also describes the
migration mechanisms and scenarios by which PBB functionality can be
incorporated into H-VPLS with existing MPLS access.
[RFC4762] describes a two-tier hierarchical solution for VPLS for
the purpose of improved Pseudo Wire (PW) scalability. This
improvement is achieved by reducing the number of PE devices
connected in a full-mesh topology through connecting CE devices via
the lower-tier access network which in turn is connected to the top-
tier core network. [RFC4762] describes two types of H-VPLS network
topologies - one with MPLS access network and another with IEEE
802.1ad (QinQ) Ethernet access network. In both types of H-VPLS, MAC
address learning and forwarding are done based on customer MAC
addresses (C-MACs) which poses scalability issues as the number of
VPLS instances (and thus customer MAC addresses) increases.
Furthermore, since a set of PWs is maintained on a per customer
service instance, the number of PWs that need to be maintained at N-
PE devices is proportional to the number of customer service
instances multiplied by the number of N-PE devices in the full-mesh
set. This can result in scalability issues (in terms of PWs
manageability and troubleshooting) as the number of customer service
instances grows.
This document describes how IEEE 802.1ah (aka Provider Backbone
Bridges) can be integrated with H-VPLS with MPLS access to address
these scalability issues. PBB functionality can be used at the U-PE
or N-PE which results in reduction of customer MAC addresses and
number of PWs in the VPLS core network. This document also explores
the scenarios by which an operator can gradually migrate an existing
H-VPLS network to PBB over VPLS.
Section 2 gives a quick terminology reference. Section 3 describes
the use of PBB functionality in H-VPLS with MPLS access including
PBB on U-PE and PBB on N-PE variants. Section 4 describes gradual
migration scenarios from existing H-VPLS to PBB over H-VPLS.
Appendix A provides a brief primer on PBB technology, for the
reader's quick reference.
Sajassi, et. al. Expires: January 2009 [Page 3]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
2.
Terminology
802.1ad: IEEE specification for "QinQ" encapsulation and bridging of
Ethernet frames
802.1ah: IEEE specification for "MAC tunneling" encapsulation and
bridging of frames across a provider backbone bridged network.
B-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains a B-component that supports
bridging in the provider backbone based on B-MAC and B-TAG
information
B-MAC: The backbone source or destination MAC address fields defined
in the 802.1ah provider MAC encapsulation header.
BCB: A backbone core bridge running in the core of a provider
backbone bridged network. It bridges frames based on B-TAG
information just as an 802.1ad provider bridge will bridge frames
based on a VLAN identifier (S-VLAN)
BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It can contain an I-component, B-component
or both I and B components.
B-TAG: field defined in the 802.1ah provider MAC encapsulation
header that conveys the backbone VLAN identifier information. The
format of the B-TAG field is the same as that of an 802.1ad S-TAG
field.
B-Tagged Service Interface: This is the interface between a BEB and
BCB in a provider backbone bridged network. Frames passed through
this interface contain a B-TAG field.
B-VID: The specific VLAN identifier carried inside a B-TAG
I-component: A bridging component contained in a backbone edge
bridge that bridges in the customer space (customer MAC addresses,
S-VLAN)
IB-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging in
the customer space (customer MAC addresses, service VLAN IDs) and a
B-component for bridging the provider's backbone space (B-MAC, B-
TAG).
I-BEB: A backbone edge bridged positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging in
the customer space (customer MAC addresses, service VLAN IDs).
Sajassi, et. al. Expires: January 2009 [Page 4]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
I-SID: The 24-bit service instance field carried inside the I-TAG.
I-SID defines the service instance that the frame should be "mapped
to".
I-SID Domain: A network administrative boundary under which all the
PBB BEBs and VPLS PE devices use the same I-SID space, i.e. the I-
SID assignment is carried out by the same administration. This
effectively means that a given service instance has the same I-SID
designation on all devices within an I-SID Domain.
I-TAG: A field defined in the 802.1ah provider MAC encapsulation
header that conveys the service instance information (I-SID)
associated with the frame.
I-Tagged Service Interface: This the interface defined between the I
and B components inside an IB-BEB or between two B-BEB. Frames
passed through this interface contain an I-TAG field
PBB: Provider Backbone Bridge
PBBN: Provider Backbone Bridged Network
S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
conveys the service VLAN identifier information (S-VLAN).
S-Tagged Service Interface: This the interface defined between the
customer (CE) and the I-BEB or IB-BEB components. Frames passed
through this interface contain an S-TAG field.
S-VLAN: The specific service VLAN identifier carried inside an S-TAG
3.
H-VPLS with MPLS Access
In this section, the case of H-VPLS with MPLS access network is
discussed. The integration of PBB functionality into VPLS-PE for
such access networks is described to improve the scalability of the
network in terms of the number of MAC addresses and service
instances that are supported.
For this topology, it is possible to embed PBB functionality in
either the U-PE or the N-PE. Both of these cases are described in
the following sub-sections.
3.1 H-VPLS with MPLS Access: PBB U-PE
As stated earlier, the objective for incorporating PBB function at
the U-PE is to improve the scalability of H-VPLS networks in terms
of the number of MAC addresses and service instances that are
supported.
Sajassi, et. al. Expires: January 2009 [Page 5]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
In current H-VPLS, the N-PE must learn customer MAC addresses (C-
MACs) of all VPLS instances that it participates in. This can easily
add-up to hundreds of thousands or even millions of C-MACs at the N-
PE. When the U-PE performs PBB encapsulation, the N-PE only needs to
learn the MAC addresses of the U-PEs, which is a significant
reduction. Furthermore, when PBB encapsulation is used, many I-SIDs
are multiplexed within a single bridge domain (e.g., B-VLAN). If the
VPLS instance is set up per B-VLAN, then one can also achieve a
significant reduction in the number of full-mesh PWs. It should be
noted that this reduction in full-mesh PWs comes at the cost of
potentially increased replication over the full-mesh of PWs: A given
customer multicast and/or broadcast frames are effectively
broadcasted within the B-VLAN. This may result in additional frame
replication because the full-mesh PWs corresponding to a B-VLAN is
most likely bigger than the full-mesh PWs corresponding to a single
I-SID. However, multicast pruning as described in [PBB-VPLS-MCAST]
can be used to remedy this drawback and have multicast traffic
replicated efficiently for each customer (i.e. for each I-SID).
Figure 1 below illustrates the scenario for H-VPLS with MPLS access.
As it can be seen, customer networks or hosts (CE) connect into the
U-PE nodes using standard Ethernet interfaces [802.1D], [802.1Q], or
[802.1ad]. The U-PE is connected upstream to one or more VPLS N-PE
nodes by MPLS PWs (per VPLS instance). These, in turn, are connected
via a full-mesh of PWs (per VPLS instance) traversing the IP/MPLS
core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB)
functions where it can encapsulate/de-encapsulate customer MAC
frames in provider B-MAC addresses and perform I-SID translation if
needed.
PBB PBB
BEB +----------+ BEB
| | | |
| +-----------+ | IP | +-----------+ |
| | MPLS | | MPLS | | MPLS | |
V | Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| | | | | |
+-----------+ +----------+ +-----------+
Figure 1: H-VPLS with MPLS Access Network and PBB U-PE
The U-PE still provides the same type of services toward its
customers as before and they are:
Sajassi, et. al. Expires: January 2009 [Page 6]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
- Port mode (either 802.1D, 802.1Q, or 802.1ad)
- VLAN mode (either 802.1Q or 802.1ad)
- VLAN-bundling mode (either 802.1Q or 802.1ad)
By incorporating PBB function, the U-PE maps each of these services
(for a given customer) onto a single I-SID based on the
configuration at the U-PE. Many I-SIDs are multiplexed within a
single bridge domain (e.g. B-VLAN). The U-PE can, then, either map a
single I-SID into a VPLS instance or it can map a bridge-domain onto
a VPLS instance, according to its configuration. Next, the
encapsulated frames are sent over the PW associated with that VPLS
instance.
If the bridge domain is mapped to a VPLS instance, then a B-VID can
be used as the service delimiter and the entire Ethernet bridging
operation over VPLS network is performed as defined in [RFC4762]. In
other words, MAC forwarding is based on the B-MAC address space and
service delimiter is based on VLAN ID, which is B-VID in this case.
There is no need to inspect or deal with I-SID values.
If the I-SID is used as the service delimiter, then the single and
multiple I-SID Domain cases must be considered as described in the
following sections.
In summary, the ingress U-PE receives a customer MAC frame. It
applies the appropriate PBB header and then performs standard
bridge-capable U-PE processing functions, including switching the
frame locally or forwarding it to the N-PE. The egress U-PE will
remove the PW label, perform any relevant processing of the PBB
header (e.g. I-SID translation if required) and then hand the frame
to the PBB bridge component for local C-MAC processing.
3.1.1 PBB U-PEs in Single I-SID Domain
In this scenario, I-SID assignment is performed globally across all
MPLS access networks and therefore there is no need for I-SID
translation. Both I-SID mode and I-SID bundling mode are supported
in this scenario. I-SID to VPLS mapping is congruent on all U-PEs.
In case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN)
is mapped to a VPLS instance and existing Ethernet raw mode (0x0005)
or tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448],
can be used with the corresponding B-VID rewrite or translation
performed at the various N-PE and egress U-PE nodes. This assumes
that I-SID bundling is congruent on the associated U-PEs and N-PEs.
In case of the I-SID mode, an I-SID is mapped to a VPLS instance and
the new PW type described in [VPLS-PBB] is utilized without the need
for I-SID translation.
Sajassi, et. al. Expires: January 2009 [Page 7]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
3.1.2 PBB U-PEs in Multiple I-SID Domains
In this scenario, I-SID assignment is performed on a per MPLS access
network basis and thus I-SID bundling is no longer viable because I-
SID values differ among different domains. In this scenario, only I-
SID mode is supported. The U-PE nodes are the only nodes that are I-
SID aware; so, it will be up to them to perform the translation as
frames are forwarded between different service domains.
At the ingress U-PE, during the PBBN encapsulation process, an I-SID
value is added. A new PW type (described in [VPLS-PBB]) will be
required to transport I-SID tagged payloads between the U-PE and N-
PE. The one-to-one mapping between this I-SID value and the PW
enables the receiving N-PE and U-PE to infer which VPLS instance the
frame belongs to.
When the encapsulated PBBN frames reach the egress U-PE, the PW
label is removed and then the appropriate I-SID translation is
performed. In this case, it is taking the I-SID originally assigned
and imposed by the U-PE nodes (in MPLS access network #1) and
translating it to the I-SID value assigned to MPLS access network
#2. Once this is completed, the frame is handed off to the PBBN BEB
for normal processing.
3.2 H-VPLS with MPLS Access: PBB N-PE
In this case, the PBB function is incorporated at the N-PE to
improve the scalability of H-VPLS networks in terms of the numbers
of MAC addresses and service instances that are supported.
Customer networks or hosts (CE) connect into the U-PE nodes using
standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The
U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS
PWs (per customer). These, in turn, are connected via a full-mesh of
PWs (per customer or group of customers) traversing the IP/MPLS
core.
The U-PE still provides the same type of services toward its
customers as before and they are:
- Port mode (either 802.1D, 802.1Q, or 802.1ad)
- VLAN mode (either 802.1Q or 802.1ad)
- VLAN-bundling mode (either 802.1Q or 802.1ad)
Spoke PW from U-PE to N-PE is not service multiplexed i.e. one
service per PW. The spoke PW cannot be multiplexed because of the
potential for having overlapping Customer MAC addresses.
PBB PBB
Sajassi, et. al. Expires: January 2009 [Page 8]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
BEB +----------+ BEB
| | | |
+-----------+ | | IP | | +-----------+
| MPLS | V | MPLS | V | MPLS |
| Access +----+ | Core | +----+ Access |
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| | | | | |
+-----------+ +----------+ +-----------+
Figure 2: H-VPLS with MPLS Access Network and PBB N-PE
By incorporating PBB function, the N-PE maps each of these services
(for a given customer) onto a single I-SID based on the
configuration at the N-PE. Many I-SIDs can be multiplexed within a
single bridge domain (e.g. B-VLAN). The N-PE can, then, either map a
single I-SID into a VPLS instance or it can map a bridge domain
(e.g. B-VLAN) onto a VPLS instance, according to its configuration.
Next, the encapsulated frames are sent over the set of PWs
associated with that VPLS instance.
If the VPLS instance is set up per bridge domain (e.g. B-VID), only
one I-SID Domain is allowed. However if VPLS instance is set up per
I-SID, single I-SID Domain and multiple I-SID Domain scenarios have
to considered, which are covered next.
3.2.1 PBB N-PEs in Single I-SID Domain
In this scenario, I-SID assignment is performed globally across all
MPLS access networks and therefore there is no need for I-SID
translation. Both I-SID mode and I-SID bundling mode are supported
in this scenario. I-SID to VPLS mapping is congruent on all N-PEs.
In case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN)
is mapped to a VPLS instance and existing Ethernet raw mode (0x0005)
or tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448],
can be used with the corresponding B-VID rewrite or translation
performed at the various N-PE nodes. This assumes that I-SID
bundling is congruent on both N-PEs.
In case of the I-SID mode, an I-SID is mapped to a VPLS instance and
the new PW type described in [VPLS-PBB] is utilized without the need
for I-SID translation.
3.2.2 PBB N-PEs in Multiple I-SID Domains
In this scenario, I-SID assignment is performed on a per MPLS access
network basis and thus I-SID bundling is no longer viable because I-
SIDs value differ among different domains. In this scenario, only I-
Sajassi, et. al. Expires: January 2009 [Page 9]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
SID mode is supported and the N-PE nodes perform the translation as
frames are forwarded between different service domains.
To perform this translation, the new PW type (described in [VPLS-
PBB]) is used. The Ethernet frame that is carried over this PW has
I-tagged format. The receiving N-PE, upon receiving this frame, will
translate the I-SID to the value associated with the service
instance of the PW and will append a B-VID associated for the local
grouping of the I-SID.
After the proper translation of I-SID and insertion of B-VID, the
processing of the frame is exactly the same as the current VPLS.
4.
Migration Scenarios
Operators and service providers that have deployed H-VPLS with
either MPLS or Ethernet are unlikely to migrate to PBB technology
overnight because of obvious cost implications. Thus, it is
imperative to outline migration strategies that will allow operators
to protect investments in their installed base while still taking
advantage of the scalability benefits of PBB technology.
In the following sub-sections, we explore three different migration
scenarios which allow a mix of existing H-VPLS access networks to
co-exist with newer PBB-based access networks. The scenarios differ
in whether the Ethernet service frames passing over the VPLS core
are PBB-encapsulated or not. The first scenario in section 4.1
involves passing only non PBB-encapsulated frames over the core. The
second scenario in section 4.2 stipulates passing only PBB-
encapsulated frames over the core. Whereas, the final scenario in
section 4.3 depicts a core that supports a mix of PBB-encapsulated
and non PBB-encapsulated frames. The advantages and disadvantages of
each scenario will be discussed in its respective section.
4.1 802.1ad Service Frames over VPLS Core
In this scenario, existing access networks are left unchanged. All
N-PEs would forward frames based on C-MAC addresses. In other words,
Ethernet frames which are traversing the VPLS core (within PWs)
would use the 802.1ad frame format, as in current VPLS. Hence, the
N-PEs in existing access networks do not require any modification.
For new MPLS access networks that have PBB functions on the U-PE,
the corresponding N-PE must incorporate built-in IB-BEB functions in
order to terminate the PBB encapsulation before the frames enter the
core. A key point here is that while both the U-PE and N-PE nodes
implement PBB IB-BEB functionality, the former has the I-Component
facing the customer (CE) and the B-Component facing the core;
whereas the latter has the I-Component facing the core and the B-
Component facing the customer (i.e. access network).
Sajassi, et. al. Expires: January 2009 [Page 10]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
PBB PBB
+----------+ IB-BEB IB-BEB
| | | |
+-----------+ | IP | | +-----------+ |
| MPLS | | MPLS | V | MPLS | |
| Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| (Existing)| | | | (New) |
+-----------+ +----------+ +-----------+
Figure 3: Migration with 802.1ad Service Frames over VPLS Core
The main advantage of this approach is that it requires no change to
existing access networks or existing VPLS N-PEs. The main
disadvantage is that these N-PEs will not leverage the advantages of
PBB in terms of MAC address and PW scalability.
It is worth noting that this migration scenario is an optimal option
for an H-VPLS deployment with a single PBB-capable access network.
When multiple PBB-capable access networks are required, then the
scenario in Section 4.3 is preferred, as it provides a more scalable
and optimal interconnect amongst the PBB-capable networks.
4.2 PBB Service Frames over VPLS Core
This scenario requires that the VPLS N-PE connecting to existing
MPLS access networks be upgraded to incorporate IB-BEB functions.
All Ethernet service frames passing over the VPLS core would be PBB-
encapsulated. The PBB over MPLS access networks would require no
special requirements beyond what is captured in section 3 of this
document.
In this case, both the U-PE and N-PE which implement IB-BEB
functionality have the I-Component facing the customer and the B-
Component facing the core.
PBB PBB
IB-BEB +----------+ IB-BEB
| | | |
+-----------+ | | IP | +-----------+ |
| MPLS | V | MPLS | | MPLS | |
| Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| (Existing)| | | | (New) |
+-----------+ +----------+ +-----------+
Figure 4: Migration with PBB Service Frames over VPLS Core
The main advantage of this approach is that it allows better
scalability of the VPLS N-PEs in terms of MAC address and pseudowire
Sajassi, et. al. Expires: January 2009 [Page 11]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
counts. The disadvantage is that it requires upgrading the VPLS N-
PEs of all existing MPLS access networks.
4.3 Mixed 802.1ad and PBB over VPLS Core
In this scenario, existing access networks are left unchanged, and
exchange Ethernet frames with 802.1ad format over the PWs in the
core. The newly added access networks, which incorporate PBB
functionality exchange Ethernet frames that are PBB-encapsulated
amongst each other over core PWs. For service connectivity between
existing access network (non PBB capable) and new access network
(PBB based), the VPLS N-PE of the latter network employs IB-BEB
functionality to de-capsulate the PBB header from frames outbound to
the core, and encapsulate the PBB header for frames inbound from the
core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet
service frames are exchanged over the VPLS core.
This mode of operation requires new functionality on the VPLS N-PE
of the PBB-capable access network, so that the PE can send frames in
802.1ad format or PBB format, on a per PW basis, depending on the
capability of the destination access network. Effectively, the PE
would have to incorporate B-BEB as well as IB-BEB functions. The
frame format to be used over a given PW will depend on the
negotiated PW type:
- PBB incapable access network to PBB incapable access network:
Existing raw mode (0x0005) or tagged mode (0x0004) PW types can
be used.
- PBB incapable access network to PBB capable access network:
Existing raw mode (0x0005) or tagged mode (0x0004) PW types can
be used.
- PBB capable access network to PBB capable access network: new
PW type discussed in [VPLS-PBB] must be used.
A given PE needs to be aware of the capability of its remote peer in
order to determine the right type of PW to negotiate with that peer.
This can be achieved either via static configuration, or by
extending the VPLS BGP-based auto-discovery mechanism discussed in
[RFC4761]. The latter approach is preferred, and the details of the
extensions required will be covered in future revision of this
document.
PBB
B-BEB PBB
+----------+ IB-BEB IB-BEB
Sajassi, et. al. Expires: January 2009 [Page 12]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
| | | |
+-----------+ | IP | | +-----------+ |
| MPLS | | MPLS | V | MPLS | |
| Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | |N-PE| |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| (Existing)| | | | (New) |
+-----------+ +----------+ +-----------+
Figure 5: Migration with Mixed 802.1ad &PBB Service Frames over VPLS
Core
The U-PE and N-PE of the PBB-capable access network both employ BEB
functionality: The U-PE implements IB-BEB function where the I-
Component faces the customer (CE) and the B-Component faces the
core. The N-PE, on the other hand, implements IB-BEB functionality
with the I-Component facing the core and the B-Component facing the
customer (access network). In addition, the N-PE implements stand-
alone B-BEB functionality.
This scenario combines the advantages of both previous scenarios
without any of their shortcomings, namely: it does not require any
changes to existing access networks and it allows the N-PE to
leverage the scalability benefits of 802.1ah for PBB to PBB access
network connectivity. The disadvantage of this option is that it
requires new functionality on the N-PE of the PBB-capable access
network.
5.
IANA Considerations
This document has no actions for IANA.
6.
Security Considerations
This document does not introduce any additional security aspects
beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security
considerations are already covered in [RFC4762].
7.
References
7.1 Normative References
[802.1ad] "Virtual Bridged Local Area Networks: Provider Bridges",
IEEE 802.1ad/D8.1, December 2005
[802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul
2007
Sajassi, et. al. Expires: January 2009 [Page 13]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
[RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447,
April 2006
[RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC4448, April 2006
[RFC4762] "Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling", RFC4762, January 2007
[RFC4761] "Virtual Private LAN Service (VPLS) Using BGP for Auto-
Discovery and Signaling", RFC4761, January 2007
7.2 Informative References
[802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q-
2005
[802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D-
2003
[VPLS-PBB] "VPLS Interoperability with Provider Backbone Bridges",
draft-sajassi-l2vpn-vpls-pbb-interop-02.txt, Work in progress,
November 2007
[VPLS-Bridge] "VPLS Interoperability with CE Bridges", draft-ietf-
l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 2007
[PBB-PW] "802.1ah Ethernet Pseudowire", draft-martini-pwe3-802-1ah-
pw-00.txt, Work in progress, May 2007
[VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-
03.txt, Work in progress, November 2007
[PBB-VPLS-MCAST] "Multicast Pruning in Provider Backbone Bridged
VPLS", draft-sajassi-l2vpn-pbb-vpls-mcast-pruning-00.txt, Work in
progress, July 2008
Appendix A: Provider Backbone Bridges - Primer
Provider Backbone Bridges (PBBs), as currently being defined in IEEE
802.1ah, offer a scalable solution for service providers to build
large bridged networks. The focus of PBB is primarily on improving
two main areas with provider Ethernet bridged networks:
- MAC-address table scalability: in current provider networks
that employ IEEE 802.1Q or IEEE 802.1ad bridging, the service
provider equipment operating at the Ethernet MAC layer is
forced to learn all customer edge device MAC addresses (when
the CE is a router) and all customer end-station MAC addresses
(when the CE is a bridge). This clearly does not scale well as
the number of customers and customer equipment, served by a
Sajassi, et. al. Expires: January 2009 [Page 14]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
given provider, increases. The service providers are often
limited by the size of the hardware MAC tables as they attempt
to scale their networks.
- Service instance scalability: when building networks using IEEE
802.1Q or IEEE 802.1ad technologies, a service provider is
limited to 4094 service instances per 802.1Q or 802.1ad
network. This limitation is due to the fact that the VLAN
identifier is 12-bits in width which translates to 4096
possible values (and VLAN identifier values 0 and 4095 are
reserved).
To obviate the above two limitations, PBB introduces a hierarchical
network architecture with associated new frame formats which extend
the work completed by Provider Bridges (IEEE 802.1ad). In the PBB
architecture, customer networks (using IEEE 802.1Q bridging) are
aggregated into provider bridge networks (using IEEE 802.1ad).
These, in turn, are aggregated into Provider Backbone Bridge
Networks (PBBNs) which utilize the IEEE 802.1ah frame format. The
frame format employs a MAC tunneling encapsulation scheme for
tunneling customer Ethernet frames within provider Ethernet frames
across the PBBN. A VLAN identifier (B-VID) is used to segregate the
backbone into broadcast domains and a new 24-bit service identifier
(I-SID) is defined and used to associate a given customer MAC frame
with a provider service instance (also called the service
delimiter). It should be noted that in 802.1ah there is a clear
segregation between provider service instances (represented by I-
SIDs) and provider VLANs (represented by B-VIDs) which was not the
case for 802.1ad. As such, the network designer for an 802.1ah
network has the freedom to define the number of VLANs which is
optimum for network operation without any dependency on the number
of service instances.
PBBN bridges utilize existing IEEE control protocols (e.g. IEEE
802.1s MST) to create a loop free topology for frame forwarding. A
PBBN bridge can be categorized as either a Backbone Core Bridge
(BCB) or Backbone Edge Bridge (BEB). A BCB is a plain IEEE 802.1ad
Provider Bridge. A BEB is responsible for encapsulation and de-
encapsulation of customer Ethernet frames to/from PBB (802.1ah)
frame format.
As shown in the following figure A.1, a Backbone Edge Bridge (BEB)
may consist of a single B-component and one or more I-components. In
simple terms, the B-component provides bridging in provider space
(B-MAC, B-VLAN) and the I-component provides bridging in customer
space (C-MAC, S-VLAN). The customer frame is first encapsulated with
the provider backbone header (B-MAC, B-tag, I-tag); then, the
bridging is performed in the provider backbone space (B-MAC, B-VLAN)
through the network till the frame arrives at the destination BEB
where it gets de-encapsulated and passed to the CE. If a PBB bridge
consists of both I & B components, then it is called IB-BEB and if
Sajassi, et. al. Expires: January 2009 [Page 15]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
it only consists of either B-component or I-component, then it is
called B-BEB or I-BEB respectively. The interface between an I-BEB
or IB-BEB and a CE is called S-tagged service interface and the
interface between an I-BEB and a B-BEB (or between two B-BEBs) is
called I-tagged service interface. The interface between a B-BEB or
IB-BEB and a Backbone Core Bridge (BCB) is called B-Tagged service
interface. These service interfaces, for Provider Backbone Bridges,
are described next.
+-------------------------------+
| 802.1ah Bridge Model |
| |
+---+ | +------+ +-----------+ |
|CE |---------|I-Comp|------| | |
+---+ | | | | |--------
| +------+ | | |
| o | B-Comp | |
| o | |--------
| o | | |
+---+ | +------+ | | |
|CE |---------|I-Comp|------| |--------
+---+ ^ | | | ^ | | | ^
| | +------+ | +-----------+ | |
| +------------|------------------+ |
| | |
| | |
S-tagged I-tagged B-tagged
Service I/F Service I/F Service I/F
Figure A1: 802.1ah Bridge Model
A.1 S-Tagged Service Interface
This service interface connects a customer 802.1ad Provider Bridge
to an I-BEB or IB-BEB. Three modes are supported:
- Port Mode. In this mode, traffic on all S-VLANs is mapped to
the same I-SID.
- S-Tag Mode. In this mode, traffic associated with each S-VLAN
is mapped to a single I-SID.
- S-Tag Bundling Mode. In this mode, traffic associated with a
group or range of S-VLANs is mapped to a single I-SID.
A.2 I-Tagged Service Interface
This service interface connects an I-BEB to a B-BEB or it connects
two B-BEBs together. Although, in figure A.1, this interface is
shown as an internal interface between I-component and B-component
within an IB-BEB, in practice this service interface is an external
Sajassi, et. al. Expires: January 2009 [Page 16]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
interface connecting a customer I-BEB with a provider B-BEB or
connecting two different providers B-BEBs across different
administrative domains.
A.3 B-Tagged Service Interface
This service interface connects a B-BEB or an IB-BEB with a provider
Backbone Core Bridge (BCB).
Authors' Addresses
Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134, U.S.
Email: sajassi@cisco.com
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9, Canada
Email: mohand@nortel.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.
Sajassi, et. al. Expires: January 2009 [Page 17]
Internet-Draft PBB in H-VPLS with MPLS Access July 2008
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Sajassi, et. al. Expires: January 2009 [Page 18]