Internet-Draft Ali Sajassi L2VPN Working Group Samer Salam Chris Metz Cisco Nabil Bitar Intended status: Standards Verizon Dinesh Mohan Expires: January 2009 Nortel July 2008 VPLS Interoperability with Provider Backbone Bridges draft-sajassi-l2vpn-vpls-pbb-interop-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in January 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Sajassi, et. al. Expires: Jan 2009 [Page 1] Internet-Draft VPLS Interoperability with PBB Jul 2008 Abstract The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB is in the process of being standardized as IEEE 802.1ah, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes how IEEE 802.1ah functionality can be used in the H-VPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. This document also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents Status of this Memo .........................................1 Conventions used in this document.............................2 1. Introduction.............................................3 2. Terminology..............................................4 3. H-VPLS with Homogeneous PBBN Access.........................5 3.1 Service Interfaces and Interworking Options.................7 3.2 H-VPLS with PBBN Access: Type I Service Interface............8 3.3 H-VPLS with PBBN Access: Type II Service Interface.......... 10 3.4 H-VPLS with PBBN Access: Type III Service Interface......... 12 4. H-VPLS with Mixed PBBN Access and PBN Access................ 14 4.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE........ 14 4.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE......... 16 6. Acknowledgments......................................... 17 7. IANA Considerations...................................... 17 8. Security Considerations.................................. 17 9. References.............................................. 17 9.1 Normative References.................................... 17 9.2 Informative References.................................. 17 A. Provider Backbone Bridges - Primer......................... 18 A.1 S-Tagged Service Interface............................... 20 A.2 I-Tagged Service Interface............................... 20 A.3 B-Tagged Service Interface............................... 20 Authors' Addresses......................................... 20 Full Copyright Statement.................................... 21 Sajassi, et. al. Expires: Jan 2009 [Page 2] Internet-Draft VPLS Interoperability with PBB Jul 2008 Intellectual Property....................................... 21 1. Introduction The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in the VPLS access. PBB is being worked on in IEEE as IEEE 802.1ah, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes how IEEE 802.1ah functionality can be used in the H-VPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. This document also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. [RFC4762] describes a two-tier hierarchical solution for VPLS for the purpose of improved 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 MPLS access network and another with IEEE 802.1ad (QinQ) Ethernet access network. In both types of H- VPLS, MAC address learning and forwarding are done based on customer MAC addresses (C-MACs), which poses scalability issues as the number of VPLS instances (and thus customer MAC addresses) increases. Furthermore, since a set of PWs is maintained on a per customer service instance 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 (in terms of PW manageability and troubleshooting) as the number of customer service instances grows. In addition to the above, H-VPLS with 802.1ad Ethernet access network has another scalability issue in terms of the maximum number of service instances that can be supported in the access network as described in [RFC4762]. Since the number of provider VLANs (S-VLANs) is limited to 4K and each S-VLAN represents a service instance in an 802.1ad network, then the maximum number of service instances that can be supported is 4K. These issues are highlighted in [VPLS- Bridge]. This document describes how IEEE 802.1ah (aka Provider Backbone Bridges) can be integrated with H-VPLS to address these scalability issues. In case of H-VPLS with 802.1ah (PBB) 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. Sajassi, et. al. Expires: Jan 2009 [Page 3] Internet-Draft VPLS Interoperability with PBB Jul 2008 This document also covers the interoperability scenarios for deploying H-VPLS with PBB Ethernet access when other types of access networks are deployed, including existing 802.1ad Ethernet access in either single or multiple service domains. Section 2 gives a quick terminology reference. Section 3 describes H-VPLS with homogeneous PBB Access Network. Section 4 discusses H- VPLS with mixed PBBN/PBN access. 2. Terminology 802.1ad: IEEE specification for "QinQ" encapsulation and bridging of Ethernet frames 802.1ah: IEEE specification for "MAC tunneling" encapsulation and bridging of frames across a provider backbone bridged network. B-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains a B-component that supports bridging in the provider backbone based on B-MAC and B-TAG information B-MAC: The backbone source or destination MAC address fields defined in the 802.1ah provider MAC encapsulation header. BCB: A backbone core bridge running in the core of a provider backbone bridged network. It bridges frames based on B-TAG information just as an 802.1ad provider bridge will bridge frames based on a VLAN identifier (S-VLAN) BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It can contain an I-component, B-component or both I and B components. B-TAG: field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier information. The format of the B-TAG field is the same as that of an 802.1ad S-TAG field. B-Tagged Service Interface: This is the interface between a BEB and BCB in a provider backbone bridged network. Frames passed through this interface contain a B-TAG field. B-VID: The specific VLAN identifier carried inside a B-TAG I-component: A bridging component contained in a backbone edge bridge that bridges in the customer space (customer MAC addresses, S-VLAN) IB-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in Sajassi, et. al. Expires: Jan 2009 [Page 4] Internet-Draft VPLS Interoperability with PBB Jul 2008 the customer space (customer MAC addresses, service VLAN IDs) and a B-component for bridging the provider's backbone space (B-MAC, B- TAG). I-BEB: A backbone edge bridged positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs). I-SID: The 24-bit service instance field carried inside the I-TAG. I-SID defines the service instance that the frame should be "mapped to". I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the service instance information (I-SID) associated with the frame. I-Tagged Service Interface: This the interface defined between the I and B components inside an IB-BEB or between two B-BEB. Frames passed through this interface contain an I-TAG field PBB: Provider Backbone Bridge PBBN: Provider Backbone Bridged Network 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 identifier information (S-VLAN). S-Tagged Service Interface: This the interface defined between the customer (CE) and the I-BEB or IB-BEB components. Frames passed through this interface contain an S-TAG field. S-VLAN: The specific service VLAN identifier carried inside an S-TAG 3. H-VPLS with Homogeneous PBBN Access A brief primer on PBB [802.1ah] is provided in Appendix A. Readers are encouraged to refer to that section to become familiar with PBB technology. 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, Sajassi, et. al. Expires: Jan 2009 [Page 5] Internet-Draft VPLS Interoperability with PBB Jul 2008 which allows up to 16M services per PBB access network, compared to 4K services per 802.1Q/802.1ad access network. Another important advantage of PBBN access is that it offers clear separation between 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 and the following sections we look into different flavors of H-VPLS with PBBN access. This section discusses the case where H- VPLS is deployed with homogenous PBBN access networks. Section 4 describes the case where at least one of the access networks is PBN access (QinQ/802.1ad) while others are PBBN access. At a macro scale, a network that employs H-VPLS with PBBN access can be represented as shown in figure 1 below. +--------------+ | | +---------+ | IP/MPLS | +---------+ +----+ | | +----+ +----+ | | +----+ | CE |--| | |VPLS| |VPLS| | |--| CE | +----+ | PBBN |---| PE | | PE |--| PBBN | +----+ +----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+ | CE |--| | | Backbone | | |--| CE | +----+ +---------+ +--------------+ +---------+ +----+ Figure 1: H-VPLS with PBBN Access In the context of PBBN and H-VPLS interoperability, "I-SID Domain" and "B-VID Domain" can be defined as follows: - "I-SID Domain" refers to a network administrative boundary under which all the PBB BEBs and VPLS PE devices use the same I-SID space, i.e. the I-SID assignment is carried out by the same administration. This effectively means that a given service instance has the same I-SID designation on all devices within an I-SID Domain. - "B-VID Domain" refers to a network administrative boundary under which all the PBB BEBs and VPLS PE devices employ consistent I-SID to B-VLAN bundling - e.g., grouping of I-SIDs to B-VLANs are 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 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 rather Sajassi, et. al. Expires: Jan 2009 [Page 6] Internet-Draft VPLS Interoperability with PBB Jul 2008 very easy to make the values of the corresponding B-VIDs also identical. Consequently, three different kinds of "Service Domains" are defined in the following manner: - Tightly Coupled Service Domain - Different PBBN access networks belonging to the same I-SID Domain and B-VID Domain. However, the network control protocols (e.g. xSTP) run independently in each PBB access network. - Loosely Coupled Service Domain - Different PBB access networks belonging to the same I-SID Domain. However, each PBBN access maintains its own independent B-VID Domain. Again, the network control protocols (e.g. xSTP) run independently in each PBBN access. - Different Service Domain - In this case, each PBBN access maintains its own independent I-SID Domain and B-VID Domain, with independent network control protocols (e.g. xSTP) in each PBB access. In general, correct service connectivity spanning networks in a Tightly Coupled Service Domain can be achieved via B-VID mapping between the networks (often even without B-VID translation). However, correct service connectivity spanning networks in a Loosely Coupled Service Domain requires I-SID to B-VID re-mapping (i.e unbundling and re-bundling 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 re-mapping. 3.1 Service Interfaces and Interworking Options Customer devices will interface with PBBN edge bridges using existing Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad. At the PBBN edge, customer MAC frames are encapsulated in a PBB header that includes a service provider source and destination MAC addresses (B-MAC) and are bridged up to the VPLS PE. The PBB encapsulated customer MAC frame is then injected into the VPLS backbone network, delivered to the remote VPLS PE node(s), and switched onto the remote PBBN access. From there, the PBBN bridges the encapsulated frame to a PBBN edge bridge where the PBB header is removed and the customer frame is sent to customer domain. Interoperating between PBBN devices and VPLS PE nodes will certainly leverage work already completed. When I-SID visibility is required at the VPLS PE nodes, new service interfaces based on I-SID tag will need to be defined; as well as a new PW type to transport certain types of PBB encapsulated frames across a PW. Moreover, by mapping a bridge domain (e.g. B-VLAN) to a VPLS instance, and bundling multiple end-customer service instances, represented by I-SIDs, over the same bridge domain, service providers will be able to significantly reduce the number of full- Sajassi, et. al. Expires: Jan 2009 [Page 7] Internet-Draft VPLS Interoperability with PBB Jul 2008 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, VPLS PE can be considered to offer service-level interworking between PBBN access and IP/MPLS core. Similarly, when PE is not expected to have visibility of I-SID at the service interface, VPLS PE can be considered to offer network-level interworking between PBBN access and MPLS core. A VPLS PE is always part of the IP/MPLS core, and may optionally participate in the control protocols (e.g. xSTP) of the access network. When connecting to a PBBN access, the VPLS PE needs to support one of the following three types of service interfaces: - Type I: B-Tagged Service Interface with B-VID as Service Delimiter - The PE connects to a Backbone Core Bridge (BCB) in PBBN access. The handoff between the BCB and the PE is B-Tagged PBB encapsulated frame (as described in Appendix A.3). The PE is transparent to PBB encapsulations and treats these frames as 802.1ad frames since B-VID EtherType is the same as S-VID EtherType. The PE does not need to support PBB functionality. This corresponds to conventional VPLS PE's tagged service interface. When using Type I service interface, the PE needs to support either raw-mode or tagged-mode Ethernet PW. Type I Service Interface is described in detail in Section 3.2. - Type II: B-Tagged Service Interface with I-SID as Service Delimiter - The PE connects to a Backbone Core Bridge (BCB) in PBBN access. The handoff between the BCB and the PE is B-Tagged PBB encapsulated frame (as described in Appendix A.3). The PE supports the B-BEB (Backbone Edge Bridge with B-Component) functionality of [802.1ah]. Consequently, the PE interprets PBB encapsulations and has I-SID visibility. With Type II service interface, the PE supports either raw-mode or tagged-mode Ethernet PW, or a newly defined mode of Ethernet PW [PBB-PW]. Type II Service Interface is described in detail in Section 3.3. - Type III: I-Tagged Service Interface with I-SID as Service Delimiter - The PE connects to a B-BEB (Backbone Edge Bridge with B-Component) in PBBN access. The PE itself also supports the B-BEB functionality of [802.1ah]. The handoff between the B-BEB in PBBN access and the PE is an I-Tagged PBB encapsulated frame (as described in Appendix A.2). With Type III service interface, the PE supports the newly defined mode of Ethernet PW [PBB-PW] in addition to the existing raw-mode and tagged-mode. Type III Service Interface is described in detail in Section 3.4. 3.2 H-VPLS with PBBN Access: Type I Service Interface Sajassi, et. al. Expires: Jan 2009 [Page 8] Internet-Draft VPLS Interoperability with PBB Jul 2008 This is a B-Tagged service interface with B-VID as service delimiter on the VPLS-PE. It does not require any new functionality on the VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on right side of Figure 2) by participating in network control protocols (e.g. xSTP) of the PBBN access. PBBN Access IP/MPLS Core PBBN Access +--------------+ +---------+ | | +---------------+ | | +----+ | | | | +---+ |VPLS| +-+ | | +---+ | | |BCB|---| PE |---|P| | | |BCB| | | +---+ /+----+ /+-+\ | | /+---+ | |+---+ | / +----+ / \+----+ / +---+| +--+ ||IB-| +---+/ |VPLS|/ +-+ |VPLS|/ +---+ |IB-|| +--+ |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE| +--+ |+---+ +---+ ^ +----+ +-+ +----+ ^ +---+ +---+| +--+ | | | | | | | | +---------+ | | | +--|------------+ | +--------------+ | | | Type I Type I Figure 2: H-VPLS with PBBN Access & Type I Service Interface Type I service interface is only applicable to networks with Tightly Coupled Service Domains, where both I-SID Domains and B-VID Domains are the same across all PBBN access networks. The BCB and VPLS PE will exchange PBB encapsulated frames that include source and destination B-MAC addresses, a B-VID and I-SID. The service delimiter, from the perspective of the VPLS PE, is the B-VID; in fact, this interface operates exactly as a current 802.1Q/ad interface into a VPLS PE does today. With Type I service interface, VPLS PE can be considered as providing network-level interworking between PBBN and MPLS domains, since VPLS PE does not have visibility of I-SIDs. The main advantage of this service interface, when compared to other types, is that it allows the service provider to save on the number of full-mesh PWs required in the core. This is primarily because multiple service instances (I-SIDs) are bundled over a single full- mesh corresponding to a bridge domain (e.g. B-VID), instead of requiring a dedicated full-mesh per service instance. Another advantage is the MAC address scalability in the core since the core is not exposed to C-MACs. The disadvantage of this interface is the comparably excessive replication required in the core: Since a group of service instances share the same full-mesh of PWs, an unknown unicast, multicast or broadcast on a single service instance will result in a flood over Sajassi, et. al. Expires: Jan 2009 [Page 9] Internet-Draft VPLS Interoperability with PBB Jul 2008 the core. This, however, can be mitigated via the use of multicast pruning as described in [PBB-VPLS-MCAST]. Three different modes of operation are supported by Type I Service Interface: - Port Mode or Unqualified Mode: All traffic over an interface in this mode is mapped to a single VPLS instance. Existing PW signaling and Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. - VLAN Mode or Qualified Mode: all traffic associated with a particular VLAN identified by the B-VID is mapped to a single VPLS instance. Existing PW signaling and Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. - VLAN Bundling Mode: all traffic associated with a group or range of VLANs or B-VIDs is mapped to a single VPLS instance. Existing PW signaling and Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. For the above three modes, it is also possible to use Ethernet tagged mode (0x0004) PW, as defined in [RFC4447] [RFC4448], for interoperability with equipment that does not support raw mode. The use of raw mode is recommended to be the default though. 3.3 H-VPLS with PBBN Access: Type II Service Interface This is a B-Tagged service interface with I-SID as service delimiter on the VPLS-PE. It requires the VPLS-PE to include B-Component of PBB BEB for I-SID processing, in addition to capability for mapping I-SID or I-SID bundle to VPLS instance. As shown in Figure 3, the PE is always part of IP/MPLS core. The PE may also be part of PBBN Access (e.g. VPLS-PE on right side of Figure 3) by participating in network control protocols (e.g. xSTP) of PBBN access. PBBN Access IP/MPLS Core PBBN Access +--------------+ +---------+ | | +---------------+ | | +-----+ | | | | +---+ |PE w/| +-+ | | +---+ | | |BCB|---|B-BEB|---|P| | | |BCB| | | +---+ /+-----+ /+-+\ | | +---+ | |+---+ | / +-----+ / \+-----+ / +---+| +--+ ||IB-| +---+/ |PW w/|/ +-+ |PE w/|/ +---+ |IB-|| +--+ |CE|-||BEB|-|BCB|---|B-BEB|---|P|--|B-BEB|--|BCB|-|BEB|--|CE| +--+ |+---+ +---+ ^ +-----+ +-+ +-----+ ^+---+ +---+| +--+ | | | | | | | | +---------+ | | | +---|-----------+ | +--------------+ | | | Type II Type II Sajassi, et. al. Expires: Jan 2009 [Page 10] Internet-Draft VPLS Interoperability with PBB Jul 2008 Figure 3: H-VPLS with PBBN Access & Type II Service Interface Type II service interface is applicable not only to networks with Tightly Coupled Service Domains but also to networks with Loosely Coupled Service Domains and even Different Service Domains. B-VID Domains can be independent and B-VID is always locally significant to each PBBN access and does not need to be transported over the IP/MPLS core. The BCB and VPLS PE will exchange PBB encapsulated frames that include source and destination B-MAC addresses, a B-VID and I-SID. The service delimiter, from the perspective of the VPLS PE, is the I-SID. Since PE has visibility into I-SIDs, the PE provides service- level interworking between PBBN access and IP/MPLS core. The advantage that Type II service interface has compared to Type I is the potentially less replication in the core without the need for a multicast pruning mechanism. This is mainly due to the increased segregation of service instances over disjoint full-meshes of PWs. Another advantage (which is shared with Type I interface) is the MAC address scalability in the core since the core is not exposed to C- MACs. The disadvantage of this service interface, compared to Type I, is that it may require a larger number of full-mesh PWs in the core. However, the number of full-mesh PWs can still be less than those required by H-VPLS without PBBN access. It is expected that this interface type will be used for customers with significant multicast traffic (but without P2MP LSP capability in VPLS PE) so that a separate VPLS instance is set up per customer (per I-SID instance). It should be noted that a VPLS PE may support both Type I and Type II service interfaces over the same physical interface. Two different operational modes are supported by Type II Service Interface: - I-SID Mode: all traffic associated with a particular I-SID is mapped to a single VPLS instance. In networks with Tightly Coupled Service Domain and Loosely Coupled Service Domain, since the I-SID Domain is the same, no I-SID translation is required. However, in networks with Different Service Domains, since I-SID Domains are independent for each PBBN access, I-SID translation is required at the PE and it is assumed that the PE only supports a single PBBN access (because if the PE supports multiple PBBN access, then I- SID translation at the PW is not sufficient). This I-SID translation occurs upon disposition from the PW, on the egress PE, to a locally significant value. To that end, a new PW mode is required, and this mode is analogous to tagged mode except that I- Sajassi, et. al. Expires: Jan 2009 [Page 11] Internet-Draft VPLS Interoperability with PBB Jul 2008 SID instead of 802.1Q/ad VLAN-ID is used as service delimiter. This new PW mode is defined in [PBB-PW] - I-SID Bundling Mode: all traffic associated with a group or range of I-SIDs is mapped to a single VPLS instance. This mode is only applicable to Tightly and Loosely Coupled Service Domains since the network consists of a single I-SID Domain and there is no need to perform I-SID translation on egress PE. Existing PW signaling and Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. It is also possible to use tagged mode (0x0004) PW type for interoperability with older devices. Note 1: For I-SID Bundling Mode operation in a network with Different Service Domains, I-SID translation can be performed in the B-BEB component of the PE only if a PE connects to a single access PBBN and all the Service Domains coordinate a common I-SID space for use over the core network. Otherwise, the B-BEB component of a given PE would not have context of the originating I-SID Domain for a received frame and would be incapable of handling interconnect to more than a single disparate I-SID Domain. The expectation with Type II service interface is that the core network does not have its own independent I-SID Domain (unlike Type III service interface covered in the next section). Therefore, to support Different Service Domains in this mode, it is required to implement an I-SID translation table per PW. This approach is unwieldy, hence, I-SID Bundling mode in Different Service Domain is not supported. 3.4 H-VPLS with PBBN Access: Type III Service Interface This is an I-Tagged service interface with I-SID as service delimiter on VPLS-PE. It requires the VPLS-PE to include B-Component of PBB BEB for I-SID processing in addition to the capability to map I-SID and I-SID Bundle to VPLS instance. As shown in Figure 4, the PE is always part of IP/MPLS core and connects to one or more B-BEB in PBBN access. 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| +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ | | | | | | | | +---------+ | | | | +---------+ | +-------------+ | | | Sajassi, et. al. Expires: Jan 2009 [Page 12] Internet-Draft VPLS Interoperability with PBB Jul 2008 Type III Type III Figure 4: H-VPLS with PBBN Access & Type III Service Interface Type III service interface is applicable to Tightly Coupled Service Domains, Loosely Coupled Service Domains and Different Service Domains. B-VID Domains can be independent and the B-VID is always locally significant in each PBBN access and does not need to be transported over the IP/MPLS core. By definition the B-BEB connecting to the VPLS PE will remove any B- VLAN tags for frames exiting the PBB access network because the B- VIDs are local to that PBBN. The B-BEB and VPLS PE will exchange PBB encapsulated frames that include source and destination B-MAC addresses, and I-SID. The service delimiter, from the perspective of the VPLS PE, is the I-SID. Since PE has visibility to I-SIDs, the PE provides service-level interworking between PBBN access and IP/MPLS core. Type III Service Interface shares the same set of advantages and disadvantages as Type II service interface (described in Section 3.3). Two different modes are supported by Type III Service Interface: - I-SID Mode: all traffic associated with a particular I-SID is mapped to a single VPLS instance. In Tightly and Loosely Coupled Service Domains, since I-SID Domain is the same, no I-SID translation is required. However, in Different Service Domains, since I-SID Domains are independent for each PBBN access, I-SID translation is needed at the PE. If the PE supports multiple PBBN access, then the I-SID translation needs to occur at the Customer Backbone Port (CBP) of B-BEB in VPLS PE. However, if the PE supports a single PBBN access, then I-SID translation can be performed at the egress of PW as with Type II Service Interface. A new PW mode is required, similar to one required in Type II Service Interface (Section 3.3). This new PW mode is defined in [PBB-PW] - I-SID Bundling Mode: all traffic associated with a group or range of I-SIDs is mapped to a single VPLS instance. The PE maintains a mapping of I-SIDs to a PE local bridge domain (e.g. B-VID). The VPLS instance is then associated with this bridge domain. With Tightly and Loosely Coupled Service Domains, no I-SID translation needs to be performed. Type III Service Interface also supports Different Service Domains in this mode, since the CBP of the B-BEB in the PE can perform the translation of PBBN-specific I-SID to a local I-SID within the IP/MPLS core, which can 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] [RFC4448], is supported. It is also possible to use tagged mode Sajassi, et. al. Expires: Jan 2009 [Page 13] Internet-Draft VPLS Interoperability with PBB Jul 2008 (0x0004) PW for purpose of interoperability with equipment that does not support raw mode. Note 2: Port mode is not called out in Type III Service Interface since it requires the mapping of I-SIDs to be identical on different I-Tagged interfaces across VPLS network. If this is indeed the case, Port mode defined in Type I Service Interface (Section 3.2) can be used. Note 3: I-SID Bundling mode assumes that bundling is homogeneous between the ingress and egress VPLS PEs. In other words, I-SIDs are divided along the same bundle boundaries. For the case where non- homogeneous bundling is required, and I-SIDs are to be mapped to different B-VLANs on different PEs, then I-SID mode should be chosen over I-SID bundling mode, for it provides maximum flexibility. 4. H-VPLS with Mixed PBBN Access and PBN Access It is foreseeable that service providers will want to interoperate their existing PBN (QinQ) access networks with PBBN access networks over H-VPLS. Figure 5 below shows the high-level network topology. +--------------+ | | +---------+ | IP/MPLS | +---------+ +----+ | | +----+ +----+ | | +----+ | CE |--| PBN | |VPLS| |VPLS| | |--| CE | +----+ | (QinQ) |---| PE1| | PE2|--| PBBN | +----+ +----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+ | CE |--| | | Backbone | | |--| CE | +----+ +---------+ +--------------+ +---------+ +----+ Figure 5: H-VPLS with Mixed PBN and PBBN Access Networks Referring to Figure 5 above, two possibilities come into play depending on whether the interworking is carried out at PE1 or PE2. These are described in the following sub-Sections. 4.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE As shown in Figure 6, the operation of VPLS PE2 (connecting to the PBBN access on the right) is no different from what was discussed in Section 3. Both Type II and Type III service interfaces, as discussed in the above section, are applicable. It is the behavior of VPLS PE1 (connecting to the PBN access on the left) that is the focus of this section. Sajassi, et. al. Expires: Jan 2009 [Page 14] Internet-Draft VPLS Interoperability with PBB Jul 2008 PBN Access IP/MPLS Core PBBN Access (802.1ad) +--------------+ (802.1ah) | | +---------+ +---------+ | | | | | | +-----+ | | +---+ | | +---+ |PE w/| +-+ | | |BCB| | | |PCB|--|IBBEB|-|P| | | +---+ | | +---+ /+-----+ +-+ | | / | | | | / +-----+/ \+-----+ | +---+| +--+ |+---+ +---+ |PE w/| +-+ |PE w/| +---+ |IB-|| +--+ |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BCB| |BEB|--|CE| +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ | | | |PE1 PE2| | | | +---------+ | | | | +---------+ | +-------------+ | | | S-Tagged Type II (B-Tagged) Figure 6: H-VPLS with Mixed PBB and PBBN Access: Modified PBN PE Some assumptions made for this topology include: - CE is directly connected to PBBN via C-Tagged Interface - I-SID in PBBN access represents the same customer as S-VID in PBN access - At S-Tagged Service Interface of PE with IB-BEB functionality (e.g. PE1 in Figure 6), the only viable service is 1:1 mapping of S-VID to I-SID. However, towards the core network side, the same PE can support I-SID bundling into a VPLS instance. - For ease of provisioning in these disparate access networks, it is recommended to use the same I-SID Domain among the PBBN access and PEs with IB-BEB functionality (those connecting to PBN). Two different modes are supported by this topology: - I-SID Mode: at PE connecting to PBN access, each S-VID is mapped to an I-SID and subsequently mapped to a VPLS instance. Similarly, at PE connecting to PBBN access, each I-SID is mapped to a VPLS instance. Since it is recommended to use the same I-SID Domain, no I-SID translation is needed. A new PW mode is required, same as one mentioned in Section 3.3 and Section 3.4. This PW mode is defined in [PBB-PW] - I-SID Bundling Mode: at PE connecting to PBN access, each S-VID is mapped to an I-SID and subsequently a group of I-SIDs is mapped to a VPLS instance. Similarly, at PE connecting to PBBN access, each group of I-SIDs is mapped to a VPLS instance. Similar to Type II interface, no I-SID translation is performed for I-SID bundling case. Existing PW signaling and Ethernet raw mode (0x0005) PW Sajassi, et. al. Expires: Jan 2009 [Page 15] Internet-Draft VPLS Interoperability with PBB Jul 2008 type, defined in [RFC4447] [RFC4448], are supported. It is possible to use tagged mode (0x0004) PW for backward compatibility as well. 4.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE As shown in Figure 7, the operation of VPLS PE1 (connecting to the PBN access on the left) is no different from existing VPLS PEs. It is the behavior of VPLS PE2 (connecting to the PBBN access on the right) that is the focus of this section. PBN Access IP/MPLS Core PBBN Access (802.1ad) +--------------+ (802.1ah) | | +---------+ +---------+ | | | | | | +-----+ | | +---+ | | +---+ | PE | +-+ | | |BCB| | | |PCB|--| |-|P| | | +---+ | | +---+ /+-----+ +-+ | | / | | | | / +-----+/ \+-----+ | +---+| +--+ |+---+ +---+ | PE | +-+ |PE w/| +---+ |IB-|| +--+ |CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BCB| |BEB|--|CE| +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ | | | |PE1 PE2| | | | +---------+ | | | | +---------+ | +-------------+ | | | S-Tagged Type II (B-Tagged) Figure 7: H-VPLS with Mixed PBB and PBBN Access: Regular PBN PE Some assumptions made for this topology include: - CE is directly connected to PBBN via C-Tagged Interface - I-SID in PBBN access represents the same customer as S-VID in PBN access - There is 1:1 mapping between the I-SID and VPLS instance - At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in Figure 7), the PE only provides 1:1 mapping of S-VID to VPLS instance. S-VID bundling is not a viable option since it does not correspond to anything in PBBN access. - The PE connecting to PBBN (e.g. PE2 in Figure 7), supports IB-BEB functionality and the I-Component is connected to the VPLS Forwarder (i.e. the I-Component faces the 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. Sajassi, et. al. Expires: Jan 2009 [Page 16] Internet-Draft VPLS Interoperability with PBB Jul 2008 Unlike the other topology, no I-SID mode or I-SID bundling mode is supported in this case. This is primarily because the VPLS core operates in the same manner as today. The PE with IB-BEB functionality connecting to PBBN access performs the mapping of each VPLS instance to an I-SID and one or more of these I-SIDs may be mapped onto a B-VID within the PBBN access network. 6. Acknowledgments TBD. 7. IANA Considerations This document has no actions for IANA. 8. Security Considerations This document does not introduce any additional security aspects beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security considerations are already covered in [RFC4762]. 9. References 9.1 Normative References [802.1ad] "Virtual Bridged Local Area Networks: Provider Bridges", IEEE 802.1ad/D8.1, December 2005 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 2007 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, April 2006 [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC4448, April 2006 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007 9.2 Informative References [802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q- 2005 [802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D- 2003 [VPLS-Bridge] "VPLS Interoperability with CE Bridges", draft-ietf- l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 2007 Sajassi, et. al. Expires: Jan 2009 [Page 17] Internet-Draft VPLS Interoperability with PBB Jul 2008 [PBB-PW] "802.1ah Ethernet Pseudowire", draft-martini-pwe3-802-1ah- pw-00.txt, Work in progress, May 2007 [VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast- 03.txt, Work in progress, November 2007 [PBB-VPLS-MCAST] "Multicast Pruning in Provider Backbone Bridged VPLS", draft-sajassi-l2vpn-pbb-vpls-mcast-pruning-00.txt, Work in progress, July 2008 A. Provider Backbone Bridges - Primer Provider Backbone Bridges (PBBs), as currently being defined in IEEE 802.1ah, offer a scalable solution for service providers to build large bridged networks. The focus of PBB is primarily on improving two main areas with provider Ethernet bridged networks: - MAC-address table scalability: in current provider networks that employ IEEE 802.1Q or IEEE 802.1ad bridging, the service provider equipment operating at the Ethernet MAC layer is forced to learn all customer edge device MAC addresses (when the CE is a router) and all customer end-station MAC addresses (when the CE is a bridge). This clearly does not scale well as the number of customers and customer equipment, served by a given provider, increases. The service providers are often limited by the size of the hardware MAC tables as they attempt to scale their networks. - Service instance scalability: when building networks using IEEE 802.1Q or IEEE 802.1ad technologies, a service provider is limited to 4094 service instances per 802.1Q or 802.1ad network. This limitation is due to the fact that the VLAN identifier is 12-bits in width which translates to 4096 possible values (and VLAN identifier values 0 and 4095 are reserved). To obviate the above two limitations, PBB introduces a hierarchical network architecture with associated new frame formats which extend the work completed by Provider Bridges (IEEE 802.1ad). In the PBB architecture, customer networks (using IEEE 802.1Q bridging) are aggregated into provider bridge networks (using IEEE 802.1ad). These, in turn, are aggregated into Provider Backbone Bridge Networks (PBBNs) which utilize the IEEE 802.1ah frame format. The frame format employs a MAC tunneling encapsulation scheme for tunneling customer Ethernet frames within provider Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to segregate the backbone into broadcast domains and a new 24-bit service identifier (I-SID) is defined and used to associate a given customer MAC frame Sajassi, et. al. Expires: Jan 2009 [Page 18] Internet-Draft VPLS Interoperability with PBB Jul 2008 with a provider service instance (also called the service delimiter). It should be noted that in 802.1ah there is a clear segregation between provider service instances (represented by I- SIDs) and provider VLANs (represented by B-VIDs) which was not the case for 802.1ad. As such, the network designer for an 802.1ah network has the freedom to define the number of VLANs which is optimum for network operation without any dependency on the number of service instances. PBBN bridges utilize existing IEEE control protocols (e.g. IEEE 802.1s MST) to create a loop free topology for frame forwarding. A PBBN bridge can be categorized as either a Backbone Core Bridge (BCB) or Backbone Edge Bridge (BEB). A BCB is a plain IEEE 802.1ad Provider Bridge. A BEB is responsible for encapsulation and de- encapsulation of customer Ethernet frames to/from PBB (802.1ah) frame format. As shown in the following figure A.1, a Backbone Edge Bridge (BEB) may consist of a single B-component and one or more I-components. In simple terms, the B-component provides bridging in provider space (B-MAC, B-VLAN) and the I-component provides bridging in customer space (C-MAC, S-VLAN). The customer frame is first encapsulated with the provider backbone header (B-MAC, B-tag, I-tag); then, the bridging is performed in the provider backbone space (B-MAC, B-VLAN) through the network till the frame arrives at the destination BEB where it gets de-encapsulated and passed to the CE. If a PBB bridge consists of both I & B components, then it is called IB-BEB and if it only consists of either B-component or I-component, then it is called B-BEB or I-BEB respectively. The interface between an I-BEB or IB-BEB and a CE is called S-tagged service interface and the interface between an I-BEB and a B-BEB (or between two B-BEBs) is called I-tagged service interface. The interface between a B-BEB or IB-BEB and a Backbone Core Bridge (BCB) is called B-Tagged service interface. These service interfaces, for Provider Backbone Bridges, are described next. +-------------------------------+ | 802.1ah Bridge Model | | | +---+ | +------+ +-----------+ | |CE |---------|I-Comp|------| | | +---+ | | | | |-------- | +------+ | | | | o | B-Comp | | | o | |-------- | o | | | +---+ | +------+ | | | |CE |---------|I-Comp|------| |-------- +---+ ^ | | | ^ | | | ^ | | +------+ | +-----------+ | | | +------------|------------------+ | | | | | | | Sajassi, et. al. Expires: Jan 2009 [Page 19] Internet-Draft VPLS Interoperability with PBB Jul 2008 S-tagged I-tagged B-tagged Service I/F Service I/F Service I/F Figure A1: 802.1ah Bridge Model A.1 S-Tagged Service Interface This service interface connects a customer 802.1ad Provider Bridge to an I-BEB or IB-BEB. Three modes are supported: - Port Mode. In this mode, traffic on all S-VLANs is mapped to the same I-SID. - S-Tag Mode. In this mode, traffic associated with each S-VLAN is mapped to a single I-SID. - S-Tag Bundling Mode. In this mode, traffic associated with a group or range of S-VLANs is mapped to a single I-SID. A.2 I-Tagged Service Interface This service interface connects an I-BEB to a B-BEB or it connects two B-BEBs together. Although, in figure A.1, this interface is shown as an internal interface between I-component and B-component within an IB-BEB, in practice this service interface is an external interface connecting a customer I-BEB with a provider B-BEB or connecting two different providers B-BEBs across different administrative domains. A.3 B-Tagged Service Interface This service interface connects a B-BEB or an IB-BEB with a provider Backbone Core Bridge (BCB). Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Chris Metz Cisco Sajassi, et. al. Expires: Jan 2009 [Page 20] Internet-Draft VPLS Interoperability with PBB Jul 2008 170 West Tasman Drive San Jose, CA 95134, US Email: metz@cisco.com Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9, Canada Email: mohand@nortel.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Sajassi, et. al. Expires: Jan 2009 [Page 21] Internet-Draft VPLS Interoperability with PBB Jul 2008 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Sajassi, et. al. Expires: Jan 2009 [Page 22]