idnits 2.17.1 draft-ietf-l2vpn-vpls-pe-etree-11.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 (December 18, 2015) is 3050 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: June 2016 December 18, 2015 8 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 9 draft-ietf-l2vpn-vpls-pe-etree-11.txt 11 Abstract 13 This document specifies a generic Virtual Private LAN Service (VPLS) 14 solution which uses VLANs to indicate root or leaf traffic to 15 support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) 16 model is illustrated as an example for the solution. In the solution, 17 E-Tree VPLS PEs are interconnected by Pseudo Wires (PWs) which carry 18 the VLAN indicating the E-Tree attribute. The MAC address-based 19 Ethernet forwarding engine and the PW work in the same way as 20 specified in RFC 4762 and RFC 4448 respectively. A signaling 21 mechanism is described to support E-Tree capability and VLAN mapping 22 negotiation. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on June 18, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 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 ....................................... 19 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 ............................. 21 87 12. Acknowledgments .......................................... 22 88 Appendix A. Other PE Models for E-Tree ........................ 23 89 A.1. A PE Model With a VSI and No bridge ................... 23 90 A.2. A PE Model With external E-Tree interface ............. 24 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.2] 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.2 [MEF6.2] as a Rooted- 149 Multipoint Ethernet Virtual Connection (EVC) service. An MEF 6.2 E- 150 Tree solution must meet the following design requirements: the 151 Ethernet frames from a root may be received by any other root or 152 leaf, and the frames from a leaf may be received by any root, but 153 must not be received by a leaf. Further, an E-Tree service may 154 include multiple roots and multiple leaves. Although Virtual Private 155 Multicast Service (VPMS) [VPMS] or Point-to-Multipoint (P2MP) 156 multicast is a somewhat simplified version of this service, in fact, 157 they are both multicast services and are different from an E-Tree 158 service which may include 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 [802.1Q-2003], a VLAN ID is used 178 to indicate the traffic from a server, and multiple VLAN IDs are 179 used to indicate the traffic from the clients (one VLAN ID per 180 client). In the new IEEE 802.1Q solution, only two VLANs are used to 181 indicate root/leaf attributes of a frame: one VLAN ID is used to 182 indicate the frames originated from the roots and another VLAN ID is 183 used to indicate the frames originated from the leaves. At a leaf 184 port, the bridge can then filter out all the frames from other leaf 185 ports based on the VLAN ID. It is better to reuse the same mechanism 186 in VPLS than to develop a new mechanism. A new mechanism would 187 introduce more complexity to interwork with the new IEEE 802.1Q 188 solution. 190 This document specifies how the Ethernet VLAN solution can be used 191 to support generic E-Tree services in VPLS. The solution specified 192 here is fully compatible with the IEEE bridge architecture and with 193 IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) technology, thus it 194 will not change the FIB (such as installing E-Tree attributes in the 195 FIB), or need any specially tailored implementation. Furthermore, 196 VPLS scalability and simplicity are also maintained. With this 197 mechanism, it is also convenient to deploy a converged E-Tree 198 service across both Ethernet and MPLS networks. 200 A typical VPLS PE model is introduced as an example; the model is 201 then extended in which a Tree VSI is connected to a VLAN bridge with 202 a dual-VLAN interface. 204 The document then discusses the PW encapsulation and PW processing 205 such as VLAN mapping options for transporting E-Tree services in 206 VPLS. 208 Finally, the document describes the signaling extensions and 209 processing procedures for E-Tree support in VPLS. 211 4. PE Model with E-Tree Support 213 The problem scenario of E-Tree as shown in Fig. 1 of [RFC7152] is a 214 simplification of the L2VPN architecture, several common VPLS PE 215 architectures are discussed in more details in [RFC4664] and 216 [RFC6246]. 218 Below, an E-Tree solution in VPLS is demonstrated with the help of a 219 typical VPLS PE model. Its use in other PE models is discussed in 220 Appendix A. 222 4.1. Existing PE Models 224 According to [RFC4664], there are at least three models possible for 225 a VPLS PE, including: 227 o A single bridge module, a single VSI; 229 o A single bridge module, multiple VSIs; 231 o Multiple bridge modules, each attaches to a VSI. 233 The second PE model is commonly used. A typical example is further 234 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. 282 Therefore, the association between an AC port and a PW on a VSI is 283 difficult. 285 This model could be further enhanced: When Ethernet frames arrive at 286 an ingress PE, a root VLAN or a leaf VLAN tag is added. At an egress 287 PE, the frames with the root VLAN tag are transmitted both to the 288 roots and the leaves, while the frames with the leaf VLAN tag are 289 transmitted to the roots but dropped for the leaves (these VLAN tags 290 are removed before the frames are transmitted over the ACs). It was 291 demonstrated in [802.1Q-2014] that the E-Tree service in Ethernet 292 networks can be well supported with this mechanism. 294 Assuming this mechanism is implemented in the bridge module, it is 295 quite straightforward to infer a VPLS PE model with two VSIs to 296 support the E-Tree (as shown in Fig. 3). But this model will require 297 two VSIs per PE and two sets of PWs per E-Tree service, which is 298 poorly scalable in a large MPLS/VPLS network; in addition, both 299 these VSIs have to share their learned MAC addresses. 301 +----------------------------------------+ 302 | VPLS-capable PE model | 303 | +---------------+ +------+ | 304 | | | |VSI-1 |------------ 305 | | |==========| |------------ PWs 306 | | Bridge ------------ |------------ 307 | | | Root +------+ | 308 | | Module | S-VLAN | 309 | | | | 310 | | (802.1ad | | 311 | | bridge) | | 312 | | | Leaf | 313 | | | S-VLAN +------+ | 314 | | ------------VSI-2 |------------- 315 | | |==========| |------------- PWs 316 | | | ^ | |------------- 317 | +---------------+ | +------+ | 318 | | | 319 +-------------------------|--------------+ 320 LAN emulation Interface 322 Figure 3 A VPLS PE Model for E-Tree with 2 VSIs 324 4.2. A New PE Model with E-Tree Support 326 In order to support the E-Tree in a more scalable way, a new VPLS PE 327 model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is 328 specified. As depicted in Fig. 4, the bridge module is connected to 329 the T-VSI with a dual-VLAN virtual interface, i.e., both the root 330 VLAN and the leaf VLAN are connected to the same T-VSI, and they 331 share the same FIB and work in shared VLAN learning. In this way, 332 only one VPLS instance and one set of PWs is needed per E-Tree 333 service, and the scalability of VPLS is improved. 335 +----------------------------------------+ 336 | VPLS-capable PE model | 337 | +---------------+ +------+ | 338 | | |==========|TVSI-1|------------ 339 +---+ AC | | ------------ |------------ PWs 340 |CE |--------| Bridge ------------ |------------ 341 +---+ | | | Root & +------+ | 342 | | Module | Leaf VLAN o | 343 | | | o | 344 | | | o | 345 | | | o | 346 | | | o | 347 +---+ AC | | | VLAN-n +------+ | 348 |CE |--------| ------------VSI-n |------------- 349 +---+ | | |==========| |------------- PWs 350 | | | ^ | |------------- 351 | +---------------+ | +------+ | 352 | | | 353 +-------------------------|--------------+ 354 LAN emulation Interface 356 Figure 4 A VPLS PE Model for E-Tree with a Single T-VSI 358 For an untagged AC port (frames over this port are untagged) or 359 VLAN-unaware port (VLAN tags in the frames are ignored), and the 360 bridge module is a C-VLAN bridge, the Ethernet frames received from 361 the root ACs MUST be tagged with a root C-VLAN. When the bridge 362 module is an 802.1ad bridge, the Ethernet frames received from the 363 root ACs MUST be tagged with a root S-VLAN. Note, this can be done 364 by adding a root C-VLAN first in a C-VLAN bridge but this is out of 365 the scope of this document. 367 For a C-VLAN tagged port, the Ethernet frames received from the root 368 ACs MUST be tagged with a root S-VLAN. 370 For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames 371 received from the root ACs SHOULD be translated to the root S-VLAN 372 in the VPLS network domain. 374 Alternatively, for an S-VLAN tagged port, the PBB VPLS PE model 375 (where an IEEE 802.1ah bridge module is embedded in the PE) as 376 described in [RFC7041] MAY be used. A root B-VLAN or leaf B-VLAN MAY 377 be added. The E-Tree attribute may also be indicated with two I-SID 378 tags in the bridge module, and the frames are then encapsulated and 379 transported transparently over a single B-VLAN. Thus the PBB VPLS 380 works in the same way as described in [RFC7041] and will not be 381 discussed further in this document. When many S-VLANs are 382 multiplexed in a single AC, PBB VPLS has the advantages of both VLAN 383 scalability and MAC address scalability. 385 In a similar way, the traffic from the leaf ACs is tagged and 386 transported on the leaf C-VLAN, S-VLAN or B-VLAN. 388 In all cases, the outermost VLAN in the resulting Ethernet header is 389 used to indicate the E-Tree attribute of an Ethernet frame; this 390 document uses VLAN to refer to this outermost VLAN for simplicity in 391 the latter sections. 393 5. PW for E-Tree Support 395 5.1. PW Encapsulation 397 To support an E-Tree service, T-VSIs in a VPLS MUST be 398 interconnected with a bidirectional Ethernet PW. The Ethernet PW 399 SHOULD work in the tagged mode (PW type 0x0004) as described in 400 [RFC4448], in which case a VLAN tag MUST be carried in each frame in 401 the PW to indicate the frame originated from either root or leaf 402 (the VLAN tag indicating the frame originated from either root or 403 leaf can be translated by a bridge module in the PE or added by an 404 outside Ethernet edge device, even by a customer device). In the 405 tagged PW mode, two service delimiting VLANs MUST be allocated in 406 the VPLS domain for an E-Tree. PW processing for the tagged PW will 407 be described in Section 5.3 of this document. 409 A raw mode PW (PW type 0x0005 in [RFC4448]) MAY also be used to 410 carry E-Tree service for a PW in Compatible mode as shown in Section 411 5.3.2. As defined in [RFC4448], for a raw mode PW, an Ethernet 412 frame's 802.1Q VLAN tag is not meaningful to the PEs and it passes 413 transparently through them. 415 5.2. VLAN Mapping 417 There are two ways of manipulating VLANs for an E-Tree in VPLS: 419 o Global VLAN based, that is, provisioning two global VLANs (Root 420 VLAN, Leaf VLAN) across the VPLS network, thus no VLAN mapping is 421 needed at all, or the VLAN mapping is done completely in the 422 Ethernet domains. 424 o Local VLAN based, that is, provisioning two local VLANs for each 425 PE (which participates in the E-Tree) in the VPLS network 426 independently. 428 The first method requires no VLAN mapping in the PW, but two unique 429 service delimiting VLANs must be allocated across the VPLS domain. 431 The second method is more scalable in the use of VLANs, but needs a 432 VLAN mapping mechanism in the PW similar to what is already 433 described in Section 4.3 of [RFC4448]. 435 Global or local VLANs can be manually configured or provisioned by 436 an Operational Support System. Alternatively, some automatic VLAN 437 allocation algorithm may be provided in the management plane, but it 438 is out of scope of this document. 440 For both methods, VLAN mapping parameters from a remote PE can be 441 provisioned or determined by a signaling protocol as described in 442 Section 6 when a PW is being established. 444 5.3. PW Processing 446 5.3.1. PW Processing in the VLAN Mapping Mode 448 In the VLAN Mapping mode, two VPLS PEs with E-Tree capability are 449 inter-connected with a PW (For example, the scenario of Fig. 5 450 depicts the interconnection of two PEs attached with both root and 451 leaf nodes). 453 +----------------------------+ 454 | VPLS PE with T-VSI | 455 | | 456 +----+ | +------+ Root VLAN +-----+ | PW 457 |Root|------| VLAN |-----------|T-VSI|---------- 458 +----+ | | BRG | Leaf VLAN | |---------- 459 +----+ | | |-----------| |---------- 460 |Leaf|------| | | |-----+ 461 +----+ | +------+ +-----+ | | 462 | | | 463 +----------------------------+ | 464 | 465 +----------------------------+ | 466 | VPLS PE with T-VSI | | 467 | | | 468 +----+ | +------+ Root VLAN +-----+ | | PW 469 |Root|------| VLAN |-----------|T-VSI|-----+ 470 +----+ | | BRG | Leaf VLAN | |---------- 471 +----+ | | |-----------| |---------- 472 |Leaf|------| | | |---------- 473 +----+ | +------+ +-----+ | 474 | | BRG: Bridge Module 475 +----------------------------+ 476 Figure 5 T-VSI Interconnected in the Normal Mode 478 If a PE is in the VLAN mapping mode for a PW, then in the data plane 479 the PE MUST map the VLAN in each frame as follows: 481 o Upon transmitting frames on the PW, map from local VLAN to remote 482 VLAN (i.e., the local leaf VLAN in a frame is translated to the 483 remote leaf VLAN; the local root VLAN in a frame is translated to 484 the remote root VLAN). 486 o Upon receiving frames on the PW, map from remote VLAN to local 487 VLAN, and the frames are further forwarded or dropped in the egress 488 bridge module using the filtering mechanism as described in [802.1Q- 489 2014]. 491 The signaling for VLANs used by E-Tree is specified in Section 6. 493 5.3.2. PW Processing in the Compatible Mode 495 The new VPLS PE model can work in a traditional VPLS network 496 seamlessly in the compatibility mode. As shown in Fig. 6, the VPLS 497 PE with T-VSI can be attached with root and/or leaf nodes, while the 498 VPLS PE with a traditional VSI can only be attached with root nodes. 499 A raw PW SHOULD be used to connect them. 501 +------------------------+ 502 | VPLS PE with T-VSI | 503 | | 504 +----+ | +------+ +-----+ | PW 505 |Root|------| VLAN |-------|T-VSI|---------- 506 +----+ | | BRG | | |---------- 507 +----+ | | |-------| |---------- 508 |Leaf|------| | | |---------+ 509 +----+ | +------+ +-----+ | | 510 | | | 511 +------------------------+ | 512 | 513 +------------------------+ | 514 | VPLS PE with VSI | | 515 | | | 516 +----+ | +------+ +-----+ | PW | 517 |Root|------| VLAN |-------|VSI |---------+ 518 +----+ | | BRG | | |---------- 519 +----+ | | | | |---------- 520 |Root|------| | | |---------- 521 +----+ | +------+ +-----+ | 522 | | 523 +------------------------+ 525 Figure 6 T-VSI interconnected with Traditional VSI 527 If a PE is in the Compatible mode for a PW, then in the data plane 528 the PE MUST process the frame as follows: 530 o Upon transmitting frames on the PW, remove the root or leaf VLAN 531 in the frames. 533 o Upon receiving frames on the PW, add a VLAN tag with a value of 534 the local root VLAN to the frames. 536 5.3.3. PW Processing in the Optimized Mode 538 When two PEs (both have E-Tree capability) are inter-connected with 539 a PW and one of them (e.g., PE2) is attached with only leaf nodes, 540 as shown in the scenario of Fig. 7, its peer PE (e.g., PE1) should 541 then work in the optimized mode for this PW. In this case, PE1 542 should not send the frames originated from the local leaf VLAN to 543 PE2, i.e., these frames are dropped rather than transported over the 544 PW. The bandwidth efficiency of the VPLS can thus be improved. The 545 signaling for the PE attached with only leaf nodes is specified in 546 Section 6. 547 +------------------------+ 548 |VPLS PE with T-VSI (PE1)| 549 | | 550 +----+ | +------+ +-----+ | PW 551 |Root|------| VLAN |-------|T-VSI|---------- 552 +----+ | | BRG | | |---------- 553 +----+ | | |-------| |---------- 554 |Leaf|------| | | |---------+ 555 +----+ | +------+ +-----+ | | 556 | | | 557 +------------------------+ | 558 | 559 +------------------------+ | 560 |VPLS PE with T-VSI (PE2)| | 561 | | | 562 +----+ | +------+ +-----+ | PW | 563 |Leaf|------| VLAN |-------|T-VSI|---------+ 564 +----+ | | BRG | | |---------- 565 +----+ | | |-------| |---------- 566 |Leaf|------| | | |---------- 567 +----+ | +------+ +-----+ | 568 | | 569 +------------------------+ 571 Figure 7 T-VSI interconnected with PE attached with only leaf nodes 573 If a PE is in the Optimized Mode for a PW, upon transmit, the PE 574 SHOULD first operate as follows: 576 o Drop a frame if its VLAN ID matches the local leaf VLAN ID. 578 6. Signaling for E-Tree Support 580 6.1. LDP Extensions for E-Tree Support 582 In addition to the signaling procedures as specified in Section 583 5.3.3 of [RFC4447], this document specifies a new interface 584 parameter sub-TLV to provision an E-Tree service and negotiate the 585 VLAN mapping function, as follows: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | E-Tree(0x1A) | Length=8 | Reserved |P|V| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | MBZ | Root VLAN ID | MBZ | Leaf VLAN ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Figure 8 E-Tree Sub-TLV 596 Where: 598 o E-Tree is the sub-TLV identifier (0x1A) as assigned by IANA. 600 o Length is the length of the sub TLV in octets. 602 o Reserved, bits MUST be set to zero on transmit and be ignored on 603 receive. 605 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 606 attached with only leaf nodes, and set to 0 otherwise. 608 o V is a bit indicating the sender's VLAN mapping capability. A PE 609 capable of VLAN mapping MUST set this bit, and clear it otherwise. 611 o MBZ, Must Be Zero, 4 bits MUST be set to zero on transmit and be 612 ignored on receive. 614 o Root VLAN ID is the value of the local root VLAN. 616 o Leaf VLAN ID is the value of the local leaf VLAN. 618 When setting up a PW for the E-Tree based VPLS, two peer PEs 619 negotiate the E-Tree support using the above E-Tree sub-TLV. Note PW 620 type of 0x0004 SHOULD be used during the PW negotiation. 622 A PE that wishes to support E-Tree service MUST include an E-Tree 623 Sub-TLV in its PW label mapping message and include its local root 624 VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping 625 capability MUST set the V bit to 1, and a PE attached with only leaf 626 nodes SHOULD set the P bit to 1. 628 A PE that receives a PW label mapping message with an E-Tree Sub-TLV 629 from its peer PE, after saving the VLAN information for the PW, MUST 630 process it as follows: 632 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 633 Optimized-Mode to FALSE. 635 2) If either the root VLAN ID in the message is not equal to the 636 local root VLAN ID or the leaf VLAN ID in the message is not equal 637 to the local leaf VLAN ID { 639 If the bit V is cleared { 641 If the PE is capable of VLAN mapping, it MUST set VLAN- 642 Mapping-Mode to TRUE; 644 Else { 646 A label release message with the error code "E- 647 Tree VLAN mapping not supported" is sent to the 648 peer PE and exit the process; 650 } 652 } 654 If the bit V is set, and the PE is capable of VLAN mapping, 655 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 656 to TRUE; 658 } 660 3) If the P bit is set 662 { 664 If the PE is a leaf-only node itself, a label release message 665 with a status code "Leaf to Leaf PW released" is sent to the peer 666 PE and exit the process; 668 Else the PE SHOULD set the Optimized-Mode to TRUE. 670 } 672 A PE SHOULD send a Label Mapping message with an E-Tree Sub-TLV as 673 per Section 5.3.3 of [RFC4447]. A PE MUST send a Label Mapping 674 message with an updated E-Tree Sub-TLV to all other PEs over 675 corresponding LDP sessions when its role changes from leaf-only to 676 not leaf-only (i.e., when a root node is added to a PE attached with 677 only leaf nodes). 679 If a PE has sent a Label Mapping message with an E-Tree Sub-TLV but 680 does not receive any E-Tree Sub-TLV in its peer's PW label mapping 681 message, The PE SHOULD then establish a raw PW with this peer as in 682 traditional VPLS and set Compatible-Mode to TRUE for this PW. 684 Data plane processing for this PW is as following: 686 If Optimized-Mode is TRUE, then data plane processing as described 687 in Section 5.3.3 applies. 689 If VLAN-Mapping-Mode is TRUE, then data plane processing as 690 described in Section 5.3.1 applies. 692 If Compatible-Mode is TRUE, then data plane processing is as 693 described in Section 5.3.2. 695 PW processing as described in [RFC4448] proceeds as usual for all 696 cases. 698 When VPLS is set up using Pseudowire ID (PWid) Forwarding 699 Equivalence Class (FEC) Element (see Appendix A of [RFC4762]), its 700 E-Tree signaling is similar to the above process. Dynamic re- 701 configuration of E-Tree should be avoided for this case, however, 702 when re-configuration of E-Tree is forced on a PE for some reason 703 (e.g., a configuration error), the PE may close the LDP sessions 704 with its peer PEs for this VPLS instance, and re-install its PW 705 labels, so that its peer PEs can send out the LDP label mapping 706 messages again. 708 6.2. BGP Extensions for E-Tree Support 710 A new E-Tree extended community (0x800b) is allocated by IANA for E- 711 Tree signaling in BGP VPLS: 713 +------------------------------------+ 714 | Extended community type (2 octets) | 715 +------------------------------------+ 716 | MBZ | Root VLAN (12 bits) | 717 +------------------------------------+ 718 | MBZ | Leaf VLAN (12 bits) | 719 +------------------------------------+ 720 | Reserved |P|V| 721 +------------------------------------+ 723 Figure 9 E-Tree Extended Community 725 Where: 727 o MBZ, Must Be Zero, 4 bits MUST be set to zero on transmit and be 728 ignored on receive. 730 o Root VLAN ID is the value of the local root VLAN. 732 o Leaf VLAN ID is the value of the local leaf VLAN. 734 o Reserved, 14 bits MUST be set to zero on transmit and be ignored 735 on receive. 737 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 738 attached with only leaf nodes, and set to 0 otherwise. 740 o V is a bit indicating the sender's VLAN mapping capability. A PE 741 capable of VLAN mapping MUST set this bit, and clear it otherwise. 743 The PEs attached with both leaf and root nodes MUST support BGP E- 744 Tree signaling as described in this document, and SHOULD support 745 VLAN mapping in their data planes. The traditional PE attached with 746 only root nodes may also participate in an E-Tree service. If some 747 PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST 748 be provisioned for an E-Tree service. 750 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 751 Community as detailed in [RFC4761], an E-Tree Extended Community 752 MUST be further attached if a PE wishes to participate in an E-Tree 753 service. The PE MUST include its local root VLAN ID and leaf VLAN ID 754 in the E-Tree Extended Community. A PE attached with only leaf nodes 755 of an E-Tree SHOULD set the P bit in the E-Tree Extended Community 756 to 1. 758 A PE that receives a BGP UPDATE message with an E-Tree Extended 759 Community from its peer PE, after saving the VLAN information for 760 the PW, MUST process it as follows (after processing procedures as 761 specified in Section 3.2 of [RFC4761]): 763 1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and 764 Optimized-Mode to FALSE. 766 2) If either the root VLAN ID in the E-Tree Extended Community is 767 not equal to the local root VLAN ID or the leaf VLAN ID in the E- 768 Tree Extended Community is not equal to the local leaf VLAN ID { 770 If the bit V is cleared { 772 If the PE is capable of VLAN mapping, it MUST set VLAN- 773 Mapping-Mode to TRUE; 775 Else { 777 Log with a message "E-Tree VLAN mapping not 778 supported" and exit the process; 780 } 782 } 784 If the bit V is set, and the PE is capable of VLAN mapping, 785 the PE with the minimum IP address MUST set VLAN-Mapping-Mode 786 to TRUE; 788 } 790 3) If the P bit is set { 792 If the PE is a leaf-only PE itself, forbids any traffic on the 793 PW; 795 Else the PE SHOULD set the Optimized-Mode to TRUE. 797 } 799 A PE which does not recognize this attribute SHALL ignore it 800 silently. If a PE has sent an E-Tree Extended Community but does not 801 receive any E-Tree Extended Community from its peer, the PE SHOULD 802 then establish a raw PW with this peer as in traditional VPLS, and 803 set Compatible-Mode to TRUE for this PW. 805 Data plane in the VPLS is the same as described in Section 4.2 of 806 [RFC4761], and data plane processing for a PW is the same as 807 described at the end of Section 6.1 in this document. 809 7. OAM Considerations 811 VPLS OAM requirements and framework as specified in [RFC6136] are 812 applicable to E-Tree, as both Ethernet OAM frames and data traffic 813 are transported over the same PW. 815 Ethernet OAM for E-Tree including both service OAM and segment OAM 816 frames SHALL undergo the same VLAN mapping as the data traffic; and 817 root VLAN SHOULD be applied to segment OAM frames so that they are 818 not filtered. 820 8. Applicability 822 The solution specified in this document is applicable to both LDP 823 VPLS [RFC4762] and BGP VPLS [RFC4761]. 825 This solution is applicable to both "VPLS Only" networks and VPLS 826 with Ethernet aggregation networks. 828 This solution is also applicable to PBB VPLS networks. 830 9. Security Considerations 832 This solution requires implementations to prevent leaf to leaf 833 communication in the data plane of VPLS when its PEs are 834 interconnected with PWs. If all PEs enforce that then network 835 attacks from one leaf to another leaf are avoided, and security can 836 be enhanced for customers with this solution. However, if a PE is 837 compromised or inappropriately configured, a leaf node may be taken 838 as a root node and may receive traffic from other leaf nodes 839 inappropriately. Authenticity and integrity measures for LDP need to 840 be considered as in RFC 5036 [RFC5036]. Security considerations as 841 described in [RFC4448], [RFC4761] and [RFC4762] also apply. 843 10. IANA Considerations 845 IANA allocated a value for E-Tree in the registry of Pseudowire 846 Interface Parameters Sub-TLV type. 848 Parameter ID Length Description 849 ======================================= 850 0x1A 8 E-Tree 852 IANA allocated two new LDP status codes from the registry of name 853 "STATUS CODE NAME SPACE". 855 Range/Value E Description 856 ------------- ----- ---------------------- 857 0x20000003 1 E-Tree VLAN mapping not supported 858 0x20000004 0 Leaf to Leaf PW released 860 IANA allocated a value for E-Tree in the registry of BGP Extended 861 Community. 863 Type Value Sub-Type Value Name 864 ========== ============== ============ 865 0x80 0x0b E-Tree Info 867 11. References 869 11.1. Normative References 871 [802.1Q-2014] IEEE Std 802.1Q-2014, Bridges and Bridged Networks, 872 November 2014. 874 [MEF6.2] Metro Ethernet Forum, "EVC Ethernet Services Definitions 875 Phase 3", Technical Specification MEF 6.2, August 2014. 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and Heron, 881 G., "Pseudowire Setup and Maintenance Using Label 882 Distribution Protocol (LDP)", RFC 4447, April 2006. 884 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and Heron,G., 885 "Encapsulation Methods for Transport of Ethernet over MPLS 886 Networks", RFC 4448, April 2006. 888 [RFC4761] Kompella, K., and Rekhter, Y., "Virtual Private LAN 889 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 890 RFC 4761, January 2007. 892 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN 893 Services using LDP", RFC 4762, January 2007. 895 [RFC5036] Andersson, L. Minei, I. and Thomas, B., "LDP 896 Specification", RFC 5036, October 2007. 898 11.2. Informative References 900 [802.1Q-2003] IEEE Std 802.1Q-2003, Virtual Bridged Local Area 901 Networks, May 2003. 903 [MEF4] Metro Ethernet Forum, Metro Ethernet Network Architecture 904 Framework - Part 1: Generic Framework, Technical 905 Specification MEF 4, May 2004. 907 [RFC3985] Bryant, S., and Pate, P., "Pseudo Wire Emulation Edge-to- 908 Edge (PWE3) Architecture", RFC 3985, March 2005. 910 [RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2 911 Virtual Private Networks (L2VPNs)", RFC 4664, September 912 2006. 914 [RFC6136] Sajassi, A. and Mohan, D., "L2VPN OAM Requirements and 915 Framework", RFC 6136, March 2011. 917 [RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Serbest, Y., 918 "Virtual Private LAN Service (VPLS) Interoperability with 919 Customer Edge (CE) Bridges", RFC 6246, June 2011. 921 [RFC7041] Balus, F., Sajassi, A., and Bitar, N., Extensions to VPLS 922 PE model for Provider Backbone Bridging, RFC 7041, 923 November 2013. 925 [RFC7152] Key, R., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. 926 Paul, "Requirements for Metro Ethernet Forum (MEF) 927 Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private 928 Network (L2VPN)", RFC 7152, March 2014. 930 [RFC7387] Key, R., Yong, L., DeLord, S., Jounay, F., and Jin, L., "A 931 Framework for Ethernet Tree (E-Tree) Service over a 932 Multiprotocol Label Switching (MPLS) Network", RFC 7387, 933 October 2014. 935 [VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., 936 and L. Jin, "Framework and Requirements for Virtual 937 Private Multicast Service (VPMS)", Work in Progress, 938 draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012. 940 12. Acknowledgments 942 The authors would like to thank Stewart Bryant, Lizhong Jin, Deborah 943 Brungard, Russ Housley, Stephen Farrell, Sheng Jiang, Alvaro Retana 944 and Ben Campbell for their detailed reviews and suggestions, thank 945 Adrian Farrel, Susan Hares, Shane Amante and Andrew Malis for their 946 valuable advices, thank Ben Mack-crane, Edwin Mallette, Donald Fedyk, 947 Dave Allan, Giles Heron, Raymond Key, Josh Rogers, Sam Cao and 948 Daniel Cohn for their valuable comments and discussions. 950 Appendix A. Other PE Models for E-Tree 952 A.1. A PE Model With a VSI and No bridge 954 If there is no bridge module in a PE, the PE may consist of Native 955 Service Processors (NSPs) as shown in Figure A.1 (adapted from Fig. 956 5 of [RFC3985]) where any transformation operation for VLANs (e.g., 957 VLAN insertion/removal or VLAN mapping) may be applied. Thus a root 958 VLAN or leaf VLAN can be added by the NSP depending on the User 959 Network Interface (UNI) type (root/leaf) associated with the AC over 960 which the packet arrives. 962 Further, when a packet with a leaf VLAN exits a forwarder and 963 arrives at the NSP, the NSP must drop the packet if the egress AC is 964 associated with a leaf UNI. 966 Tagged PW and VLAN mapping work in the same way as in the typical PE 967 model. 969 +----------------------------------------+ 970 | PE Device | 971 Multiple+----------------------------------------+ 972 AC | | | Single | PW Instance 973 <------>o NSP # + PW Instance X<----------> 974 | | | | 975 |------| VSI |----------------------| 976 | | | Single | PW Instance 977 <------>o NSP #Forwarder + PW Instance X<----------> 978 | | | | 979 |------| |----------------------| 980 | | | Single | PW Instance 981 <------>o NSP # + PW Instance X<----------> 982 | | | | 983 +----------------------------------------+ 985 Figure A.1 A PE model with a VSI and no bridge module 987 This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a 988 Hierarchical VPLS (H-VPLS) network, or a Network-facing PE (N-PE) in 989 an H-VPLS network with non-bridging edge devices, wherein a spoke PW 990 can be treated as an AC in this model. 992 A.2. A PE Model With external E-Tree interface 994 +----------------------------------------+ 995 | PE Device | 996 Root +----------------------------------------+ 997 VLAN | | Single | PW Instance 998 <------>o + PW Instance X<----------> 999 | | | 1000 | VSI |----------------------| 1001 | | Single | PW Instance 1002 | Forwarder + PW Instance X<----------> 1003 | | | 1004 Leaf | |----------------------| 1005 VLAN | | Single | PW Instance 1006 <------>o + PW Instance X<----------> 1007 | | | 1008 +----------------------------------------+ 1010 Figure A.2 A PE model with external E-Tree interface 1012 A more simplified PE model is depicted in A.2, where Root/Leaf VLANs 1013 are directly or indirectly over a single PW connected to a same VSI 1014 forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN 1015 insertion/removal or VLAN mapping, can be performed by some outer 1016 equipments, and the PE may further translate these VLANs into its 1017 own local VLANs. This PE model may be used by an N-PE in an H-VPLS 1018 network with bridging-capable devices, or scenarios such as 1019 providing E-Tree Network-to-Network interfaces. 1021 Authors' Addresses 1023 Yuanlong Jiang 1024 Huawei Technologies Co., Ltd. 1025 Bantian, Longgang district 1026 Shenzhen 518129, China 1027 Email: jiangyuanlong@huawei.com 1029 Lucy Yong 1030 Huawei USA 1031 207 Estrella Xing 1032 Georgetown TX, USA 78628 1033 Email: lucyyong@huawei.com 1035 Manuel Paul 1036 Deutsche Telekom 1037 Winterfeldtstr. 21 1038 10781 Berlin, Germany 1039 Email: manuel.paul@telekom.de 1041 Frederic Jounay 1042 Orange CH 1043 4 rue caudray 1020 Renens, Switzerland 1044 Email: frederic.jounay@orange.ch 1046 Florin Balus 1047 Alcatel-Lucent 1048 701 E. Middlefield Road 1049 Mountain View, CA, USA 94043 1050 Email: florin.balus@alcatel-lucent.com 1052 Wim Henderickx 1053 Alcatel-Lucent 1054 Copernicuslaan 50 1055 2018 Antwerp, Belgium 1056 Email: wim.henderickx@alcatel-lucent.com 1058 Ali Sajassi 1059 Cisco 1060 170 West Tasman Drive 1061 San Jose, CA 95134, USA 1062 Email: sajassi@cisco.com