idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2015) is 3138 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Jiang, Ed. 2 Internet Draft L. Yong 3 Intended status: Standards Track Huawei 4 M. Paul 5 Deutsche Telekom 6 Expires: March 2016 September 23, 2015 8 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 9 draft-ietf-l2vpn-vpls-pe-etree-09.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on March 23, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document specifies a generic Virtual Private LAN Service (VPLS) 52 solution which uses VLANs to indicate root or leaf traffic to 53 support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) 54 model is illustrated as an example for the solution. In the solution, 55 E-Tree VPLS PEs are interconnected by Pseudo Wires (PWs) which carry 56 the VLAN indicating the E-Tree attribute. The MAC address-based 57 Ethernet forwarding engine and the PW work in the same way as 58 specified in RFC 4762 and RFC 4448 respectively. A signaling 59 mechanism is described to support E-Tree capability and VLAN mapping 60 negotiation. 62 Table of Contents 64 1. Conventions used in this document ......................... 3 65 2. Terminology ............................................... 3 66 3. Introduction .............................................. 4 67 4. PE Model with E-Tree Support .............................. 5 68 4.1. Existing PE Models ..................................... 5 69 4.2. A New PE Model with E-Tree Support ..................... 8 70 5. PW for E-Tree Support ..................................... 9 71 5.1. PW Encapsulation ....................................... 9 72 5.2. VLAN Mapping .......................................... 10 73 5.3. PW Processing ......................................... 11 74 5.3.1. PW Processing in the VLAN Mapping Mode .......... 11 75 5.3.2. PW Processing in the Compatible Mode ............ 12 76 5.3.3. PW Processing in the Optimized Mode ............. 13 77 6. Signaling for E-Tree Support ............................. 14 78 6.1. LDP Extensions for E-Tree Support ..................... 14 79 6.2. BGP Extensions for E-Tree Support ..................... 16 80 7. OAM Considerations ....................................... 18 81 8. Applicability ............................................ 18 82 9. Security Considerations .................................. 19 83 10. IANA Considerations ...................................... 19 84 11. References ............................................... 19 85 11.1. Normative References ............................... 19 86 11.2. Informative References ............................. 20 87 12. Acknowledgments .......................................... 21 88 Appendix A. Other PE Models for E-Tree ........................ 22 89 A.1. A PE Model With a VSI and No bridge ................... 22 90 A.2. A PE Model With external E-Tree interface ............. 23 92 1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Terminology 100 AC: Attachment Circuit 102 B-VLAN: Backbone VLAN 104 C-VLAN: Customer VLAN 106 E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in 107 [MEF6.1] 109 EVC: Ethernet Virtual Connection, as defined in [MEF4] 111 FIB: Forwarding Information Base, also known as forwarding table 113 I-SID: Backbone Service Instance Identifier, as defined in IEEE 114 802.1ah 116 Leaf AC: an AC attached with a leaf 118 Leaf VLAN: a VLAN Identifier (ID) used to indicate all the frames 119 that are originated at a leaf AC, it may be a C-VLAN, an S-VLAN or a 120 B-VLAN 122 OAM: Operations, Administration and Maintenance 124 PBB: Provider Backbone Bridge 126 PE: Provider Edge 128 PW: Pseudo Wire 130 Root AC: an AC attached with a root 132 Root VLAN: a VLAN ID used to indicate all the frames that are 133 originated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN 135 S-VLAN: Service VLAN 137 T-VSI: Tree VSI, a VSI with E-Tree support 139 VLAN: Virtual Local Area Network 140 VPLS: Virtual Private LAN Service 142 VSI: Virtual Switching Instance as defined in [RFC4664], also known 143 as VPLS Forwarder in [RFC7041] 145 3. Introduction 147 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet 148 Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint 149 Ethernet Virtual Connection (EVC) service. It is a multipoint 150 Ethernet service with special restrictions: the Ethernet frames from 151 a root MAY be received by any other root or leaf, and the frames 152 from a leaf MAY be received by any root, but MUST NOT be received by 153 a leaf. Further, an E-Tree service MAY include multiple roots and 154 multiple leaves. Although Virtual Private Multicast Service (VPMS) 155 [VPMS] or Point-to-Multipoint (P2MP) multicast is a somewhat 156 simplified version of this service, in fact, they are both multicast 157 services and are different from an E-Tree service which may include 158 both unicast and multicast traffic. 160 [RFC7152] gives the requirements for providing E-Tree solutions in 161 the VPLS and the need to filter leaf-to-leaf traffic. [RFC7387] 162 further describes a Multiprotocol Label Switching (MPLS) framework 163 for providing E-Tree. Though there were proposals on using the 164 Pseudowire (PW) control word or PWs to indicate the root/leaf 165 attribute of an E-Tree frame, both methods are limited in that they 166 are only applicable to "VPLS only" networks. 168 A VPLS PE usually consists of a bridge module itself (see [RFC4664] 169 and [RFC6246]); and moreover, E-Tree services may cross both 170 Ethernet and VPLS domains. Therefore, it is necessary to develop an 171 E-Tree solution both for "VPLS only" scenarios and for interworking 172 between Ethernet and VPLS. 174 IEEE 802.1 has incorporated the generic E-Tree solution into 802.1Q 175 [802.1Q-2014], which is an improvement on the traditional asymmetric 176 VLAN mechanism. In the asymmetric VLAN mechanism as described in 177 Section B.1.3 of IEEE 802.1Q-2003, a VLAN ID is used to indicate the 178 traffic from a server, and multiple VLAN IDs are used to indicate 179 the traffic from the clients (one VLAN ID per client). In the new 180 IEEE 802.1Q solution, only two VLANs are used to indicate root/leaf 181 attributes of a frame: one VLAN ID is used to indicate the frames 182 originated from the roots and another VLAN ID is used to indicate 183 the frames originated from the leaves. At a leaf port, the bridge 184 can then filter out all the frames from other leaf ports based on 185 the VLAN ID. It is better to reuse the same mechanism in VPLS than 186 to develop a new mechanism. A new mechanism would introduce more 187 complexity to interwork with the new IEEE 802.1Q solution. 189 This document specifies how the Ethernet VLAN solution can be used 190 to support generic E-Tree services in VPLS. The solution specified 191 here is fully compatible with the IEEE bridge architecture and with 192 IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) technology, thus it 193 will not change the FIB (such as installing E-Tree attributes in the 194 FIB), or need any specially tailored implementation. Furthermore, 195 VPLS scalability and simplicity are also maintained. With this 196 mechanism, it is also convenient to deploy a converged E-Tree 197 service across both Ethernet and MPLS networks. 199 A typical VPLS PE model is introduced as an example; the model is 200 then extended in which a Tree VSI is connected to a VLAN bridge with 201 a dual-VLAN interface. 203 The document then discusses the PW encapsulation and PW processing 204 such as VLAN mapping options for transporting E-Tree services in 205 VPLS. 207 Finally, the document describes the signaling extensions and 208 processing procedures for E-Tree support in VPLS. 210 4. PE Model with E-Tree Support 212 The problem scenario of E-Tree as shown in Fig. 1 of [RFC7152] is a 213 simplification of the L2VPN architecture, several common VPLS PE 214 architectures are discussed in more details in [RFC4664] and 215 [RFC6246]. 217 Below, an E-Tree solution in VPLS is demonstrated with the help of a 218 typical VPLS PE model. Its use in other PE models are discussed in 219 Appendix A. 221 4.1. Existing PE Models 223 According to [RFC4664], there are at least three models possible for 224 a VPLS PE, including: 226 o A single bridge module, a single VSI; 228 o A single bridge module, multiple VSIs; 230 o Multiple bridge modules, each attaches to a VSI. 232 The second PE model is commonly used. A typical example is further 233 depicted in Fig. 1 and Fig. 2 (both figures are extracted from 235 [RFC6246]), where an S-VLAN bridge module is connected to multiple 236 VSIs each with a single VLAN virtual interface. 238 +-------------------------------+ 239 | 802.1ad Bridge Module Model | 240 | | 241 +---+ AC | +------+ +-----------+ | 242 |CE |---------|C-VLAN|------| | | 243 +---+ | |bridge|------| | | 244 | +------+ | | | 245 | o | S-VLAN | | 246 | o | | | ---> to VSI 247 | o | Bridge | | 248 +---+ AC | +------+ | | | 249 |CE |---------|C-VLAN|------| | | 250 +---+ | |bridge|------| | | 251 | +------+ +-----------+ | 252 +-------------------------------+ 254 Figure 1 A model of 802.1ad Bridge Module 256 +----------------------------------------+ 257 | VPLS-capable PE model | 258 | +---------------+ +------+ | 259 | | | |VSI-1 |------------ 260 | | |==========| |------------ PWs 261 | | Bridge ------------ |------------ 262 | | | S-VLAN-1 +------+ | 263 | | Module | o | 264 | | | o | 265 | | (802.1ad | o | 266 | | bridge) | o | 267 | | | o | 268 | | | S-VLAN-n +------+ | 269 | | ------------VSI-n |------------- 270 | | |==========| |------------- PWs 271 | | | ^ | |------------- 272 | +---------------+ | +------+ | 273 | | | 274 +-------------------------|--------------+ 275 LAN emulation Interface 277 Figure 2 A VPLS-capable PE Model 279 In this PE model, Ethernet frames from Customer Edges (CEs) will 280 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 281 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 283 Therefore, the association between an AC port and a PW on a VSI is 284 difficult. 286 This model could be further enhanced: When Ethernet frames arrive at 287 an ingress PE, a root VLAN or a leaf VLAN tag is added. At an egress 288 PE, the frames with the root VLAN tag are transmitted both to the 289 roots and the leaves, while the frames with the leaf VLAN tag are 290 transmitted to the roots but dropped for the leaves (these VLAN tags 291 are removed before the frames are transmitted over the ACs). It was 292 demonstrated in [802.1Q-2011] that the E-Tree service in Ethernet 293 networks can be well supported with this mechanism. 295 Assuming this mechanism is implemented in the bridge module, it is 296 quite straightforward to infer a VPLS PE model with two VSIs to 297 support the E-Tree (as shown in Fig. 3). But this model will require 298 two VSIs per PE and two sets of PWs per E-Tree service, which is 299 poorly scalable in a large MPLS/VPLS network; in addition, both 300 these VSIs have to share their learned MAC addresses. 302 +----------------------------------------+ 303 | VPLS-capable PE model | 304 | +---------------+ +------+ | 305 | | | |VSI-1 |------------ 306 | | |==========| |------------ PWs 307 | | Bridge ------------ |------------ 308 | | | Root +------+ | 309 | | Module | S-VLAN | 310 | | | | 311 | | (802.1ad | | 312 | | bridge) | | 313 | | | Leaf | 314 | | | S-VLAN +------+ | 315 | | ------------VSI-2 |------------- 316 | | |==========| |------------- PWs 317 | | | ^ | |------------- 318 | +---------------+ | +------+ | 319 | | | 320 +-------------------------|--------------+ 321 LAN emulation Interface 323 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 325 4.2. A New PE Model with E-Tree Support 327 In order to support the E-Tree in a more scalable way, a new VPLS PE 328 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 329 specified. As depicted in Fig. 4, the bridge module is connected to 330 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 331 VLAN and the leaf VLAN are connected to the same T-VSI, and they 332 share the same FIB and work in shared VLAN learning. In this way, 333 only one VPLS instance and one set of PWs is needed per E-Tree 334 service, and the scalability of VPLS is improved. 336 +----------------------------------------+ 337 | VPLS-capable PE model | 338 | +---------------+ +------+ | 339 | | |==========|TVSI-1|------------ 340 +---+AC | | ------------ |------------ PWs 341 |CE |-------| Bridge ------------ |------------ 342 +---+ | | | Root & +------+ | 343 | | Module | Leaf VLAN o | 344 | | | o | 345 | | | o | 346 | | | o | 347 | | | o | 348 +---+AC | | | VLAN-n +------+ | 349 |CE |-------| ------------VSI-n |------------- 350 +---+ | | |==========| |------------- PWs 351 | | | ^ | |------------- 352 | +---------------+ | +------+ | 353 | | | 354 +-------------------------|--------------+ 355 LAN emulation Interface 357 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 359 For an untagged AC port (frames over this port are untagged) or 360 VLAN-unaware port (VLAN tags in the frames are ignored), and the 361 bridge module is a C-VLAN bridge, the Ethernet frames received from 362 the root ACs MUST be tagged with a root C-VLAN. When the bridge 363 module is an 802.1ad bridge, the Ethernet frames received from the 364 root ACs MUST be tagged with a root S-VLAN. Note, this can be done 365 by adding a root C-VLAN first in a C-VLAN bridge but this is out of 366 the scope of this document. 368 For a C-VLAN tagged port, the Ethernet frames received from the root 369 ACs MUST be tagged with a root S-VLAN. 371 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 372 received from the root ACs SHOULD be translated to the root S-VLAN 373 in the VPLS network domain. 375 Alternatively, for an S-VLAN tagged port, the PBB VPLS PE model 376 (where an IEEE 802.1ah bridge module is embedded in the PE) as 377 described in [RFC7041] MAY be used. A root B-VLAN or leaf B-VLAN MAY 378 be added. The E-Tree attribute may also be indicated with two I-SID 379 tags in the bridge module, and the frames are then encapsulated and 380 transported transparently over a single B-VLAN. Thus the PBB VPLS 381 works in the same way as described in [RFC7041] and will not be 382 discussed further in this document. When many S-VLANs are 383 multiplexed in a single AC, PBB VPLS has the advantages of both VLAN 384 scalability and MAC address scalability. 386 In a similar way, the traffic from the leaf ACs is tagged and 387 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 389 In all cases, the outermost VLAN in the resulting Ethernet header is 390 used to indicate the E-Tree attribute of an Ethernet frame; this 391 document uses VLAN to refer to this outermost VLAN for simplicity in 392 the latter sections. 394 5. PW for E-Tree Support 396 5.1. PW Encapsulation 398 To support an E-Tree service, T-VSIs in a VPLS MUST be 399 interconnected with a bidirectional Ethernet PW. The Ethernet PW 400 SHOULD work in the tagged mode (PW type 0x0004) as described in 401 [RFC4448], in which case a VLAN tag MUST be carried in each frame in 402 the PW to indicate the frame originated from either root or leaf 403 (the VLAN tag indicating the frame originated from either root or 404 leaf can be translated by a bridge module in the PE or added by an 405 outside Ethernet edge device, even by a customer device). In the 406 tagged PW mode, two service delimiting VLANs MUST be allocated in 407 the VPLS domain for an E-Tree. PW processing for the tagged PW will 408 be described in Section 5.3 of this document. 410 A raw mode PW (PW type 0x0005 in [RFC4448]) MAY also be used to 411 carry E-Tree service for a PW in Compatible mode as shown in Section 412 5.3.2. As defined in [RFC4448], for a raw mode PW, an Ethernet 413 frame's 802.1Q VLAN tag is not meaningful to the PEs and it passes 414 transparently through them. 416 5.2. VLAN Mapping 418 There are two ways of manipulating VLANs for an E-Tree in VPLS: 420 o Global VLAN based, that is, provisioning two global VLANs (Root 421 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 422 needed at all, or the VLAN mapping is done completely in the 423 Ethernet domains. 425 o Local VLAN based, that is, provisioning two local VLANs for each 426 PE (which participates in the E-Tree) in the VPLS network 427 independently. 429 The first method requires no VLAN mapping in the PW, but two unique 430 service delimiting VLANs must be allocated across the VPLS domain. 432 The second method is more scalable in the use of VLANs, but needs a 433 VLAN mapping mechanism in the PW similar to what is already 434 described in Section 4.3 of [RFC4448]. 436 Global or local VLANs can be manually configured or provisioned by 437 an Operational Support System. Alternatively, some automatic VLAN 438 allocation algorithm may be provided in the management plane, but it 439 is out of scope of this document. 441 For both methods, VLAN mapping parameters from a remote PE can be 442 provisioned or determined by a signaling protocol as described in 443 Section 6 when a PW is being established. 445 5.3. PW Processing 447 5.3.1.PW Processing in the VLAN Mapping Mode 449 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 450 inter-connected with a PW (For example, the scenario of Fig. 5 451 depicts the interconnection of two PEs attached with both root and 452 leaf nodes). 454 +----------------------------+ 455 | VPLS PE with T-VSI | 456 | | 457 +----+ | +------+ Root VLAN +-----+ | PW 458 |Root|------| VLAN |-----------|T-VSI|---------- 459 +----+ | | BRG | Leaf VLAN | |---------- 460 +----+ | | |-----------| |---------- 461 |Leaf|------| | | |-----+ 462 +----+ | +------+ +-----+ | | 463 | | | 464 +----------------------------+ | 465 | 466 +----------------------------+ | 467 | VPLS PE with T-VSI | | 468 | | | 469 +----+ | +------+ Root VLAN +-----+ | | PW 470 |Root|------| VLAN |-----------|T-VSI|-----+ 471 +----+ | | BRG | Leaf VLAN | |---------- 472 +----+ | | |-----------| |---------- 473 |Leaf|------| | | |---------- 474 +----+ | +------+ +-----+ | 475 | | 476 +----------------------------+ 477 Figure 5 T-VSI Interconnected in the Normal Mode 479 If a PE is in the VLAN mapping mode for a PW, then in the data plane 480 the PE MUST map the VLAN in each frame as follows: 482 o Upon transmitting frames on the PW, map from local VLAN to remote 483 VLAN (i.e., the local leaf VLAN in a frame is translated to the 484 remote leaf VLAN; the local root VLAN in a frame is translated to 485 the remote root VLAN). 487 o Upon receiving frames on the PW, map from remote VLAN to local 488 VLAN, and the frames are further forwarded or dropped in the egress 489 bridge module using the filtering mechanism as described in [802.1Q- 490 2011]. 492 The signaling for VLANs used by E-Tree is specified in Section 6. 494 5.3.2.PW Processing in the Compatible Mode 496 The new VPLS PE model can work in a traditional VPLS network 497 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS 498 PE with T-VSI can be attached with root and/or leaf nodes, while the 499 VPLS PE with a traditional VSI can only be attached with root nodes. 500 A raw PW SHOULD be used to connect them. 502 +------------------------+ 503 | VPLS PE with T-VSI | 504 | | 505 +----+ | +------+ +-----+ | PW 506 |Root|------| VLAN |-------|T-VSI|---------- 507 +----+ | | BRG | | |---------- 508 +----+ | | |-------| |---------- 509 |Leaf|------| | | |---------+ 510 +----+ | +------+ +-----+ | | 511 | | | 512 +------------------------+ | 513 | 514 +------------------------+ | 515 | VPLS PE with VSI | | 516 | | | 517 +----+ | +------+ +-----+ | PW | 518 |Root|------| VLAN |-------|VSI |---------+ 519 +----+ | | BRG | | |---------- 520 +----+ | | | | |---------- 521 |Root|------| | | |---------- 522 +----+ | +------+ +-----+ | 523 | | 524 +------------------------+ 526 Figure 6 T-VSI interconnected with Traditional VSI 528 If a PE is in the Compatible mode for a PW, then in the data plane 529 the PE MUST process the frame as follows: 531 o Upon transmitting frames on the PW, remove the root or leaf VLAN 532 in the frames. 534 o Upon receiving frames on the PW, add a VLAN tag with a value of 535 the local root VLAN to the frames. 537 5.3.3.PW Processing in the Optimized Mode 539 When two PEs (both have E-Tree capability) are inter-connected with 540 a PW and one of them (e.g., PE2) is attached with only leaf nodes, 541 as shown in the scenario of Fig. 7, its peer PE (e.g., PE1) should 542 then work in the optimized mode for this PW. In this case, PE1 543 should not send the frames originated from the local leaf VLAN to 544 PE2, i.e., these frames are dropped rather than transported over the 545 PW. The bandwidth efficiency of the VPLS can thus be improved. The 546 signaling for the PE attached with only leaf nodes is specified in 547 Section 6. 548 +------------------------+ 549 |VPLS PE with T-VSI (PE1)| 550 | | 551 +----+ | +------+ +-----+ | PW 552 |Root|------| VLAN |-------|T-VSI|---------- 553 +----+ | | BRG | | |---------- 554 +----+ | | |-------| |---------- 555 |Leaf|------| | | |---------+ 556 +----+ | +------+ +-----+ | | 557 | | | 558 +------------------------+ | 559 | 560 +------------------------+ | 561 |VPLS PE with T-VSI (PE2)| | 562 | | | 563 +----+ | +------+ +-----+ | PW | 564 |Leaf|------| VLAN |-------|T-VSI|---------+ 565 +----+ | | BRG | | |---------- 566 +----+ | | |-------| |---------- 567 |Leaf|------| | | |---------- 568 +----+ | +------+ +-----+ | 569 | | 570 +------------------------+ 572 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 574 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 575 SHOULD first operate as follows: 577 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 579 6. Signaling for E-Tree Support 581 6.1. LDP Extensions for E-Tree Support 583 In addition to the signaling procedures as specified in Section 584 5.3.3 of [RFC4447], this document specifies a new interface 585 parameter sub-TLV to provision an E-Tree service and negotiate the 586 VLAN mapping function, as follows: 588 0 1 2 3 589 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | E-Tree(0x1A) | Length=8 | Reserved |P|V| 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Root VLAN ID | Leaf VLAN ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 8 E-Tree Sub-TLV 597 Where: 599 o E-Tree is the sub-TLV identifier (0x1A) as assigned by IANA. 601 o Length is the length of the sub TLV in octets. 603 o Reserved bits MUST be set to zero on transmit and be ignored on 604 receive. 606 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 607 attached with only leaf nodes, and set to 0 otherwise. 609 o V is a bit indicating the sender's VLAN mapping capability. A PE 610 capable of VLAN mapping MUST set this bit, and clear it otherwise. 612 o Root VLAN ID is the value of the local root VLAN. 614 o Leaf VLAN ID is the value of the local leaf VLAN. 616 When setting up a PW for the E-Tree based VPLS, two peer PEs 617 negotiate the E-Tree support using the above E-Tree sub-TLV. Note PW 618 type of 0x0004 SHOULD be used during the PW negotiation. 620 A PE that wishes to support E-Tree service MUST include an E-Tree 621 Sub-TLV in its PW label mapping message and include its local root 622 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 623 capability MUST set the V bit to 1, and a PE attached with only leaf 624 nodes SHOULD set the P bit to 1. 626 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 627 from its peer PE, after saving the VLAN information for the PW, MUST 628 process it as follows: 630 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 631 Optimized-Mode to FALSE. 633 2) If either the root VLAN ID in the message is not equal to the 634 local root VLAN ID or the leaf VLAN ID in the message is not equal 635 to the local leaf VLAN ID { 637 If the bit V is cleared { 639 If the PE is capable of VLAN mapping, it MUST set VLAN- 640 Mapping-Mode to TRUE; 642 Else { 644 A label release message with the error code "E- 645 Tree VLAN mapping not supported" is sent to the 646 peer PE and exit the process; 648 } 650 } 652 If the bit V is set, and the PE is capable of VLAN mapping, 653 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 654 to TRUE; 656 } 658 3) If the P bit is set 660 { 662 If the PE is a leaf-only node itself, a label release message 663 with a status code "Leaf to Leaf PW released" is sent to the peer 664 PE and exit the process; 666 Else the PE SHOULD set the Optimized-Mode to TRUE. 668 } 670 A PE SHOULD send a Label Mapping message with an E-Tree Sub-TLV as 671 per Section 5.3.3 of [RFC4447]. A PE MUST send a Label Mapping 672 message with an updated E-Tree Sub-TLV to all other PEs over 673 corresponding LDP sessions when its role changes from leaf-only to 674 not leaf-only (i.e., when a root node is added to a PE attached with 675 only leaf nodes). 677 If a PE has sent a Label Mapping message with an E-Tree Sub-TLV but 678 does not receive any E-Tree Sub-TLV in its peer's PW label mapping 679 message, The PE SHOULD then establish a raw PW with this peer as in 680 traditional VPLS and set Compatible-Mode to TRUE for this PW. 682 Data plane processing for this PW is as following: 684 If Optimized-Mode is TRUE, then data plane processing as described 685 in Section 5.3.3 applies. 687 If VLAN-Mapping-Mode is TRUE, then data plane processing as 688 described in Section 5.3.1 applies. 690 If Compatible-Mode is TRUE, then data plane processing is as 691 described in Section 5.3.2. 693 PW processing as described in [RFC4448] proceeds as usual for all 694 cases. 696 6.2. BGP Extensions for E-Tree Support 698 A new E-Tree extended community (0x800b) is allocated by IANA for E- 699 Tree signaling in BGP VPLS: 701 +------------------------------------+ 702 | Extended community type (2 octets) | 703 +------------------------------------+ 704 | Root VLAN (2 octets) | 705 +------------------------------------+ 706 | Leaf VLAN (2 octets) | 707 +------------------------------------+ 708 | Reserved |P|V| 709 +------------------------------------+ 711 Figure 9 E-Tree Extended Community 713 Where: 715 o Root VLAN ID is the value of the local root VLAN. 717 o Leaf VLAN ID is the value of the local leaf VLAN. 719 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 720 on receive. 722 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 723 attached with only leaf nodes, and set to 0 otherwise. 725 o V is a bit indicating the sender's VLAN mapping capability. A PE 726 capable of VLAN mapping MUST set this bit, and clear it otherwise. 728 The PEs attached with both leaf and root nodes MUST support BGP E- 729 Tree signaling as described in this document, and SHOULD support 730 VLAN mapping in their data planes. The traditional PE attached with 731 only root nodes may also participate in an E-Tree service. If some 732 PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST 733 be provisioned for an E-Tree service. 735 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 736 Community as detailed in [RFC4761], an E-Tree Extended Community 737 MUST be further attached if a PE wishes to participate in an E-Tree 738 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 739 in the E-Tree Extended Community. A PE attached with only leaf nodes 740 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community 741 to 1. 743 A PE that receives a BGP UPDATE message with an E-Tree Extended 744 Community from its peer PE, after saving the VLAN information for 745 the PW, MUST process it as follows (after processing procedures as 746 specified in Section 3.2 of [RFC4761]): 748 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 749 Optimized-Mode to FALSE. 751 2) If either the root VLAN ID in the E-Tree Extended Community is 752 not equal to the local root VLAN ID or the leaf VLAN ID in the E- 753 Tree Extended Community is not equal to the local leaf VLAN ID { 755 If the bit V is cleared { 757 If the PE is capable of VLAN mapping, it MUST set VLAN- 758 Mapping-Mode to TRUE; 760 Else { 762 Log with a message "E-Tree VLAN mapping not 763 supported" and exit the process; 765 } 767 } 769 If the bit V is set, and the PE is capable of VLAN mapping, 770 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 771 to TRUE; 773 } 775 3) If the P bit is set { 777 If the PE is a leaf-only PE itself, forbids any traffic on the 778 PW; 780 Else the PE SHOULD set the Optimized-Mode to TRUE. 782 } 784 A PE which does not recognize this attribute SHALL ignore it 785 silently. If a PE has sent an E-Tree Extended Community but does not 786 receive any E-Tree Extended Community from its peer, the PE SHOULD 787 then establish a raw PW with this peer as in traditional VPLS, and 788 set Compatible-Mode to TRUE for this PW. 790 Data plane in the VPLS is the same as described in Section 4.2 of 791 [RFC4761], and data plane processing for a PW is the same as 792 described at the end of Section 6.1 in this document. 794 7. OAM Considerations 796 VPLS OAM requirements and framework as specified in [RFC6136] are 797 applicable to E-Tree, as both Ethernet OAM frames and data traffic 798 are transported over the same PW. 800 Ethernet OAM for E-Tree including both service OAM and segment OAM 801 frames SHALL undergo the same VLAN mapping as the data traffic; and 802 root VLAN SHOULD be applied to segment OAM frames so that they are 803 not filtered. 805 8. Applicability 807 The solution specified in this document is applicable to both LDP 808 VPLS [RFC4762] and BGP VPLS [RFC4761]. 810 This solution is applicable to both "VPLS Only" networks and VPLS 811 with Ethernet aggregation networks. 813 This solution is also applicable to PBB VPLS networks. 815 9. Security Considerations 817 Besides security considerations as described in [RFC4448], [RFC4761] 818 and [RFC4762], this solution prevents leaf to leaf communication in 819 the data plane of VPLS when its PEs are interconnected with PWs. In 820 this regard, security can be enhanced for customers with this 821 solution. 823 10. IANA Considerations 825 IANA allocated a value for E-Tree in the registry of Pseudowire 826 Interface Parameters Sub-TLV type. 828 Parameter ID Length Description 829 ======================================= 830 0x1A 8 E-Tree 832 IANA allocated two new LDP status codes from the registry of name 833 "STATUS CODE NAME SPACE". 835 Range/Value E Description 836 ------------- ----- ---------------------- 837 0x20000003 1 E-Tree VLAN mapping not supported 838 0x20000004 0 Leaf to Leaf PW released 840 IANA allocated a value for E-Tree in the registry of BGP Extended 841 Community. 843 Type Value Sub-Type Value Name 844 ========== ============== ============ 845 0x80 0x0b E-Tree Info 847 11. References 849 11.1. Normative References 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and Heron, 855 G., "Pseudowire Setup and Maintenance Using Label 856 Distribution Protocol (LDP)", RFC 4447, April 2006. 858 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and Heron,G., 859 "Encapsulation Methods for Transport of Ethernet over MPLS 860 Networks", RFC 4448, April 2006. 862 [RFC4761] Kompella, K., and Rekhter, Y., "Virtual Private LAN 863 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 864 RFC 4761, January 2007. 866 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 867 Services using LDP", RFC 4762, January 2007. 869 11.2. Informative References 871 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 872 Edge (PWE3) Architecture", RFC 3985, March 2005. 874 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 875 Virtual Private Networks (L2VPNs)", RFC 4664, September 876 2006. 878 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 879 Framework", RFC 6136, March 2011. 881 [RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Serbest, Y., 882 "Virtual Private LAN Service (VPLS) Interoperability with 883 Customer Edge (CE) Bridges", RFC 6246, June 2011. 885 [RFC7041] Balus, F., Sajassi, A., and Bitar, N., Extensions to VPLS 886 PE model for Provider Backbone Bridging, RFC 7041, 887 November 2013. 889 [RFC7152] Key, R., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. 890 Paul, "Requirements for Metro Ethernet Forum (MEF) 891 Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private 892 Network (L2VPN)", RFC 7152, March 2014. 894 [RFC7387] Key, R., Yong, L., DeLord, S., Jounay, F., and Jin, L., "A 895 Framework for Ethernet Tree (E-Tree) Service over a 896 Multiprotocol Label Switching (MPLS) Network", RFC 7387, 897 October 2014. 899 [802.1Q-2014] IEEE Std 802.1Q-2014, Bridges and Bridged Networks, 900 November 2014. 902 [MEF4] Metro Ethernet Forum, Metro Ethernet Network Architecture 903 Framework - Part 1: Generic Framework, Technical 904 Specification MEF 4, May 2004. 906 [MEF6.1] Metro Ethernet Forum, "Ethernet Services Definitions - 907 Phase 2", Technical Specification MEF 6.1, April 2008. 909 [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., 910 and L. Jin, "Framework and Requirements for Virtual 911 Private Multicast Service (VPMS)", Work in Progress, 912 draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012. 914 12. Acknowledgments 916 The authors would like to thank Stewart Bryant, Lizhong Jin and 917 Deborah Brungard for their detailed reviews and suggestions, thank 918 Adrian Farrel, Susan Hares and Shane Amante for their valuable 919 advices, thank Ben Mack-crane, Edwin Mallette, Donald Fedyk, Dave 920 Allan, Giles Heron, Raymond Key, Josh Rogers, Sam Cao and Daniel 921 Cohn for their valuable comments and discussions. 923 Appendix A. Other PE Models for E-Tree 925 A.1. A PE Model With a VSI and No bridge 927 If there is no bridge module in a PE, the PE may consist of Native 928 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 929 5 of [RFC3985]) where any transformation operation for VLANs (e.g., 930 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 931 VLAN or leaf VLAN can be added by the NSP depending on the User 932 Network Interface (UNI) type (root/leaf) associated with the AC over 933 which the packet arrives. 935 Further, when a packet with a leaf VLAN exits a forwarder and 936 arrives at the NSP, the NSP must drop the packet if the egress AC is 937 associated with a leaf UNI. 939 Tagged PW and VLAN mapping work in the same way as in the typical PE 940 model. 942 +----------------------------------------+ 943 | PE Device | 944 Multiple+----------------------------------------+ 945 AC | | | Single | PW Instance 946 <------>o NSP # + PW Instance X<----------> 947 | | | | 948 |------| VSI |----------------------| 949 | | | Single | PW Instance 950 <------>o NSP #Forwarder + PW Instance X<----------> 951 | | | | 952 |------| |----------------------| 953 | | | Single | PW Instance 954 <------>o NSP # + PW Instance X<----------> 955 | | | | 956 +----------------------------------------+ 958 Figure A.1 A PE model with a VSI and no bridge module 960 This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a 961 Hierarchical VPLS (H-VPLS) network, or a Network-facing PE (N-PE) in 962 an H-VPLS network with non-bridging edge devices, wherein a spoke PW 963 can be treated as an AC in this model. 965 A.2. A PE Model With external E-Tree interface 967 +----------------------------------------+ 968 | PE Device | 969 Root +----------------------------------------+ 970 VLAN | | Single | PW Instance 971 <------>o + PW Instance X<----------> 972 | | | 973 | VSI |----------------------| 974 | | Single | PW Instance 975 | Forwarder + PW Instance X<----------> 976 | | | 977 Leaf | |----------------------| 978 VLAN | | Single | PW Instance 979 <------>o + PW Instance X<----------> 980 | | | 981 +----------------------------------------+ 983 Figure A.2 A PE model with external E-Tree interface 985 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 986 are directly or indirectly over a single PW connected to a same VSI 987 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 988 insertion/removal or VLAN mapping, can be performed by some outer 989 equipments, and the PE may further translate these VLANs into its 990 own local VLANs. This PE model may be used by an N-PE in an H-VPLS 991 network with bridging-capable devices, or scenarios such as 992 providing E-Tree Network-to-Network interfaces. 994 Authors' Addresses 996 Yuanlong Jiang 997 Huawei Technologies Co., Ltd. 998 Bantian, Longgang district 999 Shenzhen 518129, China 1000 Email: jiangyuanlong@huawei.com 1002 Lucy Yong 1003 Huawei USA 1004 207 Estrella Xing 1005 Georgetown TX, USA 78628 1006 Email: lucyyong@huawei.com 1008 Manuel Paul 1009 Deutsche Telekom 1010 Winterfeldtstr. 21 1011 10781 Berlin, Germany 1012 Email: manuel.paul@telekom.de 1014 Frederic Jounay 1015 Orange CH 1016 4 rue caudray 1020 Renens, Switzerland 1017 Email: frederic.jounay@orange.ch 1019 Florin Balus 1020 Alcatel-Lucent 1021 701 E. Middlefield Road 1022 Mountain View, CA, USA 94043 1023 Email: florin.balus@alcatel-lucent.com 1025 Wim Henderickx 1026 Alcatel-Lucent 1027 Copernicuslaan 50 1028 2018 Antwerp, Belgium 1029 Email: wim.henderickx@alcatel-lucent.com 1031 Ali Sajassi 1032 Cisco 1033 170 West Tasman Drive 1034 San Jose, CA 95134, USA 1035 Email: sajassi@cisco.com