idnits 2.17.1 draft-key-l2vpn-vpls-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4761], [RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2011) is 4569 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Raymond Key, Huawei 3 Internet Draft Simon Delord, Alcatel-Lucent 4 Category: Standard Track Frederic Jounay, Orange France Telecom 5 Expires: April 2012 Wim Henderickx, Alcatel-Lucent 6 Lucy Yong, Huawei 7 Lizhong Jin, ZTE 9 October 16, 2011 11 Extension to VPLS for E-Tree 12 draft-key-l2vpn-vpls-etree-06 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 16, 2012. 37 Abstract 39 This document proposes a simple and effective approach to emulate 40 E-Tree services over an MPLS network. Section 4 presents a minimal 41 extension to the current VPLS architecture defined in [RFC4761] and 42 [RFC4762] to fulfil the specific E-Tree requirement: Leaf cannot 43 communicate with Leaf. Backward compatibility issues are addressed 44 also. 46 Table of Contents 48 1. Introduction....................................................3 49 2. Terminology.....................................................4 50 3. Reference Model.................................................5 51 4. Extension to VPLS for E-Tree....................................6 52 4.1. AC Type.......................................................6 53 4.2. Control Word.................... .............................6 54 4.3. Additional Action in Data Forwarding..........................6 55 5. Backward Compatibility..........................................8 56 5.1. AC Type.......................................................8 57 5.2. Control Word.................... .............................8 58 5.3. Additional Action in Data Forwarding..........................8 59 5.3.1. Ingress PE Supporting the Extension but Egress PE Not.......8 60 5.3.2. Egress PE Supporting the Extension but Ingress PE Not.......9 61 6. Optional Enhancements for Leaf-only PE..........................9 62 6.1. No PW between Leaf-only PEs..................................10 63 6.2. Not Forward Frame from Leaf AC to Leaf-only PE...............10 64 7. Hierarchical VPLS..............................................10 65 7.1. Hierarchical LDP VPLS........................................10 66 7.1.1. Spoke Connectivity for Bridging-Capable Devices............10 67 7.1.2. Multi-domain VPLS Service..................................11 68 7.1.3. Spoke Connectivity for Non-Bridging Devices................11 69 7.1.4. Hierarchical VPLS Model using Ethernet Access Network......12 70 7.2. Hierarchical BGP VPLS........................................12 71 8. Compliance with Requirements...................................12 72 9. Security Considerations........................................12 73 10. IANA Considerations...........................................12 74 11. Acknowledgements..............................................12 75 12. References....................................................13 76 12.1. Normative References........................................13 77 12.2. Informative References......................................13 78 Appendix A. Control Word Scenarios................................14 79 Appendix B. Data Forwarding Scenarios.............................15 80 Authors' Addresses................................................26 81 Intellectual Property and Copyright Statements....................26 83 Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 1. Introduction 91 A specific type of multipoint Ethernet services has been defined by 92 Metro Ethernet Forum (MEF), called E-Tree [MEF6.1]. At the difference 93 of E-LAN where there is no communication restriction between 94 endpoints, on E-Tree each endpoint is designated as either a Root or 95 a Leaf. Root can communicate with all other endpoints on the E-Tree, 96 however Leaf can only communicate with Roots but not Leafs. 98 [Draft VPLS ETree Req] provides the functional requirements for MEF 99 E-Tree support in VPLS. 101 E-LAN services are currently emulated via the use of the VPLS 102 architecture. 104 This document presents a minimal extension to the current VPLS 105 architecture defined in [RFC4761] and [RFC4762], with the objective 106 to provide a simple and effective approach to fulfil the additional 107 requirements of E-Tree compared to E-LAN. 109 Backward compatibility issues are also addressed in this document. 110 PEs supporting the extension specified in this document and PEs not 111 supporting such extension can inter-operate and participate in the 112 same VPLS instance. 114 This document does not intend to address efficient packet replication 115 or bandwidth optimisation, but the approach presented here does not 116 prohibit future enhancements on those aspects. 118 In this document, "current standard" refers to [RFC4385], [RFC4447], 119 [RFC4448], [RFC4761] and [RFC4762]. 121 2. Terminology 123 E-Tree 125 An Ethernet VPN in which each Root AC can communicate with every 126 other AC, whereas Leaf ACs can only communicate with Root ACs. Each 127 AC on an E-Tree construct is designated as either a Root AC or a Leaf 128 AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct. 130 Root AC 132 An ingress frame at a Root AC can be delivered to one or more of 133 any of the other ACs in the E-Tree. Please note that this AC is 134 bidirectional. 136 Leaf AC 138 Ingress frame at a Leaf AC can only be delivered to one or more Root 139 ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered 140 to any Leaf ACs in the E-Tree. Please note that this AC is 141 bidirectional. 143 3. Reference Model 145 Figure 1 below describes a generic reference model where PE1, PE2 and 146 PE3 need to establish an E-Tree construct between different Ethernet 147 endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI. 148 These VSIs are then linked together via Ethernet PWs. 150 In most use cases, an E-Tree construct has only a few Root ACs but 151 many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE. 153 <------------E-Tree------------> 154 +---------+ +---------+ 155 | PE1 | | PE2 | 156 +----+ | +---+ | | +---+ | +----+ 157 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 158 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 159 +----+ | | | | | | | | +----+ 160 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 161 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 162 +----+ | | | | | | | | +----+ 163 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 164 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 165 +----+ | | | | | | | | +----+ 166 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 167 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 168 | | | | | | 169 +----+----+ +----+----+ 170 | | 171 |Ethernet |Ethernet 172 |PW |PW 173 | | 174 | +----+----+ 175 | | | | 176 | | +-+-+ | +----+ 177 | | | +--+----AC9----+CE09| 178 | | | V | | (Root AC) +----+ 179 | | | | | +----+ 180 | | | +--+----AC10---+CE10| 181 +-----------------+--+ S | | (Root AC) +----+ 182 | | | | +----+ 183 | | +--+----AC11---+CE11| 184 | | I | | (Leaf AC) +----+ 185 | | | | +----+ 186 | | +--+----AC12---+CE12| 187 | +---+ | (Leaf AC) +----+ 188 | PE3 | 189 +---------+ 190 <------------E-Tree------------> 192 Figure 1: E-Tree Reference Model 194 With an E-Tree construct: 195 - A Root AC can receive from and transmit to any other ACs. 196 - A Leaf AC can receive from and transmit to any Root ACs. 197 - A Leaf AC cannot receive from and transmit to any other Leaf ACs. 199 This applies to all traffic, including Unicast Known, Unicast 200 Unknown, Broadcast and Multicast. 202 When an Ethernet Frame is received on PE1 via AC1, the frame can be 203 transmitted to any other local ACs on PE1 and via Ethernet PWs to any 204 remote ACs on PE2 and PE3. 206 However when an Ethernet Frame is received on PE1 via AC3, the frame 207 can be transmitted to any other local Root ACs on PE1 and via 208 Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame 209 cannot be transmitted to any local Leaf ACs on PE1 nor any remote 210 Leaf ACs on PE2 and PE3. 212 4. Extension to VPLS for E-Tree 214 4.1 AC Type 216 Each AC connected to a specific VPLS instance on a PE MUST have an AC 217 Type attribute, either Leaf AC or Root AC. The default value for AC 218 Type attribute MUST be Root AC. 220 This AC Type is only locally configured on a PE and no signaling is 221 required between PEs. 223 4.2 Control Word 225 A PE MUST be capable of sending and receiving the Control Word on 226 Ethernet PW. Use of Control Word on Ethernet PW MUST be PREFERRED. 228 The procedure for negotiating the use of Control Word as per current 229 standard is sufficient and MUST be followed. As a result, Control 230 Word will always be used on Ethernet PW between two PEs when both PEs 231 support the extension specified in this document. 233 Refer to Appendix A for different Control Word scenarios. 235 4.3 Additional Action in Data Forwarding 237 A PE MUST support the Control Word L-bit defined in [Draft CW L-bit]. 239 A PE MUST perform the additional actions specified in Table 1 below. 241 The "Set CW L-bit" action and "Forward or Drop" decision are in 242 addition to and performed after the following 243 - MAC-based forwarding decision as per current standard 244 - Loop free VPLS "split horizon" rule (MUST NOT forward traffic 245 from one PW to another PW in the same VPLS mesh) as per current 246 standard 248 +-----+---------------------------------------+---------------------+ 249 | | IF Conditions AND | THEN Actions | 250 |Rule +---------------+---------------+-------+-----------+---------+ 251 | | Forward | Receive | CW | Set CW | Forward | 252 | | Frame to | Frame from | L-bit | L-bit | or Drop | 253 +-----+---------------+---------------+-------+-----------+---------+ 254 | 1 | Root AC | any AC/PW | any | n/a | Forward | 255 +-----+---------------+---------------+-------+-----------+---------+ 256 | 2 | PW with no CW | any AC | n/a | n/a | Forward | 257 +-----+---------------+---------------+-------+-----------+---------+ 258 | 3 | PW with CW | Root AC | n/a | Set to 0 | Forward | 259 +-----+---------------+---------------+-------+-----------+---------+ 260 | 4 | PW with CW | Leaf AC | n/a | Set to 1 | Forward | 261 +-----+---------------+---------------+-------+-----------+---------+ 262 | 5 | Leaf AC | Root AC | n/a | n/a | Forward | 263 +-----+---------------+---------------+-------+-----------+---------+ 264 | 6 | Leaf AC | Leaf AC | n/a | n/a | Drop | 265 +-----+---------------+---------------+-------+-----------+---------+ 266 | 7 | Leaf AC | PW with no CW | n/a | n/a | Forward | 267 +-----+---------------+---------------+-------+-----------+---------+ 268 | 8 | Leaf AC | PW with CW | = 0 | n/a | Forward | 269 +-----+---------------+---------------+-------+-----------+---------+ 270 | 9 | Leaf AC | PW with CW | = 1 | n/a | Drop | 271 +-----+---------------+---------------+-------+-----------+---------+ 273 Table 1: Additional Action in Data Forwarding 275 "Forward Frame to" is the result of MAC-based forwarding decision as 276 per current standard. 278 "CW L-bit" is the bit 4 in the Ethernet PW Control Word as defined in 279 [Draft CW L-bit] (the 5th bit in Control Word since the first bit is 280 bit 0). The CW L-bit = 1 if and only if the payload Ethernet frame is 281 from a Leaf AC. 283 Refer to Appendix B for different data forwarding scenarios. 285 5. Backward Compatibility 287 5.1. AC Type 289 Since there is no restriction on communication between any ACs 290 connected to a VPLS instance as per current standard, on a PE not 291 supporting the extension specified in this document, an AC is 292 functionally equivalent to a Root AC as per the extension specified 293 in this document. 295 5.2. Control Word 297 For backward compatibility reason, use of Control Word on Ethernet PW 298 is not mandatory. If the PE on the other end prefers not to use 299 Control Word or does not support Control Word (which implies such PE 300 does not support the extension specified in this document), then 301 Control Word will not be used on the Ethernet PW. 303 Refer to Appendix A for different Control Word scenarios. 305 5.3. Additional Action in Data Forwarding 307 For backward compatibility reason, a PE not supporting the extension 308 specified in this document can participate in an E-Tree construct, 309 but Leaf ACs MUST NOT be connected to such PE. 311 Lack of Control Word L-bit per-payload signaling between a PE 312 supporting the extension specified in this document and a PE not 313 supporting such extension does not result in any problem. 315 Refer to Appendix B for different data forwarding scenarios. 317 5.3.1 Ingress PE Support the Extension but Egress PE Not 319 If Control Word is used on the Ethernet PW, the ingress PE will set 320 CW L-bit to either 0 or 1 (Rule 3 and Rule 4 in Table 1). The egress 321 PE will ignore the reserved bits (which include the L-bit position) 322 as per current standard [RFC4448] and forward the frame. This is 323 correct as only Root ACs exist on a PE not supporting the extension 324 specified in this document. A Root AC can receive from any other ACs. 326 If Control Word is not used on the Ethernet PW, there will be no CW 327 L-bit. The egress PE will forward the frame as per current standard. 328 This is correct as only Root ACs exist on a PE not supporting the 329 extension specified in this document. A Root AC can receive from any 330 other ACs. 332 5.3.2 Egress PE Support the Extension but Ingress PE Not 334 If Control Word is used on the Ethernet PW, the ingress PE will set 335 the reserved bits (which include the L-bit position) to 0 as per 336 current standard [RFC4448]. The egress PE will process it as CW L-bit 337 = 0, which means the frame is from a Root AC. This is correct as only 338 Root ACs exist on a PE not supporting the extension specified in this 339 document. A Root AC can transmit to any other ACs. 341 If Control Word is not used on the Ethernet PW, there will be no CW 342 L-bit. The egress PE will process it in the same way as CW L-bit = 0 343 (compare Rule 7 and Rule 8 in Table 1), which means the frame is from 344 a Root AC. This is correct as only Root ACs exist on a PE not 345 supporting the extension specified in this document. A Root AC can 346 transmit to any other ACs. 348 6. Optional Enhancements for Leaf-only PE 350 It is important to note that the enhancements specified in this 351 section are OPTIONAL for achieving an E-Tree implementation using 352 VPLS. 354 In the context of a specific VPLS instance, a Leaf-only PE means that 355 the PE only has Leaf ACs connected to it. In Figure 2 below, PE2 and 356 PE3 are Leaf-only PEs. 358 <------------E-Tree------------> 359 +---------+ +---------+ 360 | PE1 | | PE2 | 361 +---+ | +---+ | | +---+ | +---+ 362 |CE1+----AC1----+--+ V | | | | V +--+----AC3----+CE3| 363 +---+ (Root AC) | | S +--+----PW12----+--+ S | | (Leaf AC) +---+ 364 +---+ | | I | | | | I | | +---+ 365 |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| 366 +---+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +---+ 367 +----+----+ +----+----+ 368 | | 369 |PW13 |PW23 370 | | 371 | +----+----+ 372 | | +-+-+ | +---+ 373 | | | v +--+----AC5----+CE5| 374 +-----------------+--+ s | | (Leaf AC) +---+ 375 | | I | | +---+ 376 | | +--+----AC6----+CE6| 377 | +---+ | (Leaf AC) +---+ 378 | PE3 | 379 +---------+ 380 <------------E-Tree------------> 382 Figure 2: Reference Model for Leaf-only PE 384 6.1. No PW between Leaf-only PEs 386 With an E-Tree construct, a Leaf AC cannot receive from and transmit 387 to any other Leaf ACs. Pseudowire PW23 is between two Leaf-only PEs, 388 and is therefore not supposed to carry any traffic. If removal of 389 such pseudowire can bring significant benefits, enhancement in this 390 aspect may be desirable. 392 6.2. Not Forward Frame from Leaf AC to Leaf-only PE 394 When PE1 receives a Broadcast frame via AC2, PE1 will set CW L-bit to 395 1 and forward the frame to pseudowires PW12 and PW13. PE2 receives 396 the frame via PW12 but does not forward it to any ACs. A similar 397 situation occurs for PE3. Network bandwidth is consumed and then the 398 egress PE decides to drop the frame. This applies to any frames 399 (Broadcast, Multicast, Unicast Known, Unicast Unknown) from a Leaf AC 400 towards a Leaf-only egress PE. If such traffic pattern is significant 401 in volume, enhancement in this aspect may be desirable. 403 Each PW on a PE MUST have an Leaf-only attribute, either Yes or NO, 404 indicating whether the peer PE at the other end of the PW is a 405 Leaf-only PE or not. The default value for Leaf-only attribute MUST 406 be No. 408 A PE MUST NOT forward a data frame on a PW with Leaf-only = Yes if 409 any of the following conditions is true 410 - The frame is from a Leaf AC 411 - The frame is from PW and the CW L-bit = 1 413 The Leaf-only attribute for each PW can be locally configured on a 414 PE for each PW, or MAY be decided through signaling between PEs. 416 For LDP VPLS, Interface Parameter Sub-TLV can be used for such 417 signaling, refer to section 5.5 in [RFC4447]. 419 For BGP VPLS, Signaling PE Capability can be used for such signaling, 420 refer to section 3.2.4 in [RFC4761]. 422 Further details will be added in later version of this document. 424 7. Hierarchical VPLS 426 7.1. Hierarchical LDP VPLS 428 7.1.1. Spoke Connectivity for Bridging-Capable Devices 430 This refers to section 10.1.1 in [RFC4762]. 432 MTU-s MUST support the extension specified in section 4 of this 433 document. 435 PE-rs MUST support the extension specified in section 4 of this 436 document. 438 PE-rs MUST perform the additional actions specified in Table 2 below 439 when forwarding a data frame from one PW to another PW. 441 The "Set CW L-bit" action and "Forward or Drop" decision are in 442 addition to and performed after the following 443 - MAC-based forwarding decision as per current standard 444 - Loop free VPLS "split horizon" rule (MUST NOT forward traffic 445 from one PW to another PW in the same VPLS mesh) as per current 446 standard 448 +-----+---------------------------------------+---------------------+ 449 | | IF Conditions AND | THEN Actions | 450 |Rule +---------------+---------------+-------+-----------+---------+ 451 | | Forward | Receive | CW | Set CW | Forward | 452 | | Frame to PW | Frame from PW | L-bit | L-bit | or Drop | 453 +-----+---------------+---------------+-------+-----------+---------+ 454 | H1 | PW with CW | PW with CW | any | Copy L-bit| Forward | 455 +-----+---------------+---------------+-------+-----------+---------+ 456 | H2 | PW with CW | PW with no CW | n/a | Set to 0 | Forward | 457 +-----+---------------+---------------+-------+-----------+---------+ 458 | H3 | PW with no CW | any PW | any | n/a | Forward | 459 +-----+---------------+---------------+-------+-----------+---------+ 461 Table 2: Additional Action in Data Forwarding - H-VPLS 463 7.1.2. Multi-domain VPLS Service 465 This refers to section 10.3 in [RFC4762]. 467 Border PE MUST support the extension specified in section 4 of this 468 document. 470 Border PE MUST perform the additional actions same as those specified 471 for PE-rs in section 7.1.1 when forwarding a data frame from one PW 472 to another PW. 474 7.1.3. Spoke Connectivity for Non-Bridging Devices 476 This refers to section 10.1.3 in [RFC4762]. 478 No change is required for PE-r. 480 Control Word is not required for the spoke PW between PE-rs and PE-r. 482 PE-rs MUST treat each spoke PW to PE-r equivalent to an AC of the 483 VPLS instance (consider it as an AC extended by a P2P PW), and MUST 484 support the extension specified in section 4.1 (AC Type) and section 485 4.3 (Additional Action in Data Forwarding) for such spoke PWs in the 486 same way as ACs. 488 7.1.4. Hierarchical VPLS Model using Ethernet Access Network 490 This refers to section 11 in [RFC4762]. 492 This will be added in later version of this document. 494 7.2. Hierarchical BGP VPLS 496 This refers to section 3.6 in [RFC4761]. 498 No change is required. 500 8. Compliance with Requirements 502 This refers to [Draft VPLS ETree Req] Section 5. Requirements. 504 The solution prohibits communication between any two Leaf ACs in a 505 VPLS instance. 507 The solution allows multiple Root ACs in a VPLS instance. 509 The solution allows Root AC and Leaf AC of a VPLS instance co-exist 510 on any PE. 512 The solution is applicable to both BGP-VPLS [RFC4761] and LDP-VPLS 513 [RFC4762]. 515 The solution is applicable to Case 1: Single technology "VPLS Only". 517 The solution has minimal impact on existing VPLS solution. 519 The solution is backward compatible with the existing VPLS solution. 521 9. Security Considerations 523 This will be added in later version of this document. 525 10. IANA Considerations 527 This will be added in later version of this document. 529 11. Acknowledgements 531 The authors would like to thank Chen Ran, Weilian Jiang and Yuji 532 Kamite for their valuable comments. 534 12. References 536 12.1. Normative References 538 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 539 Requirement Levels, BCP 14, RFC 2119, March 1997. 541 [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation 542 Edge-to-Edge (PWE3) Control Word for Use over an MPLS 543 PSN, February 2006. 545 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 546 Using the Label Distribution Protocol (LDP), April 2006 548 [RFC4448] Martini, L., and al, Encapsulation Methods for 549 Transport of Ethernet over MPLS Networks, April 2006 551 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) 552 Using BGP for Auto-Discovery and Signaling, January 2007 554 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 555 Using Label Distribution Protocol (LDP) Signaling, 556 January 2007 558 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - 559 Phase 2, April 2008 561 12.2. Informative References 563 [Draft VPLS ETree Req] 564 Key, et al., Requirements for MEF E-Tree Support in 565 VPLS, draft-ietf-l2vpn-etree-reqt-00 (work in progress), 566 October 2011 568 [Draft CW L-bit] 569 Delord, et al., Control Word Reserved bit for use in 570 E-Tree, draft-delord-pwe3-cw-bit-etree-06 (work in 571 progress), October 2011 573 Appendix A. Control Word Scenarios 575 As per current standard [RFC4447]: If both endpoints prefer the use 576 of the control word, this procedure will cause it to be used. If 577 either endpoint prefers not to use the control word or does not 578 support the control word, this procedure will cause it not to be 579 used. If one endpoint prefers to use the control word but the other 580 does not, the one that prefers not to use it is has no extra protocol 581 to execute; it just waits for a Label Mapping message that has c=0. 583 There are three possible scenarios. 585 +----------+--------------+--------------------------+--------------+ 586 | | PE1 | PE2 | Control Word | 587 | Scenario +--------------+------------+-------------+ used on PW | 588 | | Support this |Support this| Support | between PE1 | 589 | | Extension? | Extension? |Control Word?| and PE2? | 590 +----------+--------------+------------+-------------+--------------+ 591 | 1 | Yes | Yes | Yes | Yes | 592 +----------+--------------+------------+-------------+--------------+ 593 | 2 | Yes | No | Yes | Yes | 594 +----------+--------------+------------+-------------+--------------+ 595 | 3 | Yes | No | No | No | 596 +----------+--------------+------------+-------------+--------------+ 598 Table 2: Control Word Scenarios 600 For Scenario 2, although Control Word is used on the Ethernet PW, the 601 two PEs process the Control Word L-bit differently: 602 - PE1 will always set and interpret the CW L-bit as specified in 603 [Draft CW L-bit], i.e. 0 = from Root AC; 1 = from Leaf AC. 604 - PE2 will always set the CW L-bit to 0 when sending a frame on 605 the PW and ignore the CW L-bit when receiving a frame from the 606 PW. Actually PE2 has no concept of CW L-bit but just treat it 607 as bit 4, one of the reserved bits for future use. 609 Appendix B. Data Forwarding Scenarios 611 B.1. Reference Model 613 <------------E-Tree------------> 614 +---------+ +---------+ 615 | PE1 | | PE2 | 616 +----+ | +---+ | | +---+ | +----+ 617 |CE01+----R11----+--+ | | | | +--+----R21----+CE05| 618 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 619 +----+ | | | | | | | | +----+ 620 |CE02+----R12----+--+ | | | | +--+----R22----+CE06| 621 +----+ (Root AC) | | S +--+----PW12----+--+ S | | (Root AC) +----+ 622 +----+ | | | |Control Word| | | | +----+ 623 |CE03+----L11----+--+ | | | | +--+----L21----+CE07| 624 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 625 +----+ | | | | | | | | +----+ 626 |CE04+----L12----+--+ | | | | +--+----L22----+CE08| 627 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 628 | | | | | | 629 +----+----+ +----+----+ 630 | | 631 |PW13 |PW23 632 |Control Word |No Control Word 633 | | 634 | +----+----+ 635 | | | | 636 | | +-+-+ | 637 | | | V | | +----+ 638 | | | +--+----R31----+CE09| 639 +-----------------+--+ S | | (Root AC) +----+ 640 | | | | +----+ 641 | | I +--+----R32----+CE10| 642 | | | | (Root AC) +----+ 643 | +---+ | 644 | PE3 | 645 +---------+ 646 <------------E-Tree------------> 648 Figure 3: Reference Model for Data Forwarding Scenarios 650 PE1 and PE2 both support the extension specified in this document. 652 PE3 does not support the extension specified in this document. 654 In this appendix 655 - "this extension" means the extension to VPLS specified in this 656 document. 657 - "Rule" refers to Rules in Table 1 in Section 4.3. 659 B.2. Unicast Known 661 B.2.1. From Root AC to Root AC 663 9 scenarios, per source and destination matching in table below. 665 +-----------+-----------------------+ 666 | | Destination | 667 | Source +-------+-------+-------+ 668 | | PE1 | PE2 | PE3 | 669 +-----+-----+-------+-------+-------+ 670 | PE1 | R11 | R12 | R21 | R31 | 671 +-----+-----+-------+-------+-------+ 672 | PE2 | R21 | R11 | R22 | R31 | 673 +-----+-----+-------+-------+-------+ 674 | PE3 | R31 | R11 | R21 | R32 | 675 +-----+-----+-------+-------+-------+ 677 B.2.1.1. From R11 to R12 (same PE) 679 (1) PE1: MAC-based forwarding decision as per current standard, 680 forward frame to R12. 681 (2) PE1: Forward as per this extension. (Rule 1) 683 B.2.1.2. From R11 to R21 (different PE) 685 (1) PE1: MAC-based forwarding decision as per current standard, 686 forward frame to PW12. 687 (2) PE1: As per this extension, set L-bit to 0. (Rule 3) 688 (3) PE2: MAC-based forwarding decision as per current standard, 689 forward frame to R21. 690 (4) PE2: Forward as per this extension. (Rule 1) 692 B.2.1.3. From R11 to R31 (different PE, egress PE not support this 693 extension, control word on PW) 695 (1) PE1: MAC-based forwarding decision as per current standard, 696 forward frame to PW13. 697 (2) PE1: As per this extension, set L-bit to 0. (Rule 3) 698 (3) PE3: MAC-based forwarding decision as per current standard, 699 forward frame to R31. 700 (4) PE3: PE3 not support this extension, L-bit ignored and forward 701 frame. 703 B.2.1.4. From R21 to R11 (different PE) 705 Similar to B.2.1.2. 707 B.2.1.5. From R21 to R22 (same PE) 709 Similar to B.2.1.1. 711 B.2.1.6. From R21 to R31 (different PE, egress PE not support this 712 extension, no control word on PW) 714 (1) PE2: MAC-based forwarding decision as per current standard, 715 forward frame to PW23. 716 (2) PE2: No additional L-bit action as per this extension. (Rule 2) 717 (3) PE3: MAC-based forwarding decision as per current standard, 718 forward frame to R31. 719 (4) PE3: PE3 not support this extension, forward frame. 721 B.2.1.7. From R31 to R11 (different PE, ingress PE not support this 722 extension, control word on PW) 724 (1) PE3: MAC-based forwarding decision as per current standard, 725 forward frame to PW13. 726 (2) PE3: PE3 not support this extension, no L-bit action. 727 (3) PE1: MAC-based forwarding decision as per current standard, 728 forward frame to R11. 729 (4) PE1: Forward as per this extension. (Rule 1) 731 B.2.1.8. From R31 to R21 (different PE, ingress PE not support this 732 extension, no control word on PW) 734 (1) PE3: MAC-based forwarding decision as per current standard, 735 forward frame to PW23. 736 (2) PE3: PE3 not support this extension, no L-bit action. 737 (3) PE2: MAC-based forwarding decision as per current standard, 738 forward frame to R21. 739 (4) PE2: Forward as per this extension. (Rule 1) 741 B.2.1.9. From R31 to R32 (same PE, PE not support this extension) 743 (1) PE3: MAC-based forwarding decision as per current standard, 744 forward frame to R32. 745 (2) PE3: PE3 not support this extension, forward frame. 747 B.2.2. From Root AC to Leaf AC 749 6 scenarios, per source and destination matching in table below. 751 +-----------+-----------------------+ 752 | | Destination | 753 | Source +-------+-------+-------+ 754 | | PE1 | PE2 | PE3 | 755 +-----+-----+-------+-------+-------+ 756 | PE1 | R11 | L11 | L21 | --- | 757 +-----+-----+-------+-------+-------+ 758 | PE2 | R21 | L11 | L21 | --- | 759 +-----+-----+-------+-------+-------+ 760 | PE3 | R31 | L11 | L21 | --- | 761 +-----+-----+-------+-------+-------+ 763 B.2.2.1. From R11 to L11 (same PE) 765 (1) PE1: MAC-based forwarding decision as per current standard, 766 forward frame to L11. 767 (2) PE1: Forward as per this extension. (rule 5) 769 B.2.2.2. From R11 to L21 (different PE) 771 (1) PE1: MAC-based forwarding decision as per current standard, 772 forward frame to PW12. 773 (2) PE1: As per this extension, set L-bit to 0. (Rule 3) 774 (3) PE2: MAC-based forwarding decision as per current standard, 775 forward frame to L21. 776 (4) PE2: Forward as per this extension. (Rule 8) 778 B.2.2.3. From R21 to L11 (different PE) 780 Similar to B.2.2.2. 782 B.2.2.4. From R21 to L21 (same PE) 784 Similar to B.2.2.1. 786 B.2.2.5. From R31 to L11 (different PE, ingress PE not support this 787 extension, control word on PW) 789 (1) PE3: MAC-based forwarding decision as per current standard, 790 forward frame to PW13. 791 (2) PE3: PE3 not support this extension, no L-bit action. As per 792 current standard, the corresponding bit position must be 793 set to 0. 794 (3) PE1: MAC-based forwarding decision as per current standard, 795 forward frame to L11. 796 (4) PE1: Forward as per this extension. (Rule 8) 798 B.2.2.6. From R31 to L21 (different PE, ingress PE not support this 799 extension, no control word on PW) 801 (1) PE3: MAC-based forwarding decision as per current standard, 802 forward frame to PW23. 803 (2) PE3: PE3 not support this extension, no L-bit action. 804 (3) PE2: MAC-based forwarding decision as per current standard, 805 forward frame to L21. 806 (4) PE2: Forward as per this extension. (Rule 7) 808 B.2.3. From Leaf AC to Root AC 810 6 scenarios, per source and destination matching in table below. 812 +-----------+-----------------------+ 813 | | Destination | 814 | Source +-------+-------+-------+ 815 | | PE1 | PE2 | PE3 | 816 +-----+-----+-------+-------+-------+ 817 | PE1 | L11 | R11 | R21 | R31 | 818 +-----+-----+-------+-------+-------+ 819 | PE2 | L21 | R11 | R21 | R31 | 820 +-----+-----+-------+-------+-------+ 821 | PE3 | --- | --- | --- | --- | 822 +-----+-----+-------+-------+-------+ 824 B.2.3.1. From L11 to R11 (same PE) 826 (1) PE1: MAC-based forwarding decision as per current standard, 827 forward frame to R11. 828 (2) PE1: Forward as per this extension. (Rule 1) 830 B.2.3.2. From L11 to R21 (different PE) 832 (1) PE1: MAC-based forwarding decision as per current standard, 833 forward frame to PW12. 834 (2) PE1: As per this extension, set L-bit to 1. (Rule 4) 835 (3) PE2: MAC-based forwarding decision as per current standard, 836 forward frame to R21. 837 (4) PE2: Forward as per this extension. (Rule 1) 839 B.2.3.3. From L11 to R31 (different PE, egress PE not support this 840 extension, control word on PW) 842 (1) PE1: MAC-based forwarding decision as per current standard, 843 forward frame to PW13. 844 (2) PE1: As per this extension, set L-bit to 1. (Rule 4) 845 (3) PE3: MAC-based forwarding decision as per current standard, 846 forward frame to R31. 847 (4) PE3: PE3 not support this extension, as per current standard 848 L-bit ignored and forward frame. 850 B.2.3.4. From L21 to R11 (different PE) 852 Similar to B.2.3.2. 854 B.2.3.5. From L21 to R21 (same PE) 856 Similar to B.2.3.1. 858 B.2.3.6. From L21 to R31 (different PE, egress PE not support this 859 extension, no control word on PW) 861 (1) PE2: MAC-based forwarding decision as per current standard, 862 forward frame to PW23. 863 (2) PE2: No L-bit action as per this extension. (Rule 2) 864 (3) PE3: MAC-based forwarding decision as per current standard, 865 forward frame to R31. 866 (4) PE3: PE3 not support this extension, forward frame. 868 B.2.4. From Leaf AC to Leaf AC (MUST NOT Forward) 870 4 scenarios, per source and destination matching in table below. 872 +-----------+-----------------------+ 873 | | Destination | 874 | Source +-------+-------+-------+ 875 | | PE1 | PE2 | PE3 | 876 +-----+-----+-------+-------+-------+ 877 | PE1 | L11 | L12 | L21 | --- | 878 +-----+-----+-------+-------+-------+ 879 | PE2 | L21 | L11 | L22 | --- | 880 +-----+-----+-------+-------+-------+ 881 | PE3 | --- | --- | --- | --- | 882 +-----+-----+-------+-------+-------+ 884 B.2.4.1. From L11 to L12 (same PE) 886 (1) PE1: MAC-based forwarding decision as per current standard, 887 forward frame to L12. 888 (2) PE1: As per this extension, drop frame. (Rule 6) 890 B.2.4.2. From L11 to L21 (different PE) 892 (1) PE1: MAC-based forwarding decision as per current standard, 893 forward frame to PW12. 894 (2) PE1: As per this extension, set L-bit to 1. (Rule 4) 895 (3) PE2: MAC-based forwarding decision as per current standard, 896 forward frame to L21. 897 (4) PE2: As per this extension, drop frame. (Rule 9) 899 B.2.4.3. From L21 to L11 (different PE) 901 Similar to B.2.4.2. 903 B.2.4.4. From L21 to L22 (same PE) 905 Similar to B.2.4.1. 907 B.3. Unicast Unknown 909 B.3.1. From Root AC 911 Forward to all other AC. 913 B.3.1.1. From R11 915 (1) PE1: MAC-based forwarding decision as per current standard, 916 forward frame to R12, L11, L12, PW12 and PW13. 917 (2) PE1: Forward as per this extension. (Rule 1, 5, 3) 918 (3) PE1: For PW12 and PW13, as per this extension, set L-bit to 0. 919 (Rule 3) 920 (4) PE2: MAC-based forwarding decision as per current standard, 921 forward frame to R21, R22, L21 and L22. 922 (5) PE2: As per this extension, forward frame. (Rule 1, 8) 923 (6) PE3: MAC-based forwarding decision as per current standard, 924 forward frame to R31 and R32. 925 (7) PE3: PE3 not support this extension, as per current standard 926 L-bit ignored and forward frame. 928 B.3.1.2. From R21 930 (1) PE2: MAC-based forwarding decision as per current standard, 931 forward frame to R22, L21, L22, PW12 and PW23. 932 (2) PE2: Forward as per this extension. (Rule 1, 5, 3, 2) 933 (3) PE2: For PW12, as per this extension, set L-bit to 0. (Rule 3) 934 (4) PE2: For PW23, no L-bit action as per this extension. (Rule 2) 935 (5) PE1: MAC-based forwarding decision as per current standard, 936 forward frame to R11, R12, L11 and L12. 937 (6) PE1: As per this extension, forward frame. (Rule 1, 8) 938 (7) PE3: MAC-based forwarding decision as per current standard, 939 forward frame to R31 and R32. 940 (8) PE3: PE3 not support this extension, forward frame. 942 B.3.1.3. From R31 944 (1) PE3: MAC-based forwarding decision as per current standard, 945 forward frame to R32, PW13 and PW23. 946 (2) PE3: PE3 not support this extension, forward frame. 947 (3) PE3: For PW13, PE3 not support this extension, no L-bit action. 948 As per current standard, the corresponding bit position 949 must be set to 0. 950 (4) PE3: For PW23, PE3 not support this extension, no L-bit action. 951 No control word on PW23. 952 (5) PE1: MAC-based forwarding decision as per current standard, 953 forward frame to R11, R12, L11 and L12. 954 (6) PE1: As per this extension, forward frame. (Rule 1, 8) 955 (7) PE2: MAC-based forwarding decision as per current standard, 956 forward frame to R21, R22, L21 and L22. 957 (8) PE2: As per this extension, forward frame. (Rule 1, 7) 959 B.3.2. From Leaf AC 961 Forward to all Root AC only. 963 B.3.2.1. From L11 965 (1) PE1: MAC-based forwarding decision as per current standard, 966 forward frame to R11, R12, L12, PW12 and PW13. 967 (2) PE1: For R11 and R12, forward as per this extension. (Rule 1) 968 (3) PE1: For L12, as per this extension, drop frame. (Rule 6) 969 (4) PE1: For PW12 and PW13, as per this extension, set L-bit to 1. 970 (Rule 4) 971 (5) PE2: MAC-based forwarding decision as per current standard, 972 forward frame to R21, R22, L21 and L22. 973 (6) PE2: For R21 and R22, forward as per this extension. (Rule 1) 974 (7) PE2: For L21 and L22, as per this extension, drop frame. (Rule 9) 975 (8) PE3: MAC-based forwarding decision as per current standard, 976 forward frame to R31 and R32. 977 (9) PE3: PE3 not support this extension, as per current standard 978 L-bit ignored and forward frame. 980 B.3.2.2. From L21 982 (1) PE2: MAC-based forwarding decision as per current standard, 983 forward frame to R21, R22, L22, PW12 and PW23. 984 (2) PE2: For R21 and R22, forward as per this extension. (Rule 1) 985 (3) PE2: For L22, as per this extension, drop frame. (Rule 6) 986 (4) PE2: For PW12, as per this extension, set L-bit to 1. (Rule 4) 987 (5) PE2: For PW23, no L-bit action as per this extension. (Rule 2) 988 (6) PE1: MAC-based forwarding decision as per current standard, 989 forward frame to R11, R12, L11 and L12. 990 (7) PE1: For R11 and R12, forward as per this extension. (Rule 1) 991 (8) PE1: For L11 and L12, as per this extension, drop frame. (Rule 9) 992 (9) PE3: MAC-based forwarding decision as per current standard, 993 forward frame to R31 and R32. 994 (10) PE3: PE3 not support this extension, forward frame. 996 B.4. Broadcast 998 Same as Unicast Unknown in B.3. 1000 B.5. Multicast 1002 Same as Unicast Unknown in B.3. 1004 Authors' Addresses 1006 Raymond Key 1007 Huawei 1008 Email: raymond.key@ieee.org 1010 Simon Delord 1011 Alcatel-Lucent 1012 Email: simon.delord@gmail.com 1014 Frederic Jounay 1015 Orange France Telecom 1016 2, avenue Pierre-Marzin 1017 22307 Lannion Cedex, France 1018 Email: frederic.jounay@orange.com 1020 Wim Henderickx 1021 Alcatel-Lucent 1022 Copernicuslaan 50 1023 2018 Antwerp, Belgium 1024 Email: wim.henderickx@alcatel-lucent.com 1026 Lucy Yong 1027 Huawei USA 1028 1700 Alma Dr. Suite 500 1029 Plano, TX 75075, USA 1030 Email: lucy.yong@huawei.com 1032 Lizhong Jin 1033 ZTE Corporation 1034 889, Bibo Road 1035 Shanghai, 201203, China 1036 Email: lizhong.jin@zte.com.cn 1038 Copyright Notice 1040 Copyright (c) 2011 IETF Trust and the persons identified as the 1041 document authors. All rights reserved. 1043 This document is subject to BCP 78 and the IETF Trust's Legal 1044 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 1045 license-info) in effect on the date of publication of this document. 1046 Please review these documents carefully, as they describe your rights 1047 and restrictions with respect to this document.