idnits 2.17.1 draft-sajassi-l2vpn-vpls-pbb-interop-04.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.ii 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 19) being 60 lines 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: ' 9. 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: ' 8. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2009) is 5507 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Unused Reference: 'VPLS-Bridge' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'VPLS-MCAST' is defined on line 1076, 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 (~~), 7 warnings (==), 3 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: September 2009 March 23, 2009 18 VPLS Interoperability with Provider Backbone Bridges 19 draft-sajassi-l2vpn-vpls-pbb-interop-04.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 September 23, 2009. 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 (PBB) 59 functionality in VPLS access. PBB has been standardized as IEEE 60 802.1ah-2008, which is an amendment to 802.1Q to improve the 61 scalability of MAC addresses and service instances in Provider 62 Ethernet networks. This document describes different 63 interoperability scenarios where IEEE 802.1ah functionality is used 64 in H-VPLS with Ethernet or MPLS access network to attain better 65 scalability in terms of number of customer MAC addresses and number 66 of service instances. The document also describes the scenarios and 67 the mechanisms for incorporating PBB functionality within H-VPLS 68 with existing IEEE 802.1ad (aka QinQ) Ethernet access and 69 interoperability among them. Furthermore, the document discusses the 70 migration mechanisms and scenarios by which PBB functionality can be 71 incorporated into H-VPLS with existing MPLS access. 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119. 79 Table of Contents 81 Conventions used in this document..................................2 82 1. Introduction....................................................3 83 2. Terminology.....................................................4 84 3. H-VPLS with Homogeneous PBBN Access.............................6 85 3.1 Service Interfaces and Interworking Options....................7 86 3.2 H-VPLS with PBBN Access: Type I Service Interface..............9 87 3.3 H-VPLS with PBBN Access: Type II Service Interface............10 88 4. H-VPLS with Mixed PBBN Access and PBN Access...................12 89 4.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE..........13 90 4.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE...........14 91 5. H-VPLS with MPLS Access..................................15 92 5.1 H-VPLS with MPLS Access: PBB U-PE.............................15 93 5.1.1 PBB U-PEs in Single I-SID Domain............................16 94 5.2 H-VPLS with MPLS Access: PBB N-PE.............................17 95 5.2.1 PBB N-PEs in Single I-SID Domain............................18 96 6. H-VPLS with MPLS Access: PBB Migration Scenarios.........18 97 6.1. 802.1ad Service Frames over VPLS Core........................19 98 6.2. PBB Service Frames over VPLS Core............................19 99 6.3. Mixed 802.1ad and PBB over VPLS Core.........................20 100 7. Acknowledgments................................................21 101 8. IANA Considerations............................................21 102 9. Security Considerations........................................21 103 10. References....................................................22 104 10.1 Normative References.........................................22 105 10.2 Informative References.......................................22 106 Authors' Addresses................................................22 108 1. Introduction 110 The scalability of H-VPLS with Ethernet access network can be 111 improved by incorporating Provider Backbone Bridge (PBB) 112 functionality in the VPLS access. PBB has been standardized as IEEE 113 802.1ah-2008, which is an amendment to 802.1Q to improve the 114 scalability of MAC addresses and service instances in Provider 115 Ethernet networks. This document describes interoperability 116 scenarios where IEEE 802.1ah functionality is used in the H-VPLS 117 with Ethernet or MPLS access network to attain better scalability in 118 terms of number of customer MAC addresses and number of services. 119 This document also describes the scenarios and the mechanisms for 120 incorporating PBB functionality within H-VPLS with existing IEEE 121 802.1ad (aka QinQ) Ethernet access and interoperability among them. 122 Furthermore, this document discusses the migration mechanisms and 123 scenarios by which PBB functionality can be incorporated into H-VPLS 124 with existing MPLS access. 126 [RFC4762] describes a two-tier hierarchical solution for VPLS for 127 the purpose of improved pseudowire (PW) scalability. This 128 improvement is achieved by reducing the number of PE devices 129 connected in a full-mesh topology through connecting CE devices via 130 the lower-tier access network, which in turn is connected to the 131 top-tier core network. [RFC4762] describes two types of H-VPLS 132 network topologies - one with MPLS access network and another with 133 IEEE 802.1ad (QinQ) Ethernet access network. In both types of H- 134 VPLS, MAC address learning and forwarding are done based on customer 135 MAC addresses (C-MACs), which poses scalability issues as the number 136 of VPLS instances (and thus customer MAC addresses) increases. 137 Furthermore, since a set of PWs is maintained on a per customer 138 service instance basis, the number of PWs required at N-PE devices 139 is proportional to the number of customer service instances 140 multiplied by the number of N-PE devices in the full-mesh set. This 141 can result in scalability issues (in terms of PW manageability and 142 troubleshooting) as the number of customer service instances grows. 144 In addition to the above, H-VPLS with 802.1ad Ethernet access 145 network has another scalability issue in terms of the maximum number 146 of service instances that can be supported in the access network as 147 described in [RFC4762]. Since the number of provider VLANs (S-VLANs) 148 is limited to 4K and each S-VLAN represents a service instance in an 149 802.1ad network, then the maximum number of service instances that 150 can be supported is 4K. These issues are highlighted in [VPLS- 151 Bridge]. 153 This document describes how IEEE 802.1ah (aka Provider Backbone 154 Bridges) can be integrated with H-VPLS to address these scalability 155 issues. In case of H-VPLS with 802.1ah (PBB) Ethernet access, the 156 solution results in better scalability in terms of both number of 157 service instances and number of C-MACs in the Ethernet access 158 network and the VPLS core network, as well as number of PWs in VPLS 159 core network. And in case of H-VPLS with MPLS access, PBB 160 functionality can be used at the U-PE or N-PE which results in 161 reduction of customer MAC addresses and number of PWs in the VPLS 162 core network. 164 This document also covers the interoperability scenarios for 165 deploying H-VPLS with PBB Ethernet access when other types of access 166 networks are deployed, including existing 802.1ad Ethernet access in 167 either single or multiple service domains. Furthermore, the document 168 explores the scenarios by which an operator can gradually migrate an 169 existing H-VPLS network to PBB over VPLS. 171 Section 2 gives a quick terminology reference. Section 3 describes 172 H-VPLS with homogeneous PBB Access Network. Section 4 discusses H- 173 VPLS with mixed PBBN/PBN access. Section 5 focuses on PBB in H-VPLS 174 with MPLS Access Network including PBB on U-PE and PBB on N-PE 175 variants. Finally, section 6 describes gradual migration scenarios 176 from existing H-VPLS to PBB over H-VPLS. 178 2. Terminology 180 802.1ad: IEEE specification for "QinQ" encapsulation and bridging of 181 Ethernet frames 183 802.1ah: IEEE specification for "MAC tunneling" encapsulation and 184 bridging of frames across a provider backbone bridged network. 186 B-BEB: A backbone edge bridge positioned at the edge of a provider 187 backbone bridged network. It contains a B-component that supports 188 bridging in the provider backbone based on B-MAC and B-TAG 189 information 191 B-MAC: The backbone source or destination MAC address fields defined 192 in the 802.1ah provider MAC encapsulation header. 194 BCB: A backbone core bridge running in the core of a provider 195 backbone bridged network. It bridges frames based on B-TAG 196 information just as an 802.1ad provider bridge will bridge frames 197 based on a VLAN identifier (S-VLAN) 199 BEB: A backbone edge bridge positioned at the edge of a provider 200 backbone bridged network. It can contain an I-component, B-component 201 or both I and B components. 203 B-TAG: field defined in the 802.1ah provider MAC encapsulation 204 header that conveys the backbone VLAN identifier information. The 205 format of the B-TAG field is the same as that of an 802.1ad S-TAG 206 field. 208 B-Tagged Service Interface: This is the interface between a BEB and 209 BCB in a provider backbone bridged network. Frames passed through 210 this interface contain a B-TAG field. 212 B-VID: The specific VLAN identifier carried inside a B-TAG 214 I-component: A bridging component contained in a backbone edge 215 bridge that bridges in the customer space (customer MAC addresses, 216 S-VLAN) 218 IB-BEB: A backbone edge bridge positioned at the edge of a provider 219 backbone bridged network. It contains an I-component for bridging in 220 the customer space (customer MAC addresses, service VLAN IDs) and a 221 B-component for bridging the provider's backbone space (B-MAC, B- 222 TAG). 224 I-BEB: A backbone edge bridged positioned at the edge of a provider 225 backbone bridged network. It contains an I-component for bridging in 226 the customer space (customer MAC addresses, service VLAN IDs). 228 I-SID: The 24-bit service instance field carried inside the I-TAG. 229 I-SID defines the service instance that the frame should be "mapped 230 to". 232 I-TAG: A field defined in the 802.1ah provider MAC encapsulation 233 header that conveys the service instance information (I-SID) 234 associated with the frame. 236 I-Tagged Service Interface: This the interface defined between the I 237 and B components inside an IB-BEB or between two B-BEB. Frames 238 passed through this interface contain an I-TAG field 240 PBB: Provider Backbone Bridge 242 PBBN: Provider Backbone Bridged Network 244 PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) 245 technology. 247 S-TAG: A field defined in the 802.1ad QinQ encapsulation header that 248 conveys the service VLAN identifier information (S-VLAN). 250 S-Tagged Service Interface: This the interface defined between the 251 customer (CE) and the I-BEB or IB-BEB components. Frames passed 252 through this interface contain an S-TAG field. 254 S-VLAN: The specific service VLAN identifier carried inside an S-TAG 256 3. H-VPLS with Homogeneous PBBN Access 258 PBBN access offers MAC-address table scalability for H-VPLS PE 259 nodes. This is due to the MAC tunneling encapsulation scheme of PBB 260 which only exposes the provider's own MAC addresses to PE nodes (B- 261 MACs of Provider's PBB-capable devices in the access network), as 262 opposed to customers' MAC addresses in conventional H-VPLS with MPLS 263 or 802.1ad access. 265 PBBN access also offers service instance scalability when compared 266 to H-VPLS with 802.1Q/802.1ad access networks. This is due to the 267 new 24-bit service identifier (I-SID) used in PBB encapsulation, 268 which allows up to 16M services per PBB access network, compared to 269 4K services per 802.1Q/802.1ad access network. 271 Another important advantage of PBBN access is that it offers clear 272 separation between the service layer (represented by I-SID) and the 273 network layer (represented by B-VLAN). B-VLANs segregate a PBB 274 access network into different broadcast domains and possibly unique 275 spanning-tree topologies, with each domain being able to carry 276 multiple services (i.e. I-SIDs). In 802.1ad access networks, the 277 network and service layers are the same (represented by S-VLAN). 278 This separation allows the Provider to manage and optimize the PBB 279 access network topology independent of the number of service 280 instances that are supported. 282 In this and the following sections we look into different flavors of 283 H-VPLS with PBBN access. This section discusses the case where H- 284 VPLS is deployed with homogenous PBBN access networks. Section 4 285 describes the case where at least one of the access networks is PBN 286 access (QinQ/802.1ad) while others are PBBN access. 288 At a macro scale, a network that employs H-VPLS with PBBN access can 289 be represented as shown in figure 1 below. 291 +--------------+ 292 | | 293 +---------+ | IP/MPLS | +---------+ 294 +----+ | | +----+ +----+ | | +----+ 295 | CE |--| | |VPLS| |VPLS| | |--| CE | 296 +----+ | PBBN |---| PE | | PE |--| PBBN | +----+ 297 +----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+ 298 | CE |--| | | Backbone | | |--| CE | 299 +----+ +---------+ +--------------+ +---------+ +----+ 301 Figure 1: H-VPLS with PBBN Access 302 In the context of PBBN and H-VPLS interoperability, "I-SID Domain" 303 and "B-VID Domain" can be defined as follows: 305 - "I-SID Domain" refers to a network administrative boundary under 306 which all the PBB BEBs and VPLS PE devices use the same I-SID 307 space, i.e. the I-SID assignment is carried out by the same 308 administration. This effectively means that a given service 309 instance has the same I-SID designation on all devices within an 310 I-SID Domain. 311 - "B-VID Domain" refers to a network administrative boundary under 312 which all the PBB BEBs and VPLS PE devices employ consistent I-SID 313 to B-VLAN bundling - e.g., grouping of I-SIDs to B-VLANs are the 314 same in that domain. Although the two B-VLANs in two PBBNs that 315 represent the same group of I-SIDs do not need to use the same B- 316 VID value, in practice they often use the same value because once 317 the I-SID grouping is made identical in two PBBNs, it is rather 318 very easy to make the values of the corresponding B-VIDs also 319 identical. 321 Consequently, three different kinds of "Service Domains" are defined 322 in the following manner: 324 - Tightly Coupled Service Domain - Different PBBN access networks 325 belonging to the same I-SID Domain and B-VID Domain. However, the 326 network control protocols (e.g. xSTP) run independently in each 327 PBB access network. 328 - Loosely Coupled Service Domain - Different PBB access networks 329 belonging to the same I-SID Domain. However, each PBBN access 330 maintains its own independent B-VID Domain. Again, the network 331 control protocols (e.g. xSTP) run independently in each PBBN 332 access. 333 - Different Service Domain - In this case, each PBBN access 334 maintains its own independent I-SID Domain and B-VID Domain, with 335 independent network control protocols (e.g. xSTP) in each PBB 336 access. 338 In general, correct service connectivity spanning networks in a 339 Tightly Coupled Service Domain can be achieved via B-VID mapping 340 between the networks (often even without B-VID translation). 341 However, correct service connectivity spanning networks in a Loosely 342 Coupled Service Domain requires I-SID to B-VID re-mapping (i.e 343 unbundling and re-bundling of I-SIDs into B-VIDs). Furthermore, 344 service connectivity spanning networks in Different Service Domains 345 requires both I-SID translation and I-SID to B-VID re-mapping. 347 3.1 Service Interfaces and Interworking Options 349 Customer devices will interface with PBBN edge bridges using 350 existing Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad. 351 At the PBBN edge, customer MAC frames are encapsulated in a PBB 352 header that includes a service provider source and destination MAC 353 addresses (B-MAC) and are bridged up to the VPLS PE. The PBB 354 encapsulated customer MAC frame is then injected into the VPLS 355 backbone network, delivered to the remote VPLS PE node(s), and 356 switched onto the remote PBBN access. From there, the PBBN bridges 357 the encapsulated frame to a PBBN edge bridge where the PBB header is 358 removed and the customer frame is sent to customer domain. 360 Interoperating between PBBN devices and VPLS PE nodes will certainly 361 leverage work already completed. When I-SID visibility is required 362 at the VPLS PE nodes, a new service interface based on I-SID tag 363 will need to be defined. 365 Moreover, by mapping a bridge domain (e.g. B-VLAN) to a VPLS 366 instance, and bundling multiple end-customer service instances, 367 represented by I-SIDs, over the same bridge domain, service 368 providers will be able to significantly reduce the number of full- 369 mesh PWs required in the core. In this case, I-SID visibility is not 370 required on the VPLS-PE and the I-SID will serve as the means of 371 multiplexing/de-multiplexing individual service instances in the 372 PBBN over a bundle (e.g. B-VLAN). 374 When I-SID visibility is expected across the service interface at 375 the VPLS PE, VPLS PE can be considered to offer service-level 376 interworking between PBBN access and IP/MPLS core. Similarly, when 377 PE is not expected to have visibility of I-SID at the service 378 interface, VPLS PE can be considered to offer network-level 379 interworking between PBBN access and MPLS core. 381 A VPLS PE is always part of the IP/MPLS core, and may optionally 382 participate in the control protocols (e.g. xSTP) of the access 383 network. When connecting to a PBBN access, the VPLS PE needs to 384 support one of the following two types of service interfaces: 386 - Type I: B-Tagged Service Interface with B-VID as Service Delimiter 387 - The PE connects to a Backbone Core Bridge (BCB) in PBBN access. 388 The handoff between the BCB and the PE is B-Tagged PBB 389 encapsulated frame. The PE is transparent to PBB encapsulations 390 and treats these frames as 802.1ad frames since B-VID EtherType is 391 the same as S-VID EtherType. The PE does not need to support PBB 392 functionality. This corresponds to conventional VPLS PE's tagged 393 service interface. When using Type I service interface, the PE 394 needs to support either raw-mode or tagged-mode Ethernet PW. Type 395 I Service Interface is described in detail in Section 3.2. 397 - Type II: I-Tagged Service Interface with I-SID as Service 398 Delimiter - The PE connects to a B-BEB (Backbone Edge Bridge with 399 B-Component) in PBBN access. The PE itself also supports the B-BEB 400 functionality of [802.1ah]. The handoff between the B-BEB in PBBN 401 access and the PE is an I-Tagged PBB encapsulated frame. With Type 402 II service interface, the PE supports the existing raw-mode and 403 tagged-mode PW types. Type II Service Interface is described in 404 detail in Section 3.3. 406 3.2 H-VPLS with PBBN Access: Type I Service Interface 408 This is a B-Tagged service interface with B-VID as service delimiter 409 on the VPLS-PE. It does not require any new functionality on the 410 VPLS-PE. As shown in Figure 2, the PE is always part of the IP/MPLS 411 core. The PE may also be part of the PBBN Access (e.g. VPLS-PE on 412 right side of Figure 2) by participating in network control 413 protocols (e.g. xSTP) of the PBBN access. 415 PBBN Access IP/MPLS Core PBBN Access 416 +--------------+ 417 +---------+ | | +---------------+ 418 | | +----+ | | | 419 | +---+ |VPLS| +-+ | | +---+ | 420 | |BCB|---| PE |---|P| | | |BCB| | 421 | +---+ /+----+ /+-+\ | | /+---+ | 422 |+---+ | / +----+ / \+----+ / +---+| 423 +--+ ||IB-| +---+/ |VPLS|/ +-+ |VPLS|/ +---+ |IB-|| +--+ 424 |CE|-||BEB|-|BCB|---| PE |---|P|--| PE |---|BCB|-|BEB|--|CE| 425 +--+ |+---+ +---+ ^ +----+ +-+ +----+ ^ +---+ +---+| +--+ 426 | | | | | | | | 427 +---------+ | | | +--|------------+ 428 | +--------------+ | 429 | | 430 Type I Type I 432 Figure 2: H-VPLS with PBBN Access & Type I Service Interface 434 Type I service interface is applicable to networks with Tightly 435 Coupled Service Domains, where both I-SID Domains and B-VID Domains 436 are the same across all PBBN access networks. 438 The BCB and VPLS PE will exchange PBB encapsulated frames that 439 include source and destination B-MAC addresses, a B-VID and I-SID. 440 The service delimiter, from the perspective of the VPLS PE, is the 441 B-VID; in fact, this interface operates exactly as a current 442 802.1Q/ad interface into a VPLS PE does today. With Type I service 443 interface, VPLS PE can be considered as providing network-level 444 interworking between PBBN and MPLS domains, since VPLS PE does not 445 have visibility of I-SIDs. 447 The main advantage of this service interface, when compared to other 448 types, is that it allows the service provider to save on the number 449 of full-mesh PWs required in the core. This is primarily because 450 multiple service instances (I-SIDs) are bundled over a single full- 451 mesh corresponding to a bridge domain (e.g. B-VID), instead of 452 requiring a dedicated full-mesh per service instance. Another 453 advantage is the MAC address scalability in the core since the core 454 is not exposed to C-MACs. 456 The disadvantage of this interface is the comparably excessive 457 replication required in the core: since a group of service instances 458 share the same full-mesh of PWs, an unknown unicast, multicast or 459 broadcast on a single service instance will result in a flood over 460 the core. This, however, can be mitigated via the use of per I-SID 461 flood containment (B-MAC multicast pruning) as described in [PBB- 462 VPLS-MCAST]. 464 Three different modes of operation are supported by Type I Service 465 Interface: 467 - Port Mode: All traffic over an interface in this mode is mapped to 468 a single VPLS instance. Existing PW signaling and Ethernet raw 469 mode (0x0005) PW type, defined in [RFC4447] [RFC4448], are 470 supported. 472 - VLAN Mode: all traffic associated with a particular VLAN 473 identified by the B-VID is mapped to a single VPLS instance. 474 Existing PW signaling and Ethernet raw mode (0x0005) PW type, 475 defined in [RFC4447] [RFC4448], are supported. 477 - VLAN Bundling Mode: all traffic associated with a group or range 478 of VLANs or B-VIDs is mapped to a single VPLS instance. Existing 479 PW signaling and Ethernet raw mode (0x0005) PW type, defined in 480 [RFC4447] [RFC4448], are supported. 482 For the above three modes, it is also possible to use Ethernet 483 tagged mode (0x0004) PW, as defined in [RFC4447] [RFC4448], for 484 interoperability with equipment that does not support raw mode. The 485 use of raw mode is recommended to be the default though. 487 3.3 H-VPLS with PBBN Access: Type II Service Interface 489 This is an I-Tagged service interface with I-SID as service 490 delimiter on VPLS-PE. It requires the VPLS-PE to include B-Component 491 of PBB BEB for I-SID processing in addition to the capability to map 492 I-SID Bundle to VPLS instance. As shown in Figure 3, the PE is 493 always part of IP/MPLS core and connects to one or more B-BEB in 494 PBBN access. 496 PBBN Access IP/MPLS Core PBBN Access 497 +--------------+ 498 +---------+ | | +---------+ 499 | | | | | | 500 | +---+ +-----+ | | +---+ | 501 | |B- | |PE w/| +-+ | | |BCB| | 502 | |BEB|--|B-BEB|-|P| | | +---+ | 503 | +---+ /+-----+ +-+ | | / | | 504 |+---+ +---+/ +-----+/ \+-----+ +---+ +---+| 505 +--+ ||IB-| |B- | |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 506 |CE|-||BEB|-|BEB|--|B-BEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 507 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 508 | | | | | | | | 509 +---------+ | | | | +---------+ 510 | +-------------+ | 511 | | 512 Type II Type II 514 Figure 3: H-VPLS with PBBN Access & Type II Service Interface 516 Type II service interface is applicable to Loosely Coupled Service 517 Domains and Different Service Domains. B-VID Domains can be 518 independent and the B-VID is always locally significant in each PBBN 519 access and does not need to be transported over the IP/MPLS core. 520 Given the above, it should be apparent that Type II service 521 interface is applicable to Tightly Coupled Service Domains as well. 523 By definition the B-BEB connecting to the VPLS PE will remove any B- 524 VLAN tags for frames exiting the PBB access network. The B-BEB and 525 VPLS PE will exchange PBB encapsulated frames that include source 526 and destination B-MAC addresses, and I-SID. The service delimiter, 527 from the perspective of the VPLS PE, is the I-SID. Since PE has 528 visibility to I-SIDs, the PE provides service-level interworking 529 between PBBN access and IP/MPLS core. 531 The advantage that Type II service interface has compared to Type I 532 is the potentially less replication in the core without the need for 533 a per I-SID flood containment (B-MAC multicast pruning) mechanism. 534 This is mainly due to the increased segregation of service instances 535 over disjoint full-meshes of PWs. 537 The disadvantage of this service interface, compared to Type I, is 538 that it may require a larger number of full-mesh PWs in the core. 539 However, the number of full-mesh PWs can still be less than those 540 required by H-VPLS without PBBN access. 542 It is expected that this interface type will be used for customers 543 with significant multicast traffic (but without multicast pruning 544 capability in VPLS PE) so that a separate VPLS instance is set up 545 per group of customers with similar geographic locality (per I-SID 546 group). 548 Type II Service Interface may operate in I-SID Bundling Mode: all 549 traffic associated with a group or range of I-SIDs is mapped to a 550 single VPLS instance. The PE maintains a mapping of I-SIDs to a PE 551 local bridge domain (e.g. B-VID). The VPLS instance is then 552 associated with this bridge domain. With Tightly and Loosely Coupled 553 Service Domains, no I-SID translation needs to be performed. Type II 554 Service Interface also supports Different Service Domains in this 555 mode, since the B-BEB link in the PE connecting to the local PBBN 556 can perform the translation of PBBN-specific I-SID to a local I-SID 557 within the IP/MPLS core, which may then be translated to the other 558 PBBN specific I-SID on the egress PE. Such translation can also 559 occur in the B-BEB of PBBN access. Existing PW signaling and 560 Ethernet raw mode (0x0005), defined in [RFC4447] [RFC4448], is 561 supported. It is also possible to use tagged mode (0x0004) PW for 562 purpose of interoperability with equipment that does not support raw 563 mode. 565 Note 1: Port mode is not called out in Type II Service Interface 566 since it requires the mapping of I-SIDs to be identical on different 567 I-Tagged interfaces across VPLS network. If this is indeed the case, 568 Port mode defined in Type I Service Interface (Section 3.2) can be 569 used. 571 Note 2: In a degenerate scenario, it is possible to define an I-SID 572 bundle that comprises a single I-SID. This allows the Type II 573 service interface to effectively operate as if in I-SID Mode, at the 574 added expense of consuming more bridge-domains on the PE and 575 increased number of PW full-mesh in the core. 577 4. H-VPLS with Mixed PBBN Access and PBN Access 579 It is foreseeable that service providers will want to interoperate 580 their existing PBN (QinQ) access networks with PBBN access networks 581 over H-VPLS. Figure 4 below shows the high-level network topology. 583 +--------------+ 584 | | 585 +---------+ | IP/MPLS | +---------+ 586 +----+ | | +----+ +----+ | | +----+ 587 | CE |--| PBN | |VPLS| |VPLS| | |--| CE | 588 +----+ | (QinQ) |---| PE1| | PE2|--| PBBN | +----+ 589 +----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+ 590 | CE |--| | | Backbone | | |--| CE | 591 +----+ +---------+ +--------------+ +---------+ +----+ 593 Figure 4: H-VPLS with Mixed PBN and PBBN Access Networks 594 Referring to Figure 4 above, two possibilities come into play 595 depending on whether the interworking is carried out at PE1 or PE2. 596 These are described in the following sub-Sections. 598 4.1 H-VPLS with Mixed PBBN & PBN Access: Modified PBN PE 600 As shown in Figure 5, the operation of VPLS PE2 (connecting to the 601 PBBN access on the right) is no different from what was discussed in 602 Section 3. Type II service interface, as discussed in the above 603 section, is applicable. It is the behavior of VPLS PE1 (connecting 604 to the PBN access on the left) that is the focus of this section. 606 PBN Access IP/MPLS Core PBBN Access 607 (802.1ad) +--------------+ (802.1ah) 608 | | +---------+ 609 +---------+ | | | | 610 | | +-----+ | | +---+ | 611 | +---+ |PE w/| +-+ | | |BCB| | 612 | |PCB|--|IBBEB|-|P| | | +---+ | 613 | +---+ /+-----+ +-+ | | / | | 614 | | / +-----+/ \+-----+ +---+ +---+| 615 +--+ |+---+ +---+ |PE w/| +-+ |PE w/| |B- | |IB-|| +--+ 616 |CE|-||PEB|-|PCB|--|IBBEB|-|P|-|B-BEB|-|BEB| |BEB|--|CE| 617 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 618 | | | |PE1 PE2| | | | 619 +---------+ | | | | +---------+ 620 | +-------------+ | 621 | | 622 S-Tagged Type II (I-Tagged) 624 Figure 5: H-VPLS with Mixed PBB and PBBN Access: Modified PBN PE 626 Some assumptions made for this topology include: 627 - CE is directly connected to PBBN via C-Tagged Interface 628 - I-SID in PBBN access represents the same customer as S-VID in PBN 629 access 630 - At S-Tagged Service Interface of PE with IB-BEB functionality 631 (e.g. PE1 in Figure 5), the only viable service is 1:1 mapping of 632 S-VID to I-SID. However, towards the core network side, the same 633 PE can support I-SID bundling into a VPLS instance. 634 - PE1 participates in the local ISID domain of the IP/MPLS Core so 635 the model accommodates for the rest of the PBB network any of the 636 three domain types described in section 3 - Tightly, Loosely 637 Coupled and Different Service Domains. 638 - For ease of provisioning in these disparate access networks, it is 639 recommended to use the same I-SID Domain among the PBBN access and 640 PEs with IB-BEB functionality (those connecting to PBN). 642 This topology operates in I-SID Bundling Mode: at PE connecting to 643 PBN access, each S-VID is mapped to an I-SID and subsequently a 644 group of I-SIDs is mapped to a VPLS instance. Similarly, at PE 645 connecting to PBBN access, each group of I-SIDs is mapped to a VPLS 646 instance. Similar to Type II interface, no I-SID translation is 647 performed for I-SID bundling case. Existing PW signaling and 648 Ethernet raw mode (0x0005) PW type, defined in [RFC4447] [RFC4448], 649 are supported. It is possible to use tagged mode (0x0004) PW for 650 backward compatibility as well. 652 4.2 H-VPLS with Mixed PBBN & PBN Access: Regular PBN PE 654 As shown in Figure 6, the operation of VPLS PE1 (connecting to the 655 PBN access on the left) is no different from existing VPLS PEs. It 656 is the behavior of VPLS PE2 (connecting to the PBBN access on the 657 right) that is the focus of this section. 659 PBN Access IP/MPLS Core PBBN Access 660 (802.1ad) +--------------+ (802.1ah) 661 | | +---------+ 662 +---------+ | | | | 663 | | +-----+ | | +---+ | 664 | +---+ | PE | +-+ | | |BCB| | 665 | |PCB|--| |-|P| | | +---+ | 666 | +---+ /+-----+ +-+ | | / | | 667 | | / +-----+/ \+-----+ +---+ +---+| 668 +--+ |+---+ +---+ | PE | +-+ |PE w/| |B- | |IB-|| +--+ 669 |CE|-||PEB|-|PCB|--| |-|P|-|IBBEB|-|BEB| |BEB|--|CE| 670 +--+ |+---+ +---+ ^+-----+ +-+ +-----+^+---+ +---+| +--+ 671 | | | |PE1 PE2| | | | 672 +---------+ | | | | +---------+ 673 | +-------------+ | 674 | | 675 S-Tagged Type II (I-Tagged) 677 Figure 6: H-VPLS with Mixed PBB and PBBN Access: Regular PBN PE 679 Some assumptions made for this topology include: 680 - CE is directly connected to PBBN via C-Tagged Interface 681 - I-SID in PBBN access represents the same customer as S-VID in PBN 682 access 683 - There is 1:1 mapping between the I-SID and VPLS instance 684 - At S-Tagged Service Interface of PE connecting to PBN (e.g. PE1 in 685 Figure 6), the PE only provides 1:1 mapping of S-VID to VPLS 686 instance. S-VID bundling is not a viable option since it does not 687 correspond to anything in PBBN access. 688 - The PE connecting to PBBN (e.g. PE2 in Figure 6), supports IB-BEB 689 functionality and the I-Component is connected to the VPLS 690 Forwarder (i.e. the I-Component faces the MPLS core whereas the B- 691 Component faces the PBBN access network). One or more I-SIDs can 692 be grouped into a B-VID in the PBBN access. 694 - Since C-VID grouping in different PBBN access networks must be 695 consistent, it is assumed that same I-SID Domain is used across 696 these PBBN access networks. 698 Unlike the other topology, I-SID bundling mode is not supported in 699 this case. This is primarily because the VPLS core operates in the 700 same manner as today. The PE with IB-BEB functionality connecting to 701 PBBN access performs the mapping of each VPLS instance to an I-SID 702 and one or more of these I-SIDs may be mapped onto a B-VID within 703 the PBBN access network. 705 5. H-VPLS with MPLS Access 707 In this section, the case of H-VPLS with MPLS access network is 708 discussed. The integration of PBB functionality into VPLS-PE for 709 such access networks is described to improve the scalability of the 710 network in terms of the number of MAC addresses and service 711 instances that are supported. 713 For this topology, it is possible to embed PBB functionality in 714 either the U-PE or the N-PE. Both of these cases are described in 715 the following sub-sections. 717 5.1 H-VPLS with MPLS Access: PBB U-PE 719 As stated earlier, the objective for incorporating PBB function at 720 the U-PE is to improve the scalability of H-VPLS networks in terms 721 of the number of MAC addresses and service instances that are 722 supported. 724 In current H-VPLS, the N-PE must learn customer MAC addresses (C- 725 MACs) of all VPLS instances that it participates in. This can easily 726 add-up to hundreds of thousands or even millions of C-MACs at the N- 727 PE. When the U-PE performs PBB encapsulation, the N-PE only needs to 728 learn the MAC addresses of the U-PEs, which is a significant 729 reduction. Furthermore, when PBB encapsulation is used, many I-SIDs 730 are multiplexed within a single bridge domain (e.g., B-VLAN). If the 731 VPLS instance is set up per B-VLAN, then one can also achieve a 732 significant reduction in the number of full-mesh PWs. It should be 733 noted that this reduction in full-mesh PWs comes at the cost of 734 potentially increased replication over the full-mesh of PWs: A given 735 customer multicast and/or broadcast frames are effectively 736 broadcasted within the B-VLAN. This may result in additional frame 737 replication because the full-mesh PWs corresponding to a B-VLAN is 738 most likely bigger than the full-mesh PWs corresponding to a single 739 I-SID. However, per I-SID flood containment (B-MAC multicast 740 pruning) as described in [PBB-VPLS-MCAST] can be used to remedy this 741 drawback and have multicast traffic replicated efficiently for each 742 customer (i.e. for each I-SID). 744 Figure 7 below illustrates the scenario for H-VPLS with MPLS access. 745 As it can be seen, customer networks or hosts (CE) connect into the 746 U-PE nodes using standard Ethernet interfaces [802.1D], [802.1Q], or 747 [802.1ad]. The U-PE is connected upstream to one or more VPLS N-PE 748 nodes by MPLS PWs (per VPLS instance). These, in turn, are connected 749 via a full-mesh of PWs (per VPLS instance) traversing the IP/MPLS 750 core. The U-PE is outfitted with PBB Backbone Edge Bridge (BEB) 751 functions where it can encapsulate/de-encapsulate customer MAC 752 frames in provider B-MAC addresses and perform I-SID translation if 753 needed. 755 PBB PBB 756 BEB +----------+ BEB 757 | | | | 758 | +-----------+ | IP | +-----------+ | 759 | | MPLS | | MPLS | | MPLS | | 760 V | Access +----+ | Core | +----+ Access | V 761 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 762 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 763 +--+ +----+ +----+ | | +----+ +----+ +--+ 764 | | | | | | 765 +-----------+ +----------+ +-----------+ 767 Figure 7: H-VPLS with MPLS Access Network and PBB U-PE 769 The U-PE still provides the same type of services toward its 770 customers as before and they are: 772 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 773 - VLAN mode (either 802.1Q or 802.1ad) 774 - VLAN-bundling mode (either 802.1Q or 802.1ad) 776 By incorporating PBB function, the U-PE maps each of these services 777 (for a given customer) onto a single I-SID based on the 778 configuration at the U-PE. Many I-SIDs are multiplexed within a 779 single bridge domain (e.g. B-VLAN). The U-PE can then map a bridge- 780 domain onto a VPLS instance and the encapsulated frames are sent 781 over the PW associated with that VPLS instance. Furthermore the 782 entire Ethernet bridging operation over VPLS network is performed as 783 defined in [RFC4762]. In other words, MAC forwarding is based on the 784 B-MAC address space and service delimiter is based on VLAN ID, which 785 is B-VID in this case. There is no need to inspect or deal with I- 786 SID values in the VPLS N-PEs. 788 5.1.1 PBB U-PEs in Single I-SID Domain 790 In this scenario, I-SID assignment is performed globally across all 791 MPLS access networks and therefore there is no need for I-SID 792 translation. This scenario support I-SID bundling mode and it is 793 assumed that the mapping of the I-SIDs to the bridge domain (e.g., 794 B-VLAN) is consistent across all the participating PE devices. In 795 case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is 796 mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or 797 tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448]. 799 I-SID mode can be considered as a degenerate case of I-SID bundling 800 where a single bridge domain is used per I-SID. However, that 801 results in increase number of bridge domains and PWs in the PEs. PBB 802 flood containment (B-MAC multicast pruning) per I-SID as described 803 in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling 804 mode to limit the scope of flooding per I-SID thus removing the need 805 for I-SID mode. 807 5.2 H-VPLS with MPLS Access: PBB N-PE 809 In this case, the PBB function is incorporated at the N-PE to 810 improve the scalability of H-VPLS networks in terms of the numbers 811 of MAC addresses and service instances that are supported. 813 Customer networks or hosts (CE) connect into the U-PE nodes using 814 standard Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The 815 U-PE is connected upstream to one or more VPLS N-PE nodes by MPLS 816 PWs (per customer). These, in turn, are connected via a full-mesh of 817 PWs (per customer or group of customers) traversing the IP/MPLS 818 core. 820 The U-PE still provides the same type of services toward its 821 customers as before and they are: 823 - Port mode (either 802.1D, 802.1Q, or 802.1ad) 824 - VLAN mode (either 802.1Q or 802.1ad) 825 - VLAN-bundling mode (either 802.1Q or 802.1ad) 827 Spoke PW from U-PE to N-PE is not service multiplexed because there 828 is no PBB functionality on u-PE - i.e. one service per PW. 830 PBB PBB 831 BEB +----------+ BEB 832 | | | | 833 +-----------+ | | IP | | +-----------+ 834 | MPLS | V | MPLS | V | MPLS | 835 | Access +----+ | Core | +----+ Access | 836 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 837 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 838 +--+ +----+ +----+ | | +----+ +----+ +--+ 839 | | | | | | 840 +-----------+ +----------+ +-----------+ 841 Figure 8: H-VPLS with MPLS Access Network and PBB N-PE 843 By incorporating PBB function, the N-PE maps each of these services 844 (for a given customer) onto a single I-SID based on the 845 configuration at the N-PE. Many I-SIDs can be multiplexed within a 846 single bridge domain (e.g. B-VLAN). The N-PE can, then, either map a 847 single I-SID into a VPLS instance or it can map a bridge domain 848 (e.g. B-VLAN) onto a VPLS instance, according to its configuration. 849 Next, the encapsulated frames are sent over the set of PWs 850 associated with that VPLS instance. 852 5.2.1 PBB N-PEs in Single I-SID Domain 854 In this scenario, I-SID assignment is performed globally across all 855 MPLS access networks and therefore there is no need for I-SID 856 translation. This scenario support I-SID bundling mode and it is 857 assumed that the mapping of the I-SIDs to the bridge domain (e.g., 858 B-VLAN) is consistent across all the participating PE devices. In 859 case of the I-SID bundling mode, a bridge domain (e.g., B-VLAN) is 860 mapped to a VPLS instance and existing Ethernet raw mode (0x0005) or 861 tagged mode (0x0004) PW type as defined in [RFC4447] [RFC4448], can 862 be used. 864 I-SID mode can be considered as a degenerate case of I-SID bundling 865 where a single bridge domain is used per I-SID. However, that 866 results in increase number of bridge domains and PWs in the PE. PBB 867 flood containment (B-MAC multicast pruning) per I-SID as described 868 in [PBB-VPLS-MCAST] can be used in conjunction with I-SID bundling 869 mode to limit the scope of flooding per I-SID thus removing the need 870 for I-SID mode. 872 6. H-VPLS with MPLS Access: PBB Migration Scenarios 874 Operators and service providers that have deployed H-VPLS with 875 either MPLS or Ethernet are unlikely to migrate to PBB technology 876 overnight because of obvious cost implications. Thus, it is 877 imperative to outline migration strategies that will allow operators 878 to protect investments in their installed base while still taking 879 advantage of the scalability benefits of PBB technology. 881 In the following sub-sections, we explore three different migration 882 scenarios which allow a mix of existing H-VPLS access networks to 883 co-exist with newer PBB-based access networks. The scenarios differ 884 in whether the Ethernet service frames passing over the VPLS core 885 are PBB-encapsulated or not. The first scenario in section 6.1 886 involves passing only non PBB-encapsulated frames over the core. The 887 second scenario in section 6.2 stipulates passing only PBB- 888 encapsulated frames over the core. Whereas, the final scenario in 889 section 6.3 depicts a core that supports a mix of PBB-encapsulated 890 and non PBB-encapsulated frames. The advantages and disadvantages of 891 each scenario will be discussed in its respective section. 893 6.1. 894 802.1ad Service Frames over VPLS Core 896 In this scenario, existing access networks are left unchanged. All 897 N-PEs would forward frames based on C-MAC addresses. In other words, 898 Ethernet frames which are traversing the VPLS core (within PWs) 899 would use the 802.1ad frame format, as in current VPLS. Hence, the 900 N-PEs in existing access networks do not require any modification. 901 For new MPLS access networks that have PBB functions on the U-PE, 902 the corresponding N-PE must incorporate built-in IB-BEB functions in 903 order to terminate the PBB encapsulation before the frames enter the 904 core. A key point here is that while both the U-PE and N-PE nodes 905 implement PBB IB-BEB functionality, the former has the I-Component 906 facing the customer (CE) and the B-Component facing the core; 907 whereas the latter has the I-Component facing the core and the B- 908 Component facing the customer (i.e. access network). 910 PBB PBB 911 +----------+ IB-BEB IB-BEB 912 | | | | 913 +-----------+ | IP | | +-----------+ | 914 | MPLS | | MPLS | V | MPLS | | 915 | Access +----+ | Core | +----+ Access | V 916 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 917 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 918 +--+ +----+ +----+ | | +----+ +----+ +--+ 919 | (Existing)| | | | (New) | 920 +-----------+ +----------+ +-----------+ 922 Figure 9: Migration with 802.1ad Service Frames over VPLS Core 924 The main advantage of this approach is that it requires no change to 925 existing access networks or existing VPLS N-PEs. The main 926 disadvantage is that these N-PEs will not leverage the advantages of 927 PBB in terms of MAC address and PW scalability. 928 It is worth noting that this migration scenario is an optimal option 929 for an H-VPLS deployment with a single PBB-capable access network. 930 When multiple PBB-capable access networks are required, then the 931 scenario in Section 6.3 is preferred, as it provides a more scalable 932 and optimal interconnect amongst the PBB-capable networks. 934 6.2. 935 PBB Service Frames over VPLS Core 937 This scenario requires that the VPLS N-PE connecting to existing 938 MPLS access networks be upgraded to incorporate IB-BEB functions. 939 All Ethernet service frames passing over the VPLS core would be PBB- 940 encapsulated. The PBB over MPLS access networks would require no 941 special requirements beyond what is captured in section 5 of this 942 document. 944 In this case, both the U-PE and N-PE which implement IB-BEB 945 functionality have the I-Component facing the customer and the B- 946 Component facing the core. 948 PBB PBB 949 IB-BEB +----------+ IB-BEB 950 | | | | 951 +-----------+ | | IP | +-----------+ | 952 | MPLS | V | MPLS | | MPLS | | 953 | Access +----+ | Core | +----+ Access | V 954 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 955 |CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE| 956 +--+ +----+ +----+ | | +----+ +----+ +--+ 957 | (Existing)| | | | (New) | 958 +-----------+ +----------+ +-----------+ 960 Figure 10: Migration with PBB Service Frames over VPLS Core 962 The main advantage of this approach is that it allows better 963 scalability of the VPLS N-PEs in terms of MAC address and pseudowire 964 counts. The disadvantage is that it requires upgrading the VPLS N- 965 PEs of all existing MPLS access networks. 967 6.3. 968 Mixed 802.1ad and PBB over VPLS Core 970 In this scenario, existing access networks are left unchanged, and 971 exchange Ethernet frames with 802.1ad format over the PWs in the 972 core. The newly added access networks, which incorporate PBB 973 functionality exchange Ethernet frames that are PBB-encapsulated 974 amongst each other over core PWs. For service connectivity between 975 existing access network (non PBB capable) and new access network 976 (PBB based), the VPLS N-PE of the latter network employs IB-BEB 977 functionality to de-capsulate the PBB header from frames outbound to 978 the core, and encapsulate the PBB header for frames inbound from the 979 core. As a result, a mix of PBB-encapsulated and 802.1ad Ethernet 980 service frames are exchanged over the VPLS core. 982 This mode of operation requires new functionality on the VPLS N-PE 983 of the PBB-capable access network, so that the PE can send frames in 984 802.1ad format or PBB format, on a per PW basis, depending on the 985 capability of the destination access network. Effectively, the PE 986 would have to incorporate B-BEB as well as IB-BEB functions. 988 A given PE needs to be aware of the capability of its remote peer in 989 order to determine whether it connects to the right PW Forwarder. 990 This can be achieved either via static configuration, or by 991 extending the VPLS control plane (BGP-based auto-discovery and LDP 992 Signaling) discussed in [L2VPN-Sig]. The latter approach and the 993 details of the extensions required are out of scope for this 994 document and will be covered in a separate document. 996 PBB 997 B-BEB PBB 998 +----------+ IB-BEB IB-BEB 999 | | | | 1000 +-----------+ | IP | | +-----------+ | 1001 | MPLS | | MPLS | V | MPLS | | 1002 | Access +----+ | Core | +----+ Access | V 1003 +--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+ 1004 |CE|--|U-PE| |N-PE| | | |N-PE| |U-PE|--|CE| 1005 +--+ +----+ +----+ | | +----+ +----+ +--+ 1006 | (Existing)| | | | (New) | 1007 +-----------+ +----------+ +-----------+ 1009 Figure 11: Migration with Mixed 802.1ad &PBB Service Frames over VPLS 1010 Core 1012 The U-PE and N-PE of the PBB-capable access network both employ BEB 1013 functionality: The U-PE implements IB-BEB function where the I- 1014 Component faces the customer (CE) and the B-Component faces the 1015 core. The N-PE, on the other hand, implements IB-BEB functionality 1016 with the I-Component facing the core and the B-Component facing the 1017 customer (access network). In addition, the N-PE implements stand- 1018 alone B-BEB functionality. 1020 This scenario combines the advantages of both previous scenarios 1021 without any of their shortcomings, namely: it does not require any 1022 changes to existing access networks and it allows the N-PE to 1023 leverage the scalability benefits of 802.1ah for PBB to PBB access 1024 network connectivity. The disadvantage of this option is that it 1025 requires new functionality on the N-PE of the PBB-capable access 1026 network. 1028 7. Acknowledgments 1030 TBD. 1032 8. IANA Considerations 1034 This document has no actions for IANA. 1036 9. Security Considerations 1038 This document does not introduce any additional security aspects 1039 beyond those applicable to VPLS/H-VPLS. VPLS/H-VPLS security 1040 considerations are already covered in [RFC4762]. 1042 10. References 1044 10.1 Normative References 1046 [802.1ad] "Virtual Bridged Local Area Networks, Amendment 4: 1047 Provider Bridges", IEEE Std. 802.1ad-2005, May 2006 1049 [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider 1050 Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008 1052 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 1053 April 2006 1055 [RFC4448] "Encapsulation Methods for Transport of Ethernet over MPLS 1056 Networks", RFC4448, April 2006 1058 [RFC4762] "Virtual Private LAN Service (VPLS) Using Label 1059 Distribution Protocol (LDP) Signaling", RFC4762, January 2007 1061 [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and 1062 Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt, May 2006 1063 ( work in progress ) 1065 10.2 Informative References 1067 [802.1Q] "Virtual Bridged Local Area Networks", IEEE Std. 802.1Q- 1068 2005 1070 [802.1D-REV] "Media Access Control (MAC) Bridges", IEEE Std. 802.1D- 1071 2003 1073 [VPLS-Bridge] "VPLS Interoperability with CE Bridges", draft-ietf- 1074 l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 2007 1076 [VPLS-MCAST] "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast- 1077 03.txt, Work in progress, November 2007 1079 [PBB-VPLS-MCAST] "Multicast Pruning in Provider Backbone Bridged 1080 VPLS", draft-sajassi-l2vpn-pbb-vpls-mcast-pruning-00.txt, Work in 1081 progress, July 2008 1083 Authors' Addresses 1085 Ali Sajassi 1086 Cisco 1087 170 West Tasman Drive 1088 San Jose, CA 95134, US 1089 Email: sajassi@cisco.com 1090 Samer Salam 1091 Cisco 1092 595 Burrard Street, Suite 2123 1093 Vancouver, BC V7X 1J1, Canada 1094 Email: ssalam@cisco.com 1096 Chris Metz 1097 Cisco 1098 170 West Tasman Drive 1099 San Jose, CA 95134, US 1100 Email: metz@cisco.com 1102 Nabil Bitar 1103 Verizon Communications 1104 Email : nabil.n.bitar@verizon.com 1106 Dinesh Mohan 1107 Nortel 1108 3500 Carling Ave 1109 Ottawa, ON K2H8E9, Canada 1110 Email: mohand@nortel.com 1112 Florin Balus 1113 Alcatel-Lucent 1114 701 E. Middlefield Road 1115 Mountain View, CA, USA 94043 1116 Email: florin.balus@alcatel-lucent.com