RFC 7080
Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges
Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges 💖
- RFC: 7080
- Authors: A. Sajassi (Cisco), S. Salam (Cisco), N. Bitar (Verizon), F. Balus (Nuage Networks)
- Category: Informational 🧚
- ISSN: 2070-1721
- Date: December 2013
- Obsoletes / Updates: Neither. No such line appears in its header, so it doesn't replace or update any other RFC. 🫶
Abstract ✨
Okay bestie, the big idea: H-VPLS with Ethernet access networks ([RFC4762]) can get way more scalable if you bring Provider Backbone Bridge functionality into the VPLS access. PBB is standardized as IEEE 802.1ah-2008 and it's all about making MAC addresses and service instances scale better in Provider Ethernet networks. 🌸
This doc walks through different interop scenarios where PBB is used inside H-VPLS, whether the access is Ethernet or MPLS, so you get better scaling for the number of customer MAC addresses and service instances. It also covers the scenarios and mechanisms for dropping PBB into H-VPLS with existing Ethernet access, plus how all of those interop with each other. Last but not least, it talks through the migration mechanisms and scenarios for adding PBB to H-VPLS that already has MPLS access. It's giving full-stack glow-up energy 💅
Status of This Memo 🦋
This document is not an Internet Standards Track specification. It's published for informational purposes, so no, it's not a standard. 🙈
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you're curious about that. 🤓
Info on the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7080. 💜
Copyright Notice 🎀
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, bestie, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says. 🌈
Table of Contents ⭐
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Applicability ...................................................5
4. H-VPLS with Homogeneous PBBN Access .............................6
4.1. Service Interfaces and Interworking Options ................8
4.2. H-VPLS with PBBN Access: Type I Service Interface .........10
4.3. H-VPLS with PBBN Access: Type II Service Interface ........11
5. H-VPLS with Mixed PBBN Access and PBN Access ...................14
5.1. H-VPLS with Mixed PBBN and PBN Access: Modified PBN PE ....15
5.2. H-VPLS with Mixed PBBN and PBN Access: Regular PBN PE .....16
6. H-VPLS with MPLS Access ........................................17
6.1. H-VPLS with MPLS Access: PBB U-PE .........................17
6.2. H-VPLS with MPLS Access: PBB N-PE .........................19
7. H-VPLS with MPLS Access: PBB Migration Scenarios ...............21
7.1. 802.1ad Service Frames over VPLS Core .....................21
7.2. PBB Service Frames over VPLS Core .........................22
7.3. Mixed 802.1ad and PBB over VPLS Core ......................23
8. Acknowledgments ................................................24
9. Security Considerations ........................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................251. Introduction ✨
Okay so, the intro! H-VPLS with Ethernet access networks ([RFC4762]) can scale up a lot more when you bring Provider Backbone Bridge (PBB) functionality into the VPLS access. PBB is standardized as IEEE 802.1ah-2008 [802.1ah], which is an amendment to IEEE 802.1Q. Its whole purpose is to level up the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. 🦋
This doc describes interop scenarios where IEEE 802.1ah functionality gets used in H-VPLS with Ethernet or MPLS access networks. The goal is better scalability for the number of customer MAC addresses and the number of services. 💅
It also covers interop scenarios for deploying H-VPLS with Provider Backbone Bridging Ethernet access when other access types are already in the mix. That includes existing 802.1ad Ethernet and MPLS access, in either single or multiple service domains. Finally, it explores how an operator can gradually migrate an existing H-VPLS network over to Provider Backbone Bridging over VPLS. It's a whole glow-up journey 🌸
Here's the roadmap, so you know where everything lives:
- Section 2 is a quick terminology reference. 📖
- Section 3 covers the applicability of Provider Backbone Bridging interop with VPLS. 🎯
- Section 4 describes H-VPLS with a homogeneous Provider Backbone Bridge Access Network. 🧚
- Section 5 talks about H-VPLS with mixed 802.1ah/802.1ad access. 💜
- Section 6 focuses on Provider Backbone Bridging in H-VPLS with MPLS Access Network, including the PBB function on U-PE and N-PE variants. 🌈
- Section 7 describes the gradual migration scenarios from existing H-VPLS to Provider Backbone Bridging over H-VPLS. 🚀
2. Terminology 📖
Time for the glossary, bestie! Here's every term, no cap:
- 802.1ad: The IEEE spec for "QinQ" encapsulation and bridging of Ethernet frames. 🎀
- 802.1ah: The IEEE spec for "MAC tunneling" encapsulation and bridging of frames across a Provider Backbone Bridged Network (PBBN). 🌸
- B-BEB: A backbone edge bridge sitting at the edge of a PBBN. It has a B-component that handles bridging in the provider backbone based on B-MAC and B-TAG info. 🦋
- 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 info, just like an 802.1ad provider bridge bridges frames based on a Service VLAN (S-VLAN) identifier. ✨
- B-Component: The backbone component of a Provider Backbone edge bridge, as defined in [802.1ah]. 🧚
- BEB: A backbone edge bridge at the edge of a provider backbone bridged network. It can contain an I-component, a B-component, or both. 🫶
- B-MACs: Backbone MAC addresses, which are the outer MAC addresses of a PBB-encapsulated frame. 🌈
- B-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier info. Its format is the same as an 802.1ad S-TAG field. 💜
- B-Tagged Service Interface: The interface between a BEB and a BCB in a PBB network. Frames passing through it contain a B-TAG field. 🌸
- B-VID: The specific VLAN identifier carried inside a B-TAG. 🎀
- C-MACs: Customer MAC addresses, which are the inner MAC addresses of a PBB-encapsulated frame. 🦋
- H-VPLS: Hierarchical Virtual Private LAN Service. 👑
- I-component: A bridging component inside a backbone edge bridge that bridges in the customer space (customer MAC addresses, S-VLAN). 💅
- IB-BEB: A backbone edge bridge at the edge of a provider backbone bridged network. It has an I-component for bridging in the customer space (customer MAC addresses, S-VLAN IDs) and a B-component for bridging the provider's backbone space (B-MAC, B-TAG). ✨
- I-BEB: A backbone edge bridge at the edge of a provider backbone bridged network. It has an I-component for bridging in the customer space (customer MAC addresses, S-VLAN IDs). 🧚
- I-SID: The 24-bit service instance field carried inside the I-TAG. It 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: The interface defined between the I-component and the B-component inside an IB-BEB, or between two B-BEBs. Frames passing through it contain an I-TAG field. 💜
- N-PE: Network-facing Provider Edge. 🌸
- PBB: Provider Backbone Bridge. 🎀
- PBBN: Provider Backbone Bridged Network. 🦋
- PBN: Provider Bridged Network. A network that uses 802.1ad (QinQ) technology. 💅
- S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the Service VLAN (S-VLAN) identifier info. ✨
- S-Tagged Service Interface: The interface defined between the customer (CE) and the I-BEB or IB-BEB components. Frames passing through it contain an S-TAG field. 🧚
- S-VLAN: The specific Service VLAN identifier carried inside an S-TAG. 🫶
- U-PE: User-facing Provider Edge. 🌈
- VPLS: Virtual Private LAN Service. 💜
3. Applicability 🌸
Okay bestie, so [RFC4762] came up with a two-tier setup for VPLS 🦋 whose whole point is making pseudowire (PW) scalability better. The trick is cutting down how many PE devices need to be connected in a full-mesh, by hooking CE devices up through a lower-tier access network, and that access network then plugs into the top-tier core network ✨. [RFC4762] describes two kinds of H-VPLS topology: one with an MPLS access network, and one with an IEEE 802.1ad (QinQ) Ethernet access network 💅. In both, MAC learning and forwarding is based on customer MAC addresses (C-MACs), and that's a scalability problem because the more VPLS instances there are (and so the more C-MACs), the worse it gets 😭. Also, a set of PWs is kept up per customer service instance, so the number of PWs needed at N-PE devices is the number of customer service instances multiplied by the number of N-PE devices in the full-mesh set. As the number of customer service instances grows, that can cause scalability issues (for PW manageability and troubleshooting) 🙈.
H-VPLS with an 802.1ad Ethernet access network has one more scalability problem, and it's about how many service instances the access network can support, as [RFC4762] describes 💀. The number of provider VLANs (S-VLANs) is capped at 4094, and each S-VLAN represents one service instance in an 802.1ad network, so the maximum number of service instances that can be supported is 4094. These issues are highlighted in [RFC6246] 🔥.
This document explains how IEEE 802.1ah (aka Provider Backbone Bridges) can be integrated with H-VPLS to tackle these scalability issues 🧚. With H-VPLS over 802.1ah Ethernet access, you get better scalability in terms of the number of service instances and the number of C-MACs in the Ethernet access network and the VPLS core network, and also the number of PWs in the VPLS core network 🎀. With H-VPLS over MPLS access, Provider Backbone Bridging functionality can be used at the U-PE or N-PE, which cuts down the number of customer MAC addresses and the number of PWs in the VPLS core network 💜.
The interoperability scenarios in this document fall into two categories:
- Scenarios where Provider Backbone Bridging seamlessly works with current VPLS implementations (e.g., Section 4.2) ✨
- Scenarios where VPLS-PE implementations need to be upgraded in order to work with Provider Backbone Bridging (e.g., Sections 4.3 and 5.1) 🫶
4. H-VPLS with Homogeneous PBBN Access 🦋
Okay, this part is my favourite 😭 PBBN access gives H-VPLS PE nodes way better MAC-address-table scalability. The reason is the MAC tunneling encapsulation scheme of PBB, which only exposes the provider's own MAC addresses to PE nodes (the B-MACs of the provider's PBB-capable devices in the access network). Compare that with conventional H-VPLS over MPLS or 802.1ad access, where customers' MAC addresses are visible 🙈.
PBBN access also gives you service-instance scalability compared with H-VPLS over 802.1Q/802.1ad access networks 🔥. The new 24-bit service identifier (I-SID) used in PBB encapsulation allows up to 16M services per PBB access network, whereas an 802.1Q/802.1ad access network only gets 4094 services 💅.
Another big win with PBBN access is the clear separation between the service layer (represented by I-SID) and the network layer (represented by B-VLAN) 👑. B-VLANs split a PBB access network into different broadcast domains and possibly unique spanning-tree topologies, and each domain can carry multiple services (i.e., I-SIDs). In 802.1ad access networks, the network and service layers are the same thing, both represented by S-VLAN 🌈.
This separation means the provider can manage and optimise the PBB access network topology independently of how many service instances are supported ✨.
In this section and the ones that follow, we look at different flavours of H-VPLS with PBBN access. This section covers H-VPLS deployed with homogeneous PBBN access. Section 5 covers the case where at least one of the access networks has PBN access (QinQ/802.1ad) while the others are PBBNs 🍓.
On a macro scale, a network that uses H-VPLS with PBBN access looks like 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
In the context of PBBN and H-VPLS interoperability, we can define "I-SID Domain" and "B-VLAN Domain" like this 🧚:
- "I-SID Domain" is a network administrative boundary where all the PBB BEBs and VPLS-PE devices use the same I-SID space. In other words, the same administration does the I-SID assignment. That effectively means a given service instance has the same I-SID designation on every device inside an I-SID Domain 💖.
- "B-VLAN Domain" is a network administrative boundary where all the PBB BEBs and VPLS-PE devices use consistent I-SID to B-VLAN bundling. For example, the grouping of I-SIDs into B-VLANs is the same across that domain. The two B-VLANs in two PBBNs that represent the same group of I-SIDs don't have to use the same B-VID value. In practice, though, they often do, because once the I-SID grouping is identical in both PBBNs, it's super easy to make the corresponding B-VIDs identical too 🎀.
So, three kinds of "Service Domains" are defined like this 👑:
- Tightly Coupled Service Domain means the PBBN accesses belong to the same I-SID Domain and the same B-VLAN Domain. The network control protocols (e.g., xSTP) still run independently in each PBBN access 💜.
- Loosely Coupled Service Domain means the PBBN accesses belong to the same I-SID Domain, but each PBBN access keeps its own independent B-VLAN Domain. Again, the network control protocols (e.g., xSTP) run independently in each PBBN access 🌈.
- Different Service Domain is where each PBBN access keeps its own independent I-SID Domain and B-VLAN Domain, with independent network control protocols (e.g., xSTP) in each PBBN access 🙈.
Generally speaking, correct service connectivity across networks in a Tightly Coupled Service Domain can be achieved with B-VID mapping between the networks (often even without B-VID translation) ✨. Correct service connectivity across networks in a Loosely Coupled Service Domain needs I-SID to B-VID remapping (i.e., unbundling and rebundling of I-SIDs into B-VIDs) 🍓. And service connectivity across networks in Different Service Domains needs both I-SID translation and I-SID to B-VID remapping 😭.
4.1. Service Interfaces and Interworking Options 🧚
Customer devices will connect to PBBN edge bridges using existing Ethernet interfaces, including IEEE 802.1Q and IEEE 802.1ad 💅. At the PBBN edge, C-MAC frames are encapsulated in a PBB header that includes the service provider's source and destination MAC addresses (B-MACs), and then they're bridged up to the VPLS-PE. The PBB-encapsulated C-MAC frame is then injected into the VPLS backbone network and delivered to the remote VPLS-PE node(s), and it's 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 on to the customer domain 🦋.
Interoperating between PBBN devices and VPLS-PE nodes can leverage the BEB functions already defined in [802.1ah]. When I-SID visibility is required at the VPLS-PE nodes, a new service interface based on the I-SID tag will need to be defined 🌸.
Also, by mapping a bridge domain (e.g., B-VLAN) to a VPLS instance, and bundling multiple end-customer service instances (represented by I-SID) over that same bridge domain, service providers can significantly reduce the number of full-mesh PWs required in the core 👑. In this case, I-SID visibility isn't required on the VPLS-PE, and the I-SID serves as the means of multiplexing/de-multiplexing individual service instances in the PBBN over a bundle (e.g., B-VLAN) 💖.
When I-SID visibility is expected across the service interface at the VPLS-PE, the VPLS-PE can be considered to offer service-level interworking between PBBN access and the IP/MPLS core ✨. Similarly, when the PE isn't expected to see the I-SID at the service interface, the VPLS-PE can be considered to offer network-level interworking between PBBN access and the MPLS core 🎀.
A VPLS-PE is always part of the IP/MPLS core, and it 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 two types of service interface 🔥:
- Type I: B-Tagged Service Interface with B-VID as Service Delimiter 💜
The PE connects to a Backbone Core Bridge (BCB) in the PBBN access. The handoff between the BCB and the PE is B-Tagged PBB-encapsulated frames. The PE is transparent to PBB encapsulations and treats these frames as 802.1ad frames, since the B-VID EtherType is the same as the S-VID EtherType. The PE doesn't need to support PBB functionality. This corresponds to the conventional VPLS-PE tagged service interface 🌈. When using the Type I service interface, the PE needs to support either raw mode or tagged mode Ethernet PW. The Type I service interface is described in detail in Section 4.2 🍓.
- Type II: I-Tagged Service Interface with I-SID as Service Delimiter 🌸
The PE connects to a B-BEB (backbone edge bridge with B-component) in the PBBN access. The PE itself also supports the B-BEB functionality of [802.1ah]. The handoff between the B-BEB in the PBBN access and the PE is an I-Tagged PBB-encapsulated frame. With the Type II service interface, the PE supports the existing raw mode and tagged mode PW types. The Type II service interface is described in detail in Section 4.3 🧚.
4.2. H-VPLS with PBBN Access: Type I Service Interface ✨
okay so this one is a B-Tagged service interface, and the service delimiter on the VPLS-PE is the B-VID 💅 it does NOT need any new functionality on the VPLS-PE, no cap. The PE is always part of the IP/MPLS core 🌸 but it can also be part of the PBBN access (like the VPLS-PE on the right side of Figure 2) by joining the network control protocols (e.g., xSTP) of that 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 and Type I Service InterfaceThe Type I service interface is applicable to networks with Tightly Coupled Service Domains 💜, where both I-SID Domains and B-VLAN Domains are the same across all PBBN access networks.
The BCB and the VPLS-PE exchange PBB-encapsulated frames that include source and destination B-MACs, a B-VID, and an I-SID 📦 From the VPLS-PE's point of view, the service delimiter is the B-VID. Honestly this interface works exactly like a current 802.1Q/ad interface into a VPLS-PE does today 🎀 So with Type I, the VPLS-PE can be considered to provide network-level interworking between PBBN and MPLS domains, since the VPLS-PE has no visibility of I-SIDs 👀
The main perk of this service interface, compared to the other types, is that it lets the service provider save on the number of full-mesh PWs in the core 🤑 That's mostly because multiple service instances (I-SIDs) get bundled over a single full-mesh PW for each bridge domain (e.g., B-VID), instead of needing a dedicated full-mesh PW per service instance. Another perk is MAC address scalability in the core, since the core is not exposed to C-MACs 🧚
The downside is the comparably excessive replication in the core 😭 Since a group of service instances shares the same full mesh of PWs, an unknown unicast, multicast, or broadcast on a single service instance results in a flood over the core. This can be mitigated with flood containment per I-SID (B-MAC multicast pruning) 🛟
Three different modes of operation are supported by the Type I service interface:
- Port 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] and [RFC4448], are supported.
- VLAN 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] and [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] and [RFC4448], are supported.
For the VLAN mode, it's also possible to use an Ethernet tagged mode (0x0004) PW, as defined in [RFC4447] and [RFC4448], for interoperability with equipment that doesn't support raw mode 🫶 The use of raw mode is recommended to be the default though ✨
4.3. H-VPLS with PBBN Access: Type II Service Interface 🦋
This is an I-Tagged service interface with the I-SID as the service delimiter on the VPLS-PE. It requires the VPLS-PE to include the B-component of the PBB BEB for I-SID processing, in addition to the capability to map an I-SID Bundle to a VPLS instance 🔥 As shown in Figure 3, the PE is always part of the IP/MPLS core and connects to one or more B-BEBs in the PBBN access.
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 II Type II
Figure 3: H-VPLS with PBBN Access and Type II Service InterfaceThe Type II service interface is applicable to Loosely Coupled Service Domains and Different Service Domains 🌈 B-VLAN Domains can be independent, and the B-VID is always locally significant in each PBBN access: it does not need to be transported over the IP/MPLS core. Given all that, it should be pretty apparent that Type II is applicable to Tightly Coupled Service Domains as well 💅
By definition, the B-BEB connecting to the VPLS-PE removes any B-VLAN tags for frames exiting the PBBN access 🧹 The B-BEB and the VPLS-PE exchange PBB-encapsulated frames that include source and destination B-MACs and an I-SID. From the VPLS-PE's perspective, the service delimiter is the I-SID. Since the PE has visibility of I-SIDs, the PE provides service-level interworking between the PBBN access and the IP/MPLS core 👑
The Type II service interface may operate in 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 bridge domain (e.g., B-VID), and the VPLS instance is then associated with this bridge domain 🗺️ With Loosely Coupled Service Domains, no I-SID translation needs to be performed. Type II also supports Different Service Domains in this mode, since the B-BEB link in the PE that connects to the local PBBN can translate the PBBN-specific I-SID to a local I-SID within the IP/MPLS core, which may then be translated to the other PBBN-specific I-SID on the egress PE. Such translation can also happen in the B-BEB of the PBBN access 🔁 Existing PW signaling and Ethernet raw mode (0x0005), defined in [RFC4447] and [RFC4448], are supported. It's also possible to use a tagged mode (0x0004) PW for interoperability with equipment that doesn't support raw mode 🎀
The Type II service interface gives operators the flexibility to trade off PW state for multicast flooding containment, since a full mesh of PWs can be set up:
- a. per I-SID,
- b. per group of I-SIDs, or
- c. for all I-SIDs.
For (a) and (b), the advantage of Type II over Type I is that it can reduce replication in the core without needing a mechanism that provides flood containment per I-SID (B-MAC multicast pruning) 🙌 This is mainly due to the increased segregation of service instances over disjoint full meshes of PWs. For (c), both Type II and Type I service interfaces are at par with regard to flood containment.
For (a) and (b), the disadvantage compared to Type I is that it may require a larger number of full-mesh PWs in the core 😬 For (c), both Type II and Type I are at par with regard to PW state. However, in all three scenarios, the number of full-mesh PWs can still be fewer than the number required by H-VPLS without PBBN access, since an I-SID can multiplex many S-VLANs 💖
It's expected that this interface type will be used for customers with significant multicast traffic (but without multicast pruning capability in the VPLS-PE), so that a separate VPLS instance is set up per group of customers with similar geographic locality (per I-SID group) 🌍
Note: Port mode is not called out in the Type II service interface, since it requires the mapping of I-SIDs to be identical on different I-Tagged interfaces across the VPLS network. If this is indeed the case, Port mode defined in the Type I service interface (Section 4.2) can be used. 🙈
5. H-VPLS with Mixed PBBN Access and PBN Access 🌸
It's foreseeable that service providers will want to interoperate their existing Provider Bridged Networks (PBNs) with Provider Backbone Bridged Networks (PBBNs) over H-VPLS 🤝 Figure 4 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 4: H-VPLS with Mixed PBN and PBBN Access NetworksReferring to Figure 4 above, two possibilities come into play depending on whether the interworking is carried out at PE1 or PE2 🤔 These are described in the following subsections 🦋
5.1. H-VPLS with Mixed PBBN and PBN Access: Modified PBN PE 💅
okay so in Figure 5, VPLS-PE2 (the one hooked up to the PBBN access on the right) is doing basically the same thing as in Section 4. Type II service interface, from that section, totally applies here 🫶 The main character of this part is VPLS-PE1 (the one connecting to the PBN access on the left) 👑
PBN Access IP/MPLS Core PBBN Access
(802.1ad) +--------------+ (802.1ah)
| | +---------+
+---------+ | | | |
| | +-----+ | | +---+ |
| +---+ |PE w/| +-+ | | |BCB| |
| |PCB|--|IBBEB|-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
| | / +-----+/ +-----+ +---+ +---+|
+--+ |+---+ +---+ |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
|CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | |PE1 PE2| | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
S-Tagged Type II (I-Tagged)Figure 5: H-VPLS with Mixed PBN and PBBN Access: Modified PBN PE
Some assumptions made for this topology include:
- CE is directly connected to PBBN via S-Tagged or port-based 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 5), 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.
- PE1 participates in the local I-SID Domain of the IP/MPLS core so the model accommodates for the rest of the PBB network any of the three domain types described in Section 4 -- Tightly Coupled, Loosely Coupled, and Different Service Domains.
- For ease of provisioning in these disparate access networks, it is recommended to use the same I-SID Domain among the PBBN access networks and the PEs with IB-BEB functionality (those connecting to PBN).
This topology runs in I-SID Bundling Mode 🎀 At a PE connecting to PBN access, each S-VID gets mapped to an I-SID, and then a group of I-SIDs gets mapped to a VPLS instance. Over on a PE connecting to PBBN access, each group of I-SIDs gets mapped to a VPLS instance. Just like Type II service interface, no I-SID translation happens for the I-SID bundling case. Existing PW signaling and Ethernet raw mode (0x0005) PW type, defined in [RFC4447] and [RFC4448], are supported ✨ It's also possible to use tagged mode (0x0004) PW for backward compatibility.
5.2. H-VPLS with Mixed PBBN and PBN Access: Regular PBN PE 🌸
okay now in Figure 6, VPLS-PE1 (connecting to the PBN access on the left) is no different from existing VPLS-PEs 🙈 The one doing the interesting stuff is VPLS-PE2 (connecting to the PBBN access on the right) 💜
PBN Access IP/MPLS Core PBBN Access
(802.1ad) +--------------+ (802.1ah)
| | +---------+
+---------+ | | | |
| | +-----+ | | +---+ |
| +---+ | PE | +-+ | | |BCB| |
| |PCB|--| |-|P| | | +---+ |
| +---+ /+-----+ +-+ | | / | |
| | / +-----+/ +-----+ +---+ +---+|
+--+ |+---+ +---+ | PE | +-+ |PE w/| |B- | |IB-|| +--+
|CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BEB| |BEB|--|CE|
+--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
| | | |PE1 PE2| | | |
+---------+ | | | | +---------+
| +-------------+ |
| |
S-Tagged Type II (I-Tagged)Figure 6: H-VPLS with Mixed PBN and PBBN Access: Regular PBN PE
Some assumptions made for this topology include:
- The CE is directly connected to the PBBN access via an S-Tagged or port-based Interface.
- The I-SID in the PBBN access represents the same customer as the S-VID in the PBN access.
- There is 1:1 mapping between the I-SID and the VPLS instance.
- At the S-Tagged service interface of the PE connecting to PBN (e.g., PE1 in Figure 6), the PE only provides 1:1 mapping of S-VID to the VPLS instance. S-VID bundling is not a viable option since it does not correspond to anything in the PBBN access.
- The PE connecting to the PBBN access (e.g., PE2 in Figure 6), supports IB-BEB functionality and the I-component is connected to the VPLS Forwarder (i.e., the I-component faces the IP/MPLS core whereas the B-component faces the PBBN access network). 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 previous case, I-SID bundling mode is not supported in this case 🙅♀️ This is mainly because the VPLS core works the same way it does today. The PE with IB-BEB functionality connecting to PBBN access maps each VPLS instance to an I-SID, and one or more of these I-SIDs may be mapped onto a B-VID within the PBBN access network 🍓
6. H-VPLS with MPLS Access ✨
okay this section is all about H-VPLS with MPLS access networks 🦋 Putting PBB functionality into the VPLS-PE for these access networks boosts scalability, in terms of how many MAC addresses and service instances the network can handle. You can embed PBB functionality in either the U-PE or the N-PE, and both cases get their own subsection below 💖
6.1. H-VPLS with MPLS Access: PBB U-PE 🧚
so the whole reason to put PBB function at the U-PE is scalability, aka handling more MAC addresses and service instances 🙌
In current H-VPLS, the N-PE has to learn the customer MAC addresses (C-MACs) of every VPLS instance it takes part in. That can easily add up to hundreds of thousands or even millions of C-MACs at the N-PE 😭 When the U-PE does PBB encapsulation, the N-PE only needs to learn the MAC addresses of the U-PEs, which is a huge reduction 🔥 Also, when PBB encapsulation is used, lots of I-SIDs get multiplexed inside a single bridge domain (e.g., B-VLAN). If the VPLS instance is set up per B-VLAN, you can also cut the number of full-mesh PWs by a lot 🌈 Now, the catch: that reduction in full-mesh PWs comes with potentially more replication over the full mesh. Customer multicast and/or broadcast frames are basically broadcast within the B-VLAN, and this may cause extra frame replication because the full-mesh PWs for a B-VLAN are most likely bigger than the full-mesh PWs for a single I-SID. The good news is that flood containment per I-SID (B-MAC multicast pruning) can fix this drawback, so multicast traffic gets replicated efficiently for each customer (i.e., for each I-SID) 💅
Figure 7 below shows the H-VPLS with MPLS access scenario. Customer networks or hosts (CE) connect into the U-PE nodes using standard Ethernet interfaces [802.1D-REV], [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). Those N-PEs are then connected via a full mesh of PWs (per VPLS instance) traversing the IP/MPLS core. The U-PE has PBB Backbone Edge Bridge (BEB) functions, so it can encapsulate/decapsulate customer MAC frames in provider B-MACs 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 7: H-VPLS with MPLS Access Network and PBB U-PE
The U-PE still gives customers the same types of services as before, which 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)
With PBB function added, 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 🎀 Lots of I-SIDs get multiplexed inside a single bridge domain (e.g., B-VLAN). The U-PE can then map a bridge domain onto a VPLS instance, and the encapsulated frames get sent over the PW tied to that VPLS instance. The whole Ethernet bridging operation over the VPLS network is done as defined in [RFC4762]. In other words, MAC forwarding is based on the B-MAC address space, and the service delimiter is based on VLAN ID, which is B-VID in this case. There's no need to inspect or deal with I-SID values in the VPLS N-PEs 🙌
When there are PBB U-PEs in a single I-SID Domain, I-SID assignment is done globally across all MPLS access networks, so there's no need for I-SID translation 🧚 This scenario supports I-SID bundling mode, and it is assumed that the mapping of the I-SIDs to the bridge domain (e.g., B-VLAN) is consistent across all the participating PE devices. With I-SID bundling mode, a bridge domain (e.g., B-VLAN) is mapped to a VPLS instance, and an existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type is used, as defined in [RFC4447] and [RFC4448].
I-SID mode can be thought of as a degenerate case of I-SID bundling where a single bridge domain is used per I-SID. However, that bumps up the number of bridge domains and PWs in the PEs 😵 PBB flood containment (B-MAC multicast pruning) per I-SID can be used together with I-SID bundling mode to limit the scope of flooding per I-SID, which removes the need for I-SID mode ✨
6.2. H-VPLS with MPLS Access: PBB N-PE ✨
okay so this is where the PBB function gets tucked into the N-PE 🎀 the whole point is to make H-VPLS networks more scalable, so they can handle more MAC addresses and more service instances 💅🦋
Customer networks or hosts (CE) plug into the U-PE nodes using standard Ethernet interfaces [802.1D-REV], [802.1Q], or [802.1ad]. The U-PE connects upstream to one or more VPLS N-PE nodes by MPLS PWs (per customer). Then those N-PEs are linked by a full mesh of PWs (per customer or group of customers) that runs across the IP/MPLS core 🌸
The U-PE still gives its customers the same kinds of services it always did, which 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)
The spoke PW from the U-PE to the N-PE is not service multiplexed, because there's no PBB functionality on the U-PE. So it's one service per PW, simple as that 🫶
PBB PBB
BEB +----------+ BEB
| | | |
+-----------+ | | IP | | +-----------+
| MPLS | V | MPLS | V | MPLS |
| Access +----+ | Core | +----+ Access |
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| | | | | |
+-----------+ +----------+ +-----------+Figure 8: H-VPLS with MPLS Access Network and PBB N-PE 🍓
Now the fun part 😭 By adding a 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. Lots of I-SIDs can be multiplexed inside one bridge domain (e.g., B-VLAN) 🧚 The N-PE can then either map a single I-SID into a VPLS instance, or map a bridge domain (e.g., B-VLAN) onto a VPLS instance, depending on how it's configured. After that, the encapsulated frames get sent over the set of PWs tied to that VPLS instance 💜
When you've got PBB N-PEs in a single I-SID Domain, I-SID assignment happens globally across all MPLS access networks. So there's no need for I-SID translation, which is so clean 🙈 This scenario supports I-SID bundling mode, and it's assumed that the mapping of the I-SIDs to the bridge domain (e.g., B-VLAN) is consistent across all the participating PE devices. With I-SID bundling mode, a bridge domain (e.g., B-VLAN) is mapped to a VPLS instance, and an existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type, as defined in [RFC4447] and [RFC4448], can be used 🌈
I-SID mode can be thought of as a degenerate case of I-SID bundling, where a single bridge domain is used per I-SID. Honestly though, that means more bridge domains and PWs on the PE, which is a lot 💀 PBB flood containment (B-MAC multicast pruning) per I-SID can be used together with I-SID bundling mode to limit the scope of flooding per I-SID. That removes the need for I-SID mode, periodt ✨
7. H-VPLS with MPLS Access: PBB Migration Scenarios 👑
Okay real talk, operators and service providers that already run H-VPLS with either MPLS or Ethernet are NOT going to migrate to PBB overnight, because the cost implications are obvious 😭 So it's super important to outline migration strategies that let operators protect their existing investments while still getting the scalability perks of PBB 🦋
In the following subsections, we look at three different migration scenarios that let a mix of existing H-VPLS access networks coexist with newer PBB-based access networks 🌸 The scenarios differ in whether or not the Ethernet service frames crossing the VPLS core are PBB-encapsulated. The first scenario, in Section 7.1, only passes frames that are not PBB-encapsulated over the core. The second scenario, in Section 7.2, says to pass only PBB-encapsulated frames over the core. And the final scenario, in Section 7.3, shows a core that supports a mix of PBB-encapsulated and non-PBB-encapsulated frames 💅 The advantages and disadvantages of each one get covered in their own sections.
7.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-MACs. In other words, Ethernet frames traversing the VPLS core (within PWs) would use the 802.1ad frame format, just like current VPLS does. So the N-PEs in existing access networks don't need any modification 🫶 For new MPLS access networks that have PBB functions on the U-PE, the corresponding N-PE has to incorporate built-in IB-BEB functions, so it can terminate the PBB encapsulation before the frames enter the core. A key point here: both the U-PE and N-PE nodes implement PBB IB-BEB functionality, but the U-PE has its I-component facing the customer (CE) and its B-component facing the core, whereas the N-PE has its I-component facing the core and its B-component facing the customer (i.e., access network) 🔥
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 9: Migration with 802.1ad Service Frames over VPLS Core ✨
The big win with this approach is that it requires no change to existing access networks or existing VPLS N-PEs 🍓 The main downside is that those N-PEs won't get to use PBB's advantages in terms of MAC address and PW scalability 🥲 It's worth noting that this migration scenario is an optimal choice for an H-VPLS deployment with a single PBB-capable access network. When there are multiple PBB-capable access networks, the scenario in Section 7.3 is preferred, because it gives a more scalable and optimal interconnect between the PBB-capable networks 🌈
7.2. PBB Service Frames over VPLS Core 💜
This scenario requires that the VPLS N-PE connecting to existing MPLS access networks gets upgraded to incorporate IB-BEB functions. All Ethernet service frames passing over the VPLS core would be PBB-encapsulated. PBB over MPLS access networks wouldn't need any special requirements beyond what's captured in Section 6 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 10: Migration with PBB Service Frames over VPLS Core 🦋
The main advantage here is that it allows better scalability of the VPLS N-PEs in terms of MAC address and pseudowire counts 😭 The disadvantage is that it requires upgrading the VPLS N-PEs of all existing MPLS access networks 💀
7.3. Mixed 802.1ad and PBB over VPLS Core 🌸
In this scenario, existing access networks are left unchanged, and they exchange Ethernet frames in 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 an existing access network (non-PBB-capable) and a new access network (PBB-based), the VPLS N-PE of the latter network employs IB-BEB functionality. It decapsulates the PBB header from frames going outbound to the core, and encapsulates the PBB header for frames coming inbound from the core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet service frames gets exchanged over the VPLS core 🫶
This mode of operation needs new functionality on the VPLS N-PE of the PBB-capable access network, so 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. Basically, the PE would have to incorporate B-BEB as well as IB-BEB functions 👑
A given PE needs to be aware of the capability of its remote peer, so it can work out whether it connects to the right PW Forwarder. This can be achieved either via static configuration or by extending the VPLS control plane (BGP-based auto-discovery and LDP Signaling) discussed in [RFC6074]. The latter approach and the details of the extensions required are out of scope for this document 🔮
PBB
B-BEB PBB
+----------+ IB-BEB IB-BEB
| | | |
+-----------+ | IP | | +-----------+ |
| MPLS | | MPLS | V | MPLS | |
| Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | |N-PE| |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| (Existing)| | | | (New) |
+-----------+ +----------+ +-----------+Figure 11: Migration with Mixed 802.1ad and 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 functionality, with the I-component facing the customer (CE) and the B-component facing 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). On top of that, the N-PE implements standalone B-BEB functionality 🍓
This scenario combines the advantages of both previous scenarios without any of their shortcomings, namely: it doesn't require any changes to existing access networks, and it lets the N-PE leverage the scalability benefits of 802.1ah for PBBN to PBBN connectivity. Yay! ✨ The downside is that this option requires new functionality on the N-PE of the PBBN access. A second downside is that this option requires two P2MP LSPs to be set up at the ingress N-PE: one for the N-PEs that support PBB encapsulation, and another one for the N-PEs that don't support PBB encapsulation 🥹
8. Acknowledgments 🫶
The authors would like to thank Chris Metz and Dinesh Mohan for their valuable feedback and contributions 💖
9. Security Considerations 🔒
okay bestie, the security part is short and sweet 🫶 this doc doesn't add any new security stuff of its own. Everything that applies here is the same as for VPLS/H-VPLS in general, and those security considerations are already covered in [RFC4111] and [RFC4762]. so go read those if you want the full picture 🔐✨
10. References ✨
10.1. Normative References
- [802.1ad] "IEEE Standard for and metropolitan area networks -- Virtual Bridged Local Area Networks -- Provider Bridges", 802.1ad-2005, August 2005. 🌸
- [802.1ah] "IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges", IEEE Std. 802.1ah-2008, August 2009. 💜
- [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 🎀
- [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. 🦋
- [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. 👑
- [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 🍓
10.2. Informative References
- [802.1Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q(tm), 2012 Edition, October 2012. 🧚
- [802.1D-REV] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges", IEEE Std. 802.1D, June 2004. 💅
- [RFC6246] Sajassi, A., Ed., Brockners, F., Mohan, D., Ed., and Y. Serbest, "Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges", RFC 6246, June 2011. ⭐
- [RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 🔥
Authors' Addresses 🌈
Ali Sajassi Cisco EMail: sajassi@cisco.com
Samer Salam Cisco EMail: ssalam@cisco.com
Nabil Bitar Verizon Communications EMail : nabil.n.bitar@verizon.com
Florin Balus Nuage Networks EMail: florin.balus@nuagenetworks.net
📦 where this page comes from
- ietf: rfc7080 2013-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms