Network Working Group Raymond Key Internet Draft Simon Delord Category: Standard Track Telstra Expires: May 2010 Frederic Jounay France Telecom Wim Henderickx Alcatel-Lucent Lucy Yong Huawei Lizhong Jin Nokia Siemens Networks November 9, 2009 Extension to VPLS for E-Tree draft-key-l2vpn-vpls-etree-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 9, 2010. Key, et al. Expires May 2010 [Page 1] Internet Draft Extension to VPLS for E-Tree November 2009 Abstract This document proposes a simple and effective approach to emulate E-Tree services over an MPLS network. Section 4 presents a minimal extension to the current VPLS architecture defined in [RFC4761] and [RFC4762] to fulfil the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility issues are addressed also. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction....................................................3 2. Terminology.....................................................4 3. Reference Model.................................................5 4. Extension to VPLS for E-Tree....................................6 4.1. AC Type.......................................................6 4.2. Control Word.................... .............................6 4.3. Additional Action in Data Forwarding..........................6 5. Backward Compatibility..........................................8 5.1. AC Type.......................................................8 5.2. Control Word.................... .............................8 5.3. Additional Action in Data Forwarding..........................8 5.3.1. Ingress PE Supporting the Extension but Egress PE Not.......8 5.3.2. Egress PE Supporting the Extension but Ingress PE Not.......9 6. Hierarchical VPLS...............................................9 7. Optional Enhancement............................................9 8. Security Considerations........................................10 9. IANA Considerations............................................10 10. Acknowledgements..............................................11 11. References....................................................11 11.1. Normative References........................................11 11.2. Informative References......................................11 Appendix A. Control Word Scenarios................................12 Appendix B. Data Forwarding Scenarios.............................13 Authors' Addresses................................................24 Intellectual Property and Copyright Statements....................25 Key, et al. Expires May 2010 [Page 2] Internet Draft Extension to VPLS for E-Tree November 2009 1. Introduction A specific type of multipoint Ethernet services has been defined by Metro Ethernet Forum (MEF), called E-Tree [MEF6.1]. At the difference of E-LAN where there is no communication restriction between endpoints, on E-Tree each endpoint is designated as either a Root or a Leaf. Root can communicate with all other endpoints on the E-Tree, however Leaf can only communicate with Roots but not Leafs. The work in progress [Draft ETree Frwk] proposes a solution framework for supporting MEF E-Tree services over a MPLS network. E-LAN services are currently emulated via the use of the VPLS architecture. This document presents a minimal extension to the current VPLS architecture defined in [RFC4761] and [RFC4762], with the objective to provide a simple and effective approach to fulfil the additional requirements of E-Tree compared to E-LAN. Backward compatibility issues are also addressed in this document. PEs supporting the extension specified in this document and PEs not supporting such extension can inter-operate and participate in the same VPLS instance. This document does not intend to address efficient packet replication or bandwidth optimisation, but the approach presented here does not prohibit future enhancements on those aspects. In this document, "current standard" refers to [RFC4385], [RFC4447], [RFC4448], [RFC4761] and [RFC4762]. Key, et al. Expires May 2010 [Page 3] Internet Draft Extension to VPLS for E-Tree November 2009 2. Terminology E-Tree An Ethernet VPN in which each Root AC can communicate with every other AC, whereas Leaf ACs can only communicate with Root ACs. Each AC on an E-Tree construct is designated as either a Root AC or a Leaf AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct. Root AC An ingress frame at a Root AC can be delivered to one or more of any of the other ACs in the E-Tree. Please note that this AC is bidirectional. Leaf AC Ingress frame at a Leaf AC can only be delivered to one or more Root ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered to any Leaf ACs in the E-Tree. Please note that this AC is bidirectional. Key, et al. Expires May 2010 [Page 4] Internet Draft Extension to VPLS for E-Tree November 2009 3. Reference Model Figure 1 below describes a generic reference model where PE1, PE2 and PE3 need to establish an E-Tree construct between different Ethernet endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI. These VSIs are then linked together via Ethernet PWs. In most use cases, an E-Tree construct has only a few Root ACs but many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE. <------------E-Tree------------> +---------+ +---------+ | PE1 | | PE2 | +----+ | +---+ | | +---+ | +----+ |CE01+----AC1----+--+ | | | | +--+--- AC5----+CE05| +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ +----+ | | | | | | | | +----+ |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ +----+ | | | | | | | | +----+ |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ +----+ | | | | | | | | +----+ |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ | | | | | | +----+----+ +----+----+ | | |Ethernet |Ethernet |PW |PW | | | +----+----+ | | | | | | +-+-+ | +----+ | | | +--+----AC9----+CE09| | | | V | | (Root AC) +----+ | | | | | +----+ | | | +--+----AC10---+CE10| +-----------------+--+ S | | (Root AC) +----+ | | | | +----+ | | +--+----AC11---+CE11| | | I | | (Leaf AC) +----+ | | | | +----+ | | +--+----AC12---+CE12| | +---+ | (Leaf AC) +----+ | PE3 | +---------+ <------------E-Tree------------> Figure 1: E-Tree Reference Model Key, et al. Expires May 2010 [Page 5] Internet Draft Extension to VPLS for E-Tree November 2009 With an E-Tree construct: - A Root AC can receive from and transmit to any other ACs. - A Leaf AC can receive from and transmit to any Root ACs. - A Leaf AC cannot receive from and transmit to any other Leaf ACs. This applies to all traffic, including Unicast Known, Unicast Unknown, Broadcast and Multicast. When an Ethernet Frame is received on PE1 via AC1, the frame can be transmitted to any other local ACs on PE1 and via Ethernet PWs to any remote ACs on PE2 and PE3. However when an Ethernet Frame is received on PE1 via AC3, the frame can be transmitted to any other local Root ACs on PE1 and via Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame cannot be transmitted to any local Leaf ACs on PE1 nor any remote Leaf ACs on PE2 and PE3. 4. Extension to VPLS for E-Tree 4.1 AC Type Each AC connected to a specific VPLS instance on a PE MUST have an AC Type attribute, either Leaf AC or Root AC. The default value for AC Type attribute MUST be Root AC. This AC Type is only locally configured on a PE and no signaling is required between PEs. 4.2 Control Word A PE MUST be capable of sending and receiving the Control Word on Ethernet PW. Use of Control Word on Ethernet PW MUST be PREFERRED. The procedure for negotiating the use of Control Word as per current standard is sufficient and MUST be followed. As a result, Control Word will always be used on Ethernet PW between two PEs when both PEs support the extension specified in this document. Refer to Appendix A for different Control Word scenarios. 4.3 Additional Action in Data Forwarding A PE MUST support the Control Word L-bit defined in [Draft CW L-bit]. A PE MUST perform the additional actions specified in Table 1 below. Key, et al. Expires May 2010 [Page 6] Internet Draft Extension to VPLS for E-Tree November 2009 The "Set CW L-bit" action and "Forward or Drop" decision are in addition to and performed after the following - MAC-based forwarding decision as per current standard - Loop free VPLS "split horizon" rule (MUST NOT forward traffic from one PW to another PW in the same VPLS mesh) as per current standard +-----+---------------------------------------+---------------------+ | | IF Conditions AND | THEN Actions | |Rule +---------------+---------------+-------+-----------+---------+ | | Forward | Receive | CW | Set CW | Forward | | | Frame to | Frame from | L-bit | L-bit | or Drop | +-----+---------------+---------------+-------+-----------+---------+ | 1 | Root AC | any | any | n/a | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 2 | PW with no CW | any | any | n/a | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 3 | PW with CW | Root AC | n/a | Set to 0 | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 4 | PW with CW | Leaf AC | n/a | Set to 1 | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 5 | Leaf AC | Root AC | n/a | n/a | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 6 | Leaf AC | Leaf AC | n/a | n/a | Drop | +-----+---------------+---------------+-------+-----------+---------+ | 7 | Leaf AC | PW with no CW | n/a | n/a | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 8 | Leaf AC | PW with CW | = 0 | n/a | Forward | +-----+---------------+---------------+-------+-----------+---------+ | 9 | Leaf AC | PW with CW | = 1 | n/a | Drop | +-----+---------------+---------------+-------+-----------+---------+ Table 1: Additional Action in Data Forwarding "Forward Frame to" is the result of MAC-based forwarding decision as per current standard. "CW L-bit" is the bit 4 in the Ethernet PW Control Word as defined in [Draft CW L-bit] (the 5th bit in Control Word since the first bit is bit 0). The CW L-bit = 1 if and only if the payload Ethernet frame is from a Leaf AC. Refer to Appendix B for different data forwarding scenarios. Key, et al. Expires May 2010 [Page 7] Internet Draft Extension to VPLS for E-Tree November 2009 5. Backward Compatibility 5.1. AC Type Since there is no restriction on communication between any ACs connected to a VPLS instance as per current standard, on a PE not supporting the extension specified in this document, an AC is functionally equivalent to a Root AC as per the extension specified in this document. 5.2. Control Word For backward compatibility reason, use of Control Word on Ethernet PW is not mandatory. If the PE on the other end prefers not to use Control Word or does not support Control Word (which implies such PE does not support the extension specified in this document), then Control Word will not be used on the Ethernet PW. Refer to Appendix A for different Control Word scenarios. 5.3. Additional Action in Data Forwarding For backward compatibility reason, a PE not supporting the extension specified in this document can participate in an E-Tree construct, but only Root ACs can be connected to such PE. Lack of Control Word L-bit per-payload signaling between a PE supporting the extension specified in this document and a PE not supporting such extension does not result in any problem. Refer to Appendix B for different data forwarding scenarios. 5.3.1 Ingress PE Support the Extension but Egress PE Not If Control Word is used on the Ethernet PW, the ingress PE will set CW L-bit to either 0 or 1 (Rule 3 and Rule 4 in Table 1). The egress PE will ignore the reserved bits (which include the L-bit position) as per current standard [RFC4448] and forward the frame. This is correct as only Root ACs exist on a PE not supporting the extension specified in this document. A Root AC can receive from any other ACs. If Control Word is not used on the Ethernet PW, there will be no CW L-bit. The egress PE will forward the frame as per current standard. This is correct as only Root ACs exist on a PE not supporting the extension specified in this document. A Root AC can receive from any other ACs. Key, et al. Expires May 2010 [Page 8] Internet Draft Extension to VPLS for E-Tree November 2009 5.3.2 Egress PE Support the Extension but Ingress PE Not If Control Word is used on the Ethernet PW, the ingress PE will set the reserved bits (which include the L-bit position) to 0 as per current standard [RFC4448]. The egress PE will process it as CW L-bit = 0, which means the frame is from a Root AC. The is correct as only Root ACs exist on a PE not supporting the extension specified in this document. A Root AC can transmit to any other ACs. If Control Word is not used on the Ethernet PW, there will be no CW L-bit. The egress PE will process it in the same way as CW L-bit = 0 (compare Rule 7 and Rule 8 in Table 1), which means the frame is from a Root AC. The is correct as only Root ACs exist on a PE not support the extension specified in this document. A Root AC can transmit to any other ACs. 6. Hierarchical VPLS This will be added in next version of this document. 7. Optional Enhancement Enhancements could be done regarding efficient packet replication or bandwidth optimisation within the carrier's network. Please note that these are not MANDATORY for achieving an E-Tree implementation using VPLS. One example is the Leaf-only PE scenario, briefly discussed below. In the context of a specific VPLS instance, a Leaf-only PE means that the PE has only Leaf ACs connected to it. In Figure 2 below, PE2 and PE3 are Leaf-only PEs. Key, et al. Expires May 2010 [Page 9] Internet Draft Extension to VPLS for E-Tree November 2009 <------------E-Tree------------> +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | | +---+ | +---+ |CE1+----AC1----+--+ V | | | | V +--+----AC3----+CE3| +---+ (Root AC) | | S +--+----PW12----+--+ S | | (Leaf AC) +---+ +---+ | | I | | | | I | | +---+ |CE2+----AC2----+--+ | | | | +--+----AC4----+CE4| +---+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +---+ +----+----+ +----+----+ | | |PW13 |PW23 | | | +----+----+ | | +-+-+ | +---+ | | | v +--+----AC5----+CE5| +-----------------+--+ s | | (Leaf AC) +---+ | | I | | +---+ | | +--+----AC6----+CE6| | +---+ | (Leaf AC) +---+ | PE3 | +---------+ <------------E-Tree------------> Figure 2: Reference Model for Leaf-only PE Scenario With an E-Tree construct, a Leaf AC cannot receive from and transmit to any other Leaf ACs. Pseudowire PW23 is between two Leaf-only PEs, therefore it is not supposed to carry any traffic. If removal of such pseudowire can bring significant benefits, enhancement in this aspect may be desirable. When PE1 receives a Unicast Unknown frame via AC2, PE1 will set CW L-bit to 1 and forward the frame to pseudowires PW12 and PW13. PE2 receives the frame via PW12 but does not forward it to any ACs. Similar for PE3. Network bandwidth is consumed and then the egress PE decides to drop the frame. This generally applies to Unicast Unknown, Broadcast and Multicast from a Leaf AC towards Leaf-only egress PE. If these types of traffic are significant in volume, enhancement in this aspect may be desirable. Further discussion will be added in next version of this document. 8. Security Considerations This will be added in next version of this document. 9. IANA Considerations There are no specific IANA considerations in this document. Key, et al. Expires May 2010 [Page 10] Internet Draft Extension to VPLS for E-Tree November 2009 10. Acknowledgements The authors would like to thank Yuji Kamite for his valuable comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN, February 2006. [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), April 2006 [RFC4448] Martini, L., and al, Encapsulation Methods for Transport of Ethernet over MPLS Networks, April 2006 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, January 2007 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, January 2007 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - Phase 2, April 2008 [Draft CW L-bit] Delord, et al., Control Word Reserved bit for use in E-Tree, draft-delord-pwe3-cw-bit-etree-01.txt, November 2009 [Draft ETree Frwk] Key, et al., A Framework for E-Tree Service over MPLS Network, draft-key-l2vpn-etree-frwk-00.txt, November 2009 11.2. Informative References Key, et al. Expires May 2010 [Page 11] Internet Draft Extension to VPLS for E-Tree November 2009 Appendix A. Control Word Scenarios As per current standard [RFC4447]: If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it is has no extra protocol to execute; it just waits for a Label Mapping message that has c=0. There are three possible scenarios. +----------+--------------+--------------------------+--------------+ | | PE1 | PE2 | Control Word | | Scenario +--------------+------------+-------------+ used on PW | | | Support this |Support this| Support | between PE1 | | | Extension? | Extension? |Control Word?| and PE2? | +----------+--------------+------------+-------------+--------------+ | 1 | Yes | Yes | Yes | Yes | +----------+--------------+------------+-------------+--------------+ | 2 | Yes | No | Yes | Yes | +----------+--------------+------------+-------------+--------------+ | 3 | Yes | No | No | No | +----------+--------------+------------+-------------+--------------+ Table 2: Control Word Scenarios For Scenario 2, although Control Word is used on the Ethernet PW, the two PEs process the Control Word L-bit differently: - PE1 will always set and interpret the CW L-bit as specified in [Draft CW L-bit], i.e. 0 = from Root AC; 1 = from Leaf AC. - PE2 will always set the CW L-bit to 0 when sending a frame on the PW and ignore the CW L-bit when receiving a frame from the PW. Actually PE2 has no concept of CW L-bit but just treat it as bit 4, one of the reserved bits for future use. Key, et al. Expires May 2010 [Page 12] Internet Draft Extension to VPLS for E-Tree November 2009 Appendix B. Data Forwarding Scenarios B.1. Reference Model <------------E-Tree------------> +---------+ +---------+ | PE1 | | PE2 | +----+ | +---+ | | +---+ | +----+ |CE01+----R11----+--+ | | | | +--+----R21----+CE05| +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ +----+ | | | | | | | | +----+ |CE02+----R12----+--+ | | | | +--+----R22----+CE06| +----+ (Root AC) | | S +--+----PW12----+--+ S | | (Root AC) +----+ +----+ | | | |Control Word| | | | +----+ |CE03+----L11----+--+ | | | | +--+----L21----+CE07| +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ +----+ | | | | | | | | +----+ |CE04+----L12----+--+ | | | | +--+----L22----+CE08| +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ | | | | | | +----+----+ +----+----+ | | |PW13 |PW23 |Control Word |No Control Word | | | +----+----+ | | | | | | +-+-+ | | | | V | | +----+ | | | +--+----R31----+CE09| +-----------------+--+ S | | (Root AC) +----+ | | | | +----+ | | I +--+----R32----+CE10| | | | | (Root AC) +----+ | +---+ | | PE3 | +---------+ <------------E-Tree------------> Figure 3: Reference Model for Data Forwarding Scenarios PE1 and PE2 both support the extension specified in this document. PE3 does not support the extension specified in this document. In this appendix - "this extension" means the extension to VPLS specified in this document. - "Rule" refers to Rules in Table 1 in Section 4.3. Key, et al. Expires May 2010 [Page 13] Internet Draft Extension to VPLS for E-Tree November 2009 B.2. Unicast Known B.2.1. From Root AC to Root AC 9 scenarios, per source and destination matching in table below. +-----------+-----------------------+ | | Destination | | Source +-------+-------+-------+ | | PE1 | PE2 | PE3 | +-----+-----+-------+-------+-------+ | PE1 | R11 | R12 | R21 | R31 | +-----+-----+-------+-------+-------+ | PE2 | R21 | R11 | R22 | R31 | +-----+-----+-------+-------+-------+ | PE3 | R31 | R11 | R21 | R32 | +-----+-----+-------+-------+-------+ B.2.1.1. From R11 to R12 (same PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to R12. (2) PE1: Forward as per this extension. (Rule 1) B.2.1.2. From R11 to R21 (different PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW12. (2) PE1: As per this extension, set L-bit to 0. (Rule 3) (3) PE2: MAC-based forwarding decision as per current standard, forward frame to R21. (4) PE2: Forward as per this extension. (Rule 1) B.2.1.3. From R11 to R31 (different PE, egress PE not support this extension, control word on PW) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW13. (2) PE1: As per this extension, set L-bit to 0. (Rule 3) (3) PE3: MAC-based forwarding decision as per current standard, forward frame to R31. (4) PE3: PE3 not support this extension, L-bit ignored and forward frame. B.2.1.4. From R21 to R11 (different PE) Similar to B.2.1.2. Key, et al. Expires May 2010 [Page 14] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.1.5. From R21 to R22 (same PE) Similar to B.2.1.1. B.2.1.6. From R21 to R31 (different PE, egress PE not support this extension, no control word on PW) (1) PE2: MAC-based forwarding decision as per current standard, forward frame to PW23. (2) PE2: No additional L-bit action as per this extension. (Rule 2) (3) PE3: MAC-based forwarding decision as per current standard, forward frame to R31. (4) PE3: PE3 not support this extension, forward frame. B.2.1.7. From R31 to R11 (different PE, ingress PE not support this extension, control word on PW) (1) PE3: MAC-based forwarding decision as per current standard, forward frame to PW13. (2) PE3: PE3 not support this extension, no L-bit action. (3) PE1: MAC-based forwarding decision as per current standard, forward frame to R11. (4) PE1: Forward as per this extension. (Rule 1) B.2.1.8. From R31 to R21 (different PE, ingress PE not support this extension, no control word on PW) (1) PE3: MAC-based forwarding decision as per current standard, forward frame to PW23. (2) PE3: PE3 not support this extension, no L-bit action. (3) PE2: MAC-based forwarding decision as per current standard, forward frame to R21. (4) PE2: Forward as per this extension. (Rule 1) B.2.1.9. From R31 to R32 (same PE, PE not support this extension) (1) PE3: MAC-based forwarding decision as per current standard, forward frame to R32. (2) PE3: PE3 not support this extension, forward frame. Key, et al. Expires May 2010 [Page 15] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.2. From Root AC to Leaf AC 6 scenarios, per source and destination matching in table below. +-----------+-----------------------+ | | Destination | | Source +-------+-------+-------+ | | PE1 | PE2 | PE3 | +-----+-----+-------+-------+-------+ | PE1 | R11 | L11 | L21 | --- | +-----+-----+-------+-------+-------+ | PE2 | R21 | L11 | L21 | --- | +-----+-----+-------+-------+-------+ | PE3 | R31 | L11 | L21 | --- | +-----+-----+-------+-------+-------+ B.2.2.1. From R11 to L11 (same PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to L11. (2) PE1: Forward as per this extension. (rule 5) B.2.2.2. From R11 to L21 (different PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW12. (2) PE1: As per this extension, set L-bit to 0. (Rule 3) (3) PE2: MAC-based forwarding decision as per current standard, forward frame to L21. (4) PE2: Forward as per this extension. (Rule 8) B.2.2.3. From R21 to L11 (different PE) Similar to B.2.2.2. B.2.2.4. From R21 to L21 (same PE) Similar to B.2.2.1. Key, et al. Expires May 2010 [Page 16] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.2.5. From R31 to L11 (different PE, ingress PE not support this extension, control word on PW) (1) PE3: MAC-based forwarding decision as per current standard, forward frame to PW13. (2) PE3: PE3 not support this extension, no L-bit action. As per current standard, the corresponding bit position must be set to 0. (3) PE1: MAC-based forwarding decision as per current standard, forward frame to L11. (4) PE1: Forward as per this extension. (Rule 8) B.2.2.6. From R31 to L21 (different PE, ingress PE not support this extension, no control word on PW) (1) PE3: MAC-based forwarding decision as per current standard, forward frame to PW23. (2) PE3: PE3 not support this extension, no L-bit action. (3) PE2: MAC-based forwarding decision as per current standard, forward frame to L21. (4) PE2: Forward as per this extension. (Rule 7) Key, et al. Expires May 2010 [Page 17] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.3. From Leaf AC to Root AC 6 scenarios, per source and destination matching in table below. +-----------+-----------------------+ | | Destination | | Source +-------+-------+-------+ | | PE1 | PE2 | PE3 | +-----+-----+-------+-------+-------+ | PE1 | L11 | R11 | R21 | R31 | +-----+-----+-------+-------+-------+ | PE2 | L21 | R11 | R21 | R31 | +-----+-----+-------+-------+-------+ | PE3 | --- | --- | --- | --- | +-----+-----+-------+-------+-------+ B.2.3.1. From L11 to R11 (same PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to R11. (2) PE1: Forward as per this extension. (Rule 1) B.2.3.2. From L11 to R21 (different PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW12. (2) PE1: As per this extension, set L-bit to 1. (Rule 4) (3) PE2: MAC-based forwarding decision as per current standard, forward frame to R21. (4) PE2: Forward as per this extension. (Rule 1) B.2.3.3. From L11 to R31 (different PE, egress PE not support this extension, control word on PW) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW13. (2) PE1: As per this extension, set L-bit to 1. (Rule 4) (3) PE3: MAC-based forwarding decision as per current standard, forward frame to R31. (4) PE3: PE3 not support this extension, as per current standard L-bit ignored and forward frame. Key, et al. Expires May 2010 [Page 18] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.3.4. From L21 to R11 (different PE) Similar to B.2.3.2. B.2.3.5. From L21 to R21 (same PE) Similar to B.2.3.1. B.2.3.6. From L21 to R31 (different PE, egress PE not support this extension, no control word on PW) (1) PE2: MAC-based forwarding decision as per current standard, forward frame to PW23. (2) PE2: No L-bit action as per this extension. (Rule 2) (3) PE3: MAC-based forwarding decision as per current standard, forward frame to R31. (4) PE3: PE3 not support this extension, forward frame. Key, et al. Expires May 2010 [Page 19] Internet Draft Extension to VPLS for E-Tree November 2009 B.2.4. From Leaf AC to Leaf AC (MUST NOT Forward) 4 scenarios, per source and destination matching in table below. +-----------+-----------------------+ | | Destination | | Source +-------+-------+-------+ | | PE1 | PE2 | PE3 | +-----+-----+-------+-------+-------+ | PE1 | L11 | L12 | L21 | --- | +-----+-----+-------+-------+-------+ | PE2 | L21 | L11 | L22 | --- | +-----+-----+-------+-------+-------+ | PE3 | --- | --- | --- | --- | +-----+-----+-------+-------+-------+ B.2.4.1. From L11 to L12 (same PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to L12. (2) PE1: As per this extension, drop frame. (Rule 6) B.2.4.2. From L11 to L21 (different PE) (1) PE1: MAC-based forwarding decision as per current standard, forward frame to PW12. (2) PE1: As per this extension, set L-bit to 1. (Rule 4) (3) PE2: MAC-based forwarding decision as per current standard, forward frame to L21. (4) PE2: As per this extension, drop frame. (Rule 9) B.2.4.3. From L21 to L11 (different PE) Similar to B.2.4.2. B.2.4.4. From L21 to L22 (same PE) Similar to B.2.4.1. Key, et al. Expires May 2010 [Page 20] Internet Draft Extension to VPLS for E-Tree November 2009 B.3. Unicast Unknown B.3.1. From Root AC Forward to all other AC. B.3.1.1. From R11 (1) PE1: MAC-based forwarding decision as per current standard, forward frame to R12, L11, L12, PW12 and PW13. (2) PE1: Forward as per this extension. (Rule 1, 5, 3) (3) PE1: For PW12 and PW13, as per this extension, set L-bit to 0. (Rule 3) (4) PE2: MAC-based forwarding decision as per current standard, forward frame to R21, R22, L21 and L22. (5) PE2: As per this extension, forward frame. (Rule 1, 8) (6) PE3: MAC-based forwarding decision as per current standard, forward frame to R31 and R32. (7) PE3: PE3 not support this extension, as per current standard L-bit ignored and forward frame. B.3.1.2. From R21 (1) PE2: MAC-based forwarding decision as per current standard, forward frame to R22, L21, L22, PW12 and PW23. (2) PE2: Forward as per this extension. (Rule 1, 5, 3, 2) (3) PE2: For PW12, as per this extension, set L-bit to 0. (Rule 3) (4) PE2: For PW23, no L-bit action as per this extension. (Rule 2) (5) PE1: MAC-based forwarding decision as per current standard, forward frame to R11, R12, L11 and L12. (6) PE1: As per this extension, forward frame. (Rule 1, 8) (7) PE3: MAC-based forwarding decision as per current standard, forward frame to R31 and R32. (8) PE3: PE3 not support this extension, forward frame. Key, et al. Expires May 2010 [Page 21] Internet Draft Extension to VPLS for E-Tree November 2009 B.3.1.3. From R31 (1) PE3: MAC-based forwarding decision as per current standard, forward frame to R32, PW13 and PW23. (2) PE3: PE3 not support this extension, forward frame. (3) PE3: For PW13, PE3 not support this extension, no L-bit action. As per current standard, the corresponding bit position must be set to 0. (4) PE3: For PW23, PE3 not support this extension, no L-bit action. No control word on PW23. (5) PE1: MAC-based forwarding decision as per current standard, forward frame to R11, R12, L11 and L12. (6) PE1: As per this extension, forward frame. (Rule 1, 8) (7) PE2: MAC-based forwarding decision as per current standard, forward frame to R21, R22, L21 and L22. (8) PE2: As per this extension, forward frame. (Rule 1, 7) B.3.2. From Leaf AC Forward to all Root AC only. B.3.2.1. From L11 (1) PE1: MAC-based forwarding decision as per current standard, forward frame to R11, R12, L12, PW12 and PW13. (2) PE1: For R11 and R12, forward as per this extension. (Rule 1) (3) PE1: For L12, as per this extension, drop frame. (Rule 6) (4) PE1: For PW12 and PW13, as per this extension, set L-bit to 1. (Rule 4) (5) PE2: MAC-based forwarding decision as per current standard, forward frame to R21, R22, L21 and L22. (6) PE2: For R21 and R22, forward as per this extension. (Rule 1) (7) PE2: For L21 and L22, as per this extension, drop frame. (Rule 9) (8) PE3: MAC-based forwarding decision as per current standard, forward frame to R31 and R32. (9) PE3: PE3 not support this extension, as per current standard L-bit ignored and forward frame. Key, et al. Expires May 2010 [Page 22] Internet Draft Extension to VPLS for E-Tree November 2009 B.3.2.2. From L21 (1) PE2: MAC-based forwarding decision as per current standard, forward frame to R21, R22, L22, PW12 and PW23. (2) PE2: For R21 and R22, forward as per this extension. (Rule 1) (3) PE2: For L22, as per this extension, drop frame. (Rule 6) (4) PE2: For PW12, as per this extension, set L-bit to 1. (Rule 4) (5) PE2: For PW23, no L-bit action as per this extension. (Rule 2) (6) PE1: MAC-based forwarding decision as per current standard, forward frame to R11, R12, L11 and L12. (7) PE1: For R11 and R12, forward as per this extension. (Rule 1) (8) PE1: For L11 and L12, as per this extension, drop frame. (Rule 9) (9) PE3: MAC-based forwarding decision as per current standard, forward frame to R31 and R32. (10) PE3: PE3 not support this extension, forward frame. B.4. Broadcast Same as Unicast Unknown in B.3. B.5. Multicast Same as Unicast Unknown in B.3. Key, et al. Expires May 2010 [Page 23] Internet Draft Extension to VPLS for E-Tree November 2009 Authors' Addresses Raymond Key Telstra 242 Exhibition St Melbourne VIC 3000 Australia Email: raymond.key@team.telstra.com Simon Delord Telstra 242 Exhibition St Melbourne VIC 3000 Australia Email: simon.a.delord@team.telstra.com Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: frederic.jounay@orange-ftgroup.com Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium Email: wim.henderickx@alcatel-lucent.be Lucy Yong Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075, USA Email: lucyyong@huawei.com Lizhong Jin Nokia Siemens Networks Building 89, 1122 North QinZhou Road Shanghai, 200211 P.R.China Email: lizhong.jin@nsn.com Key, et al. Expires May 2010 [Page 24] Internet Draft Extension to VPLS for E-Tree November 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Key, et al. Expires May 2010 [Page 25]