idnits 2.17.1 draft-ietf-l2vpn-vpls-pbb-interop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2009) is 5300 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Unused Reference: 'VPLS-Bridge' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'VPLS-MCAST' is defined on line 1090, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-06) exists of draft-ietf-l2vpn-vpls-bridge-interop-02 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-03 -- No information found for draft-sajassi-l2vpn-pbb-vpls-mcast-pruning - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Ali Sajassi 3 L2VPN Working Group Samer Salam 4 Chris Metz 5 Cisco 7 Nabil Bitar 8 Intended status: Standards Verizon 10 Dinesh Mohan 11 Nortel 13 Florin Balus 14 Alcatel-Lucent 16 Expires: April 20, 2010 October 20, 2009 18 VPLS Interoperability with Provider Backbone Bridges 19 draft-ietf-l2vpn-vpls-pbb-interop-00.txt 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on April 19,20, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your 53 rights and restrictions with respect to this document. 55 Abstract 57 The scalability of H-VPLS with Ethernet access network can be 58 improved by incorporating Provider Backbone Bridge functionality in 59 VPLS access. Provider Backbone Bridging has been standardized as 60 IEEE 802.1ah-2008, and aims to improve the scalability of MAC 61 addresses and service instances in Provider Ethernet networks. This 62 document describes different interoperability scenarios where 63 Provider Backbone Bridge functionality is used in H-VPLS with 64 Ethernet or MPLS access network to attain better scalability in 65 terms of number of customer MAC addresses and number of service 66 instances. The document also describes the scenarios and the 67 mechanisms for incorporating Provider Backbone Bridge functionality 68 within H-VPLS with existing Ethernet access and interoperability 69 among them. Furthermore, the document discusses the migration 70 mechanisms and scenarios by which Provider Backbone Bridge 71 functionality can be incorporated into H-VPLS with existing MPLS 72 access. 74 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. 80 Table of Contents 82 Conventions used in this document.................................. 2 83 1. Introduction.................................................... 3 84 2. Applicability................................................... 4 85 3. Terminology..................................................... 4 86 4. H-VPLS with Homogeneous PBBN Access............................. 6 87 4.1 Service Interfaces and Interworking Options.................... 8 88 4.2 H-VPLS with PBBN Access: Type I Service Interface.............. 9 89 4.3 H-VPLS with PBBN Access: Type II Service Interface............ 10 90 5. H-VPLS with Mixed PBBN Access and PBN Access................... 13 91 5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE.......... 13 92 5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE........... 14 93 6. H-VPLS with MPLS Access........................................ 15 94 6.1 H-VPLS with MPLS Access: PBB U-PE............................. 15 95 6.1.1 PBB U-PEs in Single I-SID Domain............................ 17 96 6.2 H-VPLS with MPLS Access: PBB N-PE............................. 17 97 6.2.1 PBB N-PEs in Single I-SID Domain............................ 18 98 7. H-VPLS with MPLS Access: PBB Migration Scenarios............... 19 99 7.1 802.1ad Service Frames over VPLS Core......................... 19 100 7.2 PBB Service Frames over VPLS Core ........................ 20 101 7.3 Mixed 802.1ad and PBB over VPLS Core ..................... 20 102 8. Acknowledgments................................................ 22 103 9. IANA Considerations............................................ 22 104 10. Security Considerations....................................... 22 105 11. References.................................................... 22 106 11.1 Normative References......................................... 22 107 11.2 Informative References....................................... 22 108 Authors' Addresses................................................ 23 110 1. Introduction 112 The scalability of H-VPLS with Ethernet access network can be 113 improved by incorporating Provider Backbone Bridge functionality in 114 the VPLS access. Provider Backbone Bridging has been standardized as 115 IEEE 802.1ah-2008, which is an amendment to IEEE 802.1Q to improve 116 the scalability of MAC addresses and service instances in Provider 117 Ethernet networks. This document describes interoperability 118 scenarios where IEEE 802.1ah functionality is used in H-VPLS with 119 Ethernet or MPLS access network to attain better scalability in 120 terms of the number of customer MAC addresses and the number of 121 services. This document also describes the scenarios and the 122 mechanisms for incorporating Provider Backbone Bridging 123 functionality within H-VPLS with existing IEEE 802.1ad Ethernet 124 access and interoperability among them. Furthermore, this document 125 discusses the migration mechanisms and scenarios by which Provider 126 Backbone Bridging functionality can be incorporated into H-VPLS with 127 existing MPLS access. 129 This document also covers the interoperability scenarios for 130 deploying H-VPLS with Provider Backbone Bridging Ethernet access 131 when other types of access networks are deployed, including existing 132 802.1ad Ethernet access in either single or multiple service 133 domains. Furthermore, the document explores the scenarios by which 134 an operator can gradually migrate an existing H-VPLS network to 135 Provider Backbone Bridging over VPLS. 137 Section 2 highlights the applicability of Provider Backbone Bridging 138 interoperation with VPLS. Section 3 gives a quick terminology 139 reference. Section 4 describes H-VPLS with homogeneous Provider 140 Backbone Bridge Access Network. Section 5 discusses H-VPLS with 141 mixed 802.1ah/802.1ad access. Section 6 focuses on Provider Backbone 142 Bridging in H-VPLS with MPLS Access Network including Provider 143 Backbone Bridge function on U-PE and on N-PE variants. Finally, 144 section 7 describes gradual migration scenarios from existing H-VPLS 145 to Provider Backbone Bridging over H-VPLS. 147 2. Applicability 149 [RFC4762] describes a two-tier hierarchical solution for VPLS for 150 the purpose of improved pseudowire (PW) scalability. This 151 improvement is achieved by reducing the number of PE devices 152 connected in a full-mesh topology through connecting CE devices via 153 the lower-tier access network, which in turn is connected to the 154 top-tier core network. [RFC4762] describes two types of H-VPLS 155 network topologies - one with MPLS access network and another with 156 IEEE 802.1ad (QinQ) Ethernet access network. In both types of H- 157 VPLS, MAC address learning and forwarding are done based on customer 158 MAC addresses (C-MACs), which poses scalability issues as the number 159 of VPLS instances (and thus customer MAC addresses) increases. 160 Furthermore, since a set of PWs is maintained on a per customer 161 service instance basis, the number of PWs required at N-PE devices 162 is proportional to the number of customer service instances 163 multiplied by the number of N-PE devices in the full-mesh set. This 164 can result in scalability issues (in terms of PW manageability and 165 troubleshooting) as the number of customer service instances grows. 167 In addition to the above, H-VPLS with 802.1ad Ethernet access 168 network has another scalability issue in terms of the maximum number 169 of service instances that can be supported in the access network as 170 described in [RFC4762]. Since the number of provider VLANs (S-VLANs) 171 is limited to 4K and each S-VLAN represents a service instance in an 172 802.1ad network, then the maximum number of service instances that 173 can be supported is 4K. These issues are highlighted in [VPLS- 174 Bridge]. 176 This document describes how IEEE 802.1ah (aka Provider Backbone 177 Bridges) can be integrated with H-VPLS to address these scalability 178 issues. In case of H-VPLS with 802.1ah Ethernet access, the solution 179 results in better scalability in terms of both number of service 180 instances and number of C-MACs in the Ethernet access network and 181 the VPLS core network, as well as number of PWs in VPLS core 182 network. And in case of H-VPLS with MPLS access, Provider Backbone 183 Bridging functionality can be used at the U-PE or N-PE which results 184 in reduction of customer MAC addresses and number of PWs in the VPLS 185 core network. 187 The interoperability scenarios depicted in this document fall into 188 the following two categories: 189 - Scenarios where Provider Backbone Bridging seamlessly works 190 with current VPLS implementations (e.g. section 4.2). 191 - Scenarios where VPLS PE implementations need to be upgraded in 192 order to work with Provider Backbone Bridging (e.g. sections 193 4.3, 5.1). 195 3. Terminology 196 802.1ad: IEEE specification for "QinQ" encapsulation and bridging of 197 Ethernet frames 199 802.1ah: IEEE specification for "MAC tunneling" encapsulation and 200 bridging of frames across a provider backbone bridged network. 202 B-BEB: A backbone edge bridge positioned at the edge of a provider 203 backbone bridged network. It contains a B-component that supports 204 bridging in the provider backbone based on B-MAC and B-TAG 205 information 207 B-MAC: The backbone source or destination MAC address fields defined 208 in the 802.1ah provider MAC encapsulation header. 210 BCB: A backbone core bridge running in the core of a provider 211 backbone bridged network. It bridges frames based on B-TAG 212 information just as an 802.1ad provider bridge will bridge frames 213 based on a VLAN identifier (S-VLAN) 215 BEB: A backbone edge bridge positioned at the edge of a provider 216 backbone bridged network. It can contain an I-component, B-component 217 or both I and B components. 219 B-TAG: field defined in the 802.1ah provider MAC encapsulation 220 header that conveys the backbone VLAN identifier information. The 221 format of the B-TAG field is the same as that of an 802.1ad S-TAG 222 field. 224 B-Tagged Service Interface: This is the interface between a BEB and 225 BCB in a provider backbone bridged network. Frames passed through 226 this interface contain a B-TAG field. 228 B-VID: The specific VLAN identifier carried inside a B-TAG 230 I-component: A bridging component contained in a backbone edge 231 bridge that bridges in the customer space (customer MAC addresses, 232 S-VLAN) 234 IB-BEB: A backbone edge bridge positioned at the edge of a provider 235 backbone bridged network. It contains an I-component for bridging in 236 the customer space (customer MAC addresses, service VLAN IDs) and a 237 B-component for bridging the provider's backbone space (B-MAC, B- 238 TAG). 240 I-BEB: A backbone edge bridged positioned at the edge of a provider 241 backbone bridged network. It contains an I-component for bridging in 242 the customer space (customer MAC addresses, service VLAN IDs). 244 I-SID: The 24-bit service instance field carried inside the I-TAG. 245 I-SID defines the service instance that the frame should be "mapped 246 to". 248 I-TAG: A field defined in the 802.1ah provider MAC encapsulation 249 header that conveys the service instance information (I-SID) 250 associated with the frame. 252 I-Tagged Service Interface: This the interface defined between the I 253 and B components inside an IB-BEB or between two B-BEB. Frames 254 passed through this interface contain an I-TAG field 256 PBB: Provider Backbone Bridge 258 PBBN: Provider Backbone Bridged Network 260 PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) 261 technology. 263 S-TAG: A field defined in the 802.1ad QinQ encapsulation header that 264 conveys the service VLAN identifier information (S-VLAN). 266 S-Tagged Service Interface: This the interface defined between the 267 customer (CE) and the I-BEB or IB-BEB components. Frames passed 268 through this interface contain an S-TAG field. 270 S-VLAN: The specific service VLAN identifier carried inside an S-TAG 272 4. H-VPLS with Homogeneous PBBN Access 274 PBBN access offers MAC-address table scalability for H-VPLS PE 275 nodes. This is due to the MAC tunneling encapsulation scheme of PBB 276 which only exposes the provider's own MAC addresses to PE nodes (B- 277 MACs of Provider's PBB-capable devices in the access network), as 278 opposed to customers' MAC addresses in conventional H-VPLS with MPLS 279 or 802.1ad access. 281 PBBN access also offers service instance scalability when compared 282 to H-VPLS with 802.1Q/802.1ad access networks. This is due to the 283 new 24-bit service identifier (I-SID) used in PBB encapsulation, 284 which allows up to 16M services per PBB access network, compared to 285 4K services per 802.1Q/802.1ad access network. 287 Another important advantage of PBBN access is that it offers clear 288 separation between the service layer (represented by I-SID) and the 289 network layer (represented by B-VLAN). B-VLANs segregate a PBB 290 access network into different broadcast domains and possibly unique 291 spanning-tree topologies, with each domain being able to carry 292 multiple services (i.e. I-SIDs). In 802.1ad access networks, the 293 network and service layers are the same (represented by S-VLAN). 294 This separation allows the Provider to manage and optimize the PBB 295 access network topology independent of the number of service 296 instances that are supported. 298 In this and the following sections we look into different flavors of 299 H-VPLS with PBBN access. This section discusses the case where H- 300 VPLS is deployed with homogenous PBBN access networks. Section 5 301 describes the case where at least one of the access networks is PBN 302 access (QinQ/802.1ad) while others are PBBN access. 304 At a macro scale, a network that employs H-VPLS with PBBN access can 305 be represented as shown in figure 1 below. 307 +--------------+ 308 | | 309 +---------+ | IP/MPLS | +---------+ 310 +----+ | | +----+ +----+ | | +----+ 311 | CE |--| | |VPLS| |VPLS| | |--| CE | 312 +----+ | PBBN |---| PE | | PE |--| PBBN | +----+ 313 +----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+ 314 | CE |--| | | Backbone | | |--| CE | 315 +----+ +---------+ +--------------+ +---------+ +----+ 317 Figure 1: H-VPLS with PBBN Access 319 In the context of PBBN and H-VPLS interoperability, "I-SID Domain" 320 and "B-VID Domain" can be defined as follows: 322 - "I-SID Domain" refers to a network administrative boundary under 323 which all the PBB BEBs and VPLS PE devices use the same I-SID 324 space, i.e. the I-SID assignment is carried out by the same 325 administration. This effectively means that a given service 326 instance has the same I-SID designation on all devices within an 327 I-SID Domain. 328 - "B-VID Domain" refers to a network administrative boundary under 329 which all the PBB BEBs and VPLS PE devices employ consistent I-SID 330 to B-VLAN bundling - e.g., grouping of I-SIDs to B-VLANs are the 331 same in that domain. Although the two B-VLANs in two PBBNs that 332 represent the same group of I-SIDs do not need to use the same B- 333 VID value, in practice they often use the same value because once 334 the I-SID grouping is made identical in two PBBNs, it is rather 335 very easy to make the values of the corresponding B-VIDs also 336 identical. 338 Consequently, three different kinds of "Service Domains" are defined 339 in the following manner: 341 - Tightly Coupled Service Domain - Different PBBN access networks 342 belonging to the same I-SID Domain and B-VID Domain. However, the 343 network control protocols (e.g. xSTP) run independently in each 344 PBB access network. 345 - Loosely Coupled Service Domain - Different PBB access networks 346 belonging to the same I-SID Domain. However, each PBBN access 347 maintains its own independent B-VID Domain. Again, the network 348 control protocols (e.g. xSTP) run independently in each PBBN 349 access. 350 - Different Service Domain - In this case, each PBBN access 351 maintains its own independent I-SID Domain and B-VID Domain, with 352 independent network control protocols (e.g. xSTP) in each PBB 353 access. 355 In general, correct service connectivity spanning networks in a 356 Tightly Coupled Service Domain can be achieved via B-VID mapping 357 between the networks (often even without B-VID translation). 358 However, correct service connectivity spanning networks in a Loosely 359 Coupled Service Domain requires I-SID to B-VID re-mapping (i.e 360 unbundling and re-bundling of I-SIDs into B-VIDs). Furthermore, 361 service connectivity spanning networks in Different Service Domains 362 requires both I-SID translation and I-SID to B-VID re-mapping. 364 4.1 Service Interfaces and Interworking Options 366 Customer devices will interface with PBBN edge bridges using 367 existing Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad. 368 At the PBBN edge, customer MAC frames are encapsulated in a PBB 369 header that includes a service provider source and destination MAC 370 addresses (B-MAC) and are bridged up to the VPLS PE. The PBB 371 encapsulated customer MAC frame is then injected into the VPLS 372 backbone network, delivered to the remote VPLS PE node(s), and 373 switched onto the remote PBBN access. From there, the PBBN bridges 374 the encapsulated frame to a PBBN edge bridge where the PBB header is 375 removed and the customer frame is sent to customer domain. 377 Interoperating between PBBN devices and VPLS PE nodes will certainly 378 leverage work already completed. When I-SID visibility is required 379 at the VPLS PE nodes, a new service interface based on I-SID tag 380 will need to be defined. 382 Moreover, by mapping a bridge domain (e.g. B-VLAN) to a VPLS 383 instance, and bundling multiple end-customer service instances, 384 represented by I-SIDs, over the same bridge domain, service 385 providers will be able to significantly reduce the number of full- 386 mesh PWs required in the core. In this case, I-SID visibility is not 387 required on the VPLS-PE and the I-SID will serve as the means of 388 multiplexing/de-multiplexing individual service instances in the 389 PBBN over a bundle (e.g. B-VLAN). 391 When I-SID visibility is expected across the service interface at 392 the VPLS PE, VPLS PE can be considered to offer service-level 393 interworking between PBBN access and IP/MPLS core. Similarly, when 394 PE is not expected to have visibility of I-SID at the service 395 interface, VPLS PE can be considered to offer network-level 396 interworking between PBBN access and MPLS core. 398 A VPLS PE is always part of the IP/MPLS core, and may optionally 399 participate in the control protocols (e.g. xSTP) of the access 400 network. When connecting to a PBBN access, the VPLS PE needs to 401 support one of the following two types of service interfaces: 403 - Type I: B-Tagged Service Interface with B-VID as Service Delimiter 404 - The PE connects to a Backbone Core Bridge (BCB) in PBBN access. 405 The handoff between the BCB and the PE is B-Tagged PBB 406 encapsulated frame. The PE is transparent to PBB encapsulations 407 and treats these frames as 802.1ad frames since B-VID EtherType is 408 the same as S-VID EtherType. The PE does not need to support PBB 409 functionality. This corresponds to conventional VPLS PE's tagged 410 service interface. When using Type I service interface, the PE 411 needs to support either raw-mode or tagged-mode Ethernet PW. Type 412 I Service Interface is described in detail in Section 4.2. 414 - Type II: I-Tagged Service Interface with I-SID as Service 415 Delimiter - The PE connects to a B-BEB (Backbone Edge Bridge with 416 B-Component) in PBBN access. The PE itself also supports the B-BEB 417 functionality of [802.1ah]. The handoff between the B-BEB in PBBN 418 access and the PE is an I-Tagged PBB encapsulated frame. With Type 419 II service interface, the PE supports the existing raw-mode and 420 tagged-mode PW types. Type II Service Interface is described in 421 detail in Section 4.3. 423 4.2 H-VPLS with PBBN Access: Type I Service Interface 425 This is a B-Tagged service interface with B-VID as service delimiter 426 on the VPLS-PE. It does not require any new functionality on the 427 VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS 428 core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on 429 right side of Figure 2) by participating in network control 430 protocols (e.g. xSTP) of the PBBN access. 432 PBBN Access IP/MPLS Core PBBN Access 433 +--------------+ 434 +---------+ | | +---------------+ 435 | | +----+ | | | 436 | +---+ |VPLS| +-+ | | +---+ | 437 | |BCB|---| PE |---|P| | | |BCB| | 438 | +---+ /+----+ /+-+\ | | /+---+ | 439 |+---+ | / +----+ / \+----+ / +---+| 440 +--+ ||IB-| +---+/ |VPLS|/ +-+ |VPLS|/ +---+ |IB-|| +--+ 441 |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE| 442 +--+ |+---+ +---+ ^ +----+ +-+ +----+ ^ +---+ +---+| +--+ 443 | | | | | | | | 444 +---------+ | | | +--|------------+ 445 | +--------------+ | 446 | | 447 Type I Type I 449 Figure 2: H-VPLS with PBBN Access & Type I Service Interface 451 Type I service interface is applicable to networks with Tightly 452 Coupled Service Domains, where both I-SID Domains and B-VID Domains 453 are the same across all PBBN access networks. 455 The BCB and VPLS PE will exchange PBB encapsulated frames that 456 include source and destination B-MAC addresses, a B-VID and I-SID. 457 The service delimiter, from the perspective of the VPLS PE, is the 458 B-VID; in fact, this interface operates exactly as a current 459 802.1Q/ad interface into a VPLS PE does today. With Type I service 460 interface, VPLS PE can be considered as providing network-level 461 interworking between PBBN and MPLS domains, since VPLS PE does not 462 have visibility of I-SIDs. 464 The main advantage of this service interface, when compared to other 465 types, is that it allows the service provider to save on the number 466 of full-mesh PWs required in the core. This is primarily because 467 multiple service instances (I-SIDs) are bundled over a single full- 468 mesh corresponding to a bridge domain (e.g. B-VID), instead of 469 requiring a dedicated full-mesh per service instance. Another 470 advantage is the MAC address scalability in the core since the core 471 is not exposed to C-MACs. 473 The disadvantage of this interface is the comparably excessive 474 replication required in the core: since a group of service instances 475 share the same full-mesh of PWs, an unknown unicast, multicast or 476 broadcast on a single service instance will result in a flood over 477 the core. This, however, can be mitigated via the use of per I-SID 478 flood containment (B-MAC multicast pruning) as described in [PBB- 479 VPLS-MCAST]. 481 Three different modes of operation are supported by Type I Service 482 Interface: 484 - Port Mode: All traffic over an interface in this mode is mapped to 485 a single VPLS instance. Existing PW signaling and Ethernet raw 486 mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are 487 supported. 489 - VLAN Mode: all traffic associated with a particular VLAN 490 identified by the B-VID is mapped to a single VPLS instance. 491 Existing PW signaling and Ethernet raw mode (0x0005) PW type, 492 defined in [RFC4447] [RFC4448], are supported. 494 - VLAN Bundling Mode: all traffic associated with a group or range 495 of VLANs or B-VIDs is mapped to a single VPLS instance. Existing 496 PW signaling and Ethernet raw mode (0x0005) PW type, defined in 497 [RFC4447] [RFC4448], are supported. 499 For the above three modes, it is also possible to use Ethernet 500 tagged mode (0x0004) PW, as defined in [RFC4447] [RFC4448], for 501 interoperability with equipment that does not support raw mode. The 502 use of raw mode is recommended to be the default though. 504 4.3 H-VPLS with PBBN Access: Type II Service Interface 505 This is an I-Tagged service interface with I-SID as service 506 delimiter on VPLS-PE. It requires the VPLS-PE to include B-Component 507 of PBB BEB for I-SID processing in addition to the capability to map 508 I-SID Bundle to VPLS instance. As shown in Figure 3, the PE is 509 always part of IP/MPLS core and connects to one or more B-BEB in 510 PBBN access. 512 PBBN Access IP/MPLS Core PBBN Access 513 +--------------+ 514 +---------+ | | +---------+ 515 | | | | | | 516 | +---+ +-----+ | | +---+ | 517 | |B- | |PE w/| +-+ | | |BCB| | 518 | |BEB|--|B-BEB|-|P| | | +---+ | 519 | +---+ /+-----+ +-+ | | / | | 520 |+---+ +---+/ +-----+/ \+-----+ +---+ +---+| 521 +--+ ||IB-| |B- | |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 522 |CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 523 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 524 | | | | | | | | 525 +---------+ | | | | +---------+ 526 | +-------------+ | 527 | | 528 Type II Type II 530 Figure 3: H-VPLS with PBBN Access & Type II Service Interface 532 Type II service interface is applicable to Loosely Coupled Service 533 Domains and Different Service Domains. B-VID Domains can be 534 independent and the B-VID is always locally significant in each PBBN 535 access and does not need to be transported over the IP/MPLS core. 536 Given the above, it should be apparent that Type II service 537 interface is applicable to Tightly Coupled Service Domains as well. 539 By definition the B-BEB connecting to the VPLS PE will remove any B- 540 VLAN tags for frames exiting the PBB access network. The B-BEB and 541 VPLS PE will exchange PBB encapsulated frames that include source 542 and destination B-MAC addresses, and I-SID. The service delimiter, 543 from the perspective of the VPLS PE, is the I-SID. Since PE has 544 visibility to I-SIDs, the PE provides service-level interworking 545 between PBBN access and IP/MPLS core. 547 The advantage that Type II service interface has compared to Type I 548 is the potentially less replication in the core without the need for 549 a per I-SID flood containment (B-MAC multicast pruning) mechanism. 550 This is mainly due to the increased segregation of service instances 551 over disjoint full-meshes of PWs. 553 The disadvantage of this service interface, compared to Type I, is 554 that it may require a larger number of full-mesh PWs in the core. 555 However, the number of full-mesh PWs can still be less than those 556 required by H-VPLS without PBBN access. 558 It is expected that this interface type will be used for customers 559 with significant multicast traffic (but without multicast pruning 560 capability in VPLS PE) so that a separate VPLS instance is set up 561 per group of customers with similar geographic locality (per I-SID 562 group). 564 Type II Service Interface may operate in I-SID Bundling Mode: all 565 traffic associated with a group or range of I-SIDs is mapped to a 566 single VPLS instance. The PE maintains a mapping of I-SIDs to a PE 567 local bridge domain (e.g. B-VID). The VPLS instance is then 568 associated with this bridge domain. With Tightly and Loosely Coupled 569 Service Domains, no I-SID translation needs to be performed. Type II 570 Service Interface also supports Different Service Domains in this 571 mode, since the B-BEB link in the PE connecting to the local PBBN 572 can perform the translation of PBBN-specific I-SID to a local I-SID 573 within the IP/MPLS core, which may then be translated to the other 574 PBBN specific I-SID on the egress PE. Such translation can also 575 occur in the B-BEB of PBBN access. Existing PW signaling and 576 Ethernet raw mode (0x0005), defined in [RFC4447] [RFC4448], is 577 supported. It is also possible to use tagged mode (0x0004) PW for 578 purpose of interoperability with equipment that does not support raw 579 mode. 581 Note 1: Port mode is not called out in Type II Service Interface 582 since it requires the mapping of I-SIDs to be identical on different 583 I-Tagged interfaces across VPLS network. If this is indeed the case, 584 Port mode defined in Type I Service Interface (Section 4.2) can be 585 used. 587 Note 2: In a degenerate scenario, it is possible to define an I-SID 588 bundle that comprises a single I-SID. This allows the Type II 589 service interface to effectively operate as if in I-SID Mode, at the 590 added expense of consuming more bridge-domains on the PE and 591 increased number of PW full-mesh in the core. 593 5. H-VPLS with Mixed PBBN Access and PBN Access 595 It is foreseeable that service providers will want to interoperate 596 their existing PBN (QinQ) access networks with PBBN access networks 597 over H-VPLS. Figure 4 below shows the high-level network topology. 599 +--------------+ 600 | | 601 +---------+ | IP/MPLS | +---------+ 602 +----+ | | +----+ +----+ | | +----+ 603 | CE |--| PBN | |VPLS| |VPLS| | |--| CE | 604 +----+ | (QinQ) |---| PE1| | PE2|--| PBBN | +----+ 605 +----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+ 606 | CE |--| | | Backbone | | |--| CE | 607 +----+ +---------+ +--------------+ +---------+ +----+ 609 Figure 4: H-VPLS with Mixed PBN and PBBN Access Networks 611 Referring to Figure 4 above, two possibilities come into play 612 depending on whether the interworking is carried out at PE1 or PE2. 613 These are described in the following sub-Sections. 615 5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE 617 As shown in Figure 5, the operation of VPLS PE2 (connecting to the 618 PBBN access on the right) is no different from what was discussed in 619 Section 4. Type II service interface, as discussed in the above 620 section, is applicable. It is the behavior of VPLS PE1 (connecting 621 to the PBN access on the left) that is the focus of this section. 623 PBN Access IP/MPLS Core PBBN Access 624 (802.1ad) +--------------+ (802.1ah) 625 | | +---------+ 626 +---------+ | | | | 627 | | +-----+ | | +---+ | 628 | +---+ |PE w/| +-+ | | |BCB| | 629 | |PCB|--|IBBEB|-|P| | | +---+ | 630 | +---+ /+-----+ +-+ | | / | | 631 | | / +-----+/ \+-----+ +---+ +---+| 632 +--+ |+---+ +---+ |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 633 |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 634 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 635 | | | |PE1 PE2| | | | 636 +---------+ | | | | +---------+ 637 | +-------------+ | 638 | | 639 S-Tagged Type II (I-Tagged) 641 Figure 5: H-VPLS with Mixed PBN and PBBN Access: Modified PBN PE 642 Some assumptions made for this topology include: 643 - CE is directly connected to PBBN via S-Tagged or port-based 644 Interface 645 - I-SID in PBBN access represents the same customer as S-VID in PBN 646 access 647 - At S-Tagged Service Interface of PE with IB-BEB functionality 648 (e.g. PE1 in Figure 5), the only viable service is 1:1 mapping of 649 S-VID to I-SID. However, towards the core network side, the same 650 PE can support I-SID bundling into a VPLS instance. 651 - PE1 participates in the local ISID domain of the IP/MPLS Core so 652 the model accommodates for the rest of the PBB network any of the 653 three domain types described in section 4 - Tightly, Loosely 654 Coupled and Different Service Domains. 655 - For ease of provisioning in these disparate access networks, it is 656 recommended to use the same I-SID Domain among the PBBN access and 657 PEs with IB-BEB functionality (those connecting to PBN). 659 This topology operates in I-SID Bundling Mode: at PE connecting to 660 PBN access, each S-VID is mapped to an I-SID and subsequently a 661 group of I-SIDs is mapped to a VPLS instance. Similarly, at PE 662 connecting to PBBN access, each group of I-SIDs is mapped to a VPLS 663 instance. Similar to Type II interface, no I-SID translation is 664 performed for I-SID bundling case. Existing PW signaling and 665 Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], 666 are supported. It is possible to use tagged mode (0x0004) PW for 667 backward compatibility as well. 669 5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE 671 As shown in Figure 6, the operation of VPLS PE1 (connecting to the 672 PBN access on the left) is no different from existing VPLS PEs. It 673 is the behavior of VPLS PE2 (connecting to the PBBN access on the 674 right) that is the focus of this section. 676 PBN Access IP/MPLS Core PBBN Access 677 (802.1ad) +--------------+ (802.1ah) 678 | | +---------+ 679 +---------+ | | | | 680 | | +-----+ | | +---+ | 681 | +---+ | PE | +-+ | | |BCB| | 682 | |PCB|--| |-|P| | | +---+ | 683 | +---+ /+-----+ +-+ | | / | | 684 | | / +-----+/ \+-----+ +---+ +---+| 685 +--+ |+---+ +---+ | PE | +-+ |PE w/| |B- | |IB-|| +--+ 686 |CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BEB| |BEB|--|CE| 687 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 688 | | | |PE1 PE2| | | | 689 +---------+ | | | | +---------+ 690 | +-------------+ | 691 | | 692 S-Tagged Type II (I-Tagged) 694 Figure 6: H-VPLS with Mixed PBN and PBBN Access: Regular PBN PE 696 Some assumptions made for this topology include: 697 - CE is directly connected to PBBN via S-Tagged or port-based 698 Interface 699 - I-SID in PBBN access represents the same customer as S-VID in PBN 700 access 701 - There is 1:1 mapping between the I-SID and VPLS instance 702 - At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in 703 Figure 6), the PE only provides 1:1 mapping of S-VID to VPLS 704 instance. S-VID bundling is not a viable option since it does not 705 correspond to anything in PBBN access. 706 - The PE connecting to PBBN (e.g. PE2 in Figure 6), supports IB-BEB 707 functionality and the I-Component is connected to the VPLS 708 Forwarder (i.e. the I-Component faces the MPLS core whereas the B- 709 Component faces the PBBN access network). One or more I-SIDs can 710 be grouped into a B-VID in the PBBN access. 711 - Since C-VID grouping in different PBBN access networks must be 712 consistent, it is assumed that same I-SID Domain is used across 713 these PBBN access networks. 715 Unlike the other topology, I-SID bundling mode is not supported in 716 this case. This is primarily because the VPLS core operates in the 717 same manner as today. The PE with IB-BEB functionality connecting to 718 PBBN access performs the mapping of each VPLS instance to an I-SID 719 and one or more of these I-SIDs may be mapped onto a B-VID within 720 the PBBN access network. 722 6. H-VPLS with MPLS Access 724 In this section, the case of H-VPLS with MPLS access network is 725 discussed. The integration of PBB functionality into VPLS-PE for 726 such access networks is described to improve the scalability of the 727 network in terms of the number of MAC addresses and service 728 instances that are supported. 730 For this topology, it is possible to embed PBB functionality in 731 either the U-PE or the N-PE. Both of these cases are described in 732 the following sub-sections. 734 6.1 H-VPLS with MPLS Access: PBB U-PE 736 As stated earlier, the objective for incorporating PBB function at 737 the U-PE is to improve the scalability of H-VPLS networks in terms 738 of the number of MAC addresses and service instances that are 739 supported. 741 In current H-VPLS, the N-PE must learn customer MAC addresses (C- 742 MACs) of all VPLS instances that it participates in. This can easily 743 add-up to hundreds of thousands or even millions of C-MACs at the N- 744 PE. When the U-PE performs PBB encapsulation, the N-PE only needs to 745 learn the MAC addresses of the U-PEs, which is a significant 746 reduction. Furthermore, when PBB encapsulation is used, many I-SIDs 747 are multiplexed within a single bridge domain (e.g., B-VLAN). If the 748 VPLS instance is set up per B-VLAN, then one can also achieve a 749 significant reduction in the number of full-mesh PWs. It should be 750 noted that this reduction in full-mesh PWs comes at the cost of 751 potentially increased replication over the full-mesh of PWs: A given 752 customer multicast and/or broadcast frames are effectively 753 broadcasted within the B-VLAN. This may result in additional frame 754 replication because the full-mesh PWs corresponding to a B-VLAN is 755 most likely bigger than the full-mesh PWs corresponding to a single 756 I-SID. However, per I-SID flood containment (B-MAC multicast 757 pruning) as described in [PBB-VPLS-MCAST] can be used to remedy this 758 drawback and have multicast traffic replicated efficiently for each 759 customer (i.e. for each I-SID). 761 Figure 7 below illustrates the scenario for H-VPLS with MPLS access. 762 As it can be seen, customer networks or hosts (CE) connect into the 763 U-PE nodes using standard Ethernet interfaces [802.1D], [802.1Q], or 764 [802.1ad]. The U-PE is connected upstream to one or more VPLS N-PE 765 nodes by MPLS PWs (per VPLS instance). These, in turn, are connected 766 via a full-mesh of PWs (per VPLS instance) traversing the IP/MPLS 767 core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB) 768 functions where it can encapsulate/de-encapsulate customer MAC 769 frames in provider B-MAC addresses and perform I-SID translation if 770 needed. 772 PBB PBB 773 BEB +----------+ BEB 774 | | | | 775 | +-----------+ | IP | +-----------+ | 776 | | MPLS | | MPLS | | MPLS | | 777 V | Access +----+ | Core | +----+ Access | V 778 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 779 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 780 +--+ +----+ +----+ | | +----+ +----+ +--+ 781 | | | | | | 782 +-----------+ +----------+ +-----------+ 784 Figure 7: H-VPLS with MPLS Access Network and PBB U-PE 786 The U-PE still provides the same type of services toward its 787 customers as before and they are: 789 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 790 - VLAN mode (either 802.1Q or 802.1ad) 791 - VLAN-bundling mode (either 802.1Q or 802.1ad) 793 By incorporating PBB function, the U-PE maps each of these services 794 (for a given customer) onto a single I-SID based on the 795 configuration at the U-PE. Many I-SIDs are multiplexed within a 796 single bridge domain (e.g. B-VLAN). The U-PE can then map a bridge- 797 domain onto a VPLS instance and the encapsulated frames are sent 798 over the PW associated with that VPLS instance. Furthermore the 799 entire Ethernet bridging operation over VPLS network is performed as 800 defined in [RFC4762]. In other words, MAC forwarding is based on the 801 B-MAC address space and service delimiter is based on VLAN ID, which 802 is B-VID in this case. There is no need to inspect or deal with I- 803 SID values in the VPLS N-PEs. 805 6.1.1 PBB U-PEs in Single I-SID Domain 807 In this scenario, I-SID assignment is performed globally across all 808 MPLS access networks and therefore there is no need for I-SID 809 translation. This scenario support I-SID bundling mode and it is 810 assumed that the mapping of the I-SIDs to the bridge domain (e.g., 811 B-VLAN) is consistent across all the participating PE devices. In 812 case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is 813 mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or 814 tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448]. 816 I-SID mode can be considered as a degenerate case of I-SID bundling 817 where a single bridge domain is used per I-SID. However, that 818 results in increase number of bridge domains and PWs in the PEs. PBB 819 flood containment (B-MAC multicast pruning) per I-SID as described 820 in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling 821 mode to limit the scope of flooding per I-SID thus removing the need 822 for I-SID mode. 824 6.2 H-VPLS with MPLS Access: PBB N-PE 826 In this case, the PBB function is incorporated at the N-PE to 827 improve the scalability of H-VPLS networks in terms of the numbers 828 of MAC addresses and service instances that are supported. 830 Customer networks or hosts (CE) connect into the U-PE nodes using 831 standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The 832 U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS 833 PWs (per customer). These, in turn, are connected via a full-mesh of 834 PWs (per customer or group of customers) traversing the IP/MPLS 835 core. 837 The U-PE still provides the same type of services toward its 838 customers as before and they are: 840 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 841 - VLAN mode (either 802.1Q or 802.1ad) 842 - VLAN-bundling mode (either 802.1Q or 802.1ad) 844 Spoke PW from U-PE to N-PE is not service multiplexed because there 845 is no PBB functionality on u-PE - i.e. one service per PW. 847 PBB PBB 848 BEB +----------+ BEB 849 | | | | 850 +-----------+ | | IP | | +-----------+ 851 | MPLS | V | MPLS | V | MPLS | 852 | Access +----+ | Core | +----+ Access | 853 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 854 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 855 +--+ +----+ +----+ | | +----+ +----+ +--+ 856 | | | | | | 857 +-----------+ +----------+ +-----------+ 859 Figure 8: H-VPLS with MPLS Access Network and PBB N-PE 861 By incorporating PBB function, the N-PE maps each of these services 862 (for a given customer) onto a single I-SID based on the 863 configuration at the N-PE. Many I-SIDs can be multiplexed within a 864 single bridge domain (e.g. B-VLAN). The N-PE can, then, either map a 865 single I-SID into a VPLS instance or it can map a bridge domain 866 (e.g. B-VLAN) onto a VPLS instance, according to its configuration. 867 Next, the encapsulated frames are sent over the set of PWs 868 associated with that VPLS instance. 870 6.2.1 PBB N-PEs in Single I-SID Domain 872 In this scenario, I-SID assignment is performed globally across all 873 MPLS access networks and therefore there is no need for I-SID 874 translation. This scenario support I-SID bundling mode and it is 875 assumed that the mapping of the I-SIDs to the bridge domain (e.g., 876 B-VLAN) is consistent across all the participating PE devices. In 877 case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is 878 mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or 879 tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448], can 880 be used. 882 I-SID mode can be considered as a degenerate case of I-SID bundling 883 where a single bridge domain is used per I-SID. However, that 884 results in increase number of bridge domains and PWs in the PE. PBB 885 flood containment (B-MAC multicast pruning) per I-SID as described 886 in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling 887 mode to limit the scope of flooding per I-SID thus removing the need 888 for I-SID mode. 890 7. H-VPLS with MPLS Access: PBB Migration Scenarios 892 Operators and service providers that have deployed H-VPLS with 893 either MPLS or Ethernet are unlikely to migrate to PBB technology 894 overnight because of obvious cost implications. Thus, it is 895 imperative to outline migration strategies that will allow operators 896 to protect investments in their installed base while still taking 897 advantage of the scalability benefits of PBB technology. 899 In the following sub-sections, we explore three different migration 900 scenarios which allow a mix of existing H-VPLS access networks to 901 co-exist with newer PBB-based access networks. The scenarios differ 902 in whether the Ethernet service frames passing over the VPLS core 903 are PBB-encapsulated or not. The first scenario in section 7.1 904 involves passing only non PBB-encapsulated frames over the core. The 905 second scenario in section 7.2 stipulates passing only PBB- 906 encapsulated frames over the core. Whereas, the final scenario in 907 section 7.3 depicts a core that supports a mix of PBB-encapsulated 908 and non PBB-encapsulated frames. The advantages and disadvantages of 909 each scenario will be discussed in its respective section. 911 7.1 802.1ad Service Frames over VPLS Core 913 In this scenario, existing access networks are left unchanged. All 914 N-PEs would forward frames based on C-MAC addresses. In other words, 915 Ethernet frames which are traversing the VPLS core (within PWs) 916 would use the 802.1ad frame format, as in current VPLS. Hence, the 917 N-PEs in existing access networks do not require any modification. 918 For new MPLS access networks that have PBB functions on the U-PE, 919 the corresponding N-PE must incorporate built-in IB-BEB functions in 920 order to terminate the PBB encapsulation before the frames enter the 921 core. A key point here is that while both the U-PE and N-PE nodes 922 implement PBB IB-BEB functionality, the former has the I-Component 923 facing the customer (CE) and the B-Component facing the core; 924 whereas the latter has the I-Component facing the core and the B- 925 Component facing the customer (i.e. access network). 927 PBB PBB 928 +----------+ IB-BEB IB-BEB 929 | | | | 930 +-----------+ | IP | | +-----------+ | 931 | MPLS | | MPLS | V | MPLS | | 932 | Access +----+ | Core | +----+ Access | V 933 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 934 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 935 +--+ +----+ +----+ | | +----+ +----+ +--+ 936 | (Existing)| | | | (New) | 937 +-----------+ +----------+ +-----------+ 939 Figure 9: Migration with 802.1ad Service Frames over VPLS Core 941 The main advantage of this approach is that it requires no change to 942 existing access networks or existing VPLS N-PEs. The main 943 disadvantage is that these N-PEs will not leverage the advantages of 944 PBB in terms of MAC address and PW scalability. 945 It is worth noting that this migration scenario is an optimal option 946 for an H-VPLS deployment with a single PBB-capable access network. 947 When multiple PBB-capable access networks are required, then the 948 scenario in Section 7.3 is preferred, as it provides a more scalable 949 and optimal interconnect amongst the PBB-capable networks. 951 7.2 PBB Service Frames over VPLS Core 953 This scenario requires that the VPLS N-PE connecting to existing 954 MPLS access networks be upgraded to incorporate IB-BEB functions. 955 All Ethernet service frames passing over the VPLS core would be PBB- 956 encapsulated. The PBB over MPLS access networks would require no 957 special requirements beyond what is captured in section 6 of this 958 document. 959 In this case, both the U-PE and N-PE which implement IB-BEB 960 functionality have the I-Component facing the customer and the B- 961 Component facing the core. 963 PBB PBB 964 IB-BEB +----------+ IB-BEB 965 | | | | 966 +-----------+ | | IP | +-----------+ | 967 | MPLS | V | MPLS | | MPLS | | 968 | Access +----+ | Core | +----+ Access | V 969 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 970 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 971 +--+ +----+ +----+ | | +----+ +----+ +--+ 972 | (Existing)| | | | (New) | 973 +-----------+ +----------+ +-----------+ 975 Figure 10: Migration with PBB Service Frames over VPLS Core 977 The main advantage of this approach is that it allows better 978 scalability of the VPLS N-PEs in terms of MAC address and pseudowire 979 counts. The disadvantage is that it requires upgrading the VPLS N- 980 PEs of all existing MPLS access networks. 982 7.3 Mixed 802.1ad and PBB over VPLS Core 984 In this scenario, existing access networks are left unchanged, and 985 exchange Ethernet frames with 802.1ad format over the PWs in the 986 core. The newly added access networks, which incorporate PBB 987 functionality exchange Ethernet frames that are PBB-encapsulated 988 amongst each other over core PWs. For service connectivity between 989 existing access network (non PBB capable) and new access network 990 (PBB based), the VPLS N-PE of the latter network employs IB-BEB 991 functionality to de-capsulate the PBB header from frames outbound to 992 the core, and encapsulate the PBB header for frames inbound from the 993 core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet 994 service frames are exchanged over the VPLS core. 996 This mode of operation requires new functionality on the VPLS N-PE 997 of the PBB-capable access network, so that the PE can send frames in 998 802.1ad format or PBB format, on a per PW basis, depending on the 999 capability of the destination access network. Effectively, the PE 1000 would have to incorporate B-BEB as well as IB-BEB functions. 1002 A given PE needs to be aware of the capability of its remote peer in 1003 order to determine whether it connects to the right PW Forwarder. 1004 This can be achieved either via static configuration, or by 1005 extending the VPLS control plane (BGP-based auto-discovery and LDP 1006 Signaling) discussed in [L2VPN-Sig]. The latter approach and the 1007 details of the extensions required are out of scope for this 1008 document and will be covered in a separate document. 1010 PBB 1011 B-BEB PBB 1012 +----------+ IB-BEB IB-BEB 1013 | | | | 1014 +-----------+ | IP | | +-----------+ | 1015 | MPLS | | MPLS | V | MPLS | | 1016 | Access +----+ | Core | +----+ Access | V 1017 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 1018 |CE|--|U-PE| |N-PE| | | |N-PE| |U-PE|--|CE| 1019 +--+ +----+ +----+ | | +----+ +----+ +--+ 1020 | (Existing)| | | | (New) | 1021 +-----------+ +----------+ +-----------+ 1023 Figure 11: Migration with Mixed 802.1ad &PBB Service Frames over VPLS 1024 Core 1026 The U-PE and N-PE of the PBB-capable access network both employ BEB 1027 functionality: The U-PE implements IB-BEB function where the I- 1028 Component faces the customer (CE) and the B-Component faces the 1029 core. The N-PE, on the other hand, implements IB-BEB functionality 1030 with the I-Component facing the core and the B-Component facing the 1031 customer (access network). In addition, the N-PE implements stand- 1032 alone B-BEB functionality. 1034 This scenario combines the advantages of both previous scenarios 1035 without any of their shortcomings, namely: it does not require any 1036 changes to existing access networks and it allows the N-PE to 1037 leverage the scalability benefits of 802.1ah for PBB to PBB access 1038 network connectivity. The disadvantage of this option is that it 1039 requires new functionality on the N-PE of the PBB-capable access 1040 network. 1042 8. Acknowledgments 1044 TBD. 1046 9. IANA Considerations 1048 This document has no actions for IANA. 1050 10. Security Considerations 1052 This document does not introduce any additional security aspects 1053 beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security 1054 considerations are already covered in [RFC4762]. 1056 11. References 1058 11.1 Normative References 1060 [802.1ad] "Virtual Bridged Local Area Networks, Amendment 4: 1061 Provider Bridges", IEEE Std. 802.1ad-2005, May 2006 1063 [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider 1064 Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008 1066 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 1067 April 2006 1069 [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS 1070 Networks", RFC4448, April 2006 1072 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label 1073 Distribution Protocol (LDP) Signaling", RFC4762, January 2007 1075 [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and 1076 Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt, May 2006 1077 ( work in progress ) 1079 11.2 Informative References 1081 [802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q- 1082 2005 1084 [802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D- 1085 2003 1087 [VPLS-Bridge] "VPLS Interoperability with CE Bridges", draft-ietf- 1088 l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 2007 1090 [VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast- 1091 03.txt, Work in progress, November 2007 1093 [PBB-VPLS-MCAST] "Multicast Pruning in Provider Backbone Bridged 1094 VPLS", draft-sajassi-l2vpn-pbb-vpls-mcast-pruning-00.txt, Work in 1095 progress, July 2008 1097 Authors' Addresses 1099 Ali Sajassi 1100 Cisco 1101 170 West Tasman Drive 1102 San Jose, CA 95134, US 1103 Email: sajassi@cisco.com 1105 Samer Salam 1106 Cisco 1107 595 Burrard Street, Suite 2123 1108 Vancouver, BC V7X 1J1, Canada 1109 Email: ssalam@cisco.com 1111 Chris Metz 1112 Cisco 1113 170 West Tasman Drive 1114 San Jose, CA 95134, US 1115 Email: metz@cisco.com 1117 Nabil Bitar 1118 Verizon Communications 1119 Email : nabil.n.bitar@verizon.com 1121 Dinesh Mohan 1122 Nortel 1123 3500 Carling Ave 1124 Ottawa, ON K2H8E9, Canada 1125 Email: mohand@nortel.com 1127 Florin Balus 1128 Alcatel-Lucent 1129 701 E. Middlefield Road 1130 Mountain View, CA, USA 94043 1131 Email: florin.balus@alcatel-lucent.com