idnits 2.17.1 draft-ietf-l2vpn-pbb-vpls-interop-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3812 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Intended Status: Informational Cisco 6 Nabil Bitar 7 Verizon 9 Florin Balus 10 Nuage Networks 12 Expires: April 21, 2014 October 21, 2013 14 VPLS Interoperability with Provider Backbone Bridges 15 draft-ietf-l2vpn-pbb-vpls-interop-06 17 Abstract 19 The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) 20 with Ethernet access networks [RFC4762] can be improved by 21 incorporating Provider Backbone Bridge functionality in the VPLS 22 access. Provider Backbone Bridging has been standardized as IEEE 23 802.1ah-2008, and aims to improve the scalability of MAC addresses 24 and service instances in Provider Ethernet networks. This document 25 describes different interoperability scenarios where Provider 26 Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS 27 access network to attain better scalability in terms of number of 28 customer MAC addresses and number of service instances. The document 29 also describes the scenarios and the mechanisms for incorporating 30 Provider Backbone Bridge functionality within H-VPLS with existing 31 Ethernet access and interoperability among them. Furthermore, the 32 document discusses the migration mechanisms and scenarios by which 33 Provider Backbone Bridge functionality can be incorporated into H- 34 VPLS with existing MPLS access. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as 44 Internet-Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 Copyright and License Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4. H-VPLS with Homogeneous PBBN Access . . . . . . . . . . . . . . 7 78 4.1 Service Interfaces and Interworking Options . . . . . . . . 9 79 4.2 H-VPLS with PBBN Access: Type I Service Interface . . . . . 10 80 4.3 H-VPLS with PBBN Access: Type II Service Interface . . . . . 12 81 5. H-VPLS with Mixed PBBN Access and PBN Access . . . . . . . . . 14 82 5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE . . . . 15 83 5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE . . . . 16 84 6. H-VPLS with MPLS Access . . . . . . . . . . . . . . . . . . . . 18 85 6.1 H-VPLS with MPLS Access: PBB U-PE . . . . . . . . . . . . . 18 86 6.2 H-VPLS with MPLS Access: PBB N-PE . . . . . . . . . . . . . 20 87 7. H-VPLS with MPLS Access: PBB Migration Scenarios . . . . . . . 21 88 7.1 802.1ad Service Frames over VPLS Core . . . . . . . . . . . 21 89 7.2 PBB Service Frames over VPLS Core . . . . . . . . . . . . . 22 90 7.3 Mixed 802.1ad and PBB over VPLS Core . . . . . . . . . . . . 23 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 11.1 Normative References . . . . . . . . . . . . . . . . . . . 25 97 11.2 Informative References . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) 103 with Ethernet access networks [RFC4762] can be improved by 104 incorporating Provider Backbone Bridge functionality in the VPLS 105 access. Provider Backbone Bridging has been standardized as IEEE 106 802.1ah-2008 [802.1ah], which is an amendment to IEEE 802.1Q to 107 improve the scalability of Media Access Control (MAC) addresses and 108 service instances in Provider Ethernet networks. This document 109 describes interoperability scenarios where IEEE 802.1ah functionality 110 is used in H-VPLS with Ethernet or MPLS access network to attain 111 better scalability in terms of the number of customer MAC addresses 112 and the number of services. 114 This document also covers the interoperability scenarios for 115 deploying H-VPLS with Provider Backbone Bridging Ethernet access when 116 other types of access networks are deployed, including existing 117 802.1ad Ethernet and MPLS access in either single or multiple service 118 domains. Furthermore, the document explores the scenarios by which an 119 operator can gradually migrate an existing H-VPLS network to Provider 120 Backbone Bridging over VPLS. 122 Section 2 gives a quick terminology reference and section 3 123 highlights the applicability of Provider Backbone Bridging 124 interoperation with VPLS. Section 4 describes H-VPLS with 125 homogeneous Provider Backbone Bridge Access Network. Section 5 126 discusses H-VPLS with mixed 802.1ah/802.1ad access. Section 6 focuses 127 on Provider Backbone Bridging in H-VPLS with MPLS Access Network 128 including Provider Backbone Bridge function on U-PE and on N-PE 129 variants. Finally, section 7 describes gradual migration scenarios 130 from existing H-VPLS to Provider Backbone Bridging over H-VPLS. 132 2. Terminology 134 802.1ad: IEEE specification for "QinQ" encapsulation and bridging of 135 Ethernet frames 137 802.1ah: IEEE specification for "MAC tunneling" encapsulation and 138 bridging of frames across a provider backbone bridged network. 140 B-BEB: A backbone edge bridge positioned at the edge of a provider 141 backbone bridged network. It contains a B-component that supports 142 bridging in the provider backbone based on B-MAC and B-TAG 143 information 145 B-MAC: The backbone source or destination MAC address fields defined 146 in the 802.1ah provider MAC encapsulation header. 148 BCB: A backbone core bridge running in the core of a provider 149 backbone bridged network. It bridges frames based on B-TAG 150 information just as an 802.1ad provider bridge will bridge frames 151 based on a VLAN identifier (S-VLAN) 153 B-Component: The backbone component of a Provider Backbone edge 154 bridge as defined in [802.1ah]. 156 BEB: A backbone edge bridge positioned at the edge of a provider 157 backbone bridged network. It can contain an I-component, B-component 158 or both I and B components. 160 B-MACs: Backbone MAC addresses - outer MAC addresses of a PBB 161 encapsulated frame 163 B-TAG: field defined in the 802.1ah provider MAC encapsulation 164 header that conveys the backbone VLAN identifier information. The 165 format of the B-TAG field is the same as that of an 802.1ad S-TAG 166 field. 168 B-Tagged Service Interface: This is the interface between a BEB and 169 BCB in a provider backbone bridged network. Frames passed through 170 this interface contain a B-TAG field. 172 B-VID: The specific VLAN identifier carried inside a B-TAG 174 C-MACs: Customer MAC addresses - inner MAC addresses of a PBB 175 encapsulated frame 177 H-VPLS: Hierarchical Virtual Private LAN Service 179 I-component: A bridging component contained in a backbone edge bridge 180 that bridges in the customer space (customer MAC addresses, S-VLAN) 182 IB-BEB: A backbone edge bridge positioned at the edge of a provider 183 backbone bridged network. It contains an I-component for bridging in 184 the customer space (customer MAC addresses, service VLAN IDs) and a 185 B-component for bridging the provider's backbone space (B-MAC, B- 186 TAG). 188 I-BEB: A backbone edge bridge positioned at the edge of a provider 189 backbone bridged network. It contains an I-component for bridging in 190 the customer space (customer MAC addresses, service VLAN IDs). 192 I-SID: The 24-bit service instance field carried inside the I-TAG. I- 193 SID defines the service instance that the frame should be "mapped 194 to". 196 I-TAG: A field defined in the 802.1ah provider MAC encapsulation 197 header that conveys the service instance information (I-SID) 198 associated with the frame. 200 I-Tagged Service Interface: This the interface defined between the I 201 and B components inside an IB-BEB or between two B-BEB. Frames passed 202 through this interface contain an I-TAG field 204 N-PE: Network-facing Provider Edge 206 PBB: Provider Backbone Bridge 208 PBBN: Provider Backbone Bridged Network 210 PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) 211 technology. 213 S-TAG: A field defined in the 802.1ad QinQ encapsulation header that 214 conveys the service VLAN identifier information (S-VLAN). 216 S-Tagged Service Interface: This the interface defined between the 217 customer (CE) and the I-BEB or IB-BEB components. Frames passed 218 through this interface contain an S-TAG field. 220 S-VLAN: The specific service VLAN identifier carried inside an S-TAG 222 U-PE: User-facing Provider Edge 224 VPLS: Virtual Private LAN Service 226 3. Applicability 228 [RFC4762] describes a two-tier hierarchical solution for VPLS for the 229 purpose of improved pseudowire (PW) scalability. This improvement is 230 achieved by reducing the number of PE devices connected in a full- 231 mesh topology through connecting CE devices via the lower-tier access 232 network, which in turn is connected to the top-tier core network. 233 [RFC4762] describes two types of H-VPLS network topologies - one with 234 an MPLS access network and another with an IEEE 802.1ad (QinQ) 235 Ethernet access network. In both types of H-VPLS, MAC address 236 learning and forwarding are based on customer MAC addresses (C-MACs), 237 which poses scalability issues as the number of VPLS instances (and 238 thus customer MAC addresses) increases. Furthermore, since a set of 239 PWs is maintained on a per customer service instance basis, the 240 number of PWs required at N-PE devices is proportional to the number 241 of customer service instances multiplied by the number of N-PE 242 devices in the full-mesh set. This can result in scalability issues 243 (in terms of PW manageability and troubleshooting) as the number of 244 customer service instances grows. 246 In addition to the above, H-VPLS with 802.1ad Ethernet access network 247 has another scalability issue in terms of the maximum number of 248 service instances that can be supported in the access network as 249 described in [RFC4762]. Since the number of provider VLANs (S-VLANs) 250 is limited to 4K and each S-VLAN represents a service instance in an 251 802.1ad network, then the maximum number of service instances that 252 can be supported is 4K. These issues are highlighted in [RFC6246]. 254 This document describes how IEEE 802.1ah (aka Provider Backbone 255 Bridges) can be integrated with H-VPLS to address these scalability 256 issues. In the case of H-VPLS with 802.1ah Ethernet access, the 257 solution results in better scalability in terms of both number of 258 service instances and number of C-MACs in the Ethernet access network 259 and the VPLS core network, as well as number of PWs in VPLS core 260 network. And in the case of H-VPLS with MPLS access, Provider 261 Backbone Bridging functionality can be used at the U-PE or N-PE which 262 results in reduction of customer MAC addresses and number of PWs in 263 the VPLS core network. 265 The interoperability scenarios depicted in this document fall into 266 the following two categories: 268 - Scenarios where Provider Backbone Bridging seamlessly works with 269 current VPLS implementations (e.g. section 4.2). 271 - Scenarios where VPLS PE implementations need to be upgraded in 272 order to work with Provider Backbone Bridging (e.g. sections 4.3, 273 5.1). 275 4. H-VPLS with Homogeneous PBBN Access 277 PBBN access offers MAC-address table scalability for H-VPLS PE nodes. 278 This is due to the MAC tunneling encapsulation scheme of PBB which 279 only exposes the provider's own MAC addresses to PE nodes (B- MACs of 280 Provider's PBB-capable devices in the access network), as opposed to 281 customers' MAC addresses in conventional H-VPLS with MPLS or 802.1ad 282 access. 284 PBBN access also offers service instance scalability when compared to 285 H-VPLS with 802.1Q/802.1ad access networks. This is due to the new 286 24-bit service identifier (I-SID) used in PBB encapsulation, which 287 allows up to 16M services per PBB access network, compared to 4K 288 services per 802.1Q/802.1ad access network. 290 Another important advantage of PBBN access is that it offers clear 291 separation between the service layer (represented by I-SID) and the 292 network layer (represented by B-VLAN). B-VLANs segregate a PBB access 293 network into different broadcast domains and possibly unique 294 spanning-tree topologies, with each domain being able to carry 295 multiple services (i.e. I-SIDs). In 802.1ad access networks, the 296 network and service layers are the same (represented by S-VLAN). 298 This separation allows the provider to manage and optimize the PBB 299 access network topology independent of the number of service 300 instances that are supported. 302 In this and the following sections we look into different flavors of 303 H-VPLS with PBBN access. This section discusses the case where H- 304 VPLS is deployed with homogenous PBBNs access. Section 5 describes 305 the case where at least one of the access networks is PBN access 306 (QinQ/802.1ad) while others are PBBNs. 308 At a macro scale, a network that employs H-VPLS with PBBN access can 309 be represented as shown in figure 1 below. 311 +--------------+ 312 | | 313 +---------+ | IP/MPLS | +---------+ 314 +----+ | | +----+ +----+ | | +----+ 315 | CE |--| | |VPLS| |VPLS| | |--| CE | 316 +----+ | PBBN |---| PE | | PE |--| PBBN | +----+ 317 +----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+ 318 | CE |--| | | Backbone | | |--| CE | 319 +----+ +---------+ +--------------+ +---------+ +----+ 321 Figure 1: H-VPLS with PBBN Access 323 In the context of PBBN and H-VPLS interoperability, "I-SID Domain" 324 and "B-VLAN Domain" can be defined as follows: 326 - "I-SID Domain" refers to a network administrative boundary under 327 which all the PBB BEBs and VPLS PE devices use the same I-SID space, 328 i.e. the I-SID assignment is carried out by the same administration. 329 This effectively means that a given service instance has the same I- 330 SID designation on all devices within an I-SID Domain. 332 - "B-VLAN Domain" refers to a network administrative boundary under 333 which all the PBB BEBs and VPLS PE devices employ consistent I-SID to 334 B-VLAN bundling - e.g., grouping of I-SIDs to B-VLANs are the same in 335 that domain. Although the two B-VLANs in two PBBNs that represent the 336 same group of I-SIDs do not need to use the same B-VID value, in 337 practice they often use the same value because once the I-SID 338 grouping is made identical in two PBBNs, it is very easy to make the 339 values of the corresponding B-VIDs also identical. 341 Consequently, three different kinds of "Service Domains" are defined 342 in the following manner: 344 - Tightly Coupled Service Domain - Different PBBNs access belonging 345 to the same I-SID Domain and B-VLAN Domain. However, the network 346 control protocols (e.g. xSTP) run independently in each PBBN access. 348 - Loosely Coupled Service Domain - Different PBBNs access belonging 349 to the same I-SID Domain. However, each PBBN access maintains its own 350 independent B-VLAN Domain. Again, the network control protocols (e.g. 351 xSTP) run independently in each PBBN access. 353 - Different Service Domain - In this case, each PBBN access maintains 354 its own independent I-SID Domain and B-VLAN Domain, with independent 355 network control protocols (e.g. xSTP) in each PBBN access. 357 In general, correct service connectivity spanning networks in a 358 Tightly Coupled Service Domain can be achieved via B-VID mapping 359 between the networks (often even without B-VID translation). However, 360 correct service connectivity spanning networks in a Loosely Coupled 361 Service Domain requires I-SID to B-VID re-mapping (i.e unbundling and 362 re-bundling of I-SIDs into B-VIDs). Furthermore, service connectivity 363 spanning networks in Different Service Domains requires both I-SID 364 translation and I-SID to B-VID re-mapping. 366 4.1 Service Interfaces and Interworking Options 368 Customer devices will interface with PBBN edge bridges using existing 369 Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad. At the 370 PBBN edge, customer MAC frames are encapsulated in a PBB header that 371 includes a service provider source and destination MAC addresses (B- 372 MACs) and are bridged up to the VPLS PE. The PBB encapsulated 373 customer MAC frame is then injected into the VPLS backbone network, 374 delivered to the remote VPLS PE node(s), and switched onto the remote 375 PBBN access. From there, the PBBN bridges the encapsulated frame to a 376 PBBN edge bridge where the PBB header is removed and the customer 377 frame is sent to the customer domain. 379 Interoperating between PBBN devices and VPLS PE nodes can leverage 380 the BEB functions already defined in [802.1ah]. When I-SID visibility 381 is required at the VPLS PE nodes, a new service interface based on I- 382 SID tag will need to be defined. 384 Moreover, by mapping a bridge domain (e.g. B-VLAN) to a VPLS 385 instance, and bundling multiple end-customer service instances, 386 represented by I-SIDs, over the same bridge domain, service providers 387 will be able to significantly reduce the number of full-mesh PWs 388 required in the core. In this case, I-SID visibility is not required 389 on the VPLS-PE and the I-SID will serve as the means of 390 multiplexing/de-multiplexing individual service instances in the PBBN 391 over a bundle (e.g. B-VLAN). 393 When I-SID visibility is expected across the service interface at the 394 VPLS PE, the VPLS PE can be considered to offer service-level 395 interworking between PBBN access and IP/MPLS core. Similarly, when 396 the PE is not expected to have visibility of I-SID at the service 397 interface, the VPLS PE can be considered to offer network-level 398 interworking between PBBN access and MPLS core. 400 A VPLS PE is always part of the IP/MPLS core, and may optionally 401 participate in the control protocols (e.g. xSTP) of the access 402 network. When connecting to a PBBN access, the VPLS PE needs to 403 support one of the following two types of service interfaces: 405 - Type I: B-Tagged Service Interface with B-VID as Service Delimiter 407 The PE connects to a Backbone Core Bridge (BCB) in the PBBN access. 408 The handoff between the BCB and the PE is B-Tagged PBB encapsulated 409 frames. The PE is transparent to PBB encapsulations and treats these 410 frames as 802.1ad frames since the B-VID EtherType is the same as the 411 S-VID EtherType. The PE does not need to support PBB functionality. 412 This corresponds to conventional VPLS PE's tagged service interface. 413 When using Type I service interface, the PE needs to support either 414 raw-mode or tagged-mode Ethernet PW. Type I Service Interface is 415 described in detail in Section 4.2. 417 - Type II: I-Tagged Service Interface with I-SID as Service 418 Delimiter 420 The PE connects to a B-BEB (Backbone Edge Bridge with B-Component) in 421 the PBBN access. The PE itself also supports the B-BEB functionality 422 of [802.1ah]. The handoff between the B-BEB in the PBBN access and 423 the PE is an I-Tagged PBB encapsulated frame. With Type II service 424 interface, the PE supports the existing raw-mode and tagged-mode PW 425 types. Type II Service Interface is described in detail in Section 426 4.3. 428 4.2 H-VPLS with PBBN Access: Type I Service Interface 430 This is a B-Tagged service interface with B-VID as service delimiter 431 on the VPLS-PE. It does not require any new functionality on the 432 VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS 433 core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on 434 right side of Figure 2) by participating in network control protocols 435 (e.g. xSTP) of the PBBN access. 437 PBBN Access IP/MPLS Core PBBN Access 438 +--------------+ 439 +---------+ | | +---------------+ 440 | | +----+ | | | 441 | +---+ |VPLS| +-+ | | +---+ | 442 | |BCB|---| PE |---|P| | | |BCB| | 443 | +---+ /+----+ /+-+ | | /+---+ | 444 |+---+ | / +----+ / +----+ / +---+| 445 +--+ ||IB-| +---+/ |VPLS|/ +-+ |VPLS|/ +---+ |IB-|| +--+ 446 |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE| 447 +--+ |+---+ +---+ ^ +----+ +-+ +----+ ^ +---+ +---+| +--+ 448 | | | | | | | | 449 +---------+ | | | +--|------------+ 450 | +--------------+ | 451 | | 452 Type I Type I 454 Figure 2: H-VPLS with PBBN Access & Type I Service Interface 456 Type I service interface is applicable to networks with Tightly 457 Coupled Service Domains, where both I-SID Domains and B-VLAN Domains 458 are the same across all PBBN access networks. 460 The BCB and the VPLS PE will exchange PBB encapsulated frames that 461 include source and destination B-MACs, a B-VID and I-SID. The service 462 delimiter, from the perspective of the VPLS PE, is the B-VID; in 463 fact, this interface operates exactly as a current 802.1Q/ad 464 interface into a VPLS PE does today. With Type I service interface, 465 the VPLS PE can be considered as providing network-level interworking 466 between PBBN and MPLS domains, since VPLS PE does not have visibility 467 of I-SIDs. 469 The main advantage of this service interface, when compared to other 470 types, is that it allows the service provider to save on the number 471 of full-mesh PWs required in the core. This is primarily because 472 multiple service instances (I-SIDs) are bundled over a single full- 473 mesh corresponding to a bridge domain (e.g. B-VID), instead of 474 requiring a dedicated full-mesh per service instance. Another 475 advantage is the MAC address scalability in the core since the core 476 is not exposed to C-MACs. 478 The disadvantage of this interface is the comparably excessive 479 replication required in the core: since a group of service instances 480 share the same full-mesh of PWs, an unknown unicast, multicast or 481 broadcast on a single service instance will result in a flood over 482 the core. This, however, can be mitigated via the use of per I-SID 483 flood containment (B-MAC multicast pruning). 485 Three different modes of operation are supported by Type I Service 486 Interface: 488 - Port Mode: All traffic over an interface in this mode is mapped to 489 a single VPLS instance. Existing PW signaling and Ethernet raw mode 490 (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. 492 - VLAN Mode: all traffic associated with a particular VLAN identified 493 by the B-VID is mapped to a single VPLS instance. Existing PW 494 signaling and Ethernet raw mode (0x0005) PW type, defined in 495 [RFC4447] [RFC4448], are supported. 497 - VLAN Bundling Mode: all traffic associated with a group or range of 498 VLANs or B-VIDs is mapped to a single VPLS instance. Existing PW 499 signaling and Ethernet raw mode (0x0005) PW type, defined in 500 [RFC4447] [RFC4448], are supported. 502 For the VLAN mode, it is also possible to use Ethernet tagged mode 503 (0x0004) PW, as defined in [RFC4447] [RFC4448], for interoperability 504 with equipment that does not support raw mode. The use of raw mode is 505 recommended to be the default though. 507 4.3 H-VPLS with PBBN Access: Type II Service Interface 509 This is an I-Tagged service interface with I-SID as service delimiter 510 on the VPLS-PE. It requires the VPLS-PE to include B-Component of PBB 511 BEB for I-SID processing in addition to the capability to map I-SID 512 Bundle to VPLS instance. As shown in Figure 3, the PE is always part 513 of the IP/MPLS core and connects to one or more B-BEB in the PBBN 514 access. 516 PBBN Access IP/MPLS Core PBBN Access 517 +--------------+ 518 +---------+ | | +---------+ 519 | | | | | | 520 | +---+ +-----+ | | +---+ | 521 | |B- | |PE w/| +-+ | | |BCB| | 522 | |BEB|--|B-BEB|-|P| | | +---+ | 523 | +---+ /+-----+ +-+ | | / | | 524 |+---+ +---+/ +-----+/ +-----+ +---+ +---+| 525 +--+ ||IB-| |B- | |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 526 |CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 527 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 528 | | | | | | | | 529 +---------+ | | | | +---------+ 530 | +-------------+ | 531 | | 532 Type II Type II 534 Figure 3: H-VPLS with PBBN Access & Type II Service Interface 536 Type II service interface is applicable to Loosely Coupled Service 537 Domains and Different Service Domains. B-VLAN Domains can be 538 independent and the B-VID is always locally significant in each PBBN 539 access and does not need to be transported over the IP/MPLS core. 540 Given the above, it should be apparent that Type II service interface 541 is applicable to Tightly Coupled Service Domains as well. 543 By definition the B-BEB connecting to the VPLS PE will remove any B- 544 VLAN tags for frames exiting the PBBN access. The B-BEB and VPLS PE 545 will exchange PBB encapsulated frames that include source and 546 destination B-MACs, and I-SID. The service delimiter, from the 547 perspective of the VPLS PE, is the I-SID. Since the PE has visibility 548 of I-SIDs, the PE provides service-level interworking between PBBN 549 access and IP/MPLS core. 551 Type II Service Interface may operate in I-SID Bundling Mode: all 552 traffic associated with a group or range of I-SIDs is mapped to a 553 single VPLS instance. The PE maintains a mapping of I-SIDs to a PE 554 local bridge domain (e.g. B-VID). The VPLS instance is then 555 associated with this bridge domain. With Loosely Coupled Service 556 Domains, no I-SID translation needs to be performed. Type II Service 557 Interface also supports Different Service Domains in this mode, since 558 the B-BEB link in the PE connecting to the local PBBN can perform the 559 translation of PBBN-specific I-SID to a local I-SID within the 560 IP/MPLS core, which may then be translated to the other PBBN specific 561 I-SID on the egress PE. Such translation can also occur in the B-BEB 562 of PBBN access. Existing PW signaling and Ethernet raw mode (0x0005), 563 defined in [RFC4447] [RFC4448], is supported. It is also possible to 564 use tagged mode (0x0004) PW for purpose of interoperability with 565 equipment that does not support raw mode. 567 Type II service interface provides operators with the flexibility to 568 trade-off PW state vs. multicast flooding containment, since a full- 569 mesh of PWs can be set up: 571 a. per I-SID, 572 b. per group of I-SIDs or 573 c. for all I-SIDs. 575 For (a) and (b), the advantage that the Type II service interface has 576 compared to Type I is that it can reduce replication in the core 577 without the need for a per I-SID flood containment (B-MAC multicast 578 pruning) mechanism. This is mainly due to the increased segregation 579 of service instances over disjoint full-meshes of PWs. For (c), both 580 Type II and Type I service interfaces are at par with regards to 581 flood containment. 583 For (a) and (b), the disadvantage of this service interface, compared 584 to Type I, is that it may require a larger number of full-mesh PWs in 585 the core. For (c), both Type II and Type I service interfaces are at 586 par with regards to PW state. However, for all three scenarios, the 587 number of full-mesh PWs can still be less than those required by H- 588 VPLS without PBBN access, since an I-SID can multiplex many S-VLANs. 590 It is expected that this interface type will be used for customers 591 with significant multicast traffic (but without multicast pruning 592 capability in the VPLS PE) so that a separate VPLS instance is set up 593 per group of customers with similar geographic locality (per I-SID 594 group). 596 Note: Port mode is not called out in Type II Service Interface since 597 it requires the mapping of I-SIDs to be identical on different I- 598 Tagged interfaces across VPLS network. If this is indeed the case, 599 Port mode defined in Type I Service Interface (Section 4.2) can be 600 used. 602 5. H-VPLS with Mixed PBBN Access and PBN Access 604 It is foreseeable that service providers will want to interoperate 605 their existing PBN (QinQ) access networks with PBBN access networks 606 over H-VPLS. Figure 4 below shows the high-level network topology. 608 +--------------+ 609 | | 610 +---------+ | IP/MPLS | +---------+ 611 +----+ | | +----+ +----+ | | +----+ 612 | CE |--| PBN | |VPLS| |VPLS| | |--| CE | 613 +----+ | (QinQ) |---| PE1| | PE2|--| PBBN | +----+ 614 +----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+ 615 | CE |--| | | Backbone | | |--| CE | 616 +----+ +---------+ +--------------+ +---------+ +----+ 618 Figure 4: H-VPLS with Mixed PBN and PBBN Access Networks 620 Referring to Figure 4 above, two possibilities come into play 621 depending on whether the interworking is carried out at PE1 or PE2. 622 These are described in the following sub-Sections. 624 5.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE 626 As shown in Figure 5, the operation of VPLS PE2 (connecting to the 627 PBBN access on the right) is no different from what was discussed in 628 Section 4. Type II service interface, as discussed in the above 629 section, is applicable. It is the behavior of VPLS PE1 (connecting to 630 the PBN access on the left) that is the focus of this section. 632 PBN Access IP/MPLS Core PBBN Access 633 (802.1ad) +--------------+ (802.1ah) 634 | | +---------+ 635 +---------+ | | | | 636 | | +-----+ | | +---+ | 637 | +---+ |PE w/| +-+ | | |BCB| | 638 | |PCB|--|IBBEB|-|P| | | +---+ | 639 | +---+ /+-----+ +-+ | | / | | 640 | | / +-----+/ +-----+ +---+ +---+| 641 +--+ |+---+ +---+ |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 642 |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 643 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 644 | | | |PE1 PE2| | | | 645 +---------+ | | | | +---------+ 646 | +-------------+ | 647 | | 648 S-Tagged Type II (I-Tagged) 650 Figure 5: H-VPLS with Mixed PBN and PBBN Access: Modified PBN PE 652 Some assumptions made for this topology include: 654 - CE is directly connected to PBBN via S-Tagged or port-based 655 interface 657 - I-SID in PBBN access represents the same customer as S-VID in PBN 658 access 660 - At S-Tagged Service Interface of PE with IB-BEB functionality (e.g. 661 PE1 in Figure 5), the only viable service is 1:1 mapping of S-VID to 662 I-SID. However, towards the core network side, the same PE can 663 support I-SID bundling into a VPLS instance. 665 - PE1 participates in the local I-SID domain of the IP/MPLS Core so 666 the model accommodates for the rest of the PBB network any of the 667 three domain types described in section 4 - Tightly, Loosely Coupled 668 and Different Service Domains. 670 - For ease of provisioning in these disparate access networks, it is 671 recommended to use the same I-SID Domain among the PBBN access 672 networks and the PEs with IB-BEB functionality (those connecting to 673 PBN). 675 This topology operates in I-SID Bundling Mode: at a PE connecting to 676 PBN access, each S-VID is mapped to an I-SID and subsequently a group 677 of I-SIDs is mapped to a VPLS instance. Similarly, at a PE connecting 678 to PBBN access, each group of I-SIDs is mapped to a VPLS instance. 679 Similar to Type II interface, no I-SID translation is performed for 680 I-SID bundling case. Existing PW signaling and Ethernet raw mode 681 (0x0005) PW type, defined in [RFC4447] [RFC4448], are supported. It 682 is possible to use tagged mode (0x0004) PW for backward compatibility 683 as well. 685 5.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE 687 As shown in Figure 6, the operation of VPLS PE1 (connecting to the 688 PBN access on the left) is no different from existing VPLS PEs. It is 689 the behavior of VPLS PE2 (connecting to the PBBN access on the right) 690 that is the focus of this section. 692 PBN Access IP/MPLS Core PBBN Access 693 (802.1ad) +--------------+ (802.1ah) 694 | | +---------+ 695 +---------+ | | | | 696 | | +-----+ | | +---+ | 697 | +---+ | PE | +-+ | | |BCB| | 698 | |PCB|--| |-|P| | | +---+ | 699 | +---+ /+-----+ +-+ | | / | | 700 | | / +-----+/ +-----+ +---+ +---+| 701 +--+ |+---+ +---+ | PE | +-+ |PE w/| |B- | |IB-|| +--+ 702 |CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BEB| |BEB|--|CE| 703 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 704 | | | |PE1 PE2| | | | 705 +---------+ | | | | +---------+ 706 | +-------------+ | 707 | | 708 S-Tagged Type II (I-Tagged) 710 Figure 6: H-VPLS with Mixed PBN and PBBN Access: Regular PBN PE 712 Some assumptions made for this topology include: 714 - CE is directly connected to the PBBN access via S-Tagged or port- 715 based Interface 717 - I-SID in the PBBN access represents the same customer as S-VID in 718 the PBN access 720 - There is 1:1 mapping between the I-SID and the VPLS instance 722 - At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in 723 Figure 6), the PE only provides 1:1 mapping of S-VID to VPLS 724 instance. S-VID bundling is not a viable option since it does not 725 correspond to anything in the PBBN access. 727 - The PE connecting to the PBBN access (e.g. PE2 in Figure 6), 728 supports IB-BEB functionality and the I-Component is connected to the 729 VPLS Forwarder (i.e. the I-Component faces the IP/MPLS core whereas 730 the B-Component faces the PBBN access network). One or more I-SIDs 731 can be grouped into a B-VID in the PBBN access. 733 - Since C-VID grouping in different PBBN access networks must be 734 consistent, it is assumed that same I-SID Domain is used across 735 these PBBN access networks. 737 Unlike the previous case, I-SID bundling mode is not supported in 738 this case. This is primarily because the VPLS core operates in the 739 same manner as today. The PE with IB-BEB functionality connecting to 740 PBBN access performs the mapping of each VPLS instance to an I-SID 741 and one or more of these I-SIDs may be mapped onto a B-VID within the 742 PBBN access network. 744 6. H-VPLS with MPLS Access 746 In this section, the case of H-VPLS with MPLS access network is 747 discussed. The integration of PBB functionality into VPLS-PE for such 748 access networks is described to improve the scalability of the 749 network in terms of the number of MAC addresses and service instances 750 that are supported. 752 For this topology, it is possible to embed PBB functionality in 753 either the U-PE or the N-PE. Both of these cases are described in the 754 following sub-sections. 756 6.1 H-VPLS with MPLS Access: PBB U-PE 758 As stated earlier, the objective for incorporating PBB function at 759 the U-PE is to improve the scalability of H-VPLS networks in terms of 760 the number of MAC addresses and service instances that are 761 supported. 763 In current H-VPLS, the N-PE must learn customer MAC addresses (C- 764 MACs) of all VPLS instances that it participates in. This can easily 765 add-up to hundreds of thousands or even millions of C-MACs at the N- 766 PE. When the U-PE performs PBB encapsulation, the N-PE only needs to 767 learn the MAC addresses of the U-PEs, which is a significant 768 reduction. Furthermore, when PBB encapsulation is used, many I-SIDs 769 are multiplexed within a single bridge domain (e.g., B-VLAN). If the 770 VPLS instance is set up per B-VLAN, then one can also achieve a 771 significant reduction in the number of full-mesh PWs. It should be 772 noted that this reduction in full-mesh PWs comes at the cost of 773 potentially increased replication over the full-mesh of PWs: Customer 774 multicast and/or broadcast frames are effectively broadcasted within 775 the B-VLAN. This may result in additional frame replication because 776 the full-mesh PWs corresponding to a B-VLAN is most likely bigger 777 than the full-mesh PWs corresponding to a single I-SID. However, per 778 I-SID flood containment (B-MAC multicast pruning) can be used to 779 remedy this drawback and have multicast traffic replicated 780 efficiently for each customer (i.e. for each I-SID). 782 Figure 7 below illustrates the scenario for H-VPLS with MPLS access. 783 As it can be seen, customer networks or hosts (CE) connect into the 784 U-PE nodes using standard Ethernet interfaces [802.1D], [802.1Q], or 785 [802.1ad]. The U-PE is connected upstream to one or more VPLS N-PE 786 nodes by MPLS PWs (per VPLS instance). These, in turn, are connected 787 via a full-mesh of PWs (per VPLS instance) traversing the IP/MPLS 788 core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB) 789 functions where it can encapsulate/de-encapsulate customer MAC frames 790 in provider B-MACs and perform I-SID translation if needed. 792 PBB PBB 793 BEB +----------+ BEB 794 | | | | 795 | +-----------+ | IP | +-----------+ | 796 | | MPLS | | MPLS | | MPLS | | 797 V | Access +----+ | Core | +----+ Access | V 798 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 799 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 800 +--+ +----+ +----+ | | +----+ +----+ +--+ 801 | | | | | | 802 +-----------+ +----------+ +-----------+ 804 Figure 7: H-VPLS with MPLS Access Network and PBB U-PE 806 The U-PE still provides the same type of services toward its 807 customers as before and they are: 809 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 810 - VLAN mode (either 802.1Q or 802.1ad) 811 - VLAN-bundling mode (either 802.1Q or 802.1ad) 813 By incorporating a PBB function, the U-PE maps each of these services 814 (for a given customer) onto a single I-SID based on the configuration 815 at the U-PE. Many I-SIDs are multiplexed within a single bridge 816 domain (e.g. B-VLAN). The U-PE can then map a bridge domain onto a 817 VPLS instance and the encapsulated frames are sent over the PW 818 associated with that VPLS instance. Furthermore the entire Ethernet 819 bridging operation over the VPLS network is performed as defined in 820 [RFC4762]. In other words, MAC forwarding is based on the B-MAC 821 address space and service delimiter is based on VLAN ID, which is B- 822 VID in this case. There is no need to inspect or deal with I-SID 823 values in the VPLS N-PEs. 825 In the case of PBB U-PEs in a single I-SID domain, I-SID assignment 826 is performed globally across all MPLS access networks and therefore 827 there is no need for I-SID translation. This scenario support I-SID 828 bundling mode and it is assumed that the mapping of the I-SIDs to the 829 bridge domain (e.g., B-VLAN) is consistent across all the 830 participating PE devices. In the case of the I-SID bundling mode, a 831 bridge domain (e.g., B-VLAN) is mapped to a VPLS instance and 832 existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type 833 is used as defined in [RFC4447] [RFC4448]. 835 I-SID mode can be considered as a degenerate case of I-SID bundling 836 where a single bridge domain is used per I-SID. However, that results 837 in an increased number of bridge domains and PWs in the PEs. PBB 838 flood containment (B-MAC multicast pruning) per I-SID can be used in 839 conjunction with I-SID bundling mode to limit the scope of flooding 840 per I-SID thus removing the need for I-SID mode. 842 6.2 H-VPLS with MPLS Access: PBB N-PE 844 In this case, the PBB function is incorporated at the N-PE to improve 845 the scalability of H-VPLS networks in terms of the numbers of MAC 846 addresses and service instances that are supported. 848 Customer networks or hosts (CE) connect into the U-PE nodes using 849 standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The U- 850 PE is connected upstream to one or more VPLS N-PE nodes by MPLS PWs 851 (per customer). These, in turn, are connected via a full-mesh of PWs 852 (per customer or group of customers) traversing the IP/MPLS core. 854 The U-PE still provides the same type of services toward its 855 customers as before and they are: 857 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 858 - VLAN mode (either 802.1Q or 802.1ad) 859 - VLAN-bundling mode (either 802.1Q or 802.1ad) 861 The spoke PW from the U-PE to the N-PE is not service multiplexed 862 because there is no PBB functionality on the U-PE - i.e. one service 863 per PW. 865 PBB PBB 866 BEB +----------+ BEB 867 | | | | 868 +-----------+ | | IP | | +-----------+ 869 | MPLS | V | MPLS | V | MPLS | 870 | Access +----+ | Core | +----+ Access | 871 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 872 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 873 +--+ +----+ +----+ | | +----+ +----+ +--+ 874 | | | | | | 875 +-----------+ +----------+ +-----------+ 877 Figure 8: H-VPLS with MPLS Access Network and PBB N-PE 879 By incorporating a PBB function, the N-PE maps each of these services 880 (for a given customer) onto a single I-SID based on the configuration 881 at the N-PE. Many I-SIDs can be multiplexed within a single bridge 882 domain (e.g. B-VLAN). The N-PE can, then, either map a single I-SID 883 into a VPLS instance or it can map a bridge domain (e.g. B-VLAN) onto 884 a VPLS instance, according to its configuration. Next, the 885 encapsulated frames are sent over the set of PWs associated with that 886 VPLS instance. 888 In the case of PBB N-PEs in a single I-SID domain, I-SID assignment 889 is performed globally across all MPLS access networks and therefore 890 there is no need for I-SID translation. This scenario supports I-SID 891 bundling mode and it is assumed that the mapping of the I-SIDs to the 892 bridge domain (e.g., B-VLAN) is consistent across all the 893 participating PE devices. In the case of the I-SID bundling mode, a 894 bridge domain (e.g., B-VLAN) is mapped to a VPLS instance and 895 existing Ethernet raw mode (0x0005) or tagged mode (0x0004) PW type 896 as defined in [RFC4447] [RFC4448], can be used. 898 I-SID mode can be considered as a degenerate case of I-SID bundling 899 where a single bridge domain is used per I-SID. However, that results 900 in an increased number of bridge domains and PWs in the PE. PBB flood 901 containment (B-MAC multicast pruning) per I-SID can be used in 902 conjunction with I-SID bundling mode to limit the scope of flooding 903 per I-SID thus removing the need for I-SID mode. 905 7. H-VPLS with MPLS Access: PBB Migration Scenarios 907 Operators and service providers that have deployed H-VPLS with either 908 MPLS or Ethernet are unlikely to migrate to PBB technology overnight 909 because of obvious cost implications. Thus, it is imperative to 910 outline migration strategies that will allow operators to protect 911 investments in their installed base while still taking advantage of 912 the scalability benefits of PBB technology. 914 In the following sub-sections, we explore three different migration 915 scenarios which allow a mix of existing H-VPLS access networks to co- 916 exist with newer PBB-based access networks. The scenarios differ in 917 whether the Ethernet service frames passing over the VPLS core are 918 PBB-encapsulated or not. The first scenario in section 7.1 involves 919 passing only non PBB-encapsulated frames over the core. The second 920 scenario in section 7.2 stipulates passing only PBB-encapsulated 921 frames over the core. Whereas, the final scenario in section 7.3 922 depicts a core that supports a mix of PBB-encapsulated and non PBB- 923 encapsulated frames. The advantages and disadvantages of each 924 scenario will be discussed in its respective section. 926 7.1 802.1ad Service Frames over VPLS Core 928 In this scenario, existing access networks are left unchanged. All N- 929 PEs would forward frames based on C-MACs. In other words, Ethernet 930 frames which are traversing the VPLS core (within PWs) would use the 931 802.1ad frame format, as in current VPLS. Hence, the N-PEs in 932 existing access networks do not require any modification. For new 933 MPLS access networks that have PBB functions on the U-PE, the 934 corresponding N-PE must incorporate built-in IB-BEB functions in 935 order to terminate the PBB encapsulation before the frames enter the 936 core. A key point here is that while both the U-PE and N-PE nodes 937 implement PBB IB-BEB functionality, the former has the I-Component 938 facing the customer (CE) and the B-Component facing the core; whereas 939 the latter has the I-Component facing the core and the B-Component 940 facing the customer (i.e. access network). 942 PBB PBB 943 +----------+ IB-BEB IB-BEB 944 | | | | 945 +-----------+ | IP | | +-----------+ | 946 | MPLS | | MPLS | V | MPLS | | 947 | Access +----+ | Core | +----+ Access | V 948 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 949 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 950 +--+ +----+ +----+ | | +----+ +----+ +--+ 951 | (Existing)| | | | (New) | 952 +-----------+ +----------+ +-----------+ 954 Figure 9: Migration with 802.1ad Service Frames over VPLS Core 956 The main advantage of this approach is that it requires no change to 957 existing access networks or existing VPLS N-PEs. The main 958 disadvantage is that these N-PEs will not leverage the advantages of 959 PBB in terms of MAC address and PW scalability. It is worth noting 960 that this migration scenario is an optimal option for an H-VPLS 961 deployment with a single PBB-capable access network. When multiple 962 PBB-capable access networks are required, then the scenario in 963 Section 7.3 is preferred, as it provides a more scalable and optimal 964 interconnect amongst the PBB-capable networks. 966 7.2 PBB Service Frames over VPLS Core 968 This scenario requires that the VPLS N-PE connecting to existing MPLS 969 access networks be upgraded to incorporate IB-BEB functions. All 970 Ethernet service frames passing over the VPLS core would be PBB- 971 encapsulated. The PBB over MPLS access networks would require no 972 special requirements beyond what is captured in section 6 of this 973 document. In this case, both the U-PE and N-PE which implement IB-BEB 974 functionality have the I-Component facing the customer and the B- 975 Component facing the core. 977 PBB PBB 978 IB-BEB +----------+ IB-BEB 979 | | | | 980 +-----------+ | | IP | +-----------+ | 981 | MPLS | V | MPLS | | MPLS | | 982 | Access +----+ | Core | +----+ Access | V 983 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 984 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 985 +--+ +----+ +----+ | | +----+ +----+ +--+ 986 | (Existing)| | | | (New) | 987 +-----------+ +----------+ +-----------+ 989 Figure 10: Migration with PBB Service Frames over VPLS Core 991 The main advantage of this approach is that it allows better 992 scalability of the VPLS N-PEs in terms of MAC address and pseudowire 993 counts. The disadvantage is that it requires upgrading the VPLS N- 994 PEs of all existing MPLS access networks. 996 7.3 Mixed 802.1ad and PBB over VPLS Core 998 In this scenario, existing access networks are left unchanged, and 999 exchange Ethernet frames with 802.1ad format over the PWs in the 1000 core. The newly added access networks, which incorporate PBB 1001 functionality exchange Ethernet frames that are PBB-encapsulated 1002 amongst each other over core PWs. For service connectivity between 1003 existing access network (non PBB capable) and new access network (PBB 1004 based), the VPLS N-PE of the latter network employs IB-BEB 1005 functionality to de-capsulate the PBB header from frames outbound to 1006 the core, and encapsulate the PBB header for frames inbound from the 1007 core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet 1008 service frames are exchanged over the VPLS core. 1010 This mode of operation requires new functionality on the VPLS N-PE of 1011 the PBB-capable access network, so that the PE can send frames in 1012 802.1ad format or PBB format, on a per PW basis, depending on the 1013 capability of the destination access network. Effectively, the PE 1014 would have to incorporate B-BEB as well as IB-BEB functions. 1016 A given PE needs to be aware of the capability of its remote peer in 1017 order to determine whether it connects to the right PW Forwarder. 1018 This can be achieved either via static configuration, or by extending 1019 the VPLS control plane (BGP-based auto-discovery and LDP Signaling) 1020 discussed in [RFC6074]. The latter approach and the details of the 1021 extensions required are out of scope for this document. 1023 PBB 1024 B-BEB PBB 1025 +----------+ IB-BEB IB-BEB 1026 | | | | 1027 +-----------+ | IP | | +-----------+ | 1028 | MPLS | | MPLS | V | MPLS | | 1029 | Access +----+ | Core | +----+ Access | V 1030 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 1031 |CE|--|U-PE| |N-PE| | | |N-PE| |U-PE|--|CE| 1032 +--+ +----+ +----+ | | +----+ +----+ +--+ 1033 | (Existing)| | | | (New) | 1034 +-----------+ +----------+ +-----------+ 1036 Figure 11: Migration with Mixed 802.1ad &PBB Service Frames 1037 over VPLS Core 1039 The U-PE and N-PE of the PBB-capable access network both employ BEB 1040 functionality: The U-PE implements IB-BEB function where the I- 1041 Component faces the customer (CE) and the B-Component faces the core. 1042 The N-PE, on the other hand, implements IB-BEB functionality with the 1043 I-Component facing the core and the B-Component facing the customer 1044 (access network). In addition, the N-PE implements stand-alone B-BEB 1045 functionality. 1047 This scenario combines the advantages of both previous scenarios 1048 without any of their shortcomings, namely: it does not require any 1049 changes to existing access networks and it allows the N-PE to 1050 leverage the scalability benefits of 802.1ah for PBBN to PBBN 1051 connectivity. The disadvantage of this option is that it requires new 1052 functionality on the N-PE of the PBBN access. A second disadvantage 1053 is that this option requires two P2MP LSPs to be setup at the ingress 1054 N-PE - one for the N-PEs that support PBB encapsulation and another 1055 one for the N-PEs that don't support PBB encapsulation. 1057 8. Acknowledgments 1059 The authors would like to thank Chris Metz and Dinesh Mohan for their 1060 valuable feedback and contributions. 1062 9. IANA Considerations 1064 This document has no actions for IANA. 1066 10. Security Considerations 1068 This document does not introduce any additional security aspects 1069 beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security 1070 considerations are already covered in [RFC4111] and [RFC4762]. 1072 11. References 1074 11.1 Normative References 1076 [802.1ad] "Virtual Bridged Local Area Networks, Amendment 4: Provider 1077 Bridges", IEEE Std. 802.1ad-2005, May 2006 1079 [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider 1080 Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008 1082 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 1083 April 2006 1085 [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS 1086 Networks", RFC4448, April 2006 1088 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label 1089 Distribution Protocol (LDP) Signaling", RFC4762, January 2007 1091 [RFC6074] E. Rosen, et al., "Provisioning, Autodiscovery and 1092 Signaling in L2VPNs", RFC6074, January 2011 1094 11.2 Informative References 1096 [802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q- 1097 2005 1099 [802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D- 1100 2003 1102 [RFC6246] A. Sajassi, et al., "VPLS Interoperability with CE 1103 Bridges", RFC6246, June 2011 1105 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1106 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1108 Authors' Addresses 1110 Ali Sajassi 1111 Cisco 1112 Email: sajassi@cisco.com 1114 Samer Salam 1115 Cisco 1116 Email: ssalam@cisco.com 1118 Nabil Bitar 1119 Verizon Communications 1120 Email : nabil.n.bitar@verizon.com 1122 Florin Balus 1123 Nuage Networks 1124 Email: florin.balus@nuagenetworks.net