idnits 2.17.1 draft-jiang-l2vpn-vpls-pe-etree-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 132 has weird spacing: '...chanism the u...' == Line 655 has weird spacing: '...cessing as...' == Line 856 has weird spacing: '...) where any t...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The E-Tree service is defined in Metro Ethernet Forum (MEF) as a Rooted-Multipoint EVC service. It is a multipoint Ethernet service with special restrictions: the frames from a root may be received by any other root or leaf, and the frames from a leaf may be received by any root, but MUST not be received by a leaf. Further, an E-Tree service may include multiple roots and multiple leaves. Although VPMS or P2MP multicast is a somewhat simplified version of this service, in fact, there is no exact corresponding terminology in IETF. -- The document date (June 14, 2012) is 4331 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) == Missing Reference: 'Etree-req' is mentioned on line 201, but not defined == Unused Reference: 'ETree-req' is defined on line 825, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 6136 == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-etree-reqt-01 == Outdated reference: A later version (-07) exists of draft-key-l2vpn-vpls-etree-06 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-pbb-vpls-pe-model-04 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 L. Yong 3 Internet Draft Huawei 5 Intended status: Standards Track M. Paul 6 Deutsche Telekom 8 F. Jounay 9 Orange CH 11 F. Balus 12 W. Henderickx 13 Alcatel-Lucent 15 A. Sajassi 16 Cisco 18 Expires: December 2012 June 14, 2012 20 VPLS PE Model for E-Tree Support 21 draft-jiang-l2vpn-vpls-pe-etree-06.txt 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on December 14, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Abstract 59 A generic VPLS solution for E-Tree services is proposed which uses 60 VLANs to indicate root/leaf traffic. A VPLS Provider Edge (PE) model 61 is illustrated as an example for the solution. In the solution, E- 62 Tree VPLS PEs are interconnected by PWs which carry the VLAN 63 indicating the E-Tree attribute, the MAC address based Ethernet 64 forwarding engine and the PW work in the same way as before. A 65 signaling mechanism for E-Tree capability and VLAN mapping 66 negotiation is further described. 68 Table of Contents 70 1. Introduction .............................................. 3 71 2. Conventions used in this document ......................... 4 72 3. Terminology ............................................... 4 73 4. PE Model with E-Tree Support .............................. 5 74 4.1. Existing PE Models ..................................... 5 75 4.2. A New PE Model with E-Tree Support ..................... 8 76 5. PW for E-Tree Support ..................................... 9 77 5.1. PW Encapsulation ....................................... 9 78 5.2. VLAN Mapping ........................................... 9 79 5.3. PW Processing ......................................... 11 80 5.3.1. PW Processing in the VLAN Mapping Mode .......... 11 81 5.3.2. PW Processing in the Compatible Mode ............ 12 82 5.3.3. PW Processing in the Optimized Mode ............. 13 83 6. LDP Extensions for E-Tree Support ........................ 14 84 7. BGP Extensions for E-Tree Support ........................ 16 85 8. OAM Considerations ....................................... 17 86 9. Applicability ............................................ 18 87 10. Security Considerations .................................. 18 88 11. IANA Considerations ...................................... 18 89 12. References ............................................... 19 90 12.1. Normative References ............................... 19 91 12.2. Informative References ............................. 19 93 13. Acknowledgments ........................................... 20 94 Appendix A. Other PE Models for E-Tree ......................... 21 95 A.1. A PE Model With a VSI and No bridge .................... 21 96 A.2. A PE Model With external E-Tree interface .............. 22 98 1. Introduction 100 The E-Tree service is defined in Metro Ethernet Forum (MEF) as a 101 Rooted-Multipoint EVC service. It is a multipoint Ethernet service 102 with special restrictions: the frames from a root may be received by 103 any other root or leaf, and the frames from a leaf may be received by 104 any root, but MUST not be received by a leaf. Further, an E-Tree 105 service may include multiple roots and multiple leaves. Although VPMS 106 or P2MP multicast is a somewhat simplified version of this service, 107 in fact, there is no exact corresponding terminology in IETF. 109 [Etree-req] gives the requirements for providing E-Tree solutions in 110 the VPLS and the need to filter leaf-to-leaf traffic. 112 [Vpls-etree] describes a PW control word based E-Tree solution, where 113 a bit in the PW control word is used to indicate the root/leaf 114 attribute for a packet. The Ethernet forwarder in the VPLS is also 115 extended to filter the leaf-to-leaf traffic based on the tuple. 118 [Etree-2PW] proposes another E-Tree solution where root and leaf 119 traffic are classified and forwarded in the same VSI but with two 120 separate PWs. 122 Both solutions are only applicable to "VPLS only" networks. 124 In fact, VPLS PE usually consists of a bridge module itself (see 125 [RFC4664] and [RFC6246]); moreover, E-Tree services may cross both 126 Ethernet and VPLS domains. Therefore, it is necessary to develop an 127 E-Tree solution both for "VPLS only" scenarios and for interworking 128 between Ethernet and VPLS. 130 IEEE 802.1 has incorporated the generic E-Tree solution in the latest 131 version of 802.1Q [802.1aq], which is just an improvement on the 132 traditional asymmetric VLAN mechanism the use of different VLANs to 133 indicate E-Tree root/leaf attributes and prohibiting leaf-to-leaf 134 traffic with the help of VLANs was first standardized in IEEE 802.1Q- 135 2003 . In the solution, VLANs are used to indicate root/leaf 136 attribute of a packet: one VLAN ID is used to indicate the frames 137 originated from the roots and another VLAN ID is used to indicate the 138 frames originated from the leaves. At a leaf port, the bridge can 139 then filter out all the frames from other leaf ports based on the 140 VLAN ID. It is better to reuse the same mechanism in VPLS than to 141 develop a new mechanism. The latter will introduce more complexity to 142 interwork with IEEE 802.1Q solution. 144 This document introduces how the Ethernet VLAN solution can be used 145 to support generic E-Tree services in the VPLS. The solution proposed 146 here is fully compatible with the IEEE bridge architecture and the 147 IETF PWE3 technology, thus it will not change the FIB (such as 148 installing E-Tree attributes in the FIB), or need any specially 149 tailored implementation. Furthermore, VPLS scalability and simplicity 150 is also well kept. With this mechanism, it is also convenient to 151 deploy a converged E-Tree service across both Ethernet and MPLS 152 networks. 154 Firstly, a typical VPLS PE model is introduced as an example; the 155 model is then extended in which a Tree VSI is connected to a VLAN 156 bridge with a dual-VLAN interface. 158 This document then discusses the PW encapsulation and PW processing 159 such as VLAN mapping options for transporting E-Tree services in a 160 VPLS. 162 Finally, it describes the signaling extensions for E-Tree support and 163 PE processing procedures. 165 2. Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. Terminology 173 E-Tree: a Rooted-Multipoint EVC service as defined in MEF 6.1 175 EVC: Ethernet Virtual Connection, as defined in MEF 4.0 177 FIB: Forwarding Information Base, or forwarding table 179 T-VSI: Tree VSI, a VSI with E-Tree support 180 Root AC, an AC attached with a root 182 Leaf AC, an AC attached with a leaf 184 C-VLAN, Customer VLAN 186 S-VLAN, Service VLAN 188 B-VLAN, Backbone VLAN 190 Root VLAN, a VLAN ID used to indicate all the frames that are 191 originated at a root AC 193 Leaf VLAN, a VLAN ID used to indicate all the frames that are 194 originated at a leaf AC 196 I-SID, Backbone Service Instance Identifier, as defined in IEEE 197 802.1ah 199 4. PE Model with E-Tree Support 201 "VPLS only" PE architecture as shown in Fig. 1 of [Etree-req] is a 202 simplification of the VPLS and PWE3 architecture, several common VPLS 203 PE architectures are discussed in more details in [RFC4664] and 204 [RFC6246]. 206 Therefore, VLAN based E-Tree solution are demonstrated with the help 207 of a typical VPLS PE model. It can also be used by other PE models 208 which are discussed in Appendix A. 210 4.1. Existing PE Models 212 According to [RFC4664], there are at least three models possible for 213 a VPLS PE, including: 215 o A single bridge module, a single VSI; 217 o A single bridge module, multiple VSIs; 219 o Multiple bridge modules, each attaches to a VSI. 221 The second PE model is commonly used. A typical example is further 222 depicted in Fig. 1 and Fig. 2 [RFC6246], where an S-VLAN bridge 223 module is connected to multiple VSIs each with a single VLAN virtual 224 interface. 226 +-------------------------------+ 227 | 802.1ad Bridge Module Model | 228 | | 229 +---+ | +------+ +-----------+ | 230 |CE |---------|C-VLAN|------| | | 231 +---+ | |bridge|------| | | 232 | +------+ | | | 233 | o | S-VLAN | | 234 | o | | | 235 | o | Bridge | | 236 +---+ | +------+ | | | 237 |CE |---------|C-VLAN|------| | | 238 +---+ | |bridge|------| | | 239 | +------+ +-----------+ | 240 +-------------------------------+ 242 Figure 1 A model of 802.1ad Bridge Module 244 +----------------------------------------+ 245 | VPLS-capable PE model | 246 | +---------------+ +------+ | 247 | | | |VSI-1 |------------ 248 | | |==========| |------------ PWs 249 | | Bridge ------------ |------------ 250 | | | S-VLAN-1 +------+ | 251 | | Module | o | 252 | | | o | 253 | | (802.1ad | o | 254 | | bridge) | o | 255 | | | o | 256 | | | S-VLAN-n +------+ | 257 | | ------------VSI-n |------------- 258 | | |==========| |------------- PWs 259 | | | ^ | |------------- 260 | +---------------+ | +------+ | 261 | | | 262 +-------------------------|--------------+ 263 LAN emulation Interface 265 Figure 2 A VPLS-capable PE Model 267 In this PE model, Ethernet frames from Customer Edges (CEs) will 268 cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN 269 bridge) and a VSI in a PE before being sent on the PW to a remote PE. 270 Therefore, the association between an AC port and a PW on a VSI as 271 required in [Vpls-etree] or [Etree-2PW] is difficult, sometimes even 272 impossible. 274 This model could be further enhanced: When Ethernet frames arrive at 275 a PE, a root VLAN or a leaf VLAN tag is added. Then the frames with 276 the root VLAN tag are transmitted both to the roots and the leaves, 277 while the frames with the leaf VLAN tag are transmitted to the roots 278 but dropped for the leaves (these VLAN tags are removed before the 279 frames are transmitted over the wire). It was demonstrated in 280 [802.1aq] that the E-Tree service in Ethernet networks can be well 281 supported with this mechanism. 283 Assuming this mechanism is implemented in the bridge module, it is 284 quite straightforward to infer a VPLS PE model with two VSIs to 285 support the E-Tree (as shown in Fig. 3). But this model will require 286 two VSIs per PE and two sets of PWs per E-Tree service, which is 287 poorly scalable in a large MPLS/VPLS network; in addition, both these 288 VSIs have to share their learned MAC addresses. 290 +----------------------------------------+ 291 | VPLS-capable PE model | 292 | +---------------+ +------+ | 293 | | | |VSI-1 |------------ 294 | | |==========| |------------ PWs 295 | | Bridge ------------ |------------ 296 | | | Root +------+ | 297 | | Module | S-VLAN | 298 | | | | 299 | | (802.1ad | | 300 | | bridge) | | 301 | | | Leaf | 302 | | | S-VLAN +------+ | 303 | | ------------VSI-2 |------------- 304 | | |==========| |------------- PWs 305 | | | ^ | |------------- 306 | +---------------+ | +------+ | 307 | | | 308 +-------------------------|--------------+ 309 LAN emulation Interface 311 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 313 4.2. A New PE Model with E-Tree Support 315 In order to support the E-Tree in a more scalable way, a new VPLS PE 316 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 317 proposed. As depicted in Fig. 4, the bridge module is connected to 318 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 319 VLAN and the leaf VLAN are connected to the same T-VSI, and they 320 share the same FIB and work in shared VLAN learning. In this way, 321 only one VPLS instance and one set of PWs is needed per E-Tree 322 service, and the scalability of VPLS is improved. 324 +----------------------------------------+ 325 | VPLS-capable PE model | 326 | +---------------+ +------+ | 327 | | |==========|TVSI-1|------------ 328 +---+AC | | ------------ |------------ PWs 329 |CE |-------| Bridge ------------ |------------ 330 +---+ | | | Root & +------+ | 331 | | Module | Leaf VLAN o | 332 | | | o | 333 | | | o | 334 | | | o | 335 | | | o | 336 +---+AC | | | VLAN-n +------+ | 337 |CE |-------| ------------VSI-n |------------- 338 +---+ | | |==========| |------------- PWs 339 | | | ^ | |------------- 340 | +---------------+ | +------+ | 341 | | | 342 +-------------------------|--------------+ 343 LAN emulation Interface 345 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 347 For an untagged port (customer sites attached to the PEs with 348 untagged ports), the Ethernet frames received from the root ACs can 349 be tagged with a root C-VLAN, and optionally be added with another 350 root S-VLAN. Alternatively, the frames from the root ACs can be 351 tagged with the root S-VLAN tag directly in the VPLS network domain. 353 For a C-VLAN tagged port, the Ethernet frames received from the root 354 ACs can be added with a root S-VLAN. Alternatively, the C-VLAN can be 355 translated to the root S-VLAN in the VPLS network domain. 357 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 358 received from the root ACs can be translated to the root S-VLAN in 359 the VPLS network domain. Alternatively, the PBB VPLS PE model (where 360 an IEEE 802.1ah bridge module is embedded in the PE) as described in 361 [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added 362 in this case (the E-Tree attribute may also be indicated with two I- 363 SID tags in the bridge module, and the frames are further 364 encapsulated and transported transparently over a single B-VLAN, thus 365 the PBB VPLS works just in the same way as described in [PBB-VPLS] 366 and will be discussed no more in this document). When many S-VLANs 367 are multiplexed in a single AC, the 2nd option has an advantage of 368 both VLAN scalability and MAC address scalability. 370 In a similar way, the traffic from the leaf ACs is tagged and 371 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 373 In all cases, the outermost VLAN in the resulted Ethernet header is 374 used to indicate the E-Tree attribute of an Ethernet frame; this 375 document will use VLAN to refer to this outermost VLAN for simplicity 376 in the latter sections. 378 5. PW for E-Tree Support 380 5.1. PW Encapsulation 382 To support an E-Tree service, T-VSIs in a VPLS must be interconnected 383 with a bidirectional Ethernet PW. The Ethernet PW may work in the 384 tagged mode (PW type 0x0004) as described in [RFC4448], and a VLAN 385 tag must be carried in each frame in the PW to indicate the frame 386 originated from either root or leaf (the VLAN tag indicating the 387 frame originated from either root or leaf can be translated by a 388 bridge module in the PE or added by an outside Ethernet edge device, 389 even by a customer device). In the tagged PW mode, two service 390 delimiting VLANs must be allocated in the VPLS domain for an E-Tree. 391 PW processing for the tagged PW will be described in Section 5.3 of 392 this document. 394 Raw PW (PW type 0x0005 in [RFC4448]) may be used to carry E-Tree 395 service for a PW in Compatible mode as shown in Section 5.3.2. 397 5.2. VLAN Mapping 399 There are two ways of manipulating VLANs for an E-Tree in VPLS: 401 o Global VLAN based, that is, provisioning two global VLANs (Root 402 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 403 needed at all, or the VLAN mapping is done completely in the 404 Ethernet domains. 406 o Local VLAN based, that is, provisioning two local VLANs for each 407 PE (which participates in the E-Tree) in the VPLS network 408 independently. 410 The first method requires no VLAN mapping in the PW, but two unique 411 service delimiting VLANs must be allocated across the VPLS domain. 413 The second method is more scalable in the use of VLANs, but needs a 414 VLAN mapping mechanism in the PW similar to what is already described 415 in Section 4.3 of [RFC4448]. 417 Global or local VLANs can be manually configured or provisioned by an 418 OSS system. Alternatively, some automatic VLAN allocation algorithm 419 may be provided in the management plane, but it is out scope of this 420 document. 422 For both methods, VLAN mapping parameters from a remote PE can be 423 provisioned or determined by a signaling protocol as described in 424 Section 6 when a PW is being established. 426 5.3. PW Processing 428 5.3.1.PW Processing in the VLAN Mapping Mode 430 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 431 inter-connected with a PW (For example, the scenario of Fig. 5 432 depicts the interconnection of two PEs miscellaneously attached with 433 both root and leaf nodes). 435 +------------------------+ 436 | VPLS PE with T-VSI | 437 | | 438 +----+ | +------+ +-----+ | PW 439 |Root|------| VLAN |-------|T-VSI|---------- 440 +----+ | | BRG | | |---------- 441 +----+ | | |-------| |---------- 442 |Leaf|------| | | |---------+ 443 +----+ | +------+ +-----+ | | 444 | | | 445 +------------------------+ | 446 | 447 +------------------------+ | 448 | VPLS PE with T-VSI | | 449 | | | 450 +----+ | +------+ +-----+ | PW | 451 |Root|------| VLAN |-------|T-VSI|---------+ 452 +----+ | | BRG | | |---------- 453 +----+ | | |-------| |---------- 454 |Leaf|------| | | |---------- 455 +----+ | +------+ +-----+ | 456 | | 457 +------------------------+ 459 Figure 5 T-VSI Interconnected in the Normal Mode 461 If a PE is in the VLAN mapping mode for a PW, then in the data plane 462 the PE MUST map the VLAN in each frame as follows: 464 o Upon transmitting frames on the PW, map from local VLAN to remote 465 VLAN (i.e., the local leaf VLAN in a frame is translated to the 466 remote leaf VLAN; the local root VLAN in a frame is translated to the 467 remote root VLAN). 469 o Upon receiving frames on the PW, map from remote VLAN to local VLAN, 470 and the frames are further forwarded or dropped in the egress bridge 471 module using the filtering mechanism as described in [802.1aq]. 473 5.3.2.PW Processing in the Compatible Mode 475 The new VPLS PE model can work in a traditional VPLS network 476 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS PE 477 with T-VSI can be attached with root and/or leaf nodes, while the 478 VPLS PE with a traditional VSI can only be attached with root nodes. 479 Raw PW should be used to connect with a traditional PE. 481 +------------------------+ 482 | VPLS PE with T-VSI | 483 | | 484 +----+ | +------+ +-----+ | PW 485 |Root|------| VLAN |-------|T-VSI|---------- 486 +----+ | | BRG | | |---------- 487 +----+ | | |-------| |---------- 488 |Leaf|------| | | |---------+ 489 +----+ | +------+ +-----+ | | 490 | | | 491 +------------------------+ | 492 | 493 +------------------------+ | 494 | VPLS PE with VSI | | 495 | | | 496 +----+ | +------+ +-----+ | PW | 497 |Root|------| VLAN |-------|VSI |---------+ 498 +----+ | | BRG | | |---------- 499 +----+ | | | | |---------- 500 |Root|------| | | |---------- 501 +----+ | +------+ +-----+ | 502 | | 503 +------------------------+ 505 Figure 6 T-VSI interconnected with Traditional VSI 507 If a PE is in the Compatible mode for a PW, then in the data plane 508 the PE MUST process the frame as follows: 510 o Upon transmitting frames on the PW, remove the root or leaf VLAN in 511 the frames. 513 o Upon receiving frames on the PW, add a VLAN tag with a value of the 514 local root VLAN to the frames. 516 5.3.3.PW Processing in the Optimized Mode 518 When two PEs are connected with their T-VSIs and one PE (e.g., PE2) 519 is attached with only leaf nodes, as shown in the scenario of Fig. 6, 520 the peer PE (e.g., PE1) should then work in the optimization mode. In 521 this case, PE1 should not send the frames originated from the local 522 leaf VLAN to PE2, i.e., these frames are dropped rather than 523 transported over the PW. The bandwidth efficiency of the VPLS can 524 thus be improved. The signaling for the PE attached with only leaf 525 nodes is specified in Section 6. 526 +------------------------+ 527 |VPLS PE with T-VSI (PE1)| 528 | | 529 +----+ | +------+ +-----+ | PW 530 |Root|------| VLAN |-------|T-VSI|---------- 531 +----+ | | BRG | | |---------- 532 +----+ | | |-------| |---------- 533 |Leaf|------| | | |---------+ 534 +----+ | +------+ +-----+ | | 535 | | | 536 +------------------------+ | 537 | 538 +------------------------+ | 539 |VPLS PE with T-VSI (PE2)| | 540 | | | 541 +----+ | +------+ +-----+ | PW | 542 |Leaf|------| VLAN |-------|T-VSI|---------+ 543 +----+ | | BRG | | |---------- 544 +----+ | | |-------| |---------- 545 |Leaf|------| | | |---------- 546 +----+ | +------+ +-----+ | 547 | | 548 +------------------------+ 550 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 552 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 553 SHOULD first operate as follows: 555 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 557 6. LDP Extensions for E-Tree Support 559 In addition to the signaling procedures as specified in [RFC4447], 560 this document proposes a new interface parameter sub-TLV to provision 561 an E-Tree service and negotiate the VLAN mapping function, as follows: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | E-Tree | Length=8 | Reserved |P|V| 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Root VLAN ID | Leaf VLAN ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 8 E-Tree Sub-TLV 572 Where: 574 o E-Tree is the sub-TLV identifier to be assigned by IANA. 576 o Length is the length of the sub TLV in octets. 578 o Reserved bits MUST be set to zero on transmit and be ignored on 579 receive. 581 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 582 attached with only leaf nodes, and set to 0 otherwise. 584 o V is a bit indicating the sender's VLAN mapping capability. A PE 585 capable of VLAN mapping MUST set this bit, and clear it otherwise. 587 o Root VLAN ID is the value of the local root VLAN. 589 o Leaf VLAN ID is the value of the local leaf VLAN. 591 When setting up a PW for the E-Tree based VPLS, two PEs negotiate the 592 E-Tree support using the above E-Tree sub-TLV. Note PW type of 0x0004 593 should be used during the PW negotiation. 595 A PE that wishes to support E-Tree service MUST include an E-Tree 596 Sub-TLV in its PW label mapping message and include its local root 597 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 598 capability MUST set the V bit to 1, and a PE is attached with only 599 leaf nodes SHOULD set the P bit to 1. 601 In default, for each PW, VLAN-Mapping-Mode, Compatible-Mode, and 602 Optimized-Mode are all set to FALSE. 604 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 605 from its peer PE must process it as follows: 607 1) if the root and leaf VLAN ID in the message match the local root 608 and leaf VLAN ID, then continue to 3); 610 2) else { 612 if the bit V is cleared, then { 614 if the PE is capable of VLAN mapping, then it MUST set 615 VLAN-Mapping-Mode to TRUE; 617 else { 619 A label release message with the error code "E-Tree 620 VLAN mapping not supported" is sent to the peer PE 621 and exit the process; 623 } 625 } 627 if the bit V is set, and the PE is capable of VLAN mapping, 628 then the PE with the minimum IP address MUST set VLAN-Mapping- 629 Mode to TRUE; 631 } 633 3) If the P bit is set, then: 635 { 637 If the PE is a leaf-only node itself, then a label release 638 message with a status code "Leaf to Leaf PW released" is sent to 639 the peer PE and exit the process; 641 Else the PE SHOULD set the Optimized-Mode to TRUE. 643 } 645 If a PE has sent an E-Tree Sub-TLV but does not receive any E-Tree 646 Sub-TLV in its peer's PW label mapping message, The PE SHOULD then 647 establish a raw PW with this peer as in traditional VPLS and set 648 Compatible-Mode to TRUE for this PW. 650 Data plane processing for this PW is as following: 652 If Optimized-Mode is TRUE, then data plane processing as described in 653 Section 5.3.3 applies. 655 If VLAN-Mapping-Mode is TRUE, then data plane processing as 656 described in Section 5.3.1 applies. 658 If Compatible-Mode is TRUE, then data plane processing is as 659 described in Section 5.3.2. 661 PW processing as described in [RFC4448] proceeds as usual for all 662 cases. 664 7. BGP Extensions for E-Tree Support 666 A new E-Tree extended community is proposed for E-Tree signaling in 667 BGP VPLS: 669 +------------------------------------+ 670 | Extended community type (2 octets) | 671 +------------------------------------+ 672 | Root VLAN (2 octets) | 673 +------------------------------------+ 674 | Leaf VLAN (2 octets) | 675 +------------------------------------+ 676 | Reserved |P| 677 +------------------------------------+ 679 Figure 9 E-Tree Extended Community 681 Where: 683 o Root VLAN ID is the value of the local root VLAN. 685 o Leaf VLAN ID is the value of the local leaf VLAN. 687 o Reserved, 15 bits MUST be set to zero on transmit and be ignored 688 on receive. 690 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 691 attached with only leaf nodes, and set to 0 otherwise. 693 The PEs attached with both leaf and root nodes must support BGP E- 694 Tree signaling as described in this document, and must support VLAN 695 mapping in their data planes. The traditional PE attached with only 696 root nodes may also participate in an E-Tree service. 698 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 699 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 700 be further attached if a PE wishes to participate in an E-Tree 701 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 702 in the E-Tree Extended Community. A PE attached with only leaf nodes 703 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 704 1. 706 A PE that receives a BGP UPDATE message with an E-Tree Extended 707 Community from its peer PE must process it as follows (after 708 processing procedures as specified in Section 3.2 of [RFC4761]): 710 1) if the root and leaf VLAN ID in the E-Tree Extended Community 711 match the local root and leaf VLAN ID, then continue to 3); 713 2) else { 715 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 716 to TRUE; 718 } 720 3) If the P bit is set, then the PE SHOULD set the Optimized-Mode to 721 TRUE. 723 A PE which does not recognize this attribute shall ignore it silently. 724 If a PE has sent an E-Tree Extended Community but does not receive 725 any E-Tree Extended Community from its peer, the PE SHOULD then 726 establish a raw PW with this peer as in traditional VPLS, and set 727 Compatible-Mode to TRUE for this PW. 729 Data plane in the VPLS is the same as described in Section 4.2 of 730 [RFC4761], and data plane processing for a PW is the same as 731 described at the end of Section 6. 733 8. OAM Considerations 735 VPLS OAM requirements and framework as specified in [RFC6136] are 736 applicable to E-Tree, as both Ethernet OAM frames and data traffic 737 are transported over the same PW. 739 Ethernet OAM for E-Tree including both service OAM and segment OAM 740 frames shall undergo the same VLAN mapping as the data traffic; and 741 root VLAN SHOULD be applied to segment OAM frames so that they are 742 not filtered. 744 9. Applicability 746 The solution is applicable to both LDP VPLS [RFC4762] and BGP VPLS 747 [RFC4761]. 749 The solution is applicable to both "VPLS Only" networks and VPLS with 750 Ethernet aggregation networks. 752 The solution is also applicable to PBB VPLS networks. 754 10. Security Considerations 756 Besides security considerations as described in [RFC4448], [RFC4761] 757 and [RFC4762], this solution prevents leaf to leaf communication in 758 the data plane of VPLS when its PEs are interconnected with PWs. In 759 this regard, security can be enhanced for customers with this 760 solution. 762 11. IANA Considerations 764 IANA is requested to allocate a value for E-Tree in the registry of 765 Pseudowire Interface Parameters Sub-TLV type. 767 Parameter ID Length Description 768 ======================================= 769 TBD 8 E-Tree 771 IANA is requested to allocate two new LDP status codes from the 772 registry of name "STATUS CODE NAME SPACE". The following values are 773 suggested: 775 Range/Value E Description 776 ------------- ----- ---------------------- 777 TBD 1 E-Tree VLAN mapping not supported 778 TBD 0 Leaf to Leaf PW released 780 IANA is requested to allocate a value for E-Tree in the registry of 781 BGP Extended Community. 783 Type Value Name 784 ======================================= 785 TBD E-Tree Info 787 12. References 789 12.1. Normative References 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC4447] Martini, L., and et al, "Pseudowire Setup and Maintenance 795 Using Label Distribution Protocol (LDP)", RFC 4447, April 796 2006. 798 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 799 Transport of Ethernet over MPLS Networks", RFC 4448, April 800 2006. 802 [RFC4761] Kompella, K. and Rekhter, Y., "Virtual Private LAN Service 803 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 804 4761, January 2007 806 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 807 Services using LDP", RFC 4762, January 2007. 809 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 810 Framework", RFC 6136, March 2011 812 12.2. Informative References 814 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 815 Edge (PWE3) Architecture", RFC 3985, March 2005. 817 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 818 Virtual Private Networks (L2VPNs)", RFC 4664, September 819 2006. 821 [RFC6246] Sajassi, A., and et al, "Virtual Private LAN Service (VPLS) 822 Interoperability with Customer Edge (CE) Bridges", RFC 6246, 823 June 2011 825 [ETree-req] Key, R., et al, "Requirements for MEF E-Tree Support in 826 VPLS", draft-ietf-l2vpn-etree-reqt-01, Work in Progress 828 [Vpls-etree] Key, R., and et al, "Extension to VPLS for E-Tree", 829 draft-key-l2vpn-vpls-etree-06, October 2011 831 [802.1aq] IEEE 802.1aq D4.3, Virtual Bridged Local Area Networks - 832 Amendment 9: Shortest Path Bridging, September 2011 834 [Etree-2PW] Ram, R., and et al., Extension to LDP-VPLS for E-Tree 835 Using Two PW, draft-ram-l2vpn-ldp-vpls-etree-2pw-02, May 836 2011 838 [PBB-VPLS] Balus, F., and et al., Extensions to VPLS PE model for 839 Provider Backbone Bridging, draft-ietf-l2vpn-pbb-vpls-pe- 840 model-04, October 2011 842 13. Acknowledgments 844 The authors would like to thank Adrian Farrel, Susan Hares and Shane 845 Amante for their valuable advices, thank Ben Mack-crane, Edwin 846 Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh 847 Rogers, Sam Cao and Daniel Cohn for their valuable comments and 848 discussions. 850 Appendix A. Other PE Models for E-Tree 852 A.1. A PE Model With a VSI and No bridge 854 If there is no bridge module in a PE, the PE may consist of Native 855 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 5 856 of [RFC3985]) where any transformation operation for VLANs (e.g., 857 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 858 VLAN or leaf VLAN can be added by the NSP depending on the UNI type 859 (root/leaf) associated with the AC over which the packet arrives. 861 Further, when a packet with a leaf VLAN exits a forwarder and arrives 862 at the NSP, the NSP must drop the packet if the egress AC is 863 associated with a leaf UNI. 865 Tagged PW and VLAN mapping work in the same way as in the typical PE 866 model. 868 +----------------------------------------+ 869 | PE Device | 870 Multiple+----------------------------------------+ 871 AC | | | Single | PW Instance 872 <------>o NSP # + PW Instance X<----------> 873 | | | | 874 |------| VSI |----------------------| 875 | | | Single | PW Instance 876 <------>o NSP #Forwarder + PW Instance X<----------> 877 | | | | 878 |------| |----------------------| 879 | | | Single | PW Instance 880 <------>o NSP # + PW Instance X<----------> 881 | | | | 882 +----------------------------------------+ 884 Figure A.1 A PE model with a VSI and no bridge module 886 This PE model may be used by an MTU-s in an H-VPLS network, or an N- 887 PE in an H-VPLS network with non-bridging edge devices, wherein a 888 spoke PW can be treated as an AC in this model. 890 A.2. A PE Model With external E-Tree interface 892 +----------------------------------------+ 893 | PE Device | 894 Root +----------------------------------------+ 895 VLAN | | Single | PW Instance 896 <------>o + PW Instance X<----------> 897 | | | 898 | VSI |----------------------| 899 | | Single | PW Instance 900 | Forwarder + PW Instance X<----------> 901 | | | 902 Leaf | |----------------------| 903 VLAN | | Single | PW Instance 904 <------>o + PW Instance X<----------> 905 | | | 906 +----------------------------------------+ 908 Figure A.2 A PE model with external E-Tree interface 910 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 911 are directly or indirectly over a single PW connected to a same VSI 912 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 913 insertion/removal or VLAN mapping, can be performed by some outer 914 equipments, and the PE may further translate these VLANs into its own 915 local VLANs. This PE model may be used by an N-PE in an H-VPLS 916 network with bridging-capable devices, or scenarios such as providing 917 E-Tree Network-to-Network (NNI) interfaces. 919 Authors' Addresses 921 Yuanlong Jiang 922 Huawei Technologies Co., Ltd. 923 Bantian, Longgang district 924 Shenzhen 518129, China 925 Email: jiangyuanlong@huawei.com 927 Lucy Yong 928 Huawei USA 929 1700 Alma Dr. Suite 500 930 Plano, TX 75075, USA 931 Email: lucyyong@huawei.com 933 Manuel Paul 934 Deutsche Telekom 935 Winterfeldtstr. 21 936 10781 Berlin, Germany 937 Email: manuel.paul@telekom.de 939 Frederic Jounay 940 Orange CH 941 4 rue caudray 1020 Renens, Switzerland 942 Email: frederic.jounay@orange.ch 944 Florin Balus 945 Alcatel-Lucent 946 701 E. Middlefield Road 947 Mountain View, CA, USA 94043 948 Email: florin.balus@alcatel-lucent.com 950 Wim Henderickx 951 Alcatel-Lucent 952 Copernicuslaan 50 953 2018 Antwerp, Belgium 954 Email: wim.henderickx@alcatel-lucent.com 956 Ali Sajassi 957 Cisco 958 170 West Tasman Drive 959 San Jose, CA 95134, USA 960 Email: sajassi@cisco.com