idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-08.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 (August 20, 2015) is 3170 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: February 2016 August 20, 2015 8 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 9 draft-ietf-l2vpn-vpls-pe-etree-08.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 February 20, 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 A generic Virtual Private LAN Service (VPLS) solution which uses 52 VLANs to indicate root or leaf traffic is specified for Ethernet- 53 Tree (E-Tree) services. A VPLS Provider Edge (PE) model is 54 illustrated as an example for the solution. In the solution, E-Tree 55 VPLS PEs are interconnected by PWs which carry the VLAN indicating 56 the E-Tree attribute, the MAC address based Ethernet forwarding 57 engine and the PW work in the same way as in RFC 4762 and RFC 4448 58 respectively. A signaling mechanism is further described for E-Tree 59 capability and VLAN mapping negotiation. 61 Table of Contents 63 1. Conventions used in this document ......................... 3 64 2. Terminology ............................................... 3 65 3. Introduction .............................................. 4 66 4. PE Model with E-Tree Support .............................. 5 67 4.1. Existing PE Models ..................................... 5 68 4.2. A New PE Model with E-Tree Support ..................... 8 69 5. PW for E-Tree Support ..................................... 9 70 5.1. PW Encapsulation ....................................... 9 71 5.2. VLAN Mapping ........................................... 9 72 5.3. PW Processing ......................................... 11 73 5.3.1. PW Processing in the VLAN Mapping Mode .......... 11 74 5.3.2. PW Processing in the Compatible Mode ............ 12 75 5.3.3. PW Processing in the Optimized Mode ............. 13 76 6. Signaling for E-Tree Support ............................. 14 77 6.1. LDP Extensions for E-Tree Support ..................... 14 78 6.2. BGP Extensions for E-Tree Support ..................... 16 79 7. OAM Considerations ....................................... 18 80 8. Applicability ............................................ 18 81 9. Security Considerations .................................. 19 82 10. IANA Considerations ...................................... 19 83 11. References ............................................... 19 84 11.1. Normative References ............................... 19 85 11.2. Informative References ............................. 20 86 12. Acknowledgments .......................................... 21 87 Appendix A. Other PE Models for E-Tree ........................ 22 88 A.1. A PE Model With a VSI and No bridge ................... 22 89 A.2. A PE Model With external E-Tree interface ............. 23 91 1. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Terminology 99 AC: Attachment Circuit 101 B-VLAN: Backbone VLAN 103 C-VLAN: Customer VLAN 105 E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in 106 [MEF6.1] 108 EVC: Ethernet Virtual Connection, as defined in [MEF4] 110 FIB: Forwarding Information Base, also known as forwarding table 112 I-SID: Backbone Service Instance Identifier, as defined in IEEE 113 802.1ah 115 Leaf AC: an AC attached with a leaf 117 Leaf VLAN: a VLAN Identifier (ID) used to indicate all the frames 118 that are originated at a leaf AC, it may be a C-VLAN, an S-VLAN or a 119 B-VLAN 121 OAM: Operations, Administration and Maintenance 123 PBB: Provider Backbone Bridge 125 PE: Provider Edge 127 PW: Pseudo Wire 129 Root AC: an AC attached with a root 131 Root VLAN: a VLAN ID used to indicate all the frames that are 132 originated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN 134 S-VLAN: Service VLAN 136 T-VSI: Tree VSI, a VSI with E-Tree support 138 VLAN: Virtual Local Area Network 139 VPLS: Virtual Private LAN Service 141 VSI: Virtual Switching Instance as defined in [RFC4664], also known 142 as VPLS Forwarder in [RFC7041] 144 3. Introduction 146 The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet 147 Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint 148 Ethernet Virtual Connection (EVC) service. It is a multipoint 149 Ethernet service with special restrictions: the Ethernet frames from 150 a root MAY be received by any other root or leaf, and the frames 151 from a leaf MAY be received by any root, but MUST NOT be received by 152 a leaf. Further, an E-Tree service MAY include multiple roots and 153 multiple leaves. Although Virtual Private Multicast Service (VPMS) 154 [VPMS] or Point-to-Multipoint (P2MP) multicast is a somewhat 155 simplified version of this service, in fact, they are both multicast 156 services and are different from an E-Tree service which may include 157 both unicast and multicast traffic. 159 [RFC7152] gives the requirements for providing E-Tree solutions in 160 the VPLS and the need to filter leaf-to-leaf traffic. [RFC7387] 161 further describes a Multiprotocol Label Switching (MPLS) framework 162 for providing E-Tree. Though there were proposals on using PW 163 control word or PWs to indicate the root/leaf attribute of an E-Tree 164 frame, both methods are limited in that they are only applicable to 165 "VPLS only" networks. 167 In fact, VPLS PE usually consists of a bridge module itself (see 168 [RFC4664] and [RFC6246]); moreover, E-Tree services may cross both 169 Ethernet and VPLS domains. Therefore, it is necessary to develop an 170 E-Tree solution both for "VPLS only" scenarios and for interworking 171 between Ethernet and VPLS. 173 IEEE 802.1 has incorporated the generic E-Tree solution in the 174 latest version of 802.1Q [802.1Q-2011], which is just an improvement 175 on the traditional asymmetric VLAN mechanism (the use of different 176 VLANs to indicate E-Tree root/leaf attributes and prohibiting leaf- 177 to-leaf traffic with the help of VLANs was first standardized in 178 IEEE 802.1Q-2003). In the new IEEE 802.1Q solution, VLANs are used 179 to indicate root/leaf attribute of a frame: one VLAN ID is used to 180 indicate the frames originated from the roots and another VLAN ID is 181 used to indicate the frames originated from the leaves. At a leaf 182 port, the bridge can then filter out all the frames from other leaf 183 ports based on the VLAN ID. It is better to reuse the same mechanism 184 in VPLS than to develop a new mechanism. The latter will introduce 185 more complexity to interwork with the new IEEE 802.1Q solution. 187 This document specifies how the Ethernet VLAN solution can be used 188 to support generic E-Tree services in VPLS. The solution specified 189 here is fully compatible with the IEEE bridge architecture and with 190 IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) technology, thus it 191 will not change the FIB (such as installing E-Tree attributes in the 192 FIB), or need any specially tailored implementation. Furthermore, 193 VPLS scalability and simplicity are also well kept. With this 194 mechanism, it is also convenient to deploy a converged E-Tree 195 service across both Ethernet and MPLS networks. 197 Firstly, a typical VPLS PE model is introduced as an example; the 198 model is then extended in which a Tree VSI is connected to a VLAN 199 bridge with a dual-VLAN interface. 201 This document then discusses the PW encapsulation and PW processing 202 such as VLAN mapping options for transporting E-Tree services in 203 VPLS. 205 Finally, it describes the signaling extensions and processing 206 procedures for E-Tree support in VPLS. 208 4. PE Model with E-Tree Support 210 The problem scenario of E-Tree as shown in Fig. 1 of [RFC7152] is a 211 simplification of the L2VPN architecture, several common VPLS PE 212 architectures are discussed in more details in [RFC4664] and 213 [RFC6246]. 215 Therefore, E-Tree solution in VPLS is demonstrated with the help of 216 a typical VPLS PE model. It can also be used in other PE models 217 which are discussed in Appendix A. 219 4.1. Existing PE Models 221 According to [RFC4664], there are at least three models possible for 222 a VPLS PE, including: 224 o A single bridge module, a single VSI; 226 o A single bridge module, multiple VSIs; 228 o Multiple bridge modules, each attaches to a VSI. 230 The second PE model is commonly used. A typical example is further 231 depicted in Fig. 1 and Fig. 2 (both figures are extracted from 233 [RFC6246]), where an S-VLAN bridge module is connected to multiple 234 VSIs each with a single VLAN virtual interface. 236 +-------------------------------+ 237 | 802.1ad Bridge Module Model | 238 | | 239 +---+ AC | +------+ +-----------+ | 240 |CE |---------|C-VLAN|------| | | 241 +---+ | |bridge|------| | | 242 | +------+ | | | 243 | o | S-VLAN | | 244 | o | | | ---> to VSI 245 | o | Bridge | | 246 +---+ AC | +------+ | | | 247 |CE |---------|C-VLAN|------| | | 248 +---+ | |bridge|------| | | 249 | +------+ +-----------+ | 250 +-------------------------------+ 252 Figure 1 A model of 802.1ad Bridge Module 254 +----------------------------------------+ 255 | VPLS-capable PE model | 256 | +---------------+ +------+ | 257 | | | |VSI-1 |------------ 258 | | |==========| |------------ PWs 259 | | Bridge ------------ |------------ 260 | | | S-VLAN-1 +------+ | 261 | | Module | o | 262 | | | o | 263 | | (802.1ad | o | 264 | | bridge) | o | 265 | | | o | 266 | | | S-VLAN-n +------+ | 267 | | ------------VSI-n |------------- 268 | | |==========| |------------- PWs 269 | | | ^ | |------------- 270 | +---------------+ | +------+ | 271 | | | 272 +-------------------------|--------------+ 273 LAN emulation Interface 275 Figure 2 A VPLS-capable PE Model 277 In this PE model, Ethernet frames from Customer Edges (CEs) will 278 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 279 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 281 Therefore, the association between an AC port and a PW on a VSI is 282 difficult. 284 This model could be further enhanced: When Ethernet frames arrive at 285 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 286 the root VLAN tag are transmitted both to the roots and the leaves, 287 while the frames with the leaf VLAN tag are transmitted to the roots 288 but dropped for the leaves (these VLAN tags are removed before the 289 frames are transmitted over the wire). It was demonstrated in 290 [802.1Q-2011] that the E-Tree service in Ethernet networks can be 291 well supported with this mechanism. 293 Assuming this mechanism is implemented in the bridge module, it is 294 quite straightforward to infer a VPLS PE model with two VSIs to 295 support the E-Tree (as shown in Fig. 3). But this model will require 296 two VSIs per PE and two sets of PWs per E-Tree service, which is 297 poorly scalable in a large MPLS/VPLS network; in addition, both 298 these VSIs have to share their learned MAC addresses. 300 +----------------------------------------+ 301 | VPLS-capable PE model | 302 | +---------------+ +------+ | 303 | | | |VSI-1 |------------ 304 | | |==========| |------------ PWs 305 | | Bridge ------------ |------------ 306 | | | Root +------+ | 307 | | Module | S-VLAN | 308 | | | | 309 | | (802.1ad | | 310 | | bridge) | | 311 | | | Leaf | 312 | | | S-VLAN +------+ | 313 | | ------------VSI-2 |------------- 314 | | |==========| |------------- PWs 315 | | | ^ | |------------- 316 | +---------------+ | +------+ | 317 | | | 318 +-------------------------|--------------+ 319 LAN emulation Interface 321 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 323 4.2. A New PE Model with E-Tree Support 325 In order to support the E-Tree in a more scalable way, a new VPLS PE 326 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 327 specified. As depicted in Fig. 4, the bridge module is connected to 328 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 329 VLAN and the leaf VLAN are connected to the same T-VSI, and they 330 share the same FIB and work in shared VLAN learning. In this way, 331 only one VPLS instance and one set of PWs is needed per E-Tree 332 service, and the scalability of VPLS is improved. 334 +----------------------------------------+ 335 | VPLS-capable PE model | 336 | +---------------+ +------+ | 337 | | |==========|TVSI-1|------------ 338 +---+AC | | ------------ |------------ PWs 339 |CE |-------| Bridge ------------ |------------ 340 +---+ | | | Root & +------+ | 341 | | Module | Leaf VLAN o | 342 | | | o | 343 | | | o | 344 | | | o | 345 | | | o | 346 +---+AC | | | VLAN-n +------+ | 347 |CE |-------| ------------VSI-n |------------- 348 +---+ | | |==========| |------------- PWs 349 | | | ^ | |------------- 350 | +---------------+ | +------+ | 351 | | | 352 +-------------------------|--------------+ 353 LAN emulation Interface 355 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 357 For an untagged port (frames over this port are untagged) or VLAN- 358 unaware port (VLAN tags in the frames are ignored), when the bridge 359 module is a C-VLAN bridge, the Ethernet frames received from the 360 root ACs SHOULD be tagged with a root C-VLAN; when the bridge module 361 is an 802.1ad bridge, the Ethernet frames received from the root ACs 362 SHOULD be tagged with a root S-VLAN (it can be added with a root C- 363 VLAN firstly in a C-VLAN bridge but this is out of the scope of this 364 document). 366 For a C-VLAN tagged port, the Ethernet frames received from the root 367 ACs SHOULD be added with a root S-VLAN. 369 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 370 received from the root ACs SHOULD be translated to the root S-VLAN 371 in the VPLS network domain. Alternatively, the PBB VPLS PE model 372 (where an IEEE 802.1ah bridge module is embedded in the PE) as 373 described in [RFC7041] MAY be used, and a root B-VLAN or leaf B-VLAN 374 MAY be added in this case (the E-Tree attribute may also be 375 indicated with two I-SID tags in the bridge module, and the frames 376 are further encapsulated and transported transparently over a single 377 B-VLAN, thus the PBB VPLS works just in the same way as described in 378 [RFC7041] and will be discussed no more in this document). When many 379 S-VLANs are multiplexed in a single AC, the 2nd option has an 380 advantage of both VLAN scalability and MAC address scalability. 382 In a similar way, the traffic from the leaf ACs is tagged and 383 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 385 In all cases, the outermost VLAN in the resulted Ethernet header is 386 used to indicate the E-Tree attribute of an Ethernet frame; this 387 document uses VLAN to refer to this outermost VLAN for simplicity in 388 the latter sections. 390 5. PW for E-Tree Support 392 5.1. PW Encapsulation 394 To support an E-Tree service, T-VSIs in a VPLS MUST be 395 interconnected with a bidirectional Ethernet PW. The Ethernet PW 396 SHOULD work in the tagged mode (PW type 0x0004) as described in 397 [RFC4448], in which case a VLAN tag MUST be carried in each frame in 398 the PW to indicate the frame originated from either root or leaf 399 (the VLAN tag indicating the frame originated from either root or 400 leaf can be translated by a bridge module in the PE or added by an 401 outside Ethernet edge device, even by a customer device). In the 402 tagged PW mode, two service delimiting VLANs MUST be allocated in 403 the VPLS domain for an E-Tree. PW processing for the tagged PW will 404 be described in Section 5.3 of this document. 406 Raw PW (PW type 0x0005 in [RFC4448]) MAY also be used to carry E- 407 Tree service for a PW in Compatible mode as shown in Section 5.3.2. 409 5.2. VLAN Mapping 411 There are two ways of manipulating VLANs for an E-Tree in VPLS: 413 o Global VLAN based, that is, provisioning two global VLANs (Root 414 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 415 needed at all, or the VLAN mapping is done completely in the 416 Ethernet domains. 418 o Local VLAN based, that is, provisioning two local VLANs for each 419 PE (which participates in the E-Tree) in the VPLS network 420 independently. 422 The first method requires no VLAN mapping in the PW, but two unique 423 service delimiting VLANs must be allocated across the VPLS domain. 425 The second method is more scalable in the use of VLANs, but needs a 426 VLAN mapping mechanism in the PW similar to what is already 427 described in Section 4.3 of [RFC4448]. 429 Global or local VLANs can be manually configured or provisioned by 430 an Operational Support System. Alternatively, some automatic VLAN 431 allocation algorithm may be provided in the management plane, but it 432 is out scope of this document. 434 For both methods, VLAN mapping parameters from a remote PE can be 435 provisioned or determined by a signaling protocol as described in 436 Section 6 when a PW is being established. 438 5.3. PW Processing 440 5.3.1.PW Processing in the VLAN Mapping Mode 442 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 443 inter-connected with a PW (For example, the scenario of Fig. 5 444 depicts the interconnection of two PEs miscellaneously attached with 445 both root and leaf nodes). 447 +----------------------------+ 448 | VPLS PE with T-VSI | 449 | | 450 +----+ | +------+ Root VLAN +-----+ | PW 451 |Root|------| VLAN |-----------|T-VSI|---------- 452 +----+ | | BRG | Leaf VLAN | |---------- 453 +----+ | | |-----------| |---------- 454 |Leaf|------| | | |-----+ 455 +----+ | +------+ +-----+ | | 456 | | | 457 +----------------------------+ | 458 | 459 +----------------------------+ | 460 | VPLS PE with T-VSI | | 461 | | | 462 +----+ | +------+ Root VLAN +-----+ | | PW 463 |Root|------| VLAN |-----------|T-VSI|-----+ 464 +----+ | | BRG | Leaf VLAN | |---------- 465 +----+ | | |-----------| |---------- 466 |Leaf|------| | | |---------- 467 +----+ | +------+ +-----+ | 468 | | 469 +----------------------------+ 470 Figure 5 T-VSI Interconnected in the Normal Mode 472 If a PE is in the VLAN mapping mode for a PW, then in the data plane 473 the PE MUST map the VLAN in each frame as follows: 475 o Upon transmitting frames on the PW, map from local VLAN to remote 476 VLAN (i.e., the local leaf VLAN in a frame is translated to the 477 remote leaf VLAN; the local root VLAN in a frame is translated to 478 the remote root VLAN). 480 o Upon receiving frames on the PW, map from remote VLAN to local 481 VLAN, and the frames are further forwarded or dropped in the egress 482 bridge module using the filtering mechanism as described in [802.1Q- 483 2011]. 485 The signaling for VLANs used by E-Tree is specified in Section 6. 487 5.3.2.PW Processing in the Compatible Mode 489 The new VPLS PE model can work in a traditional VPLS network 490 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS 491 PE with T-VSI can be attached with root and/or leaf nodes, while the 492 VPLS PE with a traditional VSI can only be attached with root nodes. 493 A raw PW SHOULD be used to connect them. 495 +------------------------+ 496 | VPLS PE with T-VSI | 497 | | 498 +----+ | +------+ +-----+ | PW 499 |Root|------| VLAN |-------|T-VSI|---------- 500 +----+ | | BRG | | |---------- 501 +----+ | | |-------| |---------- 502 |Leaf|------| | | |---------+ 503 +----+ | +------+ +-----+ | | 504 | | | 505 +------------------------+ | 506 | 507 +------------------------+ | 508 | VPLS PE with VSI | | 509 | | | 510 +----+ | +------+ +-----+ | PW | 511 |Root|------| VLAN |-------|VSI |---------+ 512 +----+ | | BRG | | |---------- 513 +----+ | | | | |---------- 514 |Root|------| | | |---------- 515 +----+ | +------+ +-----+ | 516 | | 517 +------------------------+ 519 Figure 6 T-VSI interconnected with Traditional VSI 521 If a PE is in the Compatible mode for a PW, then in the data plane 522 the PE MUST process the frame as follows: 524 o Upon transmitting frames on the PW, remove the root or leaf VLAN 525 in the frames. 527 o Upon receiving frames on the PW, add a VLAN tag with a value of 528 the local root VLAN to the frames. 530 5.3.3.PW Processing in the Optimized Mode 532 When two PEs (both have E-Tree capability) are inter-connected with 533 a PW and one of them (e.g., PE2) is attached with only leaf nodes, 534 as shown in the scenario of Fig. 7, its peer PE (e.g., PE1) should 535 then work in the optimized mode for this PW. In this case, PE1 536 should not send the frames originated from the local leaf VLAN to 537 PE2, i.e., these frames are dropped rather than transported over the 538 PW. The bandwidth efficiency of the VPLS can thus be improved. The 539 signaling for the PE attached with only leaf nodes is specified in 540 Section 6. 541 +------------------------+ 542 |VPLS PE with T-VSI (PE1)| 543 | | 544 +----+ | +------+ +-----+ | PW 545 |Root|------| VLAN |-------|T-VSI|---------- 546 +----+ | | BRG | | |---------- 547 +----+ | | |-------| |---------- 548 |Leaf|------| | | |---------+ 549 +----+ | +------+ +-----+ | | 550 | | | 551 +------------------------+ | 552 | 553 +------------------------+ | 554 |VPLS PE with T-VSI (PE2)| | 555 | | | 556 +----+ | +------+ +-----+ | PW | 557 |Leaf|------| VLAN |-------|T-VSI|---------+ 558 +----+ | | BRG | | |---------- 559 +----+ | | |-------| |---------- 560 |Leaf|------| | | |---------- 561 +----+ | +------+ +-----+ | 562 | | 563 +------------------------+ 565 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 567 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 568 SHOULD first operate as follows: 570 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 572 6. Signaling for E-Tree Support 574 6.1. LDP Extensions for E-Tree Support 576 In addition to the signaling procedures as specified in [RFC4447], 577 this document specifies a new interface parameter sub-TLV to 578 provision an E-Tree service and negotiate the VLAN mapping function, 579 as follows: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | E-Tree(0x1A) | Length=8 | Reserved |P|V| 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Root VLAN ID | Leaf VLAN ID | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 8 E-Tree Sub-TLV 590 Where: 592 o E-Tree is the sub-TLV identifier (0x1A) as assigned by IANA. 594 o Length is the length of the sub TLV in octets. 596 o Reserved bits MUST be set to zero on transmit and be ignored on 597 receive. 599 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 600 attached with only leaf nodes, and set to 0 otherwise. 602 o V is a bit indicating the sender's VLAN mapping capability. A PE 603 capable of VLAN mapping MUST set this bit, and clear it otherwise. 605 o Root VLAN ID is the value of the local root VLAN. 607 o Leaf VLAN ID is the value of the local leaf VLAN. 609 When setting up a PW for the E-Tree based VPLS, two peer PEs 610 negotiate the E-Tree support using the above E-Tree sub-TLV. Note PW 611 type of 0x0004 SHOULD be used during the PW negotiation. 613 A PE that wishes to support E-Tree service MUST include an E-Tree 614 Sub-TLV in its PW label mapping message and include its local root 615 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 616 capability MUST set the V bit to 1, and a PE is attached with only 617 leaf nodes SHOULD set the P bit to 1. 619 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 620 from its peer PE, after saving the VLAN information for the PW, MUST 621 process it as follows: 623 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 624 Optimized-Mode to FALSE. 626 2) If either the root VLAN ID in the message is not equal to the 627 local root VLAN ID or the leaf VLAN ID in the message is not equal 628 to the local leaf VLAN ID { 630 If the bit V is cleared { 632 If the PE is capable of VLAN mapping, it MUST set VLAN- 633 Mapping-Mode to TRUE; 635 Else { 637 A label release message with the error code "E- 638 Tree VLAN mapping not supported" is sent to the 639 peer PE and exit the process; 641 } 643 } 645 If the bit V is set, and the PE is capable of VLAN mapping, 646 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 647 to TRUE; 649 } 651 3) If the P bit is set 653 { 655 If the PE is a leaf-only node itself, a label release message 656 with a status code "Leaf to Leaf PW released" is sent to the peer 657 PE and exit the process; 659 Else the PE SHOULD set the Optimized-Mode to TRUE. 661 } 663 A PE SHOULD send a Label Mapping message with an E-Tree Sub-TLV as 664 per Section 5.3.3 of RFC 4447. A PE MUST send a Label Mapping 665 message with an updated E-Tree Sub-TLV to all other PEs over 666 corresponding LDP sessions when its role changes from leaf-only to 667 not leaf-only (i.e., when a root node is added to a PE attached with 668 only leaf nodes). 670 If a PE has sent a Label Mapping message with an E-Tree Sub-TLV but 671 does not receive any E-Tree Sub-TLV in its peer's PW label mapping 672 message, The PE SHOULD then establish a raw PW with this peer as in 673 traditional VPLS and set Compatible-Mode to TRUE for this PW. 675 Data plane processing for this PW is as following: 677 If Optimized-Mode is TRUE, then data plane processing as described 678 in Section 5.3.3 applies. 680 If VLAN-Mapping-Mode is TRUE, then data plane processing as 681 described in Section 5.3.1 applies. 683 If Compatible-Mode is TRUE, then data plane processing is as 684 described in Section 5.3.2. 686 PW processing as described in [RFC4448] proceeds as usual for all 687 cases. 689 6.2. BGP Extensions for E-Tree Support 691 A new E-Tree extended community (0x800b) is allocated by IANA for E- 692 Tree signaling in BGP VPLS: 694 +------------------------------------+ 695 | Extended community type (2 octets) | 696 +------------------------------------+ 697 | Root VLAN (2 octets) | 698 +------------------------------------+ 699 | Leaf VLAN (2 octets) | 700 +------------------------------------+ 701 | Reserved |P|V| 702 +------------------------------------+ 704 Figure 9 E-Tree Extended Community 706 Where: 708 o Root VLAN ID is the value of the local root VLAN. 710 o Leaf VLAN ID is the value of the local leaf VLAN. 712 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 713 on receive. 715 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 716 attached with only leaf nodes, and set to 0 otherwise. 718 o V is a bit indicating the sender's VLAN mapping capability. A PE 719 capable of VLAN mapping MUST set this bit, and clear it otherwise. 721 The PEs attached with both leaf and root nodes MUST support BGP E- 722 Tree signaling as described in this document, and SHOULD support 723 VLAN mapping in their data planes. The traditional PE attached with 724 only root nodes may also participate in an E-Tree service. If some 725 PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST 726 be provisioned for an E-Tree service. 728 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 729 Community as detailed in [RFC4761], an E-Tree Extended Community 730 MUST be further attached if a PE wishes to participate in an E-Tree 731 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 732 in the E-Tree Extended Community. A PE attached with only leaf nodes 733 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community 734 to 1. 736 A PE that receives a BGP UPDATE message with an E-Tree Extended 737 Community from its peer PE, after saving the VLAN information for 738 the PW, MUST process it as follows (after processing procedures as 739 specified in Section 3.2 of [RFC4761]): 741 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 742 Optimized-Mode to FALSE. 744 2) If either the root VLAN ID in the E-Tree Extended Community is 745 not equal to the local root VLAN ID or the leaf VLAN ID in the E- 746 Tree Extended Community is not equal to the local leaf VLAN ID { 748 If the bit V is cleared { 750 If the PE is capable of VLAN mapping, it MUST set VLAN- 751 Mapping-Mode to TRUE; 753 Else { 755 Log with a message "E-Tree VLAN mapping not 756 supported" and exit the process; 758 } 760 } 762 If the bit V is set, and the PE is capable of VLAN mapping, 763 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 764 to TRUE; 766 } 768 3) If the P bit is set { 770 If the PE is a leaf-only PE itself, forbids any traffic on the 771 PW; 773 Else the PE SHOULD set the Optimized-Mode to TRUE. 775 } 777 A PE which does not recognize this attribute SHALL ignore it 778 silently. If a PE has sent an E-Tree Extended Community but does not 779 receive any E-Tree Extended Community from its peer, the PE SHOULD 780 then establish a raw PW with this peer as in traditional VPLS, and 781 set Compatible-Mode to TRUE for this PW. 783 Data plane in the VPLS is the same as described in Section 4.2 of 784 [RFC4761], and data plane processing for a PW is the same as 785 described at the end of Section 6.1 in this document. 787 7. OAM Considerations 789 VPLS OAM requirements and framework as specified in [RFC6136] are 790 applicable to E-Tree, as both Ethernet OAM frames and data traffic 791 are transported over the same PW. 793 Ethernet OAM for E-Tree including both service OAM and segment OAM 794 frames SHALL undergo the same VLAN mapping as the data traffic; and 795 root VLAN SHOULD be applied to segment OAM frames so that they are 796 not filtered. 798 8. Applicability 800 The solution specified in this document is applicable to both LDP 801 VPLS [RFC4762] and BGP VPLS [RFC4761]. 803 This solution is applicable to both "VPLS Only" networks and VPLS 804 with Ethernet aggregation networks. 806 This solution is also applicable to PBB VPLS networks. 808 9. Security Considerations 810 Besides security considerations as described in [RFC4448], [RFC4761] 811 and [RFC4762], this solution prevents leaf to leaf communication in 812 the data plane of VPLS when its PEs are interconnected with PWs. In 813 this regard, security can be enhanced for customers with this 814 solution. 816 10. IANA Considerations 818 IANA allocated a value for E-Tree in the registry of Pseudowire 819 Interface Parameters Sub-TLV type. 821 Parameter ID Length Description 822 ======================================= 823 0x1A 8 E-Tree 825 IANA allocated two new LDP status codes from the registry of name 826 "STATUS CODE NAME SPACE". 828 Range/Value E Description 829 ------------- ----- ---------------------- 830 0x20000003 1 E-Tree VLAN mapping not supported 831 0x20000004 0 Leaf to Leaf PW released 833 IANA allocated a value for E-Tree in the registry of BGP Extended 834 Community. 836 Type Value Sub-Type Value Name 837 ========== ============== ============ 838 0x80 0x0b E-Tree Info 840 11. References 842 11.1. Normative References 844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 845 Requirement Levels", BCP 14, RFC 2119, March 1997. 847 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and Heron, 848 G., "Pseudowire Setup and Maintenance Using Label 849 Distribution Protocol (LDP)", RFC 4447, April 2006. 851 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and Heron,G., 852 "Encapsulation Methods for Transport of Ethernet over MPLS 853 Networks", RFC 4448, April 2006. 855 [RFC4761] Kompella, K., and Rekhter, Y., "Virtual Private LAN 856 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 857 RFC 4761, January 2007. 859 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 860 Services using LDP", RFC 4762, January 2007. 862 11.2. Informative References 864 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 865 Edge (PWE3) Architecture", RFC 3985, March 2005. 867 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 868 Virtual Private Networks (L2VPNs)", RFC 4664, September 869 2006. 871 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 872 Framework", RFC 6136, March 2011. 874 [RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Serbest, Y., 875 "Virtual Private LAN Service (VPLS) Interoperability with 876 Customer Edge (CE) Bridges", RFC 6246, June 2011. 878 [RFC7041] Balus, F., Sajassi, A., and Bitar, N., Extensions to VPLS 879 PE model for Provider Backbone Bridging, RFC 7041, 880 November 2013. 882 [RFC7152] Key, R., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. 883 Paul, "Requirements for Metro Ethernet Forum (MEF) 884 Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private 885 Network (L2VPN)", RFC 7152, March 2014. 887 [RFC7387] Key, R., Yong, L., DeLord, S., Jounay, F., and Jin, L., "A 888 Framework for Ethernet Tree (E-Tree) Service over a 889 Multiprotocol Label Switching (MPLS) Network", RFC 7387, 890 October 2014. 892 [802.1Q-2011] IEEE 802.1Q, Media Access Control (MAC) Bridges and 893 Virtual Bridge Local Area Networks, August 2011. 895 [MEF4] Metro Ethernet Forum, Metro Ethernet Network Architecture 896 Framework - Part 1: Generic Framework, Technical 897 Specification MEF 4, May 2004. 899 [MEF6.1] Metro Ethernet Forum, "Ethernet Services Definitions - 900 Phase 2", Technical Specification MEF 6.1, April 2008. 902 [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., 903 and L. Jin, "Framework and Requirements for Virtual 904 Private Multicast Service (VPMS)", Work in Progress, 905 draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012. 907 12. Acknowledgments 909 The authors would like to thank Stewart Bryant for his detailed 910 review and suggestions, thank Adrian Farrel, Susan Hares and Shane 911 Amante for their valuable advices, thank Ben Mack-crane, Edwin 912 Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh 913 Rogers, Sam Cao and Daniel Cohn for their valuable comments and 914 discussions. 916 Appendix A. Other PE Models for E-Tree 918 A.1. A PE Model With a VSI and No bridge 920 If there is no bridge module in a PE, the PE may consist of Native 921 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 922 5 of [RFC3985]) where any transformation operation for VLANs (e.g., 923 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 924 VLAN or leaf VLAN can be added by the NSP depending on the User 925 Network Interface (UNI) type (root/leaf) associated with the AC over 926 which the packet arrives. 928 Further, when a packet with a leaf VLAN exits a forwarder and 929 arrives at the NSP, the NSP must drop the packet if the egress AC is 930 associated with a leaf UNI. 932 Tagged PW and VLAN mapping work in the same way as in the typical PE 933 model. 935 +----------------------------------------+ 936 | PE Device | 937 Multiple+----------------------------------------+ 938 AC | | | Single | PW Instance 939 <------>o NSP # + PW Instance X<----------> 940 | | | | 941 |------| VSI |----------------------| 942 | | | Single | PW Instance 943 <------>o NSP #Forwarder + PW Instance X<----------> 944 | | | | 945 |------| |----------------------| 946 | | | Single | PW Instance 947 <------>o NSP # + PW Instance X<----------> 948 | | | | 949 +----------------------------------------+ 951 Figure A.1 A PE model with a VSI and no bridge module 953 This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a 954 Hierarchical VPLS (H-VPLS) network, or a Network-facing PE (N-PE) in 955 an H-VPLS network with non-bridging edge devices, wherein a spoke PW 956 can be treated as an AC in this model. 958 A.2. A PE Model With external E-Tree interface 960 +----------------------------------------+ 961 | PE Device | 962 Root +----------------------------------------+ 963 VLAN | | Single | PW Instance 964 <------>o + PW Instance X<----------> 965 | | | 966 | VSI |----------------------| 967 | | Single | PW Instance 968 | Forwarder + PW Instance X<----------> 969 | | | 970 Leaf | |----------------------| 971 VLAN | | Single | PW Instance 972 <------>o + PW Instance X<----------> 973 | | | 974 +----------------------------------------+ 976 Figure A.2 A PE model with external E-Tree interface 978 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 979 are directly or indirectly over a single PW connected to a same VSI 980 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 981 insertion/removal or VLAN mapping, can be performed by some outer 982 equipments, and the PE may further translate these VLANs into its 983 own local VLANs. This PE model may be used by an N-PE in an H-VPLS 984 network with bridging-capable devices, or scenarios such as 985 providing E-Tree Network-to-Network interfaces. 987 Authors' Addresses 989 Yuanlong Jiang 990 Huawei Technologies Co., Ltd. 991 Bantian, Longgang district 992 Shenzhen 518129, China 993 Email: jiangyuanlong@huawei.com 995 Lucy Yong 996 Huawei USA 997 207 Estrella Xing 998 Georgetown TX, USA 78628 999 Email: lucyyong@huawei.com 1001 Manuel Paul 1002 Deutsche Telekom 1003 Winterfeldtstr. 21 1004 10781 Berlin, Germany 1005 Email: manuel.paul@telekom.de 1007 Frederic Jounay 1008 Orange CH 1009 4 rue caudray 1020 Renens, Switzerland 1010 Email: frederic.jounay@orange.ch 1012 Florin Balus 1013 Alcatel-Lucent 1014 701 E. Middlefield Road 1015 Mountain View, CA, USA 94043 1016 Email: florin.balus@alcatel-lucent.com 1018 Wim Henderickx 1019 Alcatel-Lucent 1020 Copernicuslaan 50 1021 2018 Antwerp, Belgium 1022 Email: wim.henderickx@alcatel-lucent.com 1024 Ali Sajassi 1025 Cisco 1026 170 West Tasman Drive 1027 San Jose, CA 95134, USA 1028 Email: sajassi@cisco.com