Internet-Draft A. Sajassi, S. Salam, C. Metz, Cisco
L2VPN Working Group N. Bitar, Verizon
Intended status: Standards D. Mohan, Nortel
Expires: May 2008
November 2007
VPLS Interoperability with Provider Backbone Bridges
draft-sajassi-l2vpn-vpls-pbb-interop-02.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).
Abstract
The scalability of H-VPLS (either with MPLS or Ethernet access
network) can be improved by incorporating Provider Backbone Bridge
(PBB) functionality in VPLS access. PBB is being worked on in IEEE
as IEEE 802.1ah, which is an amendment to 802.1Q to improve the
scalability of MAC addresses and service instances in Provider
Sajassi, et. al. Expires: May 2008 [Page 1]
Internet-Draft VPLS Interoperability with PBB Nov 2007
Ethernet networks. This document describes how IEEE 802.1ah
functionality can be used in the H-VPLS access network to attain
better scalability in terms of number of customer MAC addresses and
number of service instances that can be supported. This document
also describes the scenarios and the mechanisms for incorporating
PBB functionality within H-VPLS with existing MPLS access or IEEE
802.1ad (aka QinQ) Ethernet access and interoperability among them.
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....................................................3
2. Terminology.....................................................4
3. H-VPLS with PBBN Access.........................................5
3.1 H-VPLS with Homogenous PBBN Access.............................6
3.1.1 Service Interfaces and Interworking Options..................7
3.1.2 H-VPLS with PBBN Access: Type I Service Interface............9
3.1.3 H-VPLS with PBBN Access: Type II Service Interface..........10
3.1.4 H-VPLS with PBBN Access: Type III Service Interface.........12
3.2 H-VPLS with Mixed PBBN Access and PBN Access..................14
3.2.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE........15
3.2.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE.........16
3.3 H-VPLS with Mixed PBBN and MPLS Access........................17
3.3.1 H-VPLS with Mixed PBBN & MPLS Access: PBB N-PE..............17
3.3.2 H-VPLS with Mixed PBBN & MPLS Access: Regular MPLS PE.......18
4. H-VPLS with MPLS Access........................................19
4.1 H-VPLS with MPLS Access: PBB U-PE.............................19
4.1.1 PBB U-PEs in Single I-SID Domain............................21
4.1.2 PBB U-PEs in Multiple I-SID Domains.........................21
4.2 H-VPLS with MPLS Access: PBB N-PE.............................21
4.2.1 PBB N-PEs in Single I-SID Domain............................22
4.2.2 PBB N-PEs in Multiple I-SID Domains.........................22
5. Acknowledgments................................................23
6. IANA Considerations............................................23
7. Security Considerations........................................23
8. References.....................................................23
8.1 Normative References..........................................23
8.2 Informative References........................................23
Appendix A: Provider Backbone Bridges - Primer....................24
Sajassi, et. al. Expires: May 2008 [Page 2]
Internet-Draft VPLS Interoperability with PBB Nov 2007
A.1 S-Tagged Service Interface....................................26
A.2 I-Tagged Service Interface....................................26
A.3 B-Tagged Service Interface....................................26
Authors? Addresses................................................26
Full Copyright Statement..........................................27
Intellectual Property.............................................27
1. Introduction
The scalability of H-VPLS (either with MPLS or Ethernet access
network) can be improved by incorporating Provider Backbone Bridge
(PBB) functionality in VPLS access. PBB is being worked on in IEEE
as IEEE 802.1ah, which is an amendment to 802.1Q to improve the
scalability of MAC addresses and service instances in Provider
Ethernet networks. This document describes how IEEE 802.1ah
functionality can be used in the H-VPLS access network to attain
better scalability in terms of number of customer MAC addresses and
number of service instances that can be supported. This document
also describes the scenarios and the mechanisms for incorporating
PBB functionality within H-VPLS with existing MPLS access or IEEE
802.1ad (aka QinQ) Ethernet access and interoperability among them.
[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.
In addition to the above scalability issues, H-VPLS with 802.1ad
Ethernet access network has another scalability issue in terms of
the maximum number of service instances that can be supported in the
access network as described in [RFC4762]. Since the number of
provider VLANs (S-VLANs) is limited to 4K and each S-VLAN represents
a service instance in an 802.1ad network, then the maximum number of
service instances that can be supported is 4K. These issues are
highlighted in [VPLS-Bridge].
Sajassi, et. al. Expires: May 2008 [Page 3]
Internet-Draft VPLS Interoperability with PBB Nov 2007
This document describes how IEEE 802.1ah (aka Provider Backbone
Bridges) can be integrated with H-VPLS to address these scalability
issues. In case of H-VPLS with MPLS access, 802.1ah 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.
In case of H-VPLS with 802.1ah (PBB) Ethernet access, it results in
better scalability in terms of both number of service instances and
number of C-MACs in both Ethernet access network and VPLS core
network and number of PWs in VPLS core network.
This document also covers the interoperability scenarios for
deploying H-VPLS with PBB Ethernet access when other types of access
networks are deployed, including existing MPLS and 802.1ad Ethernet
access in either single or multiple service domains.
Section 2 gives a quick terminology reference. Section 3 describes
H-VPLS with PBB Access Network including homogenous PBBN access and
mixed PBBN/PBN access. Section 4 describes the use of PBB
functionality in H-VPLS with MPLS access including PBB on U-PE and
PBB on N-PE variants.
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.
Sajassi, et. al. Expires: May 2008 [Page 4]
Internet-Draft VPLS Interoperability with PBB Nov 2007
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).
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-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 PBBN Access
A brief primer on PBB [802.1ah] is provided in Appendix A. Readers
are encouraged to refer to that section to become familiar with PBB
technology.
Sajassi, et. al. Expires: May 2008 [Page 5]
Internet-Draft VPLS Interoperability with PBB Nov 2007
PBBN access offers MAC-address table scalability for H-VPLS PE
nodes. This is due to the MAC tunneling encapsulation scheme of PBB
which only exposes the provider?s own MAC addresses to PE nodes (B-
MACs of Provider?s PBB-capable devices in access network), as
opposed to customers? MAC addresses in conventional H-VPLS with MPLS
or 802.1ad access.
PBBN access also offers service instance scalability when compared
to H-VPLS with 802.1Q/802.1ad access networks. This is due to the
new 24-bit service identifier (I-SID) used in PBB encapsulation,
which allows up to 16M services per PBB access network, compared to
4K services per 802.1Q/802.1ad access network.
Another important advantage of PBBN access is that it offers clear
separation between service layer (represented by I-SID) and network
layer (represented by B-VLAN). B-VLANs segregate a PBB access
network into different broadcast domains and possibly unique
spanning-tree topologies, with each domain being able to carry
multiple services (i.e. I-SIDs). In 802.1ad access networks, the
network and service layers are the same (represented by S-VLAN).
This allows the Provider to manage and optimize the PBB access
network topology independent of the number of service instances that
are supported.
In the following sections we look into different flavors of H-VPLS
with PBBN access. Section 3.1 discusses the case where H-VPLS is
deployed with homogenous PBBN access networks. Section 3.2 describes
the case where at least one of the access networks is PBN access
(QinQ or 802.1ad) while others are PBBN access. Finally, Section 3.3
describes the case where at least one of the access networks has
existing MPLS access while others are PBBN access.
3.1 H-VPLS with Homogenous PBBN Access
At a macro scale, a network that employs H-VPLS with PBBN access can
be represented as shown in figure 1 below.
+--------------+
| |
+---------+ | IP/MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | |VPLS| |VPLS| | |--| CE |
+----+ | PBBN |---| PE | | PE |--| PBBN | +----+
+----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 1: H-VPLS with PBBN Access
Sajassi, et. al. Expires: May 2008 [Page 6]
Internet-Draft VPLS Interoperability with PBB Nov 2007
In the context of PBBN and H-VPLS interoperability, "I-SID Domain"
and "B-VID Domain" can be defined as follows:
- "I-SID Domain" refers to 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.
- "B-VID Domain" refers to a network administrative boundary under
which all the PBB BEBs and VPLS PE devices employ consistent I-SID
to B-VID bundling ? e.g., grouping of I-SIDs to B-VIDs are the
same in that domain. Although the two B-VIDs in two PBBNs that
represent the same group of I-SIDs do not need to use the same
value, in practice they often represent the same value because
once the I-SID grouping is made identical in two PBBNs, it is
rather very easy to make the values of the corresponding B-VIDs
also identical.
Consequently, three different kinds of "Service Domains" are defined
in the following manner:
- Tightly Coupled Service Domain ? Different PBBN access networks
belong to the same I-SID Domain and B-VID Domain. However, the
network control protocols (e.g. xSTP) run independently in each
PBB access network.
- Loosely Coupled Service Domain ? Different PBB access networks
belong to the same I-SID Domain. However, each PBBN access
maintains its own independent B-VID Domain. Again, the network
control protocols (e.g. xSTP) run independently in each PBBN
access.
- Different Service Domain ? In this case, each PBBN access
maintains its own independent I-SID Domain and B-VID Domain, with
independent network control protocols (e.g. xSTP) in each PBB
access.
In general, correct service connectivity spanning networks in a
Tightly Coupled Service Domain can be achieved via B-VID mapping
between the networks (often even without B-VID translation).
However, correct service connectivity spanning networks in a Loosely
Coupled Service Domain requires I-SID to B-VID re-mapping.
Furthermore, service connectivity spanning networks in Different
Service Domains requires both I-SID translation and I-SID to B-VID
re-mapping.
3.1.1 Service Interfaces and Interworking Options
Customer devices will interface with PBBN edge bridges using
existing Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad.
At the PBBN edge, customer MAC frames are encapsulated in a PBB
header that includes a service provider source and destination MAC
addresses (B-MAC) and are bridged up to the VPLS PE. The PBB
Sajassi, et. al. Expires: May 2008 [Page 7]
Internet-Draft VPLS Interoperability with PBB Nov 2007
encapsulated customer MAC frame is then injected into the VPLS
backbone network, delivered to the remote VPLS PE node(s), and
switched onto the remote PBBN access. From there, the PBBN bridges
the encapsulated frame to a PBBN edge bridge where the PBB header is
removed and the customer frame is sent to customer domain.
Interoperating between PBBN devices and VPLS PE nodes will certainly
leverage work already completed. When I-SID visibility is required
at the VPLS PE nodes, new service interfaces based on I-SID tag will
need to be defined; as well as a new PW type to transport certain
types of PBB encapsulated frames across a PW.
Moreover, by mapping a B-VLAN to a VPLS instance, and bundling
multiple end-customer service instances, represented by I-SIDs, over
the same B-VLAN, service providers will be able to significantly
reduce the number of full-mesh PWs required in the core. In this
case, I-SID visibility is not required on the VPLS-PE and the I-SID
will serve as the means of multiplexing/de-multiplexing individual
service instances in the PBBN over a bundle (B-VLAN).
When I-SID visibility is expected across the service interface at
the VPLS PE, VPLS PE can be considered to offer service-level
interworking between PBBN access and IP/MPLS core. Similarly, when
PE is not expected to have visibility of I-SID at the service
interface, VPLS PE can be considered to offer network-level
interworking between PBBN access and MPLS core.
A VPLS PE is always part of the IP/MPLS core, and may optionally
participate in the control protocols (e.g. xSTP) of the access
network. When connecting to a PBBN access, the VPLS PE needs to
support one of the following three types of service interfaces:
- Type I: B-Tagged Service Interface with B-VID as Service Delimiter
? The PE connects to a Backbone Core Bridge (BCB) in PBBN access.
The handoff between the BCB and the PE is B-Tagged PBB
encapsulated frame (as described in Appendix A.3). The PE is
transparent to [802.1ah] encapsulations and treats these frames as
802.1ad frames since B-VID EtherType is the same as S-VID
EtherType. The PE does not need to support [802.1ah]
functionality. This corresponds to conventional VPLS PE?s tagged
service interface. When using Type I service interface, the PE
needs to support either raw-mode or tagged-mode Ethernet PW. Type
I Service Interface is described in detail in Section 3.1.2.
- Type II: B-Tagged Service Interface with I-SID as Service
Delimiter ? The PE connects to a Backbone Core Bridge (BCB) in
PBBN access. The handoff between the BCB and the PE is B-Tagged
PBB encapsulated frame (as described in Appendix A.3). The PE
supports the B-BEB (Backbone Edge Bridge with B-Component)
functionality of [802.1ah]. Consequently, the PE interprets
[802.1ah] encapsulations and has I-SID visibility. With Type II
service interface, the PE supports either raw-mode or tagged-mode
Sajassi, et. al. Expires: May 2008 [Page 8]
Internet-Draft VPLS Interoperability with PBB Nov 2007
Ethernet PW or a newly defined mode of Ethernet PW [PBB-PW]. Type
II Service Interface is described in detail in Section 3.1.3.
- Type III: I-Tagged Service Interface with I-SID as Service
Delimiter ? The PE connects to a B-BEB (Backbone Edge Bridge with
B-Component) in PBBN access. The PE itself also supports the B-BEB
functionality of [802.1ah]. The handoff between the B-BEB in PBBN
access and the PE is an I-Tagged PBB encapsulated frame (as
described in Appendix A.2). With Type III service interface, the
PE supports the newly defined mode of Ethernet PW [PBB-PW] in
addition to the existing raw-mode and tagged-mode. Type III
Service Interface is described in detail in Section 3.1.4.
3.1.2 H-VPLS with PBBN Access: Type I Service Interface
This is a B-Tagged service interface with B-VID as service delimiter
on the VPLS-PE. It does not require any new functionality on the
VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS
core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on
right side of Figure 2) by participating in network control
protocols (e.g. xSTP) of the PBBN access.
PBBN Access IP/MPLS Core PBBN Access
+--------------+
+---------+ | | +---------------+
| | +----+ | | |
| +---+ |VPLS| +-+ | | +---+ |
| |BCB|---| PE |---|P| | | |BCB| |
| +---+ /+----+ /+-+\ | | /+---+ |
|+---+ | / +----+ / \+----+ / +---+|
+--+ ||IB-| +---+/ |VPLS|/ +-+ |VPLS|/ +---+ |IB-|| +--+
|CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE|
+--+ |+---+ +---+ ^ +----+ +-+ +----+ ^ +---+ +---+| +--+
| | | | | | | |
+---------+ | | | +--|------------+
| +--------------+ |
| |
Type I Type I
Figure 2: H-VPLS with PBBN Access & Type I Service Interface
Type I service interface is only applicable to networks with Tightly
Coupled Service Domains, where both I-SID Domains and B-VID Domains
are the same across all PBBN access networks.
The BCB and VPLS PE will exchange PBB encapsulated frames that
include source and destination B-MAC addresses, a B-VID and I-SID.
The service delimiter, from the perspective of the VPLS PE, is the
B-VID; in fact, this interface operates exactly as a current
802.1Q/ad interface into a VPLS PE does today. With Type I service
interface, VPLS PE can be considered as providing network-level
Sajassi, et. al. Expires: May 2008 [Page 9]
Internet-Draft VPLS Interoperability with PBB Nov 2007
interworking between PBBN and MPLS domains, since VPLS PE does not
have visibility of I-SIDs.
The main advantage of this service interface, when compared to other
types, is that it allows the service provider to save on the number
of full-mesh PWs required in the core. This is primarily because
multiple service instances (I-SIDs) are bundled over a single full-
mesh corresponding to B-VID, instead of requiring a dedicated full-
mesh per service instance. Another advantage is the MAC address
scalability in the core since the core is not exposed to C-MACs.
The disadvantage of this interface is the comparably excessive
replication required in the core: Since a group of service instances
share the same full-mesh of PWs, an unknown unicast, multicast or
broadcast on a single service instance will result in a flood over
the core. This, however, can be mitigated via the use of P2MP LSP
[VPLS-MCAST] for VPLS multicast/broadcast traffic.
Three different modes of operation are supported by Type I Service
Interface:
- Port Mode or Unqualified Mode: All traffic over an interface in
this mode is mapped to a single VPLS instance. Existing PW
signaling and Ethernet raw mode (0x0005) PW type, defined in
[RFC4447] [RFC4448], are supported.
- VLAN Mode or Qualified Mode: all traffic associated with a
particular VLAN identified by the B-VID is mapped to a single VPLS
instance. Existing PW signaling and Ethernet raw mode (0x0005) PW
type, defined in [RFC4447] [RFC4448], are supported.
- VLAN Bundling Mode: all traffic associated with a group or range
of VLANs or B-VIDs is mapped to a single VPLS instance. Existing
PW signaling and Ethernet raw mode (0x0005) PW type, defined in
[RFC4447] [RFC4448], are supported.
For the above three modes, it is also possible to use Ethernet
tagged mode (0x0004) PW, as defined in [RFC4447] [RFC4448], for
interoperability with equipment that does not support raw mode. The
use of raw mode is recommended to be the default though.
3.1.3 H-VPLS with PBBN Access: Type II Service Interface
This is a B-Tagged service interface with I-SID as service delimiter
on the VPLS-PE. It requires the VPLS-PE to include B-Component of
PBB BEB for I-SID processing, in addition to capability for mapping
I-SID or I-SID bundle to VPLS instance. As shown in Figure 3, the PE
is always part of IP/MPLS core. The PE may also be part of PBBN
Access (e.g. VPLS-PE on right side of Figure 3) by participating in
network control protocols (e.g. xSTP) of PBBN access.
Sajassi, et. al. Expires: May 2008 [Page 10]
Internet-Draft VPLS Interoperability with PBB Nov 2007
PBBN Access IP/MPLS Core PBBN Access
+--------------+
+---------+ | | +---------------+
| | +-----+ | | |
| +---+ |PE w/| +-+ | | +---+ |
| |BCB|---|B-BEB|---|P| | | |BCB| |
| +---+ /+-----+ /+-+\ | | +---+ |
|+---+ | / +-----+ / \+-----+ / +---+|
+--+ ||IB-| +---+/ |PW w/|/ +-+ |PE w/|/ +---+ |IB-|| +--+
|CE|-||BEB|-|BCB|---|B-BEB|---|P|--|B-BEB|--|BCB|-|BEB|--|CE|
+--+ |+---+ +---+ ^ +-----+ +-+ +-----+ ^+---+ +---+| +--+
| | | | | | | |
+---------+ | | | +---|-----------+
| +--------------+ |
| |
Type II Type II
Figure 3: H-VPLS with PBBN Access & Type II Service Interface
Type II service interface is applicable not only to networks with
Tightly Coupled Service Domains but also to networks with Loosely
Coupled Service Domains and even Different Service Domains. B-VID
Domains can be independent and B-VID is always locally significant
to each PBBN access and does not need to be transported over the
IP/MPLS core.
The BCB and VPLS PE will exchange PBB encapsulated frames that
include source and destination B-MAC addresses, a B-VID and I-SID.
The service delimiter, from the perspective of the VPLS PE, is the
I-SID. Since PE has visibility into I-SIDs, the PE provides service-
level interworking between PBBN access and IP/MPLS core.
The advantage that Type II service interface has compared to Type I
is the potentially less replication in the core. This is mainly due
to the increased segregation of service instances over disjoint
full-meshes of PWs. Another advantage is the MAC address scalability
in the core since the core is not exposed to C-MACs.
The disadvantage of this service interface, compared to Type I, is
that it may require a larger number of full-mesh PWs in the core.
However, the number of full-mesh PWs can still be less than those
required by H-VPLS without PBBN access.
It is expected that this interface type will be used for customers
with significant multicast traffic (but without P2MP LSP capability
in VPLS PE) so that a separate VPLS instance is set up per customer
(per I-SID instance). It should be noted that a VPLS PE may support
both Type I and Type II service interfaces over the same physical
interface.
Sajassi, et. al. Expires: May 2008 [Page 11]
Internet-Draft VPLS Interoperability with PBB Nov 2007
Two different operational modes are supported by Type II Service
Interface:
- I-SID Mode: all traffic associated with a particular I-SID is
mapped to a single VPLS instance. In networks with Tightly Coupled
Service Domain and Loosely Coupled Service Domain, since the I-SID
Domain is the same, no I-SID translation is required. However, in
networks with Different Service Domains, since I-SID Domains are
independent for each PBBN access, I-SID translation is required at
the PE and it is assumed that the PE only supports a single PBBN
access (because if the PE supports multiple PBBN access, then I-
SID translation using PW is not sufficient). This I-SID
translation occurs upon disposition from the PW, on the egress PE,
to a locally significant value. To that end, a new PW mode is
required, and this mode is analogous to tagged mode except that I-
SID instead of 802.1Q/ad VLAN-ID is used as service delimiter.
This new PW mode is defined in [PBB-PW]
- I-SID Bundling Mode: all traffic associated with a group or range
of I-SIDs is mapped to a single VPLS instance. This mode is only
applicable to Tightly and Loosely Coupled Service Domains since
the network consists of a single I-SID Domain and there is no need
to perform I-SID translation on egress PE. Existing PW signaling
and Ethernet raw mode (0x0005) PW type, defined in [RFC4447]
[RFC4448], are supported. It is also possible to use tagged mode
(0x0004) PW type for interoperability with older devices.
Note 1: For I-SID Bundling Mode operation in a network with
Different Service Domains, I-SID translation can be performed in the
B-BEB component of the PE only if a PE connects to a single access
PBBN and all the Service Domains coordinate a common I-SID space for
use over the core network. Otherwise, the B-BEB component of a given
PE would not have context of the originating I-SID Domain for a
received frame and would be incapable of handling interconnect to
more than a single disparate I-SID Domain. The expectation with Type
II service interface is that the core network does not have its own
independent I-SID Domain (unlike Type III service interface covered
in the next section). Therefore, to support Different Service
Domains in this mode, it is required to implement an I-SID
translation table per PW. This approach is unwieldy, hence, I-SID
Bundling mode in Different Service Domain is not supported.
3.1.4 H-VPLS with PBBN Access: Type III Service Interface
This is an I-Tagged service interface with I-SID as service
delimiter on VPLS-PE. It requires the VPLS-PE to include B-Component
of PBB BEB for I-SID processing in addition to the capability to map
I-SID and I-SID Bundle to VPLS instance. As shown in Figure 4, the
PE is always part of IP/MPLS core and connects to one or more B-BEB
in PBBN access.
Sajassi, et. al. Expires: May 2008 [Page 12]
Internet-Draft VPLS Interoperability with PBB Nov 2007
PBBN Access IP/MPLS Core PBBN Access
+--------------+
+---------+ | | +---------+
| | | | | |
| +---+ +-----+ | | +---+ |
| |B- | |PE w/| +-+ | | |BCB| |
| |BEB|--|B-BEB|-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
|+---+ +---+/ +-----+/ \+-----+ +---+ +---+|
+--+ ||IB-| |B- | |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
|CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | | | | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
Type III Type III
Figure 4: H-VPLS with PBBN Access & Type III Service Interface
Type III service interface is applicable to Tightly Coupled Service
Domains, Loosely Coupled Service Domains and Different Service
Domains. B-VID Domains can be independent and the B-VID is always
locally significant in each PBBN access and does not need to be
transported over the IP/MPLS core.
By definition the B-BEB connecting to the VPLS PE will remove any B-
VLAN tags for frames exiting the PBB access network because the B-
VIDs are local to that PBBN. The BEB and VPLS PE will exchange PBB
encapsulated frames that include source and destination B-MAC
addresses, and I-SID. The service delimiter, from the perspective of
the VPLS PE, is the I-SID. Since PE has visibility to I-SIDs, the PE
provides service-level interworking between PBBN access and IP/MPLS
core.
Type III Service Interface shares the same set of advantages and
disadvantages as Type II service interface (described in Section
3.1.3).
Two different modes are supported by Type III Service Interface:
- I-SID Mode: all traffic associated with a particular I-SID is
mapped to a single VPLS instance. In Tightly and Loosely Coupled
Service Domains, since I-SID Domain is the same, no I-SID
translation is required. However, in Different Service Domains,
since I-SID Domains are independent for each PBBN access, I-SID
translation is needed at the PE. If the PE supports multiple PBBN
access, then the I-SID translation needs to occur at the Customer
Backbone Port (CBP) of B-BEB in VPLS PE. However, if the PE
Sajassi, et. al. Expires: May 2008 [Page 13]
Internet-Draft VPLS Interoperability with PBB Nov 2007
supports a single PBBN access, then I-SID translation can be
performed at the egress of PW as type II interface. A new PW mode
is required, similar to one required in Type II Service Interface
(Section 3.1.3). This new PW mode is defined in [PBB-PW]
- I-SID Bundling Mode: all traffic associated with a group or range
of I-SIDs is mapped to a single VPLS instance. The PE maintains a
mapping of I-SIDs to a PE local B-VID. The VPLS instance is then
associated with this B-VID. With Tightly and Loosely Coupled
Service Domains, no I-SID translation needs to be performed. Type
III Service Interface also supports Different Service Domains in
this mode, since the CBP of B-BEB in PE can perform the
translation of PBBN specific I-SID to a local I-SID within the
IP/MPLS core, which can again be translated to the other PBBN
specific I-SID on egress PE. Such translation can also occur in
the B-BEB of PBBN access. Existing PW signaling and Ethernet raw
mode (0x0005), defined in [RFC4447] [RFC4448], is supported. It is
also possible to use tagged mode (0x0004) PW for purpose of
interoperability with equipment that doesn?t support raw mode.
Note 2: Port mode is not called out in Type III Service Interface
since it requires the mapping of I-SIDs to be identical on different
I-Tagged interfaces across VPLS network. If this is indeed the case,
Port mode defined in Type I Service Interface (Section 3.1.2) can be
used.
Note 3: I-SID Bundling mode assumes that bundling is homogeneous
between the ingress and egress VPLS PEs. In other words, I-SIDs are
divided along the same bundle boundaries. For the case where non-
homogeneous bundling is required, and I-SIDs are to be mapped to
different B-VLANs on different PEs, then I-SID mode should be chosen
over I-SID bundling mode, for it provides maximum flexibility.
3.2 H-VPLS with Mixed PBBN Access and PBN Access
It is foreseeable that service providers will want to interoperate
their existing PBN (QinQ) access networks with PBBN access networks
over H-VPLS. Figure 5 below shows the high-level network topology.
+--------------+
| |
+---------+ | IP/MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| PBN | |VPLS| |VPLS| | |--| CE |
+----+ | (QinQ) |---| PE1| | PE2|--| PBBN | +----+
+----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 5: H-VPLS with Mixed PBN and PBBN Access Networks
Sajassi, et. al. Expires: May 2008 [Page 14]
Internet-Draft VPLS Interoperability with PBB Nov 2007
Referring to the Figure 5 above, two possibilities come into play
depending on whether the interworking is carried out at PE1 or PE2.
These are described in the following sub-Sections.
3.2.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE
As shown in Figure 6, the operation of VPLS PE2 (connecting to the
PBBN access on the right) is no different from what was discussed in
Section 3.1. Both Type II and Type III service interfaces, as
discussed in the above section, are applicable. It is the behavior
of VPLS PE1 (connecting to the PBN access on the left) that is the
focus of this section.
PBN Access IP/MPLS Core PBBN Access
(802.1ad) +--------------+ (802.1ah)
| | +---------+
+---------+ | | | |
| | +-----+ | | +---+ |
| +---+ |PE w/| +-+ | | |BCB| |
| |PCB|--|IBBEB|-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
| | / +-----+/ \+-----+ | +---+|
+--+ |+---+ +---+ |PE w/| +-+ |PE w/| +---+ |IB-|| +--+
|CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BCB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | |PE1 PE2| | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
S-Tagged Type II (B-Tagged)
Figure 6: H-VPLS with Mixed PBB and PBBN Access: Modified PBN PE
Some assumptions made for this topology include:
- CE is directly connected to PBBN via C-Tagged Interface
- I-SID in PBBN access represents the same customer as S-VID in PBN
access
- At S-Tagged Service Interface of PE with IB-BEB functionality
(e.g. PE1 in Figure 6), the only viable service is 1:1 mapping of
S-VID to I-SID. However, towards the core network side, the same
PE can support I-SID bundling into a VPLS instance.
- For ease of provisioning in these disparate access networks, it is
recommended to use the same I-SID Domain among the PBBN access and
PEs with IB-BEB functionality (for those connecting to PBN).
Two different modes are supported by this topology:
- I-SID Mode: at PE connecting to PBN access, each S-VID is mapped
to an I-SID and subsequently mapped to a VPLS instance. Similarly,
Sajassi, et. al. Expires: May 2008 [Page 15]
Internet-Draft VPLS Interoperability with PBB Nov 2007
at PE connecting to PBBN access, each I-SID is mapped to a VPLS
instance. Since it is recommended to use the same I-SID Domain, no
I-SID translation is needed. A new PW mode is required, same as
one mentioned in (Section 3.1.3 and Section 3.1.4). This PW mode
is defined in [PBB-PW]
- I-SID Bundling Mode: at PE connecting to PBN access, each S-VID is
mapped to an I-SID and subsequently a group of I-SIDs is mapped to
a VPLS instance. Similarly, at PE connecting to PBBN access, each
group of I-SIDs is mapped to a VPLS instance. Similar to Type II
interface, no I-SID translation is performed for I-SID bundling
case. Existing PW signaling and Ethernet raw mode (0x0005) PW
type, defined in [RFC4447] [RFC4448], are supported. It is
possible to use tagged mode (0x0004) PW for backward compatibility
as well.
3.2.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE
As shown in Figure 7, the operation of VPLS PE1 (connecting to the
PBN access on the left) is no different from existing VPLS PEs. It
is the behavior of VPLS PE2 (connecting to the PBBN access on the
right) that is the focus of this section.
PBN Access IP/MPLS Core PBBN Access
(802.1ad) +--------------+ (802.1ah)
| | +---------+
+---------+ | | | |
| | +-----+ | | +---+ |
| +---+ | PE | +-+ | | |BCB| |
| |PCB|--| |-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
| | / +-----+/ \+-----+ | +---+|
+--+ |+---+ +---+ | PE | +-+ |PE w/| +---+ |IB-|| +--+
|CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BCB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | |PE1 PE2| | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
S-Tagged Type II (B-Tagged)
Figure 7: H-VPLS with Mixed PBB and PBBN Access: Regular PBN PE
Some assumptions made for this topology include:
- CE is directly connected to PBBN via C-Tagged Interface
- I-SID in PBBN access represents the same customer as S-VID in PBN
access
- There is 1:1 mapping between the I-SID and VPLS instance
- At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in
Figure 7), the PE only provides 1:1 mapping of S-VID to VPLS
Sajassi, et. al. Expires: May 2008 [Page 16]
Internet-Draft VPLS Interoperability with PBB Nov 2007
instance. S-VID bundling is not a viable option since it does not
correspond to anything in PBBN access.
- The PE connecting to PBBN (e.g. PE2 in Figure 7), supports IB-BEB
functionality and the I-Component is connected to the VPLS
Forwarder. One or more I-SIDs can be grouped into a B-VID in the
PBBN access.
- Since C-VID grouping in different PBBN access networks must be
consistent, it is assumed that same I-SID Domain is used across
these PBBN access networks.
Unlike the other topology, no I-SID mode or I-SID bundling mode is
supported in this case. This is primarily because the VPLS core
operates in the same manner as today. The PE with IB-BEB
functionality connecting to PBBN access performs the mapping of each
VPLS instance to an I-SID and one or more of these I-SIDs may be
mapped onto a B-VID.
3.3 H-VPLS with Mixed PBBN and MPLS Access
Similar to mixed PBBN and PBN access, as mentioned in Section 3.2,
it is foreseeable that service providers will want to interoperate
their existing MPLS access networks with PBBN access networks over
H-VPLS. Figure 7-1 below shows the high-level network topology.
+--------------+
| |
+---------+ | IP/MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| MPLS | |VPLS| |VPLS| | |--| CE |
+----+ | |---| PE1| | PE2|--| PBBN | +----+
+----+ | access | +----+ +----+ | 802.1ah | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 7-1: H-VPLS with Mixed MPLS and PBBN Access Networks
Referring to the Figure 7-1 above, two possibilities come into play
depending on whether the interworking is carried out at PE1 or PE2.
These are described in the following sub-Sections.
3.3.1 H-VPLS with Mixed PBBN & MPLS Access: PBB N-PE
In this case, the PE1 in Figure 7-1 is expected to be equipped with
PBB functionality. This case is similar to the case covered later in
Section 4.2, where an N-PE embodies PBB functionality. Though in
Section 4.2, the other PEs (e.g. PE2 in Figure 7-1) are also N-PE
with PBB functionality in an MPLS Access. The behavior at PE1 is the
same in both cases.
Sajassi, et. al. Expires: May 2008 [Page 17]
Internet-Draft VPLS Interoperability with PBB Nov 2007
For further details pertaining to this scenario, please refer
Section 4.2
3.3.2 H-VPLS with Mixed PBBN & MPLS Access: Regular MPLS PE
As shown in Figure 7-2, the operation of VPLS PE1 (connecting to the
MPLS access on the left) is no different from existing VPLS PEs. It
is the behavior of VPLS PE2 (connecting to the PBBN access on the
right) that is the focus of this section.
MPLS Access IP/MPLS Core PBBN Access
+--------------+ (802.1ah)
| | +---------+
+---------+ | | | |
| | +-----+ | | +---+ |
| +---+ |N-PE | +-+ | | |BCB| |
| | P |--| |-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
| | / +-----+/ \+-----+ | +---+|
+--+ |+---+ +---+ |N-PE | +-+ |PE w/| +---+ |IB-|| +--+
|CE|-||UPE|-| P |--| |-|P|-|IBBEB|-|BCB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | |PE1 PE2| | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
Spoke PW Type II (B-Tagged)
Figure 7-2: H-VPLS with Mixed MPLS and PBBN Access: Regular MPLS PE
Some assumptions made for this topology include:
- CE is directly connected to PBBN via C-Tagged Interface
- I-SID in PBBN access represents the same customer as the VPLS
instance in MPLS access
- There is 1:1 mapping between the I-SID and VPLS instance
- At C-Tagged Service Interface of U-PE connecting to CE, the U-PE
may provide a Port based, VLAN based or VLAN Bundle based service.
As such, there would be all:1, 1:1 or N:1 mapping of C-VID to
Spoke PW, respectively. The N-PE provides 1:1 mapping between a
Spoke PW and a VPLS instance.
- The PE connecting to PBBN (e.g. PE2 in Figure 7-2), supports IB-
BEB functionality and the I-Component is connected to the VPLS
Forwarder. One or more I-SIDs can be grouped into a B-VID in the
PBBN access.
- Since C-VID grouping in different PBBN access networks must be
consistent, it is assumed that same I-SID Domain is used across
these PBBN access networks.
I-SID mode and I-SID bundling mode are not applicable in this case.
This is because the VPLS instance operates in the same manner as
Sajassi, et. al. Expires: May 2008 [Page 18]
Internet-Draft VPLS Interoperability with PBB Nov 2007
today. The PE with IB-BEB functionality connecting to PBBN access
performs the mapping of each VPLS instance to an I-SID and one or
more of these I-SIDs may be mapped onto a B-VID going into the PBBN.
4. 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.
4.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.
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 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 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, if one
supports VPLS multicast data via MPLS P2MP tunnels, then this
drawback goes away.
Figure 8 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 BEB functions where it can
encapsulate/de-encapsulate customer MAC frames in provider B-MAC
addresses and perform I-SID translation if needed.
Sajassi, et. al. Expires: May 2008 [Page 19]
Internet-Draft VPLS Interoperability with PBB Nov 2007
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 8: 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:
- 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 B-VLAN. The U-PE can, then, either map a single I-SID into a
VPLS instance or it can map a B-VLAN onto a VPLS instance, according
to its configuration. Next, the encapsulated frames are sent over
the PW associated with that VPLS instance.
If the B-VID is used as the service delimiter, then 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 PW processing.
Sajassi, et. al. Expires: May 2008 [Page 20]
Internet-Draft VPLS Interoperability with PBB Nov 2007
4.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. I-SID to VPLS mapping is congruent on all U-PEs.
The PW type established between the U-PE and N-PE can be existing
Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type, defined
in [RFC4447] [RFC4448] with the corresponding B-VID rewrite or
translation performed at the various PE nodes. Alternatively, the
new PW type described in section 3.1.3 and 3.1.4 can be utilized,
without the need for I-SID translation.
4.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. 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 section 3.1.3 and 3.1.4)
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.
4.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 VPLS instance). These, in turn, are connected via a full-
mesh of PWs (per VPLS instance) traversing the IP/MPLS core.
The U-PE still provides the same type of services toward its
customers as before and they are:
Sajassi, et. al. Expires: May 2008 [Page 21]
Internet-Draft VPLS Interoperability with PBB Nov 2007
- 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.
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 are multiplexed within a
single B-VLAN. The N-PE can, then, either map a single I-SID into a
VPLS instance or it can map a 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 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.
4.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. I-SID to VPLS mapping is congruent on all N-PEs.
If B-VID is mapped to VPLS instance, existing Ethernet raw mode
(0x0005) or tagged mode (0x0004) PW type, defined in [RFC4447]
[RFC4448], can be used with the corresponding B-VID rewrite or
translation performed at the various N-PE nodes. This assumed that
I-SID to B-VID bundling is congruent on both N-PEs.
Alternatively, if I-SID is mapped to VPLS instance, the new PW type
described in section 3.1.3 and 3.1.4 can be utilized, without the
need for I-SID translation.
4.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. 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 section
3.1.3 and 3.1.4) 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.
Sajassi, et. al. Expires: May 2008 [Page 22]
Internet-Draft VPLS Interoperability with PBB Nov 2007
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.
5. Acknowledgments
TBD.
6. IANA Considerations
This document has no actions for IANA.
7. 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].
8. References
8.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
[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
8.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-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
Sajassi, et. al. Expires: May 2008 [Page 23]
Internet-Draft VPLS Interoperability with PBB Nov 2007
[VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-
03.txt, Work in progress, November 2007
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
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.
Sajassi, et. al. Expires: May 2008 [Page 24]
Internet-Draft VPLS Interoperability with PBB Nov 2007
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
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
Sajassi, et. al. Expires: May 2008 [Page 25]
Internet-Draft VPLS Interoperability with PBB Nov 2007
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
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
Email: sajassi@cisco.com
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Email: ssalam@cisco.com
Chris Metz
Cisco
170 West Tasman Drive
San Jose, CA 95134
Email: metz@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Sajassi, et. al. Expires: May 2008 [Page 26]
Internet-Draft VPLS Interoperability with PBB Nov 2007
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
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: May 2008 [Page 27]