[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-ietf-l2vpn-vpls-pbb-interop) 00 01 02 03 04 05 06 RFC 7080

   Internet-Draft                                          Ali Sajassi
   L2VPN Working Group                                     Samer Salam
                                                             Chris Metz
                                                                  Cisco
 
                                                            Nabil Bitar
   Intended status: Standards                                  Verizon
 
                                                           Dinesh Mohan
                                                                Nortel
 
                                                          Florin Balus
                                                        Alcatel-Lucent
 
   Expires: July 5, 2010                               January 5, 2010
 
 
 
 
           VPLS Interoperability with Provider Backbone Bridges
                 draft-ietf-l2vpn-pbb-vpls-interop-00.txt
 
 
 
   Status of this Memo
 
   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.
 
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
 
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
 
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
 
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
 
   This Internet-Draft will expire on July 5, 2010.
 
   Copyright Notice
 
   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.
 
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 1]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.
 
 
 
   Abstract
 
   The scalability of H-VPLS with Ethernet access network can be
   improved by incorporating Provider Backbone Bridge functionality in
   VPLS access. Provider Backbone Bridging has been standardized as
   IEEE 802.1ah-2008, and aims to improve the scalability of MAC
   addresses and service instances in Provider Ethernet networks. This
   document describes different interoperability scenarios where
   Provider Backbone Bridge functionality is used in H-VPLS with
   Ethernet or MPLS access network to attain better scalability in
   terms of number of customer MAC addresses and number of service
   instances. The document also describes the scenarios and the
   mechanisms for incorporating Provider Backbone Bridge functionality
   within H-VPLS with existing Ethernet access and interoperability
   among them. Furthermore, the document discusses the migration
   mechanisms and scenarios by which Provider Backbone Bridge
   functionality can be incorporated into H-VPLS with existing MPLS
   access.
 
 
  Conventions used in this document
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.
 
 
   Table of Contents
 
   Conventions used in this document.................................. 2
   1. Introduction.................................................... 3
   2. Applicability................................................... 4
   3. Terminology..................................................... 4
   4. H-VPLS with Homogeneous PBBN Access............................. 6
   4.1 Service Interfaces and Interworking Options.................... 8
   4.2 H-VPLS with PBBN Access: Type I Service Interface.............. 9
   4.3 H-VPLS with PBBN Access: Type II Service Interface............ 10
   5. H-VPLS with Mixed PBBN Access and PBN Access................... 13
   5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE.......... 13
   5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE........... 14
   6. H-VPLS with MPLS Access........................................ 15
   6.1 H-VPLS with MPLS Access: PBB U-PE............................. 15
   6.1.1 PBB U-PEs in Single I-SID Domain............................ 17
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 2]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   6.2 H-VPLS with MPLS Access: PBB N-PE............................. 17
   6.2.1 PBB N-PEs in Single I-SID Domain............................ 18
   7. H-VPLS with MPLS Access: PBB Migration Scenarios............... 19
   7.1 802.1ad Service Frames over VPLS Core......................... 19
   7.2     PBB Service Frames over VPLS Core ........................ 20
   7.3     Mixed 802.1ad and PBB over VPLS Core ..................... 20
   8. Acknowledgments................................................ 22
   9. IANA Considerations............................................ 22
   10. Security Considerations....................................... 22
   11. References.................................................... 22
   11.1 Normative References......................................... 22
   11.2 Informative References....................................... 22
   Authors' Addresses................................................ 23
 
 
  1. Introduction
 
   The scalability of H-VPLS with Ethernet access network can be
   improved by incorporating Provider Backbone Bridge functionality in
   the VPLS access. Provider Backbone Bridging has been standardized as
   IEEE 802.1ah-2008, which is an amendment to IEEE 802.1Q to improve
   the scalability of MAC addresses and service instances in Provider
   Ethernet networks. This document describes interoperability
   scenarios where IEEE 802.1ah functionality is used in H-VPLS with
   Ethernet or MPLS access network to attain better scalability in
   terms of the number of customer MAC addresses and the number of
   services. This document also describes the scenarios and the
   mechanisms for incorporating Provider Backbone Bridging
   functionality within H-VPLS with existing IEEE 802.1ad Ethernet
   access and interoperability among them. Furthermore, this document
   discusses the migration mechanisms and scenarios by which Provider
   Backbone Bridging functionality can be incorporated into H-VPLS with
   existing MPLS access.
 
   This document also covers the interoperability scenarios for
   deploying H-VPLS with Provider Backbone Bridging Ethernet access
   when other types of access networks are deployed, including existing
   802.1ad Ethernet access in either single or multiple service
   domains. Furthermore, the document explores the scenarios by which
   an operator can gradually migrate an existing H-VPLS network to
   Provider Backbone Bridging over VPLS.
 
   Section 2 highlights the applicability of Provider Backbone Bridging
   interoperation with VPLS. Section 3 gives a quick terminology
   reference. Section 4 describes H-VPLS with homogeneous Provider
   Backbone Bridge Access Network. Section 5 discusses H-VPLS with
   mixed 802.1ah/802.1ad access. Section 6 focuses on Provider Backbone
   Bridging in H-VPLS with MPLS Access Network including Provider
   Backbone Bridge function on U-PE and on N-PE variants. Finally,
   section 7 describes gradual migration scenarios from existing H-VPLS
   to Provider Backbone Bridging over H-VPLS.
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 3]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
 
 
  2. Applicability
 
   [RFC4762] describes a two-tier hierarchical solution for VPLS for
   the purpose of improved pseudowire (PW) scalability. This
   improvement is achieved by reducing the number of PE devices
   connected in a full-mesh topology through connecting CE devices via
   the lower-tier access network, which in turn is connected to the
   top-tier core network. [RFC4762] describes two types of H-VPLS
   network topologies - one with MPLS access network and another with
   IEEE 802.1ad (QinQ) Ethernet access network. In both types of H-
   VPLS, MAC address learning and forwarding are done based on customer
   MAC addresses (C-MACs), which poses scalability issues as the number
   of VPLS instances (and thus customer MAC addresses) increases.
   Furthermore, since a set of PWs is maintained on a per customer
   service instance basis, the number of PWs required at N-PE devices
   is proportional to the number of customer service instances
   multiplied by the number of N-PE devices in the full-mesh set. This
   can result in scalability issues (in terms of PW manageability and
   troubleshooting) as the number of customer service instances grows.
 
   In addition to the above, H-VPLS with 802.1ad Ethernet access
   network has another scalability issue in terms of the maximum number
   of service instances that can be supported in the access network as
   described in [RFC4762]. Since the number of provider VLANs (S-VLANs)
   is limited to 4K and each S-VLAN represents a service instance in an
   802.1ad network, then the maximum number of service instances that
   can be supported is 4K. These issues are highlighted in [VPLS-
   Bridge].
 
   This document describes how IEEE 802.1ah (aka Provider Backbone
   Bridges) can be integrated with H-VPLS to address these scalability
   issues. In case of H-VPLS with 802.1ah Ethernet access, the solution
   results in better scalability in terms of both number of service
   instances and number of C-MACs in the Ethernet access network and
   the VPLS core network, as well as number of PWs in VPLS core
   network. And in case of H-VPLS with MPLS access, Provider Backbone
   Bridging functionality can be used at the U-PE or N-PE which results
   in reduction of customer MAC addresses and number of PWs in the VPLS
   core network.
 
   The interoperability scenarios depicted in this document fall into
   the following two categories:
     - Scenarios where Provider Backbone Bridging seamlessly works
        with current VPLS implementations (e.g. section 4.2).
     - Scenarios where VPLS PE implementations need to be upgraded in
        order to work with Provider Backbone Bridging (e.g. sections
        4.3, 5.1).
 
  3. Terminology
 
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 4]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   802.1ad: IEEE specification for "QinQ" encapsulation and bridging of
   Ethernet frames
 
   802.1ah: IEEE specification for "MAC tunneling" encapsulation and
   bridging of frames across a provider backbone bridged network.
 
   B-BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It contains a B-component that supports
   bridging in the provider backbone based on B-MAC and B-TAG
   information
 
   B-MAC: The backbone source or destination MAC address fields defined
   in the 802.1ah provider MAC encapsulation header.
 
   BCB: A backbone core bridge running in the core of a provider
   backbone bridged network. It bridges frames based on B-TAG
   information just as an 802.1ad provider bridge will bridge frames
   based on a VLAN identifier (S-VLAN)
 
   BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It can contain an I-component, B-component
   or both I and B components.
 
   B-TAG:  field defined in the 802.1ah provider MAC encapsulation
   header that conveys the backbone VLAN identifier information. The
   format of the B-TAG field is the same as that of an 802.1ad S-TAG
   field.
 
   B-Tagged Service Interface: This is the interface between a BEB and
   BCB in a provider backbone bridged network. Frames passed through
   this interface contain a B-TAG field.
 
   B-VID: The specific VLAN identifier carried inside a B-TAG
 
   I-component: A bridging component contained in a backbone edge
   bridge that bridges in the customer space (customer MAC addresses,
   S-VLAN)
 
   IB-BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It contains an I-component for bridging in
   the customer space (customer MAC addresses, service VLAN IDs) and a
   B-component for bridging the provider's backbone space (B-MAC, B-
   TAG).
 
   I-BEB: A backbone edge bridged positioned at the edge of a provider
   backbone bridged network. It contains an I-component for bridging in
   the customer space (customer MAC addresses, service VLAN IDs).
 
   I-SID: The 24-bit service instance field carried inside the I-TAG.
   I-SID defines the service instance that the frame should be "mapped
   to".
 
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 5]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   I-TAG: A field defined in the 802.1ah provider MAC encapsulation
   header that conveys the service instance information (I-SID)
   associated with the frame.
 
   I-Tagged Service Interface: This the interface defined between the I
   and B components inside an IB-BEB or between two B-BEB. Frames
   passed through this interface contain an I-TAG field
 
   PBB: Provider Backbone Bridge
 
   PBBN: Provider Backbone Bridged Network
 
   PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ)
   technology.
 
   S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
   conveys the service VLAN identifier information (S-VLAN).
 
   S-Tagged Service Interface: This the interface defined between the
   customer (CE) and the I-BEB or IB-BEB components. Frames passed
   through this interface contain an S-TAG field.
 
   S-VLAN: The specific service VLAN identifier carried inside an S-TAG
 
 
  4. H-VPLS with Homogeneous PBBN Access
 
   PBBN access offers MAC-address table scalability for H-VPLS PE
   nodes. This is due to the MAC tunneling encapsulation scheme of PBB
   which only exposes the provider's own MAC addresses to PE nodes (B-
   MACs of Provider's PBB-capable devices in the access network), as
   opposed to customers' MAC addresses in conventional H-VPLS with MPLS
   or 802.1ad access.
 
   PBBN access also offers service instance scalability when compared
   to H-VPLS with 802.1Q/802.1ad access networks. This is due to the
   new 24-bit service identifier (I-SID) used in PBB encapsulation,
   which allows up to 16M services per PBB access network, compared to
   4K services per 802.1Q/802.1ad access network.
 
   Another important advantage of PBBN access is that it offers clear
   separation between the service layer (represented by I-SID) and the
   network layer (represented by B-VLAN). B-VLANs segregate a PBB
   access network into different broadcast domains and possibly unique
   spanning-tree topologies, with each domain being able to carry
   multiple services (i.e. I-SIDs). In 802.1ad access networks, the
   network and service layers are the same (represented by S-VLAN).
   This separation allows the Provider to manage and optimize the PBB
   access network topology independent of the number of service
   instances that are supported.
 
   In this and the following sections we look into different flavors of
   H-VPLS with PBBN access. This section discusses the case where H-
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 6]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   VPLS is deployed with homogenous PBBN access networks. Section 5
   describes the case where at least one of the access networks is PBN
   access (QinQ/802.1ad) while others are PBBN access.
 
   At a macro scale, a network that employs H-VPLS with PBBN access can
   be represented as shown in figure 1 below.
 
                               +--------------+
                               |              |
               +---------+     |    IP/MPLS   |    +---------+
       +----+  |         |   +----+        +----+  |         |  +----+
       | CE |--|         |   |VPLS|        |VPLS|  |         |--| CE |
       +----+  |  PBBN   |---| PE |        | PE |--|  PBBN   |  +----+
       +----+  | 802.1ah |   +----+        +----+  | 802.1ah |  +----+
       | CE |--|         |     |   Backbone   |    |         |--| CE |
       +----+  +---------+     +--------------+    +---------+  +----+
 
                     Figure 1: H-VPLS with PBBN Access
 
 
   In the context of PBBN and H-VPLS interoperability, "I-SID Domain"
   and "B-VID Domain" can be defined as follows:
 
   - "I-SID Domain" refers to a network administrative boundary under
     which all the PBB BEBs and VPLS PE devices use the same I-SID
     space, i.e. the I-SID assignment is carried out by the same
     administration. This effectively means that a given service
     instance has the same I-SID designation on all devices within an
     I-SID Domain.
   - "B-VID Domain" refers to a network administrative boundary under
     which all the PBB BEBs and VPLS PE devices employ consistent I-SID
     to B-VLAN bundling - e.g., grouping of I-SIDs to B-VLANs are the
     same in that domain. Although the two B-VLANs in two PBBNs that
     represent the same group of I-SIDs do not need to use the same B-
     VID value, in practice they often use the same value because once
     the I-SID grouping is made identical in two PBBNs, it is rather
     very easy to make the values of the corresponding B-VIDs also
     identical.
 
   Consequently, three different kinds of "Service Domains" are defined
   in the following manner:
 
   - Tightly Coupled Service Domain - Different PBBN access networks
     belonging to the same I-SID Domain and B-VID Domain. However, the
     network control protocols (e.g. xSTP) run independently in each
     PBB access network.
   - Loosely Coupled Service Domain - Different PBB access networks
     belonging to the same I-SID Domain. However, each PBBN access
     maintains its own independent B-VID Domain. Again, the network
     control protocols (e.g. xSTP) run independently in each PBBN
     access.
   - Different Service Domain - In this case, each PBBN access
     maintains its own independent I-SID Domain and B-VID Domain, with
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 7]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
     independent network control protocols (e.g. xSTP) in each PBB
     access.
 
   In general, correct service connectivity spanning networks in a
   Tightly Coupled Service Domain can be achieved via B-VID mapping
   between the networks (often even without B-VID translation).
   However, correct service connectivity spanning networks in a Loosely
   Coupled Service Domain requires I-SID to B-VID re-mapping (i.e
   unbundling and re-bundling of I-SIDs into B-VIDs). Furthermore,
   service connectivity spanning networks in Different Service Domains
   requires both I-SID translation and I-SID to B-VID re-mapping.
 
 
   4.1 Service Interfaces and Interworking Options
 
   Customer devices will interface with PBBN edge bridges using
   existing Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad.
   At the PBBN edge, customer MAC frames are encapsulated in a PBB
   header that includes a service provider source and destination MAC
   addresses (B-MAC) and are bridged up to the VPLS PE. The PBB
   encapsulated customer MAC frame is then injected into the VPLS
   backbone network, delivered to the remote VPLS PE node(s), and
   switched onto the remote PBBN access. From there, the PBBN bridges
   the encapsulated frame to a PBBN edge bridge where the PBB header is
   removed and the customer frame is sent to customer domain.
 
   Interoperating between PBBN devices and VPLS PE nodes will certainly
   leverage work already completed. When I-SID visibility is required
   at the VPLS PE nodes, a new service interface based on I-SID tag
   will need to be defined.
 
   Moreover, by mapping a bridge domain (e.g. B-VLAN) to a VPLS
   instance, and bundling multiple end-customer service instances,
   represented by I-SIDs, over the same bridge domain, service
   providers will be able to significantly reduce the number of full-
   mesh PWs required in the core. In this case, I-SID visibility is not
   required on the VPLS-PE and the I-SID will serve as the means of
   multiplexing/de-multiplexing individual service instances in the
   PBBN over a bundle (e.g. B-VLAN).
 
   When I-SID visibility is expected across the service interface at
   the VPLS PE, VPLS PE can be considered to offer service-level
   interworking between PBBN access and IP/MPLS core. Similarly, when
   PE is not expected to have visibility of I-SID at the service
   interface, VPLS PE can be considered to offer network-level
   interworking between PBBN access and MPLS core.
 
   A VPLS PE is always part of the IP/MPLS core, and may optionally
   participate in the control protocols (e.g. xSTP) of the access
   network. When connecting to a PBBN access, the VPLS PE needs to
   support one of the following two types of service interfaces:
 
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 8]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   - Type I: B-Tagged Service Interface with B-VID as Service Delimiter
     - The PE connects to a Backbone Core Bridge (BCB) in PBBN access.
     The handoff between the BCB and the PE is B-Tagged PBB
     encapsulated frame. The PE is transparent to PBB encapsulations
     and treats these frames as 802.1ad frames since B-VID EtherType is
     the same as S-VID EtherType. The PE does not need to support PBB
     functionality. This corresponds to conventional VPLS PE's tagged
     service interface. When using Type I service interface, the PE
     needs to support either raw-mode or tagged-mode Ethernet PW. Type
     I Service Interface is described in detail in Section 4.2.
 
   - Type II: I-Tagged Service Interface with I-SID as Service
     Delimiter - The PE connects to a B-BEB (Backbone Edge Bridge with
     B-Component) in PBBN access. The PE itself also supports the B-BEB
     functionality of [802.1ah]. The handoff between the B-BEB in PBBN
     access and the PE is an I-Tagged PBB encapsulated frame. With Type
     II service interface, the PE supports the existing raw-mode and
     tagged-mode PW types. Type II Service Interface is described in
     detail in Section 4.3.
 
 
   4.2 H-VPLS with PBBN Access: Type I Service Interface
 
   This is a B-Tagged service interface with B-VID as service delimiter
   on the VPLS-PE. It does not require any new functionality on the
   VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS
   core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on
   right side of Figure 2) by participating in network control
   protocols (e.g. xSTP) of the PBBN access.
 
 
          PBBN Access       IP/MPLS Core      PBBN Access
                          +--------------+
          +---------+     |              | +---------------+
          |         |    +----+          | |               |
          |      +---+   |VPLS|   +-+    | |    +---+      |
          |      |BCB|---| PE |---|P|    | |    |BCB|      |
          |      +---+  /+----+  /+-+\   | |   /+---+      |
          |+---+    |  / +----+ /     \+----+ /       +---+|
     +--+ ||IB-| +---+/  |VPLS|/  +-+  |VPLS|/  +---+ |IB-|| +--+
     |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE|
     +--+ |+---+ +---+ ^ +----+   +-+  +----+ ^ +---+ +---+| +--+
          |         |  |  |              | |  |            |
          +---------+  |  |              | +--|------------+
                       |  +--------------+    |
                       |                      |
                     Type I                  Type I
 
       Figure 2: H-VPLS with PBBN Access & Type I Service Interface
 
   Type I service interface is applicable to networks with Tightly
   Coupled Service Domains, where both I-SID Domains and B-VID Domains
   are the same across all PBBN access networks.
 
 
   Sajassi, et. al.       Expires: July 2010                  [Page 9]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
 
   The BCB and VPLS PE will exchange PBB encapsulated frames that
   include source and destination B-MAC addresses, a B-VID and I-SID.
   The service delimiter, from the perspective of the VPLS PE, is the
   B-VID; in fact, this interface operates exactly as a current
   802.1Q/ad interface into a VPLS PE does today. With Type I service
   interface, VPLS PE can be considered as providing network-level
   interworking between PBBN and MPLS domains, since VPLS PE does not
   have visibility of I-SIDs.
 
   The main advantage of this service interface, when compared to other
   types, is that it allows the service provider to save on the number
   of full-mesh PWs required in the core. This is primarily because
   multiple service instances (I-SIDs) are bundled over a single full-
   mesh corresponding to a bridge domain (e.g. B-VID), instead of
   requiring a dedicated full-mesh per service instance. Another
   advantage is the MAC address scalability in the core since the core
   is not exposed to C-MACs.
 
   The disadvantage of this interface is the comparably excessive
   replication required in the core: since a group of service instances
   share the same full-mesh of PWs, an unknown unicast, multicast or
   broadcast on a single service instance will result in a flood over
   the core. This, however, can be mitigated via the use of per I-SID
   flood containment (B-MAC multicast pruning) as described in [PBB-
   VPLS-MCAST].
 
   Three different modes of operation are supported by Type I Service
   Interface:
 
   - Port Mode: All traffic over an interface in this mode is mapped to
     a single VPLS instance. Existing PW signaling and Ethernet raw
     mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are
     supported.
 
   - VLAN Mode: all traffic associated with a particular VLAN
     identified by the B-VID is mapped to a single VPLS instance.
     Existing PW signaling and Ethernet raw mode (0x0005) PW type,
     defined in [RFC4447] [RFC4448], are supported.
 
   - VLAN Bundling Mode: all traffic associated with a group or range
     of VLANs or B-VIDs is mapped to a single VPLS instance. Existing
     PW signaling and Ethernet raw mode (0x0005) PW type, defined in
     [RFC4447] [RFC4448], are supported.
 
   For the above three modes, it is also possible to use Ethernet
   tagged mode (0x0004) PW, as defined in [RFC4447] [RFC4448], for
   interoperability with equipment that does not support raw mode. The
   use of raw mode is recommended to be the default though.
 
   4.3 H-VPLS with PBBN Access: Type II Service Interface
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 10]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   This is an I-Tagged service interface with I-SID as service
   delimiter on VPLS-PE. It requires the VPLS-PE to include B-Component
   of PBB BEB for I-SID processing in addition to the capability to map
   I-SID Bundle to VPLS instance. As shown in Figure 3, the PE is
   always part of IP/MPLS core and connects to one or more B-BEB in
   PBBN access.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
          PBBN Access      IP/MPLS Core      PBBN Access
                         +--------------+
          +---------+    |              |    +---------+
          |         |    |              |    |         |
          |      +---+  +-----+         |    |  +---+  |
          |      |B- |  |PE w/| +-+     |    |  |BCB|  |
          |      |BEB|--|B-BEB|-|P|     |    |  +---+  |
          |      +---+ /+-----+ +-+     |    | /   |   |
          |+---+ +---+/ +-----+/   \+-----+ +---+ +---+|
     +--+ ||IB-| |B- |  |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
     |CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
     +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
          |         |  |  |             |  | |         |
          +---------+  |  |             |  | +---------+
                       |  +-------------+  |
                       |                   |
                   Type II             Type II
 
       Figure 3: H-VPLS with PBBN Access & Type II Service Interface
 
   Type II service interface is applicable to Loosely Coupled Service
   Domains and Different Service Domains. B-VID Domains can be
   independent and the B-VID is always locally significant in each PBBN
   access and does not need to be transported over the IP/MPLS core.
   Given the above, it should be apparent that Type II service
   interface is applicable to Tightly Coupled Service Domains as well.
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 11]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   By definition the B-BEB connecting to the VPLS PE will remove any B-
   VLAN tags for frames exiting the PBB access network. The B-BEB and
   VPLS PE will exchange PBB encapsulated frames that include source
   and destination B-MAC addresses, and I-SID. The service delimiter,
   from the perspective of the VPLS PE, is the I-SID. Since PE has
   visibility to I-SIDs, the PE provides service-level interworking
   between PBBN access and IP/MPLS core.
 
   The advantage that Type II service interface has compared to Type I
   is the potentially less replication in the core without the need for
   a per I-SID flood containment (B-MAC multicast pruning) mechanism.
   This is mainly due to the increased segregation of service instances
   over disjoint full-meshes of PWs.
 
   The disadvantage of this service interface, compared to Type I, is
   that it may require a larger number of full-mesh PWs in the core.
   However, the number of full-mesh PWs can still be less than those
   required by H-VPLS without PBBN access.
 
   It is expected that this interface type will be used for customers
   with significant multicast traffic (but without multicast pruning
   capability in VPLS PE) so that a separate VPLS instance is set up
   per group of customers with similar geographic locality (per I-SID
   group).
 
   Type II Service Interface may operate in I-SID Bundling Mode: all
   traffic associated with a group or range of I-SIDs is mapped to a
   single VPLS instance. The PE maintains a mapping of I-SIDs to a PE
   local bridge domain (e.g. B-VID). The VPLS instance is then
   associated with this bridge domain. With Tightly and Loosely Coupled
   Service Domains, no I-SID translation needs to be performed. Type II
   Service Interface also supports Different Service Domains in this
   mode, since the B-BEB link in the PE connecting to the local PBBN
   can perform the translation of PBBN-specific I-SID to a local I-SID
   within the IP/MPLS core, which may then be translated to the other
   PBBN specific I-SID on the egress PE. Such translation can also
   occur in the B-BEB of PBBN access. Existing PW signaling and
   Ethernet raw mode (0x0005), defined in [RFC4447] [RFC4448], is
   supported. It is also possible to use tagged mode (0x0004) PW for
   purpose of interoperability with equipment that does not support raw
   mode.
 
   Note 1: Port mode is not called out in Type II Service Interface
   since it requires the mapping of I-SIDs to be identical on different
   I-Tagged interfaces across VPLS network. If this is indeed the case,
   Port mode defined in Type I Service Interface (Section 4.2) can be
   used.
 
   Note 2: In a degenerate scenario, it is possible to define an I-SID
   bundle that comprises a single I-SID. This allows the Type II
   service interface to effectively operate as if in I-SID Mode, at the
   added expense of consuming more bridge-domains on the PE and
   increased number of PW full-mesh in the core.
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 12]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
 
   5. H-VPLS with Mixed PBBN Access and PBN Access
 
   It is foreseeable that service providers will want to interoperate
   their existing PBN (QinQ) access networks with PBBN access networks
   over H-VPLS. Figure 4 below shows the high-level network topology.
 
                             +--------------+
                             |              |
             +---------+     |    IP/MPLS   |    +---------+
     +----+  |         |   +----+        +----+  |         |  +----+
     | CE |--|   PBN   |   |VPLS|        |VPLS|  |         |--| CE |
     +----+  |  (QinQ) |---| PE1|        | PE2|--|  PBBN   |  +----+
     +----+  | 802.1ad |   +----+        +----+  | 802.1ah |  +----+
     | CE |--|         |     |   Backbone   |    |         |--| CE |
     +----+  +---------+     +--------------+    +---------+  +----+
 
         Figure 4: H-VPLS with Mixed PBN and PBBN Access Networks
 
   Referring to Figure 4 above, two possibilities come into play
   depending on whether the interworking is carried out at PE1 or PE2.
   These are described in the following sub-Sections.
 
 
   5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE
 
   As shown in Figure 5, the operation of VPLS PE2 (connecting to the
   PBBN access on the right) is no different from what was discussed in
   Section 4. Type II service interface, as discussed in the above
   section, is applicable. It is the behavior of VPLS PE1 (connecting
   to the PBN access on the left) that is the focus of this section.
 
          PBN Access       IP/MPLS Core      PBBN Access
           (802.1ad)     +--------------+     (802.1ah)
                         |              |    +---------+
          +---------+    |              |    |         |
          |         |   +-----+         |    |  +---+  |
          |      +---+  |PE w/| +-+     |    |  |BCB|  |
          |      |PCB|--|IBBEB|-|P|     |    |  +---+  |
          |      +---+ /+-----+ +-+     |    | /   |   |
          |         | / +-----+/   \+-----+ +---+ +---+|
     +--+ |+---+ +---+  |PE w/| +-+ |PE w/| |B- | |IB-|| +--+
     |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE|
     +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
          |         |  |  |PE1       PE2|  | |         |
          +---------+  |  |             |  | +---------+
                       |  +-------------+  |
                       |                   |
                   S-Tagged           Type II (I-Tagged)
 
     Figure 5: H-VPLS with Mixed PBN and PBBN Access: Modified PBN PE
 
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 13]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   Some assumptions made for this topology include:
   - CE is directly connected to PBBN via S-Tagged or port-based
     Interface
   - I-SID in PBBN access represents the same customer as S-VID in PBN
     access
   - At S-Tagged Service Interface of PE with IB-BEB functionality
     (e.g. PE1 in Figure 5), the only viable service is 1:1 mapping of
     S-VID to I-SID. However, towards the core network side, the same
     PE can support I-SID bundling into a VPLS instance.
   - PE1 participates in the local ISID domain of the IP/MPLS Core so
     the model accommodates for the rest of the PBB network any of the
     three domain types described in section 4 - Tightly, Loosely
     Coupled and Different Service Domains.
   - For ease of provisioning in these disparate access networks, it is
     recommended to use the same I-SID Domain among the PBBN access and
     PEs with IB-BEB functionality (those connecting to PBN).
 
 
   This topology operates in I-SID Bundling Mode: at PE connecting to
   PBN access, each S-VID is mapped to an I-SID and subsequently a
   group of I-SIDs is mapped to a VPLS instance. Similarly, at PE
   connecting to PBBN access, each group of I-SIDs is mapped to a VPLS
   instance. Similar to Type II interface, no I-SID translation is
   performed for I-SID bundling case. Existing PW signaling and
   Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448],
   are supported. It is possible to use tagged mode (0x0004) PW for
   backward compatibility as well.
 
 
 
   5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE
 
   As shown in Figure 6, the operation of VPLS PE1 (connecting to the
   PBN access on the left) is no different from existing VPLS PEs. It
   is the behavior of VPLS PE2 (connecting to the PBBN access on the
   right) that is the focus of this section.
 
 
          PBN Access       IP/MPLS Core      PBBN Access
           (802.1ad)     +--------------+     (802.1ah)
                         |              |    +---------+
          +---------+    |              |    |         |
          |         |   +-----+         |    |  +---+  |
          |      +---+  |  PE | +-+     |    |  |BCB|  |
          |      |PCB|--|     |-|P|     |    |  +---+  |
          |      +---+ /+-----+ +-+     |    | /   |   |
          |         | / +-----+/   \+-----+ +---+ +---+|
     +--+ |+---+ +---+  |  PE | +-+ |PE w/| |B- | |IB-|| +--+
     |CE|-||PEB|-|PCB|--|     |-|P|-|IBBEB|-|BEB| |BEB|--|CE|
     +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+
          |         |  |  |PE1       PE2|  | |         |
          +---------+  |  |             |  | +---------+
                       |  +-------------+  |
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 14]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
                       |                   |
                   S-Tagged           Type II (I-Tagged)
 
      Figure 6: H-VPLS with Mixed PBN and PBBN Access: Regular PBN PE
 
 
   Some assumptions made for this topology include:
   - CE is directly connected to PBBN via S-Tagged or port-based
     Interface
   - I-SID in PBBN access represents the same customer as S-VID in PBN
     access
   - There is 1:1 mapping between the I-SID and VPLS instance
   - At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in
     Figure 6), the PE only provides 1:1 mapping of S-VID to VPLS
     instance. S-VID bundling is not a viable option since it does not
     correspond to anything in PBBN access.
   - The PE connecting to PBBN (e.g. PE2 in Figure 6), supports IB-BEB
     functionality and the I-Component is connected to the VPLS
     Forwarder (i.e. the I-Component faces the MPLS core whereas the B-
     Component faces the PBBN access network). One or more I-SIDs can
     be grouped into a B-VID in the PBBN access.
   - Since C-VID grouping in different PBBN access networks must be
     consistent, it is assumed that same I-SID Domain is used across
     these PBBN access networks.
 
   Unlike the other topology, I-SID bundling mode is not supported in
   this case. This is primarily because the VPLS core operates in the
   same manner as today. The PE with IB-BEB functionality connecting to
   PBBN access performs the mapping of each VPLS instance to an I-SID
   and one or more of these I-SIDs may be mapped onto a B-VID within
   the PBBN access network.
 
  6. H-VPLS with MPLS Access
 
   In this section, the case of H-VPLS with MPLS access network is
   discussed. The integration of PBB functionality into VPLS-PE for
   such access networks is described to improve the scalability of the
   network in terms of the number of MAC addresses and service
   instances that are supported.
 
   For this topology, it is possible to embed PBB functionality in
   either the U-PE or the N-PE. Both of these cases are described in
   the following sub-sections.
 
 
   6.1 H-VPLS with MPLS Access: PBB U-PE
 
   As stated earlier, the objective for incorporating PBB function at
   the U-PE is to improve the scalability of H-VPLS networks in terms
   of the number of MAC addresses and service instances that are
   supported.
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 15]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   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 PBB encapsulation, the N-PE only needs to
   learn the MAC addresses of the U-PEs, which is a significant
   reduction. Furthermore, when PBB encapsulation is used, many I-SIDs
   are multiplexed within a single bridge domain (e.g., B-VLAN). If the
   VPLS instance is set up per B-VLAN, then one can also achieve a
   significant reduction in the number of full-mesh PWs. It should be
   noted that this reduction in full-mesh PWs comes at the cost of
   potentially increased replication over the full-mesh of PWs: 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 PWs corresponding to a B-VLAN is
   most likely bigger than the full-mesh PWs corresponding to a single
   I-SID. However, per I-SID flood containment (B-MAC multicast
   pruning) as described in [PBB-VPLS-MCAST] can be used to remedy this
   drawback and have multicast traffic replicated efficiently for each
   customer (i.e. for each I-SID).
 
   Figure 7 below illustrates the scenario for H-VPLS with MPLS access.
   As 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 PWs (per VPLS instance). These, in turn, are connected
   via a full-mesh of PWs (per VPLS instance) traversing the IP/MPLS
   core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB)
   functions where it can encapsulate/de-encapsulate 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 PBB U-PE
 
 
   The U-PE still provides the same type of services toward its
   customers as before and they are:
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 16]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
     - Port mode (either 802.1D, 802.1Q, or 802.1ad)
     - VLAN mode (either 802.1Q or 802.1ad)
     - VLAN-bundling mode (either 802.1Q or 802.1ad)
 
   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 bridge domain (e.g. B-VLAN). The U-PE can then map a bridge-
   domain onto a VPLS instance and the encapsulated frames are sent
   over the PW associated with that VPLS instance. Furthermore the
   entire Ethernet bridging operation over VPLS network is performed as
   defined in [RFC4762]. In other words, MAC forwarding is based on the
   B-MAC address space and service delimiter is based on VLAN ID, which
   is B-VID in this case. There is no need to inspect or deal with I-
   SID values in the VPLS N-PEs.
 
 
   6.1.1 PBB U-PEs in Single I-SID Domain
 
   In this scenario, I-SID assignment is performed globally across all
   MPLS access networks and therefore there is no need for I-SID
   translation. This scenario support I-SID bundling mode and it is
   assumed that the mapping of the I-SIDs to the bridge domain (e.g.,
   B-VLAN) is consistent across all the participating PE devices. In
   case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is
   mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or
   tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448].
 
   I-SID mode can be considered as a degenerate case of I-SID bundling
   where a single bridge domain is used per I-SID. However, that
   results in increase number of bridge domains and PWs in the PEs. PBB
   flood containment (B-MAC multicast pruning) per I-SID as described
   in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling
   mode to limit the scope of flooding per I-SID thus removing the need
   for I-SID mode.
 
 
 
   6.2 H-VPLS with MPLS Access: PBB N-PE
 
   In this case, the PBB function is incorporated at the N-PE to
   improve the scalability of H-VPLS networks in terms of the numbers
   of MAC addresses and service instances that are supported.
 
   Customer networks or hosts (CE) connect into the U-PE nodes using
   standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The
   U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS
   PWs (per customer). These, in turn, are connected via a full-mesh of
   PWs (per customer or group of customers) traversing the IP/MPLS
   core.
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 17]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   The U-PE still provides the same type of services toward its
   customers as before and they are:
 
     - Port mode (either 802.1D, 802.1Q, or 802.1ad)
     - VLAN mode (either 802.1Q or 802.1ad)
     - VLAN-bundling mode (either 802.1Q or 802.1ad)
 
   Spoke PW from U-PE to N-PE is not service multiplexed because there
   is no PBB functionality on u-PE - i.e. one service per PW.
 
 
                           PBB              PBB
                           BEB +----------+ BEB
                             | |          | |
               +-----------+ | |    IP    | | +-----------+
               | MPLS      | V |   MPLS   | V |    MPLS   |
               | Access +----+ |   Core   | +----+ Access |
     +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
     |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
     +--+  +----+       +----+ |          | +----+       +----+  +--+
               |           |   |          |   |           |
               +-----------+   +----------+   +-----------+
 
         Figure 8: H-VPLS with MPLS Access Network and PBB N-PE
 
   By incorporating PBB function, the N-PE maps each of these services
   (for a given customer) onto a single I-SID based on the
   configuration at the N-PE. Many I-SIDs can be multiplexed within a
   single bridge domain (e.g. B-VLAN). The N-PE can, then, either map a
   single I-SID into a VPLS instance or it can map a bridge domain
   (e.g. B-VLAN) onto a VPLS instance, according to its configuration.
   Next, the encapsulated frames are sent over the set of PWs
   associated with that VPLS instance.
 
 
   6.2.1 PBB N-PEs in Single I-SID Domain
 
   In this scenario, I-SID assignment is performed globally across all
   MPLS access networks and therefore there is no need for I-SID
   translation. This scenario support I-SID bundling mode and it is
   assumed that the mapping of the I-SIDs to the bridge domain (e.g.,
   B-VLAN) is consistent across all the participating PE devices. In
   case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is
   mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or
   tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448], can
   be used.
 
   I-SID mode can be considered as a degenerate case of I-SID bundling
   where a single bridge domain is used per I-SID. However, that
   results in increase number of bridge domains and PWs in the PE. PBB
   flood containment (B-MAC multicast pruning) per I-SID as described
   in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 18]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   mode to limit the scope of flooding per I-SID thus removing the need
   for I-SID mode.
 
 
 
  7. H-VPLS with MPLS Access: PBB Migration Scenarios
 
   Operators and service providers that have deployed H-VPLS with
   either MPLS or Ethernet are unlikely to migrate to PBB technology
   overnight because of obvious cost implications. Thus, it is
   imperative to outline migration strategies that will allow operators
   to protect investments in their installed base while still taking
   advantage of the scalability benefits of PBB technology.
 
   In the following sub-sections, we explore three different migration
   scenarios which allow a mix of existing H-VPLS access networks to
   co-exist with newer PBB-based access networks. The scenarios differ
   in whether the Ethernet service frames passing over the VPLS core
   are PBB-encapsulated or not. The first scenario in section 7.1
   involves passing only non PBB-encapsulated frames over the core. The
   second scenario in section 7.2 stipulates passing only PBB-
   encapsulated frames over the core. Whereas, the final scenario in
   section 7.3 depicts a core that supports a mix of PBB-encapsulated
   and non PBB-encapsulated frames. The advantages and disadvantages of
   each scenario will be discussed in its respective section.
 
 
   7.1 802.1ad Service Frames over VPLS Core
 
   In this scenario, existing access networks are left unchanged. All
   N-PEs would forward frames based on C-MAC addresses. In other words,
   Ethernet frames which are traversing the VPLS core (within PWs)
   would use the 802.1ad frame format, as in current VPLS. Hence, the
   N-PEs in existing access networks do not require any modification.
   For new MPLS access networks that have PBB functions on the U-PE,
   the corresponding N-PE must incorporate built-in IB-BEB functions in
   order to terminate the PBB encapsulation before the frames enter the
   core. A key point here is that while both the U-PE and N-PE nodes
   implement PBB IB-BEB functionality, the former has the I-Component
   facing the customer (CE) and the B-Component facing the core;
   whereas the latter has the I-Component facing the core and the B-
   Component facing the customer (i.e. access network).
 
 
                                            PBB            PBB
                               +----------+ IB-BEB         IB-BEB
                               |          | |               |
               +-----------+   |    IP    | | +-----------+ |
               | MPLS      |   |   MPLS   | V |    MPLS   | |
               | Access +----+ |   Core   | +----+ Access | V
     +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
     |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
     +--+  +----+       +----+ |          | +----+       +----+  +--+
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 19]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
               | (Existing)|   |          |   |  (New)    |
               +-----------+   +----------+   +-----------+
 
     Figure 9: Migration with 802.1ad Service Frames over VPLS Core
 
   The main advantage of this approach is that it requires no change to
   existing access networks or existing VPLS N-PEs. The main
   disadvantage is that these N-PEs will not leverage the advantages of
   PBB in terms of MAC address and PW scalability.
   It is worth noting that this migration scenario is an optimal option
   for an H-VPLS deployment with a single PBB-capable access network.
   When multiple PBB-capable access networks are required, then the
   scenario in Section 7.3 is preferred, as it provides a more scalable
   and optimal interconnect amongst the PBB-capable networks.
 
   7.2 PBB Service Frames over VPLS Core
 
   This scenario requires that the VPLS N-PE connecting to existing
   MPLS access networks be upgraded to incorporate IB-BEB functions.
   All Ethernet service frames passing over the VPLS core would be PBB-
   encapsulated. The PBB over MPLS access networks would require no
   special requirements beyond what is captured in section 6 of this
   document.
   In this case, both the U-PE and N-PE which implement IB-BEB
   functionality have the I-Component facing the customer and the B-
   Component facing the core.
 
 
                           PBB                             PBB
                        IB-BEB +----------+              IB-BEB
                             | |          |                 |
               +-----------+ | |    IP    |   +-----------+ |
               | MPLS      | V |   MPLS   |   |    MPLS   | |
               | Access +----+ |   Core   | +----+ Access | V
     +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
     |CE|--|U-PE|       |N-PE| |          | | PE |       |U-PE|--|CE|
     +--+  +----+       +----+ |          | +----+       +----+  +--+
               | (Existing)|   |          |   |  (New)    |
               +-----------+   +----------+   +-----------+
 
      Figure 10: Migration with PBB Service Frames over VPLS Core
 
   The main advantage of this approach is that it allows better
   scalability of the VPLS N-PEs in terms of MAC address and pseudowire
   counts. The disadvantage is that it requires upgrading the VPLS N-
   PEs of all existing MPLS access networks.
 
   7.3 Mixed 802.1ad and PBB over VPLS Core
 
   In this scenario, existing access networks are left unchanged, and
   exchange Ethernet frames with 802.1ad format over the PWs in the
   core. The newly added access networks, which incorporate PBB
   functionality exchange Ethernet frames that are PBB-encapsulated
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 20]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   amongst each other over core PWs. For service connectivity between
   existing access network (non PBB capable) and new access network
   (PBB based), the VPLS N-PE of the latter network employs IB-BEB
   functionality to de-capsulate the PBB header from frames outbound to
   the core, and encapsulate the PBB header for frames inbound from the
   core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet
   service frames are exchanged over the VPLS core.
 
   This mode of operation requires new functionality on the VPLS N-PE
   of the PBB-capable access network, so that the PE can send frames in
   802.1ad format or PBB format, on a per PW basis, depending on the
   capability of the destination access network. Effectively, the PE
   would have to incorporate B-BEB as well as IB-BEB functions.
 
   A given PE needs to be aware of the capability of its remote peer in
   order to determine whether it connects to the right PW Forwarder.
   This can be achieved either via static configuration, or by
   extending the VPLS control plane (BGP-based auto-discovery and LDP
   Signaling) discussed in [L2VPN-Sig]. The latter approach and the
   details of the extensions required are out of scope for this
   document and will be covered in a separate document.
 
 
 
 
 
 
                                            PBB
                                            B-BEB          PBB
                               +----------+ IB-BEB         IB-BEB
                               |          | |               |
               +-----------+   |    IP    | | +-----------+ |
               | MPLS      |   |   MPLS   | V |    MPLS   | |
               | Access +----+ |   Core   | +----+ Access | V
     +--+  +----+       |VPLS|-|          |-|VPLS|       +----+  +--+
     |CE|--|U-PE|       |N-PE| |          | |N-PE|       |U-PE|--|CE|
     +--+  +----+       +----+ |          | +----+       +----+  +--+
               | (Existing)|   |          |   |  (New)    |
               +-----------+   +----------+   +-----------+
 
 Figure 11: Migration with Mixed 802.1ad &PBB Service Frames over VPLS
                                  Core
 
   The U-PE and N-PE of the PBB-capable access network both employ BEB
   functionality: The U-PE implements IB-BEB function where the I-
   Component faces the customer (CE) and the B-Component faces the
   core. The N-PE, on the other hand, implements IB-BEB functionality
   with the I-Component facing the core and the B-Component facing the
   customer (access network). In addition, the N-PE implements stand-
   alone B-BEB functionality.
 
   This scenario combines the advantages of both previous scenarios
   without any of their shortcomings, namely: it does not require any
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 21]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   changes to existing access networks and it allows the N-PE to
   leverage the scalability benefits of 802.1ah for PBB to PBB access
   network connectivity. The disadvantage of this option is that it
   requires new functionality on the N-PE of the PBB-capable access
   network.
 
  8. Acknowledgments
 
   TBD.
 
  9. IANA Considerations
 
   This document has no actions for IANA.
 
 
  10. Security Considerations
 
   This document does not introduce any additional security aspects
   beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security
   considerations are already covered in [RFC4762].
 
 
  11. References
 
  11.1 Normative References
 
   [802.1ad] "Virtual Bridged Local Area Networks, Amendment 4:
   Provider Bridges", IEEE Std. 802.1ad-2005, May 2006
 
   [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider
   Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008
 
   [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447,
   April 2006
 
   [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS
   Networks", RFC4448, April 2006
 
   [RFC4762] "Virtual Private LAN Service (VPLS) Using Label
   Distribution Protocol (LDP) Signaling", RFC4762, January 2007
 
   [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and
   Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt,   May 2006
   ( work in progress )
 
  11.2 Informative References
 
   [802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q-
   2005
 
   [802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D-
   2003
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 22]
 

   Internet-Draft    VPLS Interoperability with PBB           January
 
   [VPLS-Bridge] "VPLS Interoperability with CE Bridges", draft-ietf-
   l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 2007
 
   [VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-
   03.txt, Work in progress, November 2007
 
   [PBB-VPLS-MCAST] "Multicast Pruning in Provider Backbone Bridged
   VPLS", draft-sajassi-l2vpn-pbb-vpls-mcast-pruning-00.txt, Work in
   progress, July 2008
 
 
 
  Authors' Addresses
 
   Ali Sajassi
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134, US
   Email: sajassi@cisco.com
 
 
   Samer Salam
   Cisco
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1, Canada
   Email: ssalam@cisco.com
 
   Chris Metz
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134, US
   Email: metz@cisco.com
 
   Nabil Bitar
   Verizon Communications
   Email : nabil.n.bitar@verizon.com
 
   Dinesh Mohan
   Nortel
   3500 Carling Ave
   Ottawa, ON K2H8E9, Canada
   Email: mohand@nortel.com
 
   Florin Balus
   Alcatel-Lucent
   701 E. Middlefield Road
   Mountain View, CA, USA 94043
   Email: florin.balus@alcatel-lucent.com
 
 
 
 
   Sajassi, et. al.       Expires: July 2010                 [Page 23]
 

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/