Internet Working Group Ali Sajassi Internet Draft Samer Salam Chris Metz Cisco Nabil Bitar Verizon Dinesh Mohan Nortel Expires: February 2008 July 2007 VPLS Interoperability with Provider Backbone Bridges draft-sajassi-l2vpn-vpls-pbb-interop-01.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- Sajassi, et. al. [Page 1] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. 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.....................................................3 2. Overview........................................................4 3. Background: Provider Backbone Bridges...........................5 3.1. S-Tagged Service Interface....................................7 3.2. I-Tagged Service Interface....................................8 3.3. B-Tagged Service Interface....................................8 4. H-VPLS with PBB Access Network..................................8 4.1. Network Topologies............................................9 4.1.1. Topology Variant A..........................................9 4.1.2. Topology Variant B.........................................10 4.2. Service Interfaces & Interworking Options....................11 4.2.1. PBBN-VPLS Type I Service Interface.........................12 4.2.2. PBBN-VPLS Type II Service Interface........................14 4.2.3. PBBN-VPLS Type III Service Interface.......................16 5. H-VPLS with mixed Q-in-Q and PBB Access Networks...............19 5.1. Supported Services...........................................20 5.1.1. Single Administrative Domain Operation.....................21 5.1.2. Multiple Administrative Domains Operation..................21 5.2. Pseudowire Requirements......................................22 5.2.1. Requirements with B-VID as Service Delimiter...............22 5.2.2. Requirements with I-SID as Service Delimiter...............22 6. H-VPLS with MPLS Access Network................................22 6.1. Supported Services...........................................23 6.2. U-PE Operation in a Single Domain............................24 6.3. U-PE Operation in Multiple Domains...........................24 6.4. Pseudowire Requirements......................................25 6.4.1. Requirements with B-VID as Service Delimiter...............25 6.4.2. Requirements with I-SID as Service Delimiter...............25 7. Security Considerations........................................25 8. Intellectual Property Considerations...........................25 Sajassi, et al. [Page 2] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 9. Full Copyright Statement.......................................25 10. IPR Notice....................................................26 11. Normative References..........................................26 12. Informative References........................................27 13. Authors' Addresses............................................27 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 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. [Page 3] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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 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 Sajassi, et al. [Page 4] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. These issues are also highlighted in the [VPLS-Bridge]. 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 service 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 Q-in-Q access network respectively. Section 5 discusses PBB interoperability for H-VPLS with MPLS access network. 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. 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 Sajassi, et al. [Page 5] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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 Sajassi, et al. [Page 6] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 consists of both I & B components, then it is called IB-BEB and if it only consists of either B-component or I-component, then it is called B-BEB or I-BEB respectively. The interface between an I-BEB or IB-BEB and a CE is called S-tagged service interface and the interface between an I-BEB and a B-BEB (or between two B-BEBs) is called I-tagged service interface. The interface between a B-BEB or IB-BEB and a Backbone Core Bridge (BCB) is called B-Tagged service interface. These service interfaces, for Provider Backbone Bridges, are described next. +-------------------------------+ | 802.1ah Bridge Model | | | +---+ | +------+ +-----------+ | |CE |---------|I-Comp|------| | | +---+ | | | | |-------- | +------+ | | | | o | B-Comp | | | o | |-------- | o | | | +---+ | +------+ | | | |CE |---------|I-Comp|------| |-------- +---+ ^ | | | ^ | | | ^ | | +------+ | +-----------+ | | | +------------|------------------+ | | | | | | | S-tagged I-tagged B-tagged Service I/F Service I/F Service I/F Figure 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 I-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. Sajassi, et al. [Page 7] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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-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 sections 4 and 5. Then, in section 6, 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. Sajassi, et al. [Page 8] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 At this point, it is important to define the notion of 'service domains' as being used in the context of this discussion: Two (or more) networks are considered to be in the same service 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 service 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 service 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 service domains by employing I-SID (and B- VLAN) translations. 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 Sajassi, et al. [Page 9] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 Given that the VPLS PE is part of the access PBBN, it will be connected to a BCB directly. In scenarios where different 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. 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 MPLS 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 MPLS core network Sajassi, et al. [Page 10] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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 service 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. 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 Sajassi, et al. [Page 11] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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 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, though it is transparent to I- SID. 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. As such, Type I service interface is only applicable for the scenario where the access and MPLS core networks all belong to the same service domain. If those networks were to belong to multiple domains, then I-SID translation becomes mandatory and the VPLS PE is required to have I-SID level visibility. One of 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. Another advantage is the MAC address scalability in the core since the core is not exposed to C-MACs. The disadvantage of this interface, on the other hand, is the comparably Sajassi, et al. [Page 12] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. This, however, can be mitigated via the use of P2MP LSP [VPLS-MCAST] for VPLS multicast/broadcast traffic. 4.2.1.1. Operational 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. It is assumed that the assignment of B-VLANs is ubiquitous across the network for both port and vlan bundling modes of operation. In theory, any VPLS PE supporting VLAN or Port Mode interfaces should be able 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 [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 Sajassi, et al. [Page 13] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. However, the number of full-mesh psuedowires can still be less than those required by H-VPLS without PBBN. 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 set up 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: I-SID and I-SID bundle. We note that Port mode for Type II interface is, in practice, indiscernible from Port mode for Type I interface. As such, it is not considered as a stand-alone mode of operation for 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 Sajassi, et al. [Page 14] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 All traffic associated with a group or range of I-SID values are mapped to a single VPLS instance N. 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. 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. A new pseudowire type is used for the I-SID mode where the I-tagged frame (802.1ah frame without a B-VID) is transported over the pseudowire and the I-SID is used as a service delimiter. This pseudowire mode is analogous to tagged mode except the fact that I- SID instead of 802.1Q VLAN-ID is used as service delimiter. This new pseudowire type is defined in [PBB-PW]. It should be noted that the addition of B-VLAN tag (B-Tag) to an I-tagged frame is considered a local function and it may or may not be required. If it is required, then the PE is configured so that it adds a B-tag to the frame received over the pseudowire. For this mode, two cases are to be considered: i) Access and MPLS core networks belong to the same service domain. In this case, I-SID translation is not required, and therefore I-SID translation need not be performed on the I- tagged frames received over the pseudowire at the egress PE. ii) Access and MPLS core networks belong to different service domains. In this scenario, I-SID translation is required. Therefore, the egress PE should rewrite the I-SID value of an I-tagged frame, received over the pseudowire, with a locally configured I-SID value. In order to simplify the new pseudowire operation and avoid any unnecessary negotiation, the I-SID rewrite MUST always be performed at the egress PE. 4.2.2.2.2 I-SID Bundle Mode Requirements 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 Sajassi, et al. [Page 15] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 whether the access and core networks lie within or across service domain boundaries: i) Access and core networks belong to the same service 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 service 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 MPLS 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 service domains, then it will be covered under I-SID bundling mode as all-to-one bundling. Sajassi, et al. [Page 16] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. 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) can 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 service 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 service domains, then I-SID translation is necessary, and I-SID all-to-one bundling mode should be used instead. 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 service domain; hence, I-SID translation is not needed. In this scenario the new pseudowire type per section 4.2.2.2.1 is used but without the need for any I-SID rewrite at the egress PE. ii) Access and core networks correspond to different service domains; hence, it is required to perform I-SID translation. In this scenario, the translation is performed at the Attachment Circuits of the VPLS PEs or at the Customer Backbone Ports of Sajassi, et al. [Page 17] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 the B-BEBs (the interfaces that connect the B-BEBs to the VPLS PEs). This translation is symmetric, in a sense that it applies to both ingress and egress frames. In this scenario, the new pseudowire type per section 4.2.2.2.1 is also used. Note that there is no need for any I-SID rewrite at the egress of the pseudowire because I-SID translation is performed at the Attachment Circuits or at the Customer Backbone Ports. We note that this scheme has the advantage of allowing a single VPLS PE to support multiple access network domains. If, for a given VPLS instance, the VPLS PE only needs to interface to a single PBBN service domain, then I-SID translation can be performed at the egress of the pseudowire and, thus, the requirement for I- SID translation table at the Attachment Circuit (or Customer Backbone Port) can be lifted. 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 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 MPLS core networks are under the same service domain. In this case, the I-SID is ubiquitous and passes transparently end to end. ii) Access and MPLS core networks belong to different service domains. In this scenario, it is assumed that the MPLS core network is one service domain and uses a single I-SID space. The I-SID translation should be performed either on the Attachment Circuit of the VPLS PE or on the Customer Backbone Port of the B-BEB (the port that connects to the VPLS PE). In either case, the translation must be symmetric, i.e. applied to both ingress and egress frames. 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 Sajassi, et al. [Page 18] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 different PEs, then I-SID mode should be chosen over I-SID bundling mode, for it provides maximum flexibility. In the next section, we will look into another flavor of H-VPLS with Ethernet access networks where at least one of the access networks employs Provider Bridges (Q-in-Q or IEEE 802.1ad) whereas the others are PBBNs. 5. H-VPLS with mixed Q-in-Q and PBB Access Networks It is foreseeable that service providers will want to interoperate their existing Q-in-Q access networks with PBBNs over VPLS. Figure 5 below shows the high-level network topology. +--------------+ | | +---------+ | IP/MPLS | +---------+ +----+ | | +----+ +----+ | | +----+ | CE |--| | |VPLS| |VPLS| | |--| CE | +----+ | Q-in-Q |---| PE1| | PE2|--| PBBN | +----+ +----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+ | CE |--| | | Backbone | | |--| CE | +----+ +---------+ +--------------+ +---------+ +----+ Figure 5: H-VPLS with Mixed Q-in-Q and PBB Access Networks Referring to the figure above, the operation of VPLS PE2 (connecting to the PBB access network on the right) is no different from what was discussed in section 4 above. It is the behavior of VPLS PE1 (connecting to the Q-in-Q access network on the left) that is the subject and focus of this section. The specifics of the PE behavior differ depending on whether the Q-in-Q access network is a stand- alone service domain which is different from the MPLS network, or whether the entire network is a single service domain. In either case, we will only explore the scenario where the VPLS PE is administratively part of the Q-in-Q access network. The case where the VPLS PE is administratively not part of the Q-in-Q access network will not be studied at this point as it is not common or expected to be desirable by service providers. Figure 6 below shows a more detailed network diagram, with associated frame formats. Sajassi, et al. [Page 19] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 |C-MAC| |B-MAC| |S-VID| |B-VID| |C-VID| |I-SID| |CUST | |CUST | |DATA | |MAC | |C-MAC| | | |FRAME| |C-VID| | | |CUST | | | |DATA | | +---------+ | | | | | | | +------------|-------+| IP |+-------|------------+ v | Q-in-Q | || MPLS || | PBB Access | | Access V || Core || V Network | | Network +----+|| ||+----+ | +--+ |+---+ +---+ |VPLS||| |||VPLS| +---+ +---+| +--+ |CE|-||PEB| |PCB|---| PE1||| ||| PE2|---|BCB| |BEB||-|CE| +--+ |+---+ +---+ +----+|| ||+----+ ^ +---+ +---+| +--+ +--------------------+| |+-------|------------+ +---------+ | | Type I & II Figure 6: VPLS PE part of Q-in-Q access network In section 5.1, we describe the services supported by the VPLS PE, and in section 5.2, we discuss the pseudowire requirements. 5.1. Supported Services The VPLS PE offers an S-Tagged interface that can operate in one of three modes: i) Port Mode. In this mode, all frames ingress on the port are mapped to the same I-SID. ii) VLAN Mode. In this mode, every S-Tag is mapped to its own I- SID. iii) VLAN Bundling Mode. In this mode, a range or list of S-Tags are mapped to a single I-SID. Sajassi, et al. [Page 20] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 After performing the S-Tag to I-SID mapping, per one of the modes above, the I-SIDs are multiplexed within a B-Tag. The PE, then, has the option of either mapping a B-Tag to a VPLS instance or each I- SID to a VPLS instance. Note that depending on whether or not the entire network is a single service domain, some of the above modes may not be applicable. We will explore this in the following sub-sections. 5.1.1. Single Service Domain Operation When the entire network comprises of a single service domain, all three interface modes described above are applicable, namely: port mode, vlan mode and vlan bundling mode. In port mode of operation, the ingress PE retains the S-Tag on the frames and adds a per-port I-SID. The PE, then, multiplexes the I- SID over a B-Tag and either maps the B-Tag to a VPLS instance per section 4.2.1, or maps the I-SID to a VPLS instance per the procedures discussed in section 4.2.2. Note that the S-Tag is retained on the frame to allow for proper de-multiplexing on the egress PE. In vlan mode of operation, the ingress PE translates the S-Tag on the frame to a unique I-SID. The S-Tag is removed from the frame when passed over the pseudowire, as it conveys no extra information. The PE multiplexes the I-SID over a B-tag and then maps either the B-Tag or the I-SID to a VPLS instance per the procedures of sections 4.2.1 and 4.2.2 respectively. In vlan bundling mode of operation, the ingress PE bundles a range or list of S-Tags over a single I-SID. The S-Tag is retained on the frame to allow for de-multiplexing on the egress PE. The mapping of B-Tag or I-SID to VPLS instance is similar to the previous two modes. 5.1.2. Multiple Service Domains Operation In this scenario, VPLS PE1 is in a different service domain than VPLS PE2. Therefore, I-SID translation needs to be performed between the two domains. In order to achieve this translation easily, a one- to-one mapping between I-SID and VPLS instance is used as described in section 4.2.2.2.1 case ii. If aggregation of I-SIDs inside a single VPLS instance is required, then that would mandate the need for an I-SID translation table for each pseudowire which is not considered here because of its added complexity. We note that if the Q-in-Q access network is a client network of the VPLS, then all three interface modes (port, VLAN and VLAN bundling) are applicable for multiple service domain operation. However, if the Q-in-Q access network interprets the S-Tag as a local service delimiter, then only VLAN mode of operation is allowed. This is Sajassi, et al. [Page 21] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 because it is the only mode that does not require that the S-Tag be transported over the pseudowire. 5.2. Pseudowire Requirements The pseudowire requirements depend on whether the PE maps the B-VID or I-SID to a VPLS instance; i.e., whether the B-VID or I-SID is a service delimiter, respectively. The two cases are explored next. 5.2.1. Requirements with B-VID as Service Delimiter There are no new pseudowire requirements for this case. Existing pseudowire raw and tagged modes can be used as is. 5.2.2. Requirements with I-SID as Service Delimiter For this case, a new pseudowire type is used to carry I-tagged frame over the pseudowire with I-SID as service delimiter per section 4.2.2.2.1. 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. 6. H-VPLS with MPLS Access Network In the previous two sections, 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), 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 Sajassi, et al. [Page 22] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 corresponding to a single I-SID. However, if one supports VPLS multicast data via MPLS P2MP tunnels, then this drawback goes away. Figure 7 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 7: 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 service domain. However, different MPLS access networks can be part of the same or separate service domains. We describe both cases below. 6.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. Sajassi, et al. [Page 23] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 If the B-VID is used as the service delimiter, then the entire Ethernet bridging operation over VPLS network is performed as defined in [RFC4762]. In other words, MAC forwarding is based on the B-MAC address space and service delimiter is based on VLAN ID, which is B-VID in this case. There is no need to inspect or deal with I- SID values. If the I-SID is used as the service delimiter, then the single and multiple 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. 6.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. Alternatively, the new pseudowire type described in section 4.2.2.2.1 can be utilized, without the need for I-SID translation. 6.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 service domains. At the ingress U-PE, during the PBBN encapsulation process, an I-SID value is added. A new pseudowire type (described in section 4.2.2.2.1) 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 Sajassi, et al. [Page 24] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. 6.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 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 service domains. These scenarios are described next. 6.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. 6.4.2. Requirements with I-SID as Service Delimiter For this case, a new pseudowire type is used to carry I-tagged frame over the pseudowire with I-SID as service delimiter per section 4.2.2.2.1. We note that the pseudowire type used should be uniform and consistent across both the access and core networks. In other words, the access pseudowires between the uPEs and nPEs as well as the full mesh of core pseudowires between the nPEs should all share the same pseudowire type. 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 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Sajassi, et al. [Page 25] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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. Sajassi, et al. [Page 26] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 [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. [RFC4664] Andersson, L. and et al, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Proposed Standard, September 2006. [P802.1ad] IEEE Draft P802.1ad, "Virtual Bridged Local Area Networks: Provider Bridges", December 2005. [P802.1ag] IEEE Draft P802.1ag/D8.1, "Virtual Bridge Local Area Networks: Connectivity Fault Management", Work in Progress, June 2007 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". [VPLS-Bridge] Sajassi, A. and et al, "VPLS Interoperability with CE Bridges", Work in progress, November 2006 [PBB-PW] Martini, L. and et al, "802.1ah Ethernet Pseudowire", Work in progress, May 2007 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 Sajassi, et al. [Page 27] draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007 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 28]