Internet Working Group Ali Sajassi Internet Draft Samer Salam Chris Metz Cisco Nabil Bitar Verizon Dinesh Mohan Nortel Expires: September 2007 March 2007 VPLS Interoperability with Provider Backbone Bridges draft-sajassi-l2vpn-vpls-pbb-interop-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB - - 802.1ah) functionality in PE devices. PBB is being worked on in IEEE as an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This draft 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 draft also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS (with either MPLS or Ethernet access network) and interoperability between them. Sajassi, et. al. [Page 1] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 Conventions 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 1. Terminology........................................................2 2. Overview..........................................................4 3. Background: Provider Backbone Bridges..................................4 3.1. S-Tagged Service Interface..........................................6 3.2. I-Tagged Service Interface..........................................6 3.3. B-Tagged Service Interface..........................................7 4. H-VPLS with PBB Access Network........................................7 4.1. Network Topologies................................................8 4.1.1. Topology Variant A...............................................8 4.1.2. Topology Variant B...............................................9 4.2. Service Interfaces & Interworking Options............................10 4.2.1. PBBN-VPLS Type I Service Interface................................10 4.2.2. PBBN-VPLS Type II Service Interface................................12 4.2.3. PBBN-VPLS Type III Service Interface...............................14 5. H-VPLS with MPLS Access Network......................................16 5.1. Supported Services...............................................17 5.2. U-PE Operation in a Single Domain...................................18 5.3. U-PE Operation in Multiple Domains..................................18 5.4. Pseudowire Requirements...........................................18 5.4.1. Requirements with B-VID as Service Delimiter........................19 5.4.2. Requirements with I-SID as Service Delimiter........................19 6. Acknowledgments....................................................19 7. Security Considerations.............................................19 8. Intellectual Property Considerations..................................19 9. Full Copyright Statement............................................19 10. 14. IPR Notice....................................................20 11. Normative References...............................................20 12. Informative References.............................................21 13. Authors' Addresses................................................21 1. Terminology 802.1ad: IEEE specification for ‘‘Q-in-Q’’ 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 Sajassi, et al. [Page 2] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 B-MAC: The backbone source and destination MAC address fields defined in the 802.1ah provider MAC encapsulation header. BCB: A backbone core bridge running in the core of a provider backbone bridged network. It bridges frames based on B-TAG information just as an 802.1ad provider bridge will bridge frames based on a VLAN identifier (S-VLAN) BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It can contain an I-component, B-component or both I and B components. B-TAG: field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier information. The format of the B-TAG field is the same as that of an 802.1ad S-TAG field. B-Tagged Service Interface: This is the interface between a BEB and BCB in a provider backbone bridged network. Frames passed through this interface contain a B-TAG field. B-VID: The specific VLAN identifier carried inside a B-TAG I-component: A bridging component contained in a backbone edge bridge that bridges in the customer space (customer MAC addresses, S-VLAN) IB-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs) and a B-component for bridging the provider’s backbone space (B-MAC, B-TAG). I-BEB: A backbone edge bridged positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs). I-SID: The 24-bit service instance field carried inside the I-TAG. The I-SID defines the service instance that the frame should be ‘‘mapped to’’. I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the service instance information (I-SID) associated with the frame. I-Tagged Service Interface: This the interface defined between the I and B components inside an IB-BEB or between two B-BEB. Frames passed through this interface contain an I-TAG field PBB: Provider Backbone Bridge PBBN: Provider Backbone Bridged Network S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the service VLAN identifier information (S-VLAN). S-Tagged Service Interface: This the interface defined between the customer (CE) and the I-BEB or IB-BEB components. Frames passed through this interface contain Sajassi, et al. [Page 3] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 an S-TAG field. S-VLAN: The specific service VLAN identifier carried inside an S-TAG 2. Overview [RFC4762] describes a two-tier hierarchical solution for VPLS for the purpose of improved pseudowire 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. The RFC describes two types of H-VPLS network topologies - one with MPLS access network and another with Ethernet access network. The later one (Ethernet access network) is based on IEEE 802.1ad (QinQ) standards. 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 pseudowires is maintained on a per customer service instance, the number of pseudowires that need to be maintained at N-PE devices is proportional to the number of customer service instances multiplied by the number of N-PE devices in the full-mesh set. This can result in scalability issues (in terms of pseudowire management and OAM aspects) as the number of customer service instances grows. In addition to the above scalability issues, H-VPLS with Ethernet access network (based on 802.1ad), has another scalability issue in terms of the number of service instances that can be supported in the access network as described in that RFC. 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, the number of service instances that can be supported is also limited to 4K. This draft describes how IEEE 802.1ah (aka Provider Backbone Bridges) can be integrated with H-VPLS to address these scalability issues. In case of H-VPLS with MPLS access, 802.1ah functionality is used at the U-PE which results in reduction of customer MAC addresses and number of pseudowires in the VPLS core network. And in case of H-VPLS with Ethernet access, 802.1ah access network results in better scalability in terms of both number of service instances and number of C-MACs in both Ethernet access network and VPLS core network. This draft describes possible PBB interoperability scenarios for H-VPLS with Ethernet and MPLS access networks for both single and multiple administrative domains. Section 2 gives a quick background in Provider Backbone Bridges and sections 3 and 4 describe interoperability scenarios and mechanisms for H-VPLS with PBB access network, and H-VPLS with MPLS access network respectively. 3. Background: Provider Backbone Bridges Provider Backbone Bridges (PBBs), as currently being defined in IEEE 802.1ah, offer a scalable solution for service providers to build large bridged networks. Sajassi, et al. [Page 4] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 The focus of PBB is primarily on improving two main areas with provider Ethernet bridged networks: i) 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. ii)Service instance scalability: when building networks using IEEE 802.1Q or IEEE 802.1ad technologies, a service provider is limited to 4094 service instances per 802.1Q or 802.1ad network. This limitation is due to the fact that the VLAN identifier is 12-bits in width which translates to 4096 possible values (and VLAN identifier values 0 and 4095 are reserved). To obviate the above two limitations, PBB introduces a hierarchical network architecture with associated new frame formats which extend the work completed by Provider Bridges (IEEE 802.1ad). In the PBB architecture, customer networks (using IEEE 802.1Q bridging) are aggregated into provider bridge networks (using IEEE 802.1ad). These, in turn, are aggregated into Provider Backbone Bridge Networks (PBBNs) which utilize the IEEE 802.1ah frame format. The frame format employs a MAC tunneling encapsulation scheme for tunneling customer Ethernet frames within provider Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to segregate the backbone into broadcast domains and a new 24-bit service identifier (I-SID) is defined and used to associate a given customer MAC frame with a provider service instance (also called the service delimiter). It should be noted that in 802.1ah there is a clear segregation between provider service instances (represented by I-SIDs) and provider VLANs (represented by B-VIDs) which was not the case for 802.1ad. As such, the network designer for an 802.1ah network has the freedom to define the number of VLANs which is optimum for network operation without any dependency on the number of service instances. PBBN bridges utilize existing IEEE control protocols (e.g. IEEE 802.1s MST) to create a loop free topology for frame forwarding. A PBBN bridge can be categorized as either a Backbone Core Bridge (BCB) or Backbone Edge Bridge (BEB). A BCB is a plain IEEE 802.1ad Provider Bridge. A BEB is responsible for encapsulation and decapsulation of customer Ethernet frames to/from PBB (802.1ah) frame format. As shown in the following figure, 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 decapsulated 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. Sajassi, et al. [Page 5] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 The interface between a B-BEB or IB-BEB and a Backbone Core Bridge (BCB) is called B-Tagged service interface. These service interfaces, for Provider Backbone Bridges, are described next. +-------------------------------+ | 802.1ah Bridge Model | | | +---+ | +------+ +-----------+ | |CE |---------|I-Comp|------| | | +---+ | | | | |-------- | +------+ | | | | o | B-Comp | | | o | |-------- | o | | | +---+ | +------+ | | | |CE |---------|I-Comp|------| |-------- +---+ ^ | | | ^ | | | ^ | | +------+ | +-----------+ | | | +------------|------------------+ | | | | | | | S-tagged I-tagged B-tagged Service I/F Service I/F Service I/F Figure 1: 802.1ah Bridge Model 3.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: i) Port Mode. In this mode, traffic on all S-VLANs is mapped to the same SID. ii)S-Tag Mode. In this mode, traffic associated with each S-VLAN is mapped to a single I-SID. iii) S-Tag Bundling Mode. In this mode, traffic associated with a group or range of S-VLANs is mapped to a single I-SID. 3.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 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- Sajassi, et al. [Page 6] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 BEB or connecting two different providers B-BEBs across different administrative domains. 3.3. B-Tagged Service Interface This service interface connects a B-BEB or an IB-BEB with a provider Backbone Core Bridge (BCB). Having provided a brief primer on PBB in this section, next we discuss how PBB technology can be used in the Ethernet access network for H-VPLS. This is captured in section 4. Then, in section 5, we describe interoperability mechanisms for PBB with H-VPLS using MPLS access. 4. H-VPLS with PBB Access Network At a macro scale, a network that employs H-VPLS with PBBN access can be represented as shown in figure 2 below. However, careful examination of the administrative relationships that govern each of the access network, the VPLS PE and the IP/MPLS core reveals two discernable network topologies. The topologies differ by the logical or administrative placement of the VPLS PE with respect to the access and core networks. Furthermore, the topology classification has a direct bearing on the type of service interface through which the PBBN connects to the VPLS PE. +--------------+ | | +---------+ | IP/MPLS | +---------+ +----+ | | +----+ +----+ | | +----+ | CE |--| | |VPLS| |VPLS| | |--| CE | +----+ | PBBN |---| PE | | PE |--| PBBN | +----+ +----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+ | CE |--| | | Backbone | | |--| CE | +----+ +---------+ +--------------+ +---------+ +----+ Figure 2: PBBN and VPLS Networks In subsection 4.1, we describe the network topologies in detail, and in subsection 4.2 the service interface(s) associated with each topology is(are) defined. At this point, it is important to define the notion of ‘administrative domains’ as being used in the context of this discussion: Two (or more) networks are considered to be in the same administrative domain when they share the same global I-SID space and use the same I-SID value for a given service instance. It is possible for each network within the same administrative domain to run independent spanning tree instances and thus operate with different B-VLANs. On the other hand, two (or more) networks are considered in different administrative domains if they have different I-SID spaces (and different B-VLAN spaces). It is possible to achieve correct service connectivity spanning networks belonging to different administrative domains by employing I-SID (and B-VLAN) translations. Sajassi, et al. [Page 7] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 4.1. Network Topologies Two network topology variants are identified. The details of these are discussed in the following subsections. 4.1.1. Topology Variant A In this topology, the VPLS PE is administratively part of the access network. One example of this topology is a service provider with 802.1ah access network connecting to another provider over an MPLS network. Another example is the case where two access networks of the same service provider are being connected over its MPLS core. This topology is shown in figure 3 below. |B-MAC| |B-MAC| |B-VID| |B-VID| |I-SID| |I-SID| |CUST | |CUST | |MAC | |MAC | |FRAME| |FRAME| |CUST | | | |MAC | | | |FRAME| | +---------+ | | | | | | | +------------|-------+| IP |+-------|------------+ v | PBB Access | || MPLS || | PBB Access | | Network V || Core || V Network | | +----+|| ||+----+ | +--+ |+---+ +---+ |VPLS||| |||VPLS| +---+ +---+| +--+ |CE|-||BEB| |BCB|---| PE ||| ||| PE |---|BCB| |BEB||-|CE| +--+ |+---+ +---+ ^ +----+|| ||+----+ ^ +---+ +---+| +--+ +------------|-------+| |+-------|------------+ | +---------+ | | | Type I & II Type I & II Figure 3: Topology A - - VPLS PE part of access network Given that the VPLS PE is part of the access PBBN, it will be connected to a BCB directly. In scenarios where the VPLS PEs are part of different administrative domains, they will be required to perform functions that are the responsibility of a B-type Backbone Edge Bridge (B-BEB): Basically B-VLAN and I-SID translations. We note, here, that with this topology variant, the assumption is that a VPLS PE will always be connected to a BCB and not to a BEB and thus shares the same administrative domain with PBBN. The reason for that is straightforward: A BEB demarks the edge of a PBBN. If a VPLS PE connects to a PBBN via a BEB then that PE is logically outside the PBBN’s administrative boundaries. Sajassi, et al. [Page 8] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 Two service interface types are applicable and associated with this topology variant. These are Type I and Type II service interfaces discussed in sections 4.2.1 and 4.2.2 respectively. 4.1.2. Topology Variant B In this topology, the VPLS PE is administratively part of the core network. An example of this topology is a service provider providing connectivity among different independent 802.1ah networks over its MPLS core network. This is shown in figure 4 below. |B-MAC| |B-MAC| |I-SID| |I-SID| |CUST | |CUST | |MAC | |MAC | |CUST | |FRAME| |FRAME| |MAC | | | |FRAME| | +-------------------+ | | | | | | | +------------+ | | IP | | +------------+ | | PBB Access | V | MPLS | V | PBB Access | V | Network | | Core | | Network | | | |+----+ +----+| | | +--+ |+---+ +---+| ||VPLS| |VPLS|| |+---+ +---+| +--+ |CE|-||BEB| |BEB||---|| PE | | PE ||---||BEB| |BEB||-|CE| +--+ |+---+ +---+| ^ |+----+ +----+| ^ |+---+ +---+| +--+ +------------+ | | | | +------------+ | +-------------------+ | | | Type III Type III Figure 4: Topology B - - VPLS PE part of core network The VPLS PE will connect to the PBBN via a BEB. This is the only connectivity option for this topology variant. The rationale for that is as follows: If the PE were to be connected to a BCB (as an alternative), the BCB does not have the capability to perform B-VLAN or I-SID translation. As a matter of fact, it is an 802.1ad bridge that cannot even parse the 802.1ah frame beyond the B-VLAN. Hence, the BCB cannot sit at the edge of an administrative domain. Which leads us to conclude that the administrative domain boundary must be beyond the BCB - VPLS PE interconnect and, therefore, this resolves back to topology variant A. In the case where the MPLS and PBBN networks are not ubiquitously part of the same administrative domain, the VPLS PE is required to perform the I-SID translation functions of a BEB B-Component. A single service interface, Type III, is associated with this topology variant. It is described in details in section 4.2.3. Sajassi, et al. [Page 9] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 4.2. Service Interfaces & Interworking Options Customer devices or networks 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 PBBN header that includes a service provider source and destination MAC addresses (B-MAC) and bridged up to the VPLS PE. The PBBN-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 network. From there, the PBBN bridges the encapsulated frame to a PBBN edge bridge where the PBBN header is removed and the customer frame is sent on its way. 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 pseudowire type to transport certain types of PBBN-encapsulated frames across a pseudowire. The use of the B-MAC address space will ease the provider’s provisioning tasks and better scale the overall system for the simple reason that MAC processing is based on the provider’s backbone MAC addressing space, not the many customer MAC addresses serviced. Furthermore, the larger I-SID space (24- bits) defined in 802.1ah, compared to the 12-bit VID space defined in 802.1ad/802.1Q, scales the number of service instance identifiers available to a single access network by many orders of magnitude. Instead of being limited to 4094 service instances per access network, the service provider can now, in theory, accommodate 2^24 service instances. Of course, physical device limitations (in terms of memory and processing power) will be reached before this identifier space is exhausted. Moreover, by mapping a B-VLAN to a VPLS instance, and bundling multiple end-customer service instances over the same B-VLAN, service providers will be able to significantly reduce the number of full-mesh pseudowires required in the core. In this case, I-SID visibility is not required on the VPLS-PE and the I-SID will serve as the means of multiplexing/de-multiplexing individual service instances in the PBBN over a bundle (B-VLAN). Thus, instead of maintaining a full mesh of pseudowires per individual service instance, it is possible to maintain a full mesh per group or collection of service instances. In addition, the scaling advantages of H-VPLS including reduced pseudowire signaling overhead remain in effect. 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 and MPLS domain. 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 and MPLS domain. PBBN-VPLS service interfaces may differ depending on the topology variants identified earlier. The following sub-sections describe the different PBBN - - VPLS service interfaces and their expected behavior. 4.2.1. PBBN-VPLS Type I Service Interface Sajassi, et al. [Page 10] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 This is B-tagged service interface with B-VID as the service delimiter. This service interface is applicable to Topology Variant A only. It connects a PBBN backbone core bridge (BCB) to a VPLS PE and is illustrated in figure 3. The VPLS PE is administratively part of the access network, which means it shares the same I-SID and B-VID space as its PBBN access network. The BCB and VPLS PE will exchange PBBN 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 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 pseudowires required in the core. This is primarily because multiple service instances (I- SIDs) are bundled over a single full-mesh, instead of requiring a dedicated full- mesh per service instance. The disadvantage of this interface, on the other hand, is the comparably excessive replication required in the core: Since a group of service instances share the same full-mesh of pseudowires, an unknown unicast, multicast or broadcast on a single service instance will result in a flood over the core. 4.2.1.1. O perational Modes There are three modes supported by this service interface: 4.2.1.1.1 Port Mode In this mode, all Ethernet traffic arriving on an Ethernet port is mapped into a single VPLS instance N. Another name for this is unqualified mode. 4.2.1.1.2 VLAN Mode In this mode, all traffic associated with a particular VLAN identified by the B- VID is mapped to a single VPLS instance N. This is known as qualified mode. 4.2.1.1.3 VLAN-bundle Mode In this mode, all traffic associated with a group or range of VLANs or B-VIDs are mapped to a single VPLS instance N. In theory, any VPLS PE supporting VLAN or Port Mode interfaces should be able to to support PBBN-VPLS Type I service interfaces. Indeed the fact that the PBBN frame is transporting an encapsulated customer MAC frame is completely transparent to the VPLS PE. The forwarding table for a particular VPLS instance is built using the procedures described in [RFC4762]. We note, however, that forwarding and learning is performed based on B-MAC addresses and not customer addresses as is the case with Sajassi, et al. [Page 11] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 [RFC4762]. We also observe that the use of B-MAC address space can lead to a reduction in the size of the MAC tables maintained on the PE. This is accomplished by encapsulating a larger pool of customer MAC addresses inside a smaller set of provider MAC addresses (B-MACs). This is effectively a form of hierarchical MAC address summarization where the mapping between customer MACs and provider B-MACs is maintained at the backbone edge bridges directly connected to customer devices. 4.2.1.2. Pseudowire Requirements Existing pseudowire signaling and encapsulation modes defined in [RFC4447][RFC4448] can be applied to PBBN frames sent and received over the type I service interface. Ethernet raw mode (0x0005) and VLAN tagged mode (0x0004) pseudowire types are supported for this service interface just like current VPLS. 4.2.2. PBBN-VPLS Type II Service Interface This is B-tagged service interface with I-SID as service delimiter. Similar to the type I service interface, as shown in figure 3, this service interface is applicable to Topology Variant A only. It connects a PBBN backbone core bridge (BCB) to a VPLS PE which is administratively part of the access network. The BCB and VPLS PE will exchange PBBN encapsulated frames that include source and destination B-MAC addresses, a B-VID and I-SID. What distinguishes this from type I service interface is the fact that the VPLS PE interprets I-SID as service delimiters (rather than B-VID). With Type II service interface, VPLS PE provides service-level interworking between PBBN and MPLS domains, since VPLS PE has visibility of I-SIDs. The disadvantage of this service interface, compared to type I, is that it may require a larger number of full-mesh pseudowires in the core. On the other hand, the advantage that this interface type has compared to type I is the potentially less replication in the core. This is mainly due to the increased segregation of service instances over disjoint full-meshes of pseudowires. It is expected that this interface type to be used for customers with significant multicast traffic so that a separate VPLS instance is setup per customer (per I-SID instance). It should be noted that a VPLS PE may support both type I & II service interface types over the same physical interface. 4.2.2.1. Operational Modes There are two modes supported by this service interface: 4.2.2.1.1 I-SID Mode In this mode, all traffic associated with a particular I-SID value is mapped to a single VPLS instance N. 4.2.2.1.2 I-SID Bundle Mode All traffic associated with a group or range of I-SID values are mapped to a single VPLS instance N. Sajassi, et al. [Page 12] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 The forwarding table requirements for this service interface are similar to those of type I service interface described earlier. We note that for I-SID and I-SID bundle modes, the larger I-SID space vis-à-vis the VLAN ID or B-VID enables the provider to potentially create a much larger set of VPLS instances. 4.2.2.2. Pseudowire Requirements It was noted earlier that with this interface type, I-SIDs are interpreted by the VPLS PE as service delimiters: Basically, for frames ingress from the PBBN, the I- SID is used to uniquely identify a VPLS instance on the PE and to uniquely identify the full-mesh of Pseudowires. Note that the fact that the I-SID space is global across B-VLANs makes it unnecessary to utilize (B-VID, I-SID) tuple as the VPLS instance identifier. It should be noted that, from the perspective of Pseudowires, the B-VID is considered to be the service delimiter while the I-SID is treated as part of the Ethernet payload. However, from the perspective of the PE, the I-SID is the actual service delimiter. This interpretation of I-SID and B- VID in the PE, makes it possible to reuse existing pseudowire types and only define a new type when absolutely required. 4.2.2.2.1 I-SID Mode Requirements In I-SID mode, each I-SID uniquely maps to a single VPLS instance. The B-VIDs are locally significant to a given PBBN access network; hence, they need not be transported in the pseudowire over the core. For this mode, two cases are to be considered: i) Access and core networks belong to the same administrative domain. In this case, I-SID translation is not required, and therefore existing pseudowire types can be used. In Ethernet raw mode (0x0005), the B-VLAN is removed by the VPLS PE on ingress to the pseudowire and added by the egress VPLS PE(s). In Ethernet tagged mode (0x0004), the B-VLAN is passed along by the ingress VPLS PE and rewritten by the egress VPLS PE(s), per normal tagged mode operation. ii)Access and core networks belong to different administrative domains. In this scenario, I-SID translation is required. To accommodate this, a new pseudowire type is defined that performs the following two functions on frames that exit the pseudowire: (1) translate the I-SID of the frames to the local I-SID value based on the associated service instance. And (2) add a B-VLAN to the frames based on the associated service instance. This scheme obviates the need to maintain an I-SID translation table per pseudowire as along as there is a single I-SID per pseudowire. We note here that performing I-SID translation at the egress point of the pseudowire is the only viable option if a single I-SID translation is to be performed in a given flow direction: It is not possible to perform the translation at the attachment circuit on the ingress VPLS PE simply because the translation is dependent on the destination network. Furthermore, it is not possible to perform the translation at the attachment circuit of the egress VPLS PE because the received I-SID can only be interpreted in the context of the pseudowire on which it was received. 4.2.2.2.2 I-SID Bundle Mode Requirements Sajassi, et al. [Page 13] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 In I-SID bundle mode, a group or range of I-SIDs map to a single VPLS instance. Again here, two cases are distinguished depending on whether the access and core networks lie within or across administrative domain boundaries: i) Access and core networks belong to the same administrative domain. In this case, I-SID translation is not required and I-SID bundling can be achieved via grouping I-SIDs within a B-VLAN and associating a VPLS instance with that B-VLAN. The pseudowire requirements for this scenario are similar to type I service interface. ii)Access and core networks belong to different administrative domains. Since I-SID translation is required in this case, bundling of I-SIDs over a single pseudowire mandates the use of a per-pseudowire I-SID translation table. The overhead associated with this approach is considerable; therefore, we shall not consider it any further. 4.2.3. PBBN-VPLS Type III Service Interface This is simply I-tagged service interface with I-SID as service delimiter. This service interface applies to Topology Variant B only. It connects a PBBN B-type backbone edge bridge (B-BEB) to a VPLS PE and is illustrated in figure 4. The VPLS PE is administratively part of the core network. By definition the B-BEB will remove any B-VLAN tags for frames exiting the PBBN domain because it is local to that domain. So what is exchanged between the B-BEB and VPLS PE are PBBN- encapsulated frames composed of source and destination B-MAC addresses and an I- SID. The service delimiter, as observed by the VPLS PE, in this case is the I-SID. This interface mode shares the same set of advantages and disadvantages as type II service interface. 4.2.3.1. Operational Modes There are three modes supported by this service interface: 4.2.3.1.1 Port Mode In this mode, all Ethernet traffic arriving on an Ethernet port is mapped into a single VPLS instance N. This exhibits the same behavior as a port mode type I service interface described earlier. In this mode, VPLS PE provides network-level interworking between PBBN and MPLS domains, since VPLS PE does not require visibility of I-SIDs. If I-SID visibility is required for the purpose of I-SID translation across different administrative domains, then it will be covered under I-SID bundling mode as all-to-one bundling. 4.2.3.1.2 I-SID Mode In this mode, all traffic associated with a particular I-SID value is mapped to a single VPLS instance N. In this mode, VPLS PE provides service-level interworking between PBBN and MPLS domains, since VPLS PE requires visibility of I-SIDs. 4.2.3.1.3 I-SID Bundle Mode In this mode, all traffic associated with a group or range of I-SID values are mapped to a single VPLS instance N. In this mode, VPLS PE provides service-level interworking between PBBN and MPLS domains, since VPLS PE requires visibility of I-SIDs. Sajassi, et al. [Page 14] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 4.2.3.2. Pseudowire Requirements The pseudowire type signaled depends on the services configured across the type III service interface. 4.2.3.2.1 Port Mode Requirements Port Mode can re-use the existing raw mode pseudowire type (0x0005) as is; so nothing new is needed here. VLAN tagged mode (0x0004) might also be used but with B-VID as the service delimiter, from the VPLS PE perspective. We note that in either case, the frame appearing on the wire between the PE and B-BEB will not contain a B-VID value. If both the access and core networks are under the same administrative domain, then I-SID consistency across the various networks eliminates any need for visibility or processing by the PEs of the I-SID values. If, on the other hand, the access and core networks fall into disparate administrative domains, then I-SID translation should be performed at the attachment circuits of the VPLS PEs (the Customer Backbone Ports connecting the VPLS PEs to the B-BEBs). As such, the PE is required to have B-Component functionality for I-SID remapping. Note that, even in this case, the I-SIDs continue to pass transparently over the pseudowire, and the existing pseudowire modes (raw and tagged) are applicable. 4.2.3.2.2 I-SID Mode Requirement In the case of I-SID mode where traffic belonging to a particular I-SID is mapped to a single VPLS instance, two scenarios are observed: i) Access and core networks fall under the same administrative domain; hence, I-SID translation is not needed. The existing Ethernet raw (0x0005) or tagged (0x0004) mode can be used in this case. If raw mode is used, the I- SIDs are passed transparently over the pseudowire. If tagged mode is used, the ingress PE should append a local B-VID that may correspond to the I-SID. This B-VID is removed by the egress PE. We note here that even though tagged or raw mode pseudowire operation is based on the B-VLAN, the VPLS instance and associated full-mesh of pseudowires corresponds to a unique I-SID. ii)Access and core networks correspond to different administrative domains; hence, it is required to perform I-SID translation. In this scenario, the translation should be performed at the attachment circuits of the VPLS PEs (the Customer Backbone Ports connecting the VPLS PEs to the B-BEBs). This translation is symmetric, in a sense that it applies to both ingress and egress frames. As such, no I-SID translation is required on egress from the pseudowire. We note that this scheme has two advantages: (1) The existing Ethernet raw and tagged pseudowire modes can be employed, with the procedures described in the previous scenario; and (2) a single VPLS PE will be capable of supporting multiple access network domains. 4.2.3.2.3 I-SID Bundle Mode Requirements In the case of I-SID bundling mode where a range or group of I-SID values are mapped to a single VPLS instance, the PE maintains a local mapping of each I-SID group or range to a single B-VID. The VPLS instance, with associated full mesh of pseudowires, is then associated with that B-VID. For this mode, no new pseudowire Sajassi, et al. [Page 15] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 type is required. There’s a choice of using either the Ethernet raw or tagged mode. If raw mode is used, the local B-VIDs are not carried over the pseudowires and the I-SIDs pass transparently. If tagged mode is employed, then the ingress PE appends its local B-VID that corresponds to the group or range of I-SIDs, and the egress PE remaps it to its local value. Note that the egress PE will send frames towards the B-BEB without the local B-VID. We observe two scenarios here: i) Access and core networks are under the same administrative domain. In this case, the I-SID is ubiquitous and passes transparently end to end. ii)Access and core networks belong to different administrative domains. In this scenario, it is assumed that the core network is one administrative domain and uses a single I-SID space. For purpose of maintaining consistency with IEEE 802.1ah, the I-SID translation should be performed on the attachment circuit of the VPLS PE for traffic ingress onto the core network; and, on the B-BEB port that connects to the VPLS PE for traffic ingress onto the access network. This 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. This concludes the discussion of PBB in H-VPLS with Ethernet access. In the next section, we will shift focus to look into how PBB technology interoperates with H- VPLS in the case of MPLS access network. 5. H-VPLS with MPLS Access Network In the previous section, we described various interoperability scenarios for H- VPLS with PBBN as Ethernet access network. We now shift focus to the case where the access network is MPLS and U-PE nodes support PBB function. The objective for incorporating PBB function at the U-PE is to improve the scalability of H-VPLS networks in terms of the numbers of MAC addresses and service instances that are supported. In current H-VPLS, the N-PE must learn customer MAC addresses (C-MACs) of all VPLS instances that it participates in. This can easily add-up to hundreds of thousands or even millions of C-MACs at the N-PE. When the U-PE performs 802.1ah encapsulation, the N-PE only needs to learn the MAC addresses of the U-PEs, which is a significant reduction. Furthermore, when 802.1ah encapsulation is used, many I-SIDs are multiplexed within a single B-VLAN. If the VPLS instance is set up per B-VLAN (instead of per I-SID), then one can also achieve a significant reduction in the number of pseudowires. It should be noted that this reduction in pseudowires comes at the cost of potentially increased replication over the pseudowire full-mesh: A given customer multicast and/or broadcast frames are effectively broadcasted within the B-VLAN. This may result in additional frame replication because the full-mesh of pseudowires corresponding to a B-VLAN is most likely bigger than the full-mesh of pseudowires corresponding to a single I-SID. Sajassi, et al. [Page 16] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 However, if one supports VPLS multicast data via MPLS P2MP tunnels, then this drawback goes away. Figure 5 below illustrates the scenario for H-VPLS with MPLS access. As it can be seen, customer networks or hosts (CE) connect into the U-PE nodes using standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS pseudowires (per VPLS instance). These, in turn, are connected via a full-mesh of pseudowires (per VPLS instance) traversing the IP/MPLS backbone. The U-PE is outfitted with PBB BEB functions where it can encapsulate/ decapsulate customer MAC frames in provider B-MAC addresses and perform I-SID translation if needed. PBB PBB BEB +----------+ BEB | | | | | +-----------+ | IP | +-----------+ | | | MPLS | | MPLS | | MPLS | | V | Access +----+ | Core | +----+ Access | V +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| +--+ +----+ +----+ | | +----+ +----+ +--+ | | | | | | +-----------+ +----------+ +-----------+ Figure 5: H-VPLS with MPLS Access Network and PBBN U-PE We also note that the U-PE and N-PE are members of the same administrative domain. However, different MPLS access networks can be part of the same or separate administrative domains. We will describe both cases shortly. 5.1. Supported Services The U-PE still provides the same type of services toward its customers as before and they are: i) Port mode (either 802.1D, 802.1Q, or 802.1ad) ii)VLAN mode (either 802.1Q or 802.1ad) iii) VLAN-bundling mode (either 802.1Q or 802.1ad) By incorporating PBB function, the U-PE maps each of these services (for a given customer) onto a single I-SID based on the configuration at the U-PE. Many I-SIDs are multiplexed within a single B-VLAN. The U-PE can, then, either map a single I- SID into a VPLS instance or it can map a B-VLAN onto a VPLS instance, according to its configuration. Next, the encapsulated frames are sent over the pseudowire associated with that VPLS instance. If the B-VID is used as the service delimiter, then the entire Ethernet bridging operation over VPLS network is performed as defined in [RFC4762]. In other words, MAC forwarding is based on the B-MAC address space and service delimiter is based Sajassi, et al. [Page 17] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 on VLAN ID, which is B-VID in this case. There is no need to inspect or deal with I-SID values. If the I-SID is used as the service delimiter, then the single and multiple domain cases must be considered as described in the following sections. This is primarily because I-SID values are assigned on a per-domain basis. In summary, the ingress U-PE receives a customer MAC frame. It imposes the appropriate PBB header information and then performs standard bridge-capable U-PE processing functions, including switching the frame locally or forwarding it to the N-PE. The egress U-PE will remove the pseudowire label, perform any relevant processing of the PBB header (e.g. I-SID translation if required) and then hand the frame to the PBB bridge component for 802.1ah processing. 5.2. U-PE Operation in a Single Domain In this scenario, I-SID assignment is performed globally across all MPLS access networks. Thus there is no need to perform any sort of I-SID translation at the U- PE. The pseudowire type established between the U-PE and N-PE can be raw or tagged mode with the corresponding B-VID rewrite or translation performed at the various PE nodes. 5.3. U-PE Operation in Multiple Domains In this scenario, I-SID assignment is performed on a per-MPLS access network basis. The U-PE nodes are the only nodes that are I-SID aware; so, it will be up to them to perform the translation as frames are forwarded between different administrative domains. At the ingress U-PE, during the PBBN encapsulation process, an I-SID value is added. A new pseudowire type (described in section 3.2.2.2.2) will be required to transport I-SID tagged payloads between the U-PE and N-PE. The one-to-one mapping between this I-SID value and the pseudowire enables the receiving N-PE and U-PE to infer which VPLS instance the frame belongs to. When the encapsulated PBBN frames reach the egress U-PE, the pseudowire label is removed and then the appropriate I-SID translation is performed. In this case, it is taking the I-SID originally assigned and imposed by the U-PE nodes (in MPLS access network #1) and translating it to the I-SID value assigned to MPLS access network #2. Once this is completed, the frame is handed off to the PBBN BEB for normal processing. 5.4. Pseudowire Requirements This section summarizes the pseudowire requirements that were identified in the three previous sub-sections. To recap, these requirements differ depending on Sajassi, et al. [Page 18] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 whether the U-PE uses the B-VID or I-SID as a service delimiter; and, in the latter case, the requirements can be further distinguished based on whether the network comprises of a single or multiple administrative domains. These scenarios are described next. 5.4.1. Requirements with B-VID as Service Delimiter In this scenario, existing pseudowire raw and tagged modes can be used. There are no new requirements. 5.4.2. Requirements with I-SID as Service Delimiter In this case, the requirements differ depending on whether the network comprises of a single or multiple administrative domains. The details of each are described in the following subsections. 5.4.2.1. Single Administrative Domain Network In this case, I-SID translation is not required. Therefore, existing pseudowire raw and tagged modes can be used. There are no new requirements for this case. 5.4.2.2. Multiple Administrative Domain Network In this scenario, I-SID translation is required. Therefore, the pseudowire requirements are similar to those identified in section 3.2.2.2.2. 6. Acknowledgments 7. Security Considerations There are no additional security aspects beyond that of VPLS/H-VPLS that needs to be discussed here. 8. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 9. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on Sajassi, et al. [Page 19] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 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. 10. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 11. Normative References [RFC4762] Lasserre, M. and et al, ‘‘Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling’’, Proposed Standard, January 2007. [RFC4447] Martini, L. and et al, ‘‘Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)’’, Proposed Standard, April 2006. [RFC4448] Martini, L. and et al, ‘‘Encapsulation Methods for Transport of Ethernet over MPLS Networks’’, Proposed Standard, April 2006. [RFC4665] Agustyn, W. et al, "Service Requirements for Layer-2 Provider Provisioned Virtual Provider Networks", Proposed Standard, September 2006. Sajassi, et al. [Page 20] draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007 [RFC4664] Andersson, L. and et al, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Proposed Standard, September 2006. [P802.1ad] IEEE Draft P802.1ad/D2.4 ‘‘Virtual Bridged Local Area Networks: Provider Bridges’’, Work in progress, September 2004 [P802.1ag] IEEE Draft P802.1ag/D0.1 ‘‘Virtual Bridge Local Area Networks: Connectivity Fault Management’’, Work in Progress, October 2004 12. Informative References [802.1D-REV] IEEE Std. 802.1D-2003 ‘‘Media Access Control (MAC) Bridges’’. [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area Networks". 13. Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Email: ssalam@cisco.com Chris Metz Cisco 170 West Tasman Drive San Jose, CA 95134 Email: metz@cisco.com Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Dinesh Mohan Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 Email: mohand@nortel.com Sajassi, et al. [Page 21]