diff options
Diffstat (limited to 'doc/rfc/rfc7080.txt')
| -rw-r--r-- | doc/rfc/rfc7080.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7080.txt b/doc/rfc/rfc7080.txt new file mode 100644 index 0000000..c134911 --- /dev/null +++ b/doc/rfc/rfc7080.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Sajassi +Request for Comments: 7080 S. Salam +Category: Informational Cisco +ISSN: 2070-1721 N. Bitar + Verizon + F. Balus + Nuage Networks + December 2013 + + + Virtual Private LAN Service (VPLS) Interoperability + with Provider Backbone Bridges + +Abstract + + The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) + with Ethernet access networks (RFC 4762) can be improved by + incorporating Provider Backbone Bridge functionality in the VPLS + access. Provider Backbone Bridging has been standardized as IEEE + 802.1ah-2008. It aims to improve the scalability of Media Access + Control (MAC) addresses and service instances in Provider Ethernet + networks. This document describes different interoperability + scenarios where Provider Backbone Bridge functionality is used in + H-VPLS with Ethernet or MPLS access network to attain better + scalability in terms of number of customer MAC addresses and number + of service instances. The document also describes the scenarios and + the mechanisms for incorporating Provider Backbone Bridge + functionality within H-VPLS with existing Ethernet access and + interoperability among them. Furthermore, the document discusses the + migration mechanisms and scenarios by which Provider Backbone Bridge + functionality can be incorporated into H-VPLS with existing MPLS + access. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7080. + + + +Sajassi, et al. Informational [Page 1] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 ...................................25 + + + + + + + + + + + + +Sajassi, et al. Informational [Page 2] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +1. Introduction + + The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) + with Ethernet access networks [RFC4762] can be improved by + incorporating Provider Backbone Bridge (PBB) functionality in the + VPLS access. Provider Backbone Bridging has been standardized as + IEEE 802.1ah-2008 [802.1ah], which is an amendment to IEEE 802.1Q to + improve the scalability of Media Access Control (MAC) addresses and + service instances in Provider Ethernet networks. This document + describes interoperability scenarios where IEEE 802.1ah functionality + is used in H-VPLS with Ethernet or MPLS access network to attain + better scalability in terms of the number of customer MAC addresses + and the number of services. + + This document also covers the interoperability scenarios for + deploying H-VPLS with Provider Backbone Bridging Ethernet access when + other types of access networks are deployed, including existing + 802.1ad Ethernet and MPLS access in either single or multiple service + domains. Furthermore, the document explores the scenarios by which + an operator can gradually migrate an existing H-VPLS network to + Provider Backbone Bridging over VPLS. + + Section 2 gives a quick terminology reference and Section 3 + highlights the applicability of Provider Backbone Bridging + interoperation with VPLS. Section 4 describes H-VPLS with + homogeneous Provider Backbone Bridge Access Network. Section 5 + discusses H-VPLS with mixed 802.1ah/802.1ad access. Section 6 + focuses on Provider Backbone Bridging in H-VPLS with MPLS Access + Network including PBB function on U-PE and on N-PE variants. + Finally, Section 7 describes gradual migration scenarios from + existing H-VPLS to Provider Backbone Bridging over H-VPLS. + +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 + (PBBN). + + B-BEB: A backbone edge bridge positioned at the edge of a PBBN. 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. + + + + +Sajassi, et al. Informational [Page 3] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + 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 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 positioned at the edge of a provider + backbone bridged network. It can contain an I-component, + B-component, or both. + + B-MACs: Backbone MAC addresses -- 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 information. The + format of the B-TAG field is the same as that of an 802.1ad S-TAG + field. + + B-Tagged Service Interface: This is the interface between a BEB and + BCB in a PBB network. Frames passed through this interface + contain a B-TAG field. + + B-VID: This is the specific VLAN identifier carried inside a B-TAG + + C-MACs: Customer MAC addresses are the inner MAC addresses of a PBB- + encapsulated frame. + + H-VPLS: Hierarchical Virtual Private LAN Service. + + 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, S-VLAN IDs) and a + B-component for bridging the provider's backbone space (B-MAC, + B-TAG). + + I-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, S-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". + + + +Sajassi, et al. Informational [Page 4] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + 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 is the interface defined between the + I-component and B-component inside an IB-BEB or between two + B-BEBs. Frames passed through this interface 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 employs 802.1ad (QinQ) + technology. + + S-TAG: A field defined in the 802.1ad QinQ encapsulation header that + conveys the Service VLAN (S-VLAN) identifier information. + + 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 + + U-PE: User-facing Provider Edge + + VPLS: Virtual Private LAN Service + +3. Applicability + + [RFC4762] describes a two-tier hierarchical solution for VPLS for the + purpose of improved pseudowire (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 an MPLS access network and another with an IEEE 802.1ad (QinQ) + Ethernet access network. In both types of H-VPLS, the learning and + forwarding of MAC addresses is based on customer MAC addresses + (C-MACs), which poses scalability issues as the number of VPLS + instances (and thus C-MACs) increases. Furthermore, since a set of + PWs is maintained on a per customer service instance basis, the + number of PWs required 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 + + + +Sajassi, et al. Informational [Page 5] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + (in terms of PW manageability and troubleshooting) as the number of + customer service instances grows. + + In addition to the above, H-VPLS with an 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 4094 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 4094. These issues are highlighted in [RFC6246]. + + This document describes how IEEE 802.1ah (aka Provider Backbone + Bridges) can be integrated with H-VPLS to address these scalability + issues. In the case of H-VPLS with 802.1ah Ethernet access, the + solution results in better scalability in terms of both number of + service instances and number of C-MACs in the Ethernet access network + and the VPLS core network, as well as number of PWs in VPLS core + network. And in the case of H-VPLS with MPLS access, Provider + Backbone Bridging functionality can be used at the U-PE or N-PE, + which results in reduction of customer MAC addresses and the number + of PWs in the VPLS core network. + + The interoperability scenarios depicted in this document fall into + the following two categories: + + - Scenarios in which Provider Backbone Bridging seamlessly works + with current VPLS implementations (e.g., Section 4.2). + + - Scenarios in which 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 + + 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 the 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 4094 + services per 802.1Q/802.1ad access network. + + + + + +Sajassi, et al. Informational [Page 6] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + Another important advantage of PBBN access is that it offers clear + separation between the service layer (represented by I-SID) and the + 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 separation allows the provider to manage and optimize the PBB + access network topology independent of the number of service + instances that are supported. + + In this section and those following, we look into different flavors + of H-VPLS with PBBN access. This section discusses the case in which + H-VPLS is deployed with homogeneous PBBN access. Section 5 describes + the case in which 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 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 + + In the context of PBBN and H-VPLS interoperability, "I-SID Domain" + and "B-VLAN 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. That is, 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-VLAN Domain" refers to a network administrative boundary under + which all the PBB BEBs and VPLS-PE devices employ consistent I-SID + to B-VLAN bundling. For example, the grouping of I-SIDs to + B-VLANs is the same in that domain. Although the two B-VLANs in + two PBBNs that represent the same group of I-SIDs do not need to + + + +Sajassi, et al. Informational [Page 7] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + use the same B-VID value, in practice, they often use the same + value because once the I-SID grouping is made identical in two + PBBNs. It is very easy to make the values of the corresponding + B-VIDs identical also. + + Consequently, three different kinds of "Service Domains" are defined + in the following manner: + + - Tightly Coupled Service Domain - Different PBBNs' access belonging + to the same I-SID Domain and B-VLAN Domain. However, the network + control protocols (e.g., xSTP) run independently in each PBBN + access. + + - Loosely Coupled Service Domain - Different PBBNs' access belonging + to the same I-SID Domain. However, each PBBN access maintains its + own independent B-VLAN 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-VLAN Domain, with + independent network control protocols (e.g., xSTP) in each PBBN + 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 remapping (i.e., + unbundling and rebundling of I-SIDs into B-VIDs). Furthermore, + service connectivity spanning networks in Different Service Domains + requires both I-SID translation and I-SID to B-VID remapping. + +4.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, C-MAC frames are encapsulated in a PBB header that + includes service provider source and destination MAC addresses + (B-MACs) and are bridged up to the VPLS-PE. The PBB-encapsulated + C-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 the customer domain. + + + + + + + +Sajassi, et al. Informational [Page 8] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + 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 I-SID tag will need to be defined. + + Moreover, 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 the same bridge domain, 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 (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 is not expected to have visibility of 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 interfaces: + + - 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 does not need to support PBB functionality. + This corresponds to conventional VPLS-PEs' 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 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 Type II service + + + + + +Sajassi, et al. Informational [Page 9] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + interface, the PE supports the existing raw mode and tagged mode PW + types. Type II service interface is described in detail in Section + 4.3. + +4.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 and Type I Service Interface + + 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 will exchange PBB-encapsulated frames that + include source and destination B-MACs, a B-VID, and an 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, + the VPLS-PE can be considered to provide network-level 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 + + + +Sajassi, et al. Informational [Page 10] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + multiple service instances (I-SIDs) are bundled over a single full- + mesh PW corresponding to a bridge domain (e.g., B-VID), instead of + requiring a dedicated full-mesh PW 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 flood + containment per I-SID (B-MAC multicast pruning). + + Three different modes of operation are supported by 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 is also possible to use Ethernet tagged mode + (0x0004) PW, as defined in [RFC4447] and [RFC4448], for + interoperability with equipment that does not 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 I-SID as service delimiter + on the VPLS-PE. It requires the VPLS-PE to include the B-component + of 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. + + + + + + + +Sajassi, et al. Informational [Page 11] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + 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 Interface + + 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 the above, it should be apparent that Type II service interface + is applicable to Tightly Coupled Service Domains as well. + + By definition, the B-BEB connecting to the VPLS-PE will remove any + B-VLAN tags for frames exiting the PBBN access. The B-BEB and + VPLS-PE will exchange PBB-encapsulated frames that include source and + destination B-MACs and an I-SID. The service delimiter, from the + perspective of the VPLS-PE, is the I-SID. Since the PE has + visibility of I-SIDs, the PE provides service-level interworking + between PBBN access and IP/MPLS core. + + 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). 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 Service + interface also supports Different Service Domains in this mode, since + the B-BEB link in the PE connecting to the local PBBN can perform the + translation of 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 occur in the B-BEB + of PBBN access. Existing PW signaling and Ethernet raw mode + (0x0005), defined in [RFC4447] and [RFC4448], is supported. It is + + + +Sajassi, et al. Informational [Page 12] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + also possible to use a tagged mode (0x0004) PW for purpose of + interoperability with equipment that does not support raw mode. + + Type II service interface provides operators with 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 that Type II service interface has + compared to Type I is that it can reduce replication in the core + without the need for 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 of this service interface, 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 service interfaces are at + par with regard to PW state. However, for 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 is 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 Type II 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 4.2) can be + used. + + + + + + + + + + + + + +Sajassi, et al. Informational [Page 13] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +5. H-VPLS with Mixed PBBN Access and PBN Access + + It is 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 Networks + + Referring 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Informational [Page 14] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +5.1. H-VPLS with Mixed PBBN and PBN Access: Modified PBN PE + + As shown in Figure 5, the operation of VPLS-PE2 (connecting to the + PBBN access on the right) is no different from what was discussed in + Section 4. Type II service interface, as discussed in the above + section, is 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/| |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. + + + + + + +Sajassi, et al. Informational [Page 15] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + - 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 operates in I-SID Bundling Mode: at a 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 a PE + connecting to PBBN access, each group of I-SIDs is mapped to a VPLS + instance. Similar to Type II service interface, no I-SID translation + is performed for the I-SID bundling case. Existing PW signaling and + Ethernet raw mode (0x0005) PW type, defined in [RFC4447] and + [RFC4448], are supported. It is possible to use tagged mode (0x0004) + PW for backward compatibility as well. + +5.2. H-VPLS with Mixed PBBN and PBN Access: Regular PBN PE + + As shown in Figure 6, 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/| |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. + + + + + +Sajassi, et al. Informational [Page 16] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + - 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 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 within the + PBBN access network. + +6. 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 subsections. + +6.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 in which it participates. This can + easily add up to hundreds of thousands or even millions of C-MACs at + + + +Sajassi, et al. Informational [Page 17] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + the N-PE. When the U-PE performs PBB encapsulation, the N-PE only + needs to learn the MAC addresses of the U-PEs, which is a significant + reduction. Furthermore, when PBB encapsulation is used, many I-SIDs + are multiplexed within a single bridge domain (e.g., B-VLAN). If the + VPLS instance is set up per B-VLAN, then one can also achieve a + significant reduction in the number of full-mesh PWs. It should be + noted that this reduction in full-mesh PWs comes at the cost of + potentially increased replication over the full-mesh of PWs: 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 are most likely bigger + than the full-mesh PWs corresponding to a single I-SID. However, + flood containment per I-SID (B-MAC multicast pruning) can be used to + remedy this drawback and have multicast traffic replicated + efficiently for each customer (i.e., for each I-SID). + + Figure 7 below illustrates the scenario for H-VPLS with MPLS access. + As illustrated, 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). These, in turn, are connected + via a full mesh of PWs (per VPLS instance) traversing the IP/MPLS + core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB) + functions where it can encapsulate/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 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) + + + + + +Sajassi, et al. Informational [Page 18] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + By incorporating a PBB function, the U-PE maps each of these services + (for a given customer) onto a single I-SID based on the configuration + at the U-PE. Many I-SIDs are multiplexed within a single bridge + domain (e.g., B-VLAN). The U-PE can then map a bridge domain onto a + VPLS instance and the encapsulated frames are sent over the PW + associated with that VPLS instance. Furthermore, the entire Ethernet + bridging operation over the 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 in the VPLS N-PEs. + + In the case of PBB U-PEs in a single I-SID Domain, I-SID assignment + is performed globally across all MPLS access networks and therefore + there is 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. In the case of the 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 considered to be a degenerate case of I-SID + bundling where a single bridge domain is used per I-SID. However, + that results in an increased number of bridge domains and PWs in the + PEs. PBB flood containment (B-MAC multicast pruning) per I-SID can + be used in conjunction with I-SID bundling mode to limit the scope of + flooding per I-SID thus removing the need for I-SID mode. + +6.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-REV], [802.1Q], or [802.1ad]. + The U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS + PWs (per customer). These, in turn, are connected via a full mesh of + PWs (per customer or group of customers) traversing the IP/MPLS core. + + The U-PE still provides the same type of services toward its + customers as before and they are: + + - Port mode (either 802.1D, 802.1Q, or 802.1ad) + - VLAN mode (either 802.1Q or 802.1ad) + - VLAN-bundling mode (either 802.1Q or 802.1ad) + + + + +Sajassi, et al. Informational [Page 19] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + The spoke PW from the U-PE to the N-PE is not service multiplexed + because there is no PBB functionality on the U-PE, i.e., one service + per PW. + + 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 + + By incorporating 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. Many I-SIDs can be multiplexed within a single bridge + domain (e.g., B-VLAN). The N-PE can, then, either map a single I-SID + into a VPLS instance or map a bridge domain (e.g., B-VLAN) onto a + VPLS instance, according to its configuration. Next, the + encapsulated frames are sent over the set of PWs associated with that + VPLS instance. + + In the case of PBB N-PEs in a single I-SID Domain, I-SID assignment + is performed globally across all MPLS access networks and therefore + there is 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. In the case of the 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 considered to be a degenerate case of I-SID + bundling where a single bridge domain is used per I-SID. However, + that results in an increased number of bridge domains and PWs in the + PE. PBB flood containment (B-MAC multicast pruning) per I-SID can be + used in conjunction with I-SID bundling mode to limit the scope of + flooding per I-SID thus removing the need for I-SID mode. + + + + + + + + +Sajassi, et al. Informational [Page 20] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +7. H-VPLS with MPLS Access: PBB Migration Scenarios + + Operators and service providers that have deployed H-VPLS with either + MPLS or Ethernet are unlikely to migrate to PBB technology over night + because of obvious cost implications. Thus, it is imperative to + outline migration strategies that will allow operators to protect + investments in their installed base while still taking advantage of + the scalability benefits of PBB technology. + + In the following subsections, we explore three different migration + scenarios that allow a mix of existing H-VPLS access networks to + coexist with newer PBB-based access networks. The scenarios differ + in whether or not the Ethernet service frames passing over the VPLS + core are PBB-encapsulated. The first scenario, in Section 7.1, + involves passing only frames that are not PBB-encapsulated over the + core. The second scenario, in Section 7.2, stipulates passing only + PBB-encapsulated frames over the core. Whereas, the final scenario, + in Section 7.3, depicts a core that supports a mix of PBB- + encapsulated and non-PBB-encapsulated frames. The advantages and + disadvantages of each scenario will be discussed in the respective + 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 that are traversing the VPLS core (within PWs) would use the + 802.1ad frame format, as in current VPLS. Hence, the N-PEs in + existing access networks do not require any modification. For new + MPLS access networks that have PBB functions on the U-PE, the + corresponding N-PE must incorporate built-in IB-BEB functions in + order to terminate the PBB encapsulation before the frames enter the + core. A key point here is that while both the U-PE and N-PE nodes + implement PBB IB-BEB functionality, the former has the I-component + facing the customer (CE) and the B-component facing the core; whereas + the latter has the I-component facing the core and the B-component + facing the customer (i.e., access network). + + + + + + + + + + + + + + +Sajassi, et al. Informational [Page 21] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + 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 main advantage of this approach is that it requires no change to + existing access networks or existing VPLS N-PEs. The main + disadvantage is that these N-PEs will not leverage the advantages of + PBB in terms of MAC address and PW scalability. It is worth noting + that this migration scenario is an optimal option for an H-VPLS + deployment with a single PBB-capable access network. When multiple + PBB-capable access networks are required, then the scenario in + Section 7.3 is preferred, as it provides a more scalable and optimal + interconnect amongst 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 be upgraded to incorporate IB-BEB functions. All + Ethernet service frames passing over the VPLS core would be PBB- + encapsulated. The PBB over MPLS access networks would require no + special requirements beyond what is captured in Section 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 + + + +Sajassi, et al. Informational [Page 22] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + The main advantage of this approach 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 with 802.1ad format over the PWs in the + core. The newly added access networks, which incorporate PBB + functionality exchange Ethernet frames that are PBB-encapsulated + amongst each other over core PWs. For service connectivity between + existing access network (non-PBB-capable) and new access network (PBB + based), the VPLS N-PE of the latter network employs IB-BEB + functionality to decapsulate the PBB header from frames outbound to + the core and encapsulate the PBB header for frames inbound from the + core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet + service frames are exchanged over the VPLS core. + + This mode of operation requires new functionality on the VPLS N-PE of + the PBB-capable access network, so that the PE can send frames in + 802.1ad format or PBB format, on a per PW basis, depending on the + capability of the destination access network. Effectively, the PE + would have to incorporate B-BEB as well as IB-BEB functions. + + A given PE needs to be aware of the capability of its remote peer in + order to determine 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 + + + + +Sajassi, et al. Informational [Page 23] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + The U-PE and N-PE of the PBB-capable access network both employ BEB + functionality. The U-PE implements IB-BEB functionality where the + I-component faces the customer (CE) and the B-component faces the + core. The N-PE, on the other hand, implements IB-BEB functionality + with the I-component facing the core and the B-component facing the + customer (access network). In addition, the N-PE implements + standalone B-BEB functionality. + + This scenario combines the advantages of both previous scenarios + without any of their shortcomings, namely: it does not require any + changes to existing access networks and it allows the N-PE to + leverage the scalability benefits of 802.1ah for PBBN to PBBN + connectivity. The disadvantage of this option is that it requires + new functionality on the N-PE of the PBBN access. A second + disadvantage 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 + + 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 [RFC4111] and [RFC4762]. + +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. + + + + + +Sajassi, et al. Informational [Page 24] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + + [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. + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Informational [Page 25] + +RFC 7080 VPLS Interoperability with PBB December 2013 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Informational [Page 26] + |