idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-10.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 (November 10, 2015) is 3090 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: May 2016 November 10, 2015 8 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 9 draft-ietf-l2vpn-vpls-pe-etree-10.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 May 10, 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 ............................................ 19 82 9. Security Considerations .................................. 19 83 10. IANA Considerations ...................................... 19 84 11. References ............................................... 20 85 11.1. Normative References ............................... 20 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 When VPLS is set up using PWid FEC Element (see Appendix A of 697 [RFC4762]), its E-Tree signaling is similar to the above process. 698 Dynamic re-configuration of E-Tree should be avoided for this case, 699 however, when re-configuration of E-Tree is forced on a PE for some 700 reason (e.g., a configuration error), the PE may close the LDP 701 sessions with its peer PEs for this VPLS instance, and re-install 702 its PW labels, so that its peer PEs can send out the LDP label 703 mapping messages again. 705 6.2. BGP Extensions for E-Tree Support 707 A new E-Tree extended community (0x800b) is allocated by IANA for E- 708 Tree signaling in BGP VPLS: 710 +------------------------------------+ 711 | Extended community type (2 octets) | 712 +------------------------------------+ 713 | Root VLAN (2 octets) | 714 +------------------------------------+ 715 | Leaf VLAN (2 octets) | 716 +------------------------------------+ 717 | Reserved |P|V| 718 +------------------------------------+ 720 Figure 9 E-Tree Extended Community 722 Where: 724 o Root VLAN ID is the value of the local root VLAN. 726 o Leaf VLAN ID is the value of the local leaf VLAN. 728 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 729 on receive. 731 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 732 attached with only leaf nodes, and set to 0 otherwise. 734 o V is a bit indicating the sender's VLAN mapping capability. A PE 735 capable of VLAN mapping MUST set this bit, and clear it otherwise. 737 The PEs attached with both leaf and root nodes MUST support BGP E- 738 Tree signaling as described in this document, and SHOULD support 739 VLAN mapping in their data planes. The traditional PE attached with 740 only root nodes may also participate in an E-Tree service. If some 741 PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST 742 be provisioned for an E-Tree service. 744 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 745 Community as detailed in [RFC4761], an E-Tree Extended Community 746 MUST be further attached if a PE wishes to participate in an E-Tree 747 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 748 in the E-Tree Extended Community. A PE attached with only leaf nodes 749 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community 750 to 1. 752 A PE that receives a BGP UPDATE message with an E-Tree Extended 753 Community from its peer PE, after saving the VLAN information for 754 the PW, MUST process it as follows (after processing procedures as 755 specified in Section 3.2 of [RFC4761]): 757 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 758 Optimized-Mode to FALSE. 760 2) If either the root VLAN ID in the E-Tree Extended Community is 761 not equal to the local root VLAN ID or the leaf VLAN ID in the E- 762 Tree Extended Community is not equal to the local leaf VLAN ID { 764 If the bit V is cleared { 766 If the PE is capable of VLAN mapping, it MUST set VLAN- 767 Mapping-Mode to TRUE; 768 Else { 770 Log with a message "E-Tree VLAN mapping not 771 supported" and exit the process; 773 } 775 } 777 If the bit V is set, and the PE is capable of VLAN mapping, 778 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 779 to TRUE; 781 } 783 3) If the P bit is set { 785 If the PE is a leaf-only PE itself, forbids any traffic on the 786 PW; 788 Else the PE SHOULD set the Optimized-Mode to TRUE. 790 } 792 A PE which does not recognize this attribute SHALL ignore it 793 silently. If a PE has sent an E-Tree Extended Community but does not 794 receive any E-Tree Extended Community from its peer, the PE SHOULD 795 then establish a raw PW with this peer as in traditional VPLS, and 796 set Compatible-Mode to TRUE for this PW. 798 Data plane in the VPLS is the same as described in Section 4.2 of 799 [RFC4761], and data plane processing for a PW is the same as 800 described at the end of Section 6.1 in this document. 802 7. OAM Considerations 804 VPLS OAM requirements and framework as specified in [RFC6136] are 805 applicable to E-Tree, as both Ethernet OAM frames and data traffic 806 are transported over the same PW. 808 Ethernet OAM for E-Tree including both service OAM and segment OAM 809 frames SHALL undergo the same VLAN mapping as the data traffic; and 810 root VLAN SHOULD be applied to segment OAM frames so that they are 811 not filtered. 813 8. Applicability 815 The solution specified in this document is applicable to both LDP 816 VPLS [RFC4762] and BGP VPLS [RFC4761]. 818 This solution is applicable to both "VPLS Only" networks and VPLS 819 with Ethernet aggregation networks. 821 This solution is also applicable to PBB VPLS networks. 823 9. Security Considerations 825 Besides security considerations as described in [RFC4448], [RFC4761] 826 and [RFC4762], this solution prevents leaf to leaf communication in 827 the data plane of VPLS when its PEs are interconnected with PWs. In 828 this regard, security can be enhanced for customers with this 829 solution. 831 10. IANA Considerations 833 IANA allocated a value for E-Tree in the registry of Pseudowire 834 Interface Parameters Sub-TLV type. 836 Parameter ID Length Description 837 ======================================= 838 0x1A 8 E-Tree 840 IANA allocated two new LDP status codes from the registry of name 841 "STATUS CODE NAME SPACE". 843 Range/Value E Description 844 ------------- ----- ---------------------- 845 0x20000003 1 E-Tree VLAN mapping not supported 846 0x20000004 0 Leaf to Leaf PW released 848 IANA allocated a value for E-Tree in the registry of BGP Extended 849 Community. 851 Type Value Sub-Type Value Name 852 ========== ============== ============ 853 0x80 0x0b E-Tree Info 855 11. References 857 11.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and Heron, 863 G., "Pseudowire Setup and Maintenance Using Label 864 Distribution Protocol (LDP)", RFC 4447, April 2006. 866 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and Heron,G., 867 "Encapsulation Methods for Transport of Ethernet over MPLS 868 Networks", RFC 4448, April 2006. 870 [RFC4761] Kompella, K., and Rekhter, Y., "Virtual Private LAN 871 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 872 RFC 4761, January 2007. 874 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 875 Services using LDP", RFC 4762, January 2007. 877 11.2. Informative References 879 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 880 Edge (PWE3) Architecture", RFC 3985, March 2005. 882 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 883 Virtual Private Networks (L2VPNs)", RFC 4664, September 884 2006. 886 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 887 Framework", RFC 6136, March 2011. 889 [RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Serbest, Y., 890 "Virtual Private LAN Service (VPLS) Interoperability with 891 Customer Edge (CE) Bridges", RFC 6246, June 2011. 893 [RFC7041] Balus, F., Sajassi, A., and Bitar, N., Extensions to VPLS 894 PE model for Provider Backbone Bridging, RFC 7041, 895 November 2013. 897 [RFC7152] Key, R., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. 898 Paul, "Requirements for Metro Ethernet Forum (MEF) 899 Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private 900 Network (L2VPN)", RFC 7152, March 2014. 902 [RFC7387] Key, R., Yong, L., DeLord, S., Jounay, F., and Jin, L., "A 903 Framework for Ethernet Tree (E-Tree) Service over a 904 Multiprotocol Label Switching (MPLS) Network", RFC 7387, 905 October 2014. 907 [802.1Q-2014] IEEE Std 802.1Q-2014, Bridges and Bridged Networks, 908 November 2014. 910 [MEF4] Metro Ethernet Forum, Metro Ethernet Network Architecture 911 Framework - Part 1: Generic Framework, Technical 912 Specification MEF 4, May 2004. 914 [MEF6.2] Metro Ethernet Forum, "EVC Ethernet Services Definitions 915 Phase 3", Technical Specification MEF 6.2, August 2014. 917 [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., 918 and L. Jin, "Framework and Requirements for Virtual 919 Private Multicast Service (VPMS)", Work in Progress, 920 draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012. 922 12. Acknowledgments 924 The authors would like to thank Stewart Bryant, Lizhong Jin and 925 Deborah Brungard for their detailed reviews and suggestions, thank 926 Adrian Farrel, Susan Hares and Shane Amante for their valuable 927 advices, thank Ben Mack-crane, Edwin Mallette, Donald Fedyk, Dave 928 Allan, Giles Heron, Raymond Key, Josh Rogers, Sam Cao and Daniel 929 Cohn for their valuable comments and discussions. 931 Appendix A. Other PE Models for E-Tree 933 A.1. A PE Model With a VSI and No bridge 935 If there is no bridge module in a PE, the PE may consist of Native 936 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 937 5 of [RFC3985]) where any transformation operation for VLANs (e.g., 938 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 939 VLAN or leaf VLAN can be added by the NSP depending on the User 940 Network Interface (UNI) type (root/leaf) associated with the AC over 941 which the packet arrives. 943 Further, when a packet with a leaf VLAN exits a forwarder and 944 arrives at the NSP, the NSP must drop the packet if the egress AC is 945 associated with a leaf UNI. 947 Tagged PW and VLAN mapping work in the same way as in the typical PE 948 model. 950 +----------------------------------------+ 951 | PE Device | 952 Multiple+----------------------------------------+ 953 AC | | | Single | PW Instance 954 <------>o NSP # + PW Instance X<----------> 955 | | | | 956 |------| VSI |----------------------| 957 | | | Single | PW Instance 958 <------>o NSP #Forwarder + PW Instance X<----------> 959 | | | | 960 |------| |----------------------| 961 | | | Single | PW Instance 962 <------>o NSP # + PW Instance X<----------> 963 | | | | 964 +----------------------------------------+ 966 Figure A.1 A PE model with a VSI and no bridge module 968 This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a 969 Hierarchical VPLS (H-VPLS) network, or a Network-facing PE (N-PE) in 970 an H-VPLS network with non-bridging edge devices, wherein a spoke PW 971 can be treated as an AC in this model. 973 A.2. A PE Model With external E-Tree interface 975 +----------------------------------------+ 976 | PE Device | 977 Root +----------------------------------------+ 978 VLAN | | Single | PW Instance 979 <------>o + PW Instance X<----------> 980 | | | 981 | VSI |----------------------| 982 | | Single | PW Instance 983 | Forwarder + PW Instance X<----------> 984 | | | 985 Leaf | |----------------------| 986 VLAN | | Single | PW Instance 987 <------>o + PW Instance X<----------> 988 | | | 989 +----------------------------------------+ 991 Figure A.2 A PE model with external E-Tree interface 993 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 994 are directly or indirectly over a single PW connected to a same VSI 995 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 996 insertion/removal or VLAN mapping, can be performed by some outer 997 equipments, and the PE may further translate these VLANs into its 998 own local VLANs. This PE model may be used by an N-PE in an H-VPLS 999 network with bridging-capable devices, or scenarios such as 1000 providing E-Tree Network-to-Network interfaces. 1002 Authors' Addresses 1004 Yuanlong Jiang 1005 Huawei Technologies Co., Ltd. 1006 Bantian, Longgang district 1007 Shenzhen 518129, China 1008 Email: jiangyuanlong@huawei.com 1010 Lucy Yong 1011 Huawei USA 1012 207 Estrella Xing 1013 Georgetown TX, USA 78628 1014 Email: lucyyong@huawei.com 1016 Manuel Paul 1017 Deutsche Telekom 1018 Winterfeldtstr. 21 1019 10781 Berlin, Germany 1020 Email: manuel.paul@telekom.de 1022 Frederic Jounay 1023 Orange CH 1024 4 rue caudray 1020 Renens, Switzerland 1025 Email: frederic.jounay@orange.ch 1027 Florin Balus 1028 Alcatel-Lucent 1029 701 E. Middlefield Road 1030 Mountain View, CA, USA 94043 1031 Email: florin.balus@alcatel-lucent.com 1033 Wim Henderickx 1034 Alcatel-Lucent 1035 Copernicuslaan 50 1036 2018 Antwerp, Belgium 1037 Email: wim.henderickx@alcatel-lucent.com 1039 Ali Sajassi 1040 Cisco 1041 170 West Tasman Drive 1042 San Jose, CA 95134, USA 1043 Email: sajassi@cisco.com