Network Working Group Yuqun Cao Internet Draft Ruijie Networks Intended status: Standard Track January 29, 2012 Expires: July 2012 Extension to VPLS for E-Tree draft-cao-l2vpn-vpls-etree-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." Cao Expires July 29, 2012 [Page 1] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 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 July 29, 2012. Copyright Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service [RFC4761] [RFC4762]. The proposed solution is characterized by breaking pseudowire setup between Leaf endpoints in E-Tree instance to fulfill the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility is also considered in this document. Table of Contents 1. Introduction................................................3 2. Conventions used in this document............................5 3. Terminology.................................................5 4. Reference Model.............................................6 5. Extension to VPLS for E-Tree.................................9 5.1. Assumptions............................................9 5.2. PW setup Matrix.........................................9 5.3. Endpoint type..........................................9 5.4. Endpoint identifier designation........................10 5.4.1. Endpoint identifier designation using LDP FEC 128..10 5.4.2. Endpoint identifier designation using LDP FEC 129..10 5.4.3. Endpoint identifier designation using BGP..........10 5.5. Signaling procedures...................................11 5.5.1. Signaling endpoint type using LDP.................11 5.5.1.1. Extension to Interface Parameters Sub-TLV.....11 Cao Expires July 29, 2012 [Page 2] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 5.5.1.2. Extension to the Generalized FEC 129..........12 5.5.2. Signaling endpoint type using BGP.................12 5.6. PW setup and teardown..................................13 5.6.1. Signaling procedures using LDP FEC 128............13 5.6.2. Signaling procedures using the Generalized FEC 129.14 5.6.3. Signaling using BGP...............................15 5.6.3.1. Originated from Root endpoint................15 5.6.3.2. Originated from Leaf endpoint................16 5.7. Backward Compatibility.................................16 6. Extension to Data Plane for E-Tree..........................16 7. Compliance with Requirements................................17 8. Security Considerations.....................................17 9. IANA Considerations........................................17 10. References................................................17 10.1. Normative References..................................17 10.2. Informative References................................18 11. Acknowledgments...........................................18 1. Introduction A specific Rooted-multipoint service, Ethernet Tree (E-Tree), has been defined by Metro Ethernet Forum [MEF6.1]. Unlike MEF Ethernet LAN (E-LAN) service where there is no communication restriction between its attachment circuits, each attachment circuit of an E-Tree instance is designated as either a Root or a Leaf. A Root-AC can communicate with all other attachment circuit in an E-Tree instance, however a Leaf-AC can only communicate with Root-ACs but not Leafs. In VPLS application [RFC4761] [RFC4762], the attachment circuits can be thought as LAN interfaces that attach to "virtual LAN switches", and each attachment circuit in a VPLS instance is equivalent to the others, therefore the VPLS instance requires that a single pseudowire is established between each pair of PES in VPLS domain. [RFC6074] proposed Partial Mesh with a set of "import RTs" and "export RTs", but cannot fully meet the functional requirements in [Draft VPLS ETree Req]. In an E-Tree, the attachment circuits SHOULD be distinguished between Roots and Leafs. An E-Tree instance MAY have several Roots and several Leafs. Figure 1 below shows scenario for Leaf-to-Leaf communication restriction between a pair of PEs which have both Root and Leaf in an E-Tree: Cao Expires July 29, 2012 [Page 3] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 |<----------E-Tree-------->| | | V V +-------+ +---------+ | PE1 | | PE2 | +---+ | +---+ |Ethernet| +---+ | +---+ |CE1+----AC1---+-+ +-+--PW1---+--+ +--+---AC3----+CE3| +---+ (Root AC)| | V | | | | V | |(Root AC) +---+ | | S +-+--PW2---+--+ S | | +---+ | | I | | | | I | | +---+ |CE2+----AC2---+-+ +-+--PW3---+--+ +--+---AC4----+CE4| +---+ (Leaf AC)| +---+ | | +---+ | (Leaf AC)+---+ +-------+ +---------+ Figure 1 Leaf-to-Leaf communication restriction in E-Tree - Like A. 8 in [Draft ETree Frwk], a VSI on PE1 or PE2 in an E-Tree has two members, one is composed of all Root attachment circuits and called as Root endpoint; another is composed of all Leaf attachment circuits and called as Leaf endpoint. - 3 Ethernet pseudowires are established between the VSI of PE1 and the VSI of PE2 in Figure 1, where Ethernet PW1 is established for communication between Root AC(s) of PE1 and Root AC(s) of PE2, Ethernet PW2 is established for communication between Root AC(s) of PE1 and Leaf AC(s) of PE2, and Ethernet PW3 is established for communication between Leaf AC(s) of PE1 and Root AC(s) of PE2. There is no pseudowire between Leaf AC(s). - If PE2 transmits a frame from AC3, if it is unicast known, it will forward to the corresponding PW upon MAC address learning; If PE2 transmits an unicast unknown or broadcast from AC3, it will transmit it via PW2 and PW3. In this case PE1 will receive two copies and forward them to Root AC and Leaf AC respectively. - If PE2 receives a frame from PW2, for example, it will forward it to its Root AC directly; if PE2 receives one frame from PW3, it will forward to its Leaf AC directly since the frame comes from Root AC of PE1. There is no communication between AC2 and AC4 of PE2 since there is no bound pseudowire for them. The functional requirements for MEF E-Tree support in VPLS can be found in [Draft VPLS ETree Req]. This document presents a minimal extension to the current VPLS standard [RFC4761] [RFC4762] to break the ''communication channel'' between Leaf attachment circuits. Cao Expires July 29, 2012 [Page 4] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 2. 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 RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Terminology There are two potential solutions to restrict Leaf-to-Leaf communication: 1. Extension to data forwarding: Each frame carries additional information to indicate that it is originated from a Leaf AC or Root AC on the ingress PE, egress PE will know forward behavior of the frame: if it comes from Leaf, it will NOT be forwarded to its local Leaf ACs. [Draft Ext VPLS for ETree] proposes this solution. 2. Extension on control plane: Leaf-to-Leaf communication restriction includes two cases, o Restriction between local Leafs. If two leafs are bound to a PE in a VSI and that PE receives a frame from one local Leaf, it does not forward it to the other local Leafs. This restriction is local behavior and out of the scope of this document. o Restriction between local Leafs and remote Leafs, say AC2 of PE1 and AC4 of PE2 in Figure 1. If AC2 and AC4 are not bound to any pseudowire, communication between AC2 and AC4 is natively forbidden. The purposed solution in this document prefers to the second one and extends signaling for BGP-VPLS [RFC4761] and LDP-VPLS [RFC4762]. Herein introduces two terms, - Root-endpoint. Root endpoint is bound to a set of Root-ACs. In a VSI on any PE has no or only 1 Root-endpoint. - Leaf-endpoint. Leaf endpoint is bound to a set of Leaf-ACs. In a VSI on any PE has no or only 1 Leaf-endpoint. Cao Expires July 29, 2012 [Page 5] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 There is no endpoint which is bound to both Root-ACs and Leaf-ACs in this document. Each endpoint is designated endpoint identifier. As a simple example, two endpoint identifiers are designated for PE1 in Figure 1, say r for Root AC AC1 and l for Leaf AC AC2, but r and l belong to the same E-Tree instance. 4. Reference Model Figure 2 shows E-Tree reference model which has 3 PEs: Root-Leaf- Mixed PE (PE1), Leaf-only PE (PE2) and Root-only PE (PE3). PE1, PE2 and PE3 are in one E-Tree instance. In Figure 2, Root ACs {AC1, AC5, AC6} can communicate with all other Ethernet ACs in the E-Tree, Leaf ACs {AC2, AC3, AC4} only can communicate with Root ACs {AC1, AC5, AC6}, but Leaf ACs can not communicate with each other. In most use cases, an E-Tree has only several Root ACs but many Leaf- ACs. The procedures for creating an E-Tree instance are given below: - Root-Leaf-Mixed PE. Some connected to VSI are Root ACs and some are Leaf ACs, say AC1 and AC2 of PE1 in Figure 2. Here two endpoint identifiers are designated to PE1, one is called Root- endpoint r1, and one is called Leaf-endpoint l1. Both r1 and l1 belong to one VSI; - Leaf-AC-only PE. All ACs connected to VSI are Leaf ACs, say AC3 and AC4 of PE2 in Figure 2. One endpoint identifier l2 is designated to PE2 and two Leaf-ACs (AC3 and AC4) are bound to l2. - Root-AC-only PE. All ACs connected to VSI are Root ACs, say AC5 and AC6 of PE3 in Figure 2. One endpoint identifier r3 which is designated to PE3 and two Root-ACs (AC5 and AC6) are bound to r3. Cao Expires July 29, 2012 [Page 6] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 |<--------E-Tree------------>| | | V V +-----------+ +---------+ Leaf endpoint Root endpoint | PE1 | | PE2 | / +---+ \ | +-----+ | | +---+ | /\ +---+ | | /\ | | | | | | | | | | | | |CE1+-|-----AC1---+--+ V | | | | V +--+-|--- --AC3----+CE3| | | \/(Root AC)| | | | | | | | | | | | +---+ | | +--+-PW12-+--+ S | | | |(Leaf AC) +---+ Leaf endpoint | | S | | | | | | | | +---+ \ | | | | | | I | | | | +---+ | | /\ | | | | | | | | | | | | |CE2+-|-----AC2---+--+ I | | | | +--+-|------AC4----+CE4| | | \/(Leaf AC)| | | | | | | | | | | | +---+ | ++---++ | | +-+-+ | \/ (Leaf AC) +---+ +---+---+---+ +----+----+ ^ | | | | | |PW23 | | | +----+----+ Root endpoint PW13-1| |PW13-2 | PE3 | / | | | | +-+-+ | /\ +---+ | | | | | +--+-|--------AC5-+CE5| | | +----------+--+ V | | | |(Root AC)+---+ | | | | | | | | +---+ | | | | S +--+-|------AC6---+CE6| | +--------------+--+ | | \/ (Root AC)+---+ | | | I | | | | +---+ | | | PE3 | | +---------+ | ^ | <---------E-Tree---------->| Figure 2 E-Tree typical Reference Model Within an E-Tree, - For BGP-VPLS the endpoint identifier is VE ID carried in NLRI, and it is global unique in E-Tree domain; For LDP-VPLS it can be taken as attachment identifier (AI) or PW ID. - All attachment circuits of a Root endpoint can receive frames from or transmit frames to ACs of any other endpoints in an E-Tree upon MAC address learning. Cao Expires July 29, 2012 [Page 7] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 - Any attachment circuit of a Root endpoint can receive frames from and transmit frames to other Root-ACs in its own domain upon MAC address learning; - All attachment circuits of a Leaf endpoint can receive frames from and transmit frames to ACs of any Root endpoints in an E-Tree upon MAC address learning. - Any attachment circuit of a Leaf endpoint cannot receive frames from and transmit frames to any attachment circuit of other Leaf endpoints in the E-Tree since there is no communication channel. - Any attachment of a Leaf endpoint cannot receive frames from and transmit frames to any other attachment circuit in its domain; Therefore in Figure 2, - All endpoint identifiers are designated by network administrator: 1. r1 for PE1's Root endpoint which AC1 (Root AC) is bound to; l1 for PE1's Leaf endpoint which AC2 (Leaf AC) is bound to; 2. l2 for PE2's Leaf endpoint which is AC3 and AC4 (Leaf ACs) are bound to. 3. r3 for PE3's Root endpoint which AC5 and AC6 (Root ACs) are bound to; - PE1 establishes one pseudowire (PW12) between r1 and l2, but does not establish any pseudowire between l1 and l2; - PE1 establishes two pseudowires with PE3 where PW13-1 between r1 and r3, PW13-2 between l1 and r3; - PE2 has one Leaf endpoint, so PE2 establish one pseudowire (PW12) between l2 and r1 with PE1, and one pseudowire (PW23) between l2 and r3 with PE3; - PE3 establishes two pseudowires with PE1 where PW13-1 between r3 and r1, and PW13-2 between r3 and l1; - On Root-Leaf-Mixed PE, say on PE1, Leaf AC and Root AC belong to different endpoints where AC1 belongs to r1 and AC2 belongs to l1, but all belongs to same E-Tree instance. Any attachment circuit of Leaf endpoint can receive frame from or transmit frame to any attachment circuit of local Root endpoint, and vice versa. Cao Expires July 29, 2012 [Page 8] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 - On Leaf-only PE, say PE2, communication between local Leafs of Leaf endpoint, l2, is forbidden. - On Root-only PE, say PE3, communication between local Root-ACs of Root endpoint, r2, is allowed. This applies to all traffic, including Unicast Known, Unicast Unknown, Broadcast or Multicast. 5. Extension to VPLS for E-Tree 5.1. Assumptions In current VPLS application [RFC4761] [RFC4762], the PEs are assumed to be logically fully meshed with tunnels over which packets that belong to a service (such as VPLS) are encapsulated and forwarded, therefore one single Bidirectional Pseudowire is sufficient between every two PEs in one VPLS. In an E-Tree, 0, 1 or more pseudowires are created between every two PEs since one PE MAY have 1 or 2 endpoints with proposed solution in this document. Any E-Tree endpoint comprises only one AC type. If a PE in a VPLS has both Root ACs and Leaf ACs, it SHOULD be configured with at least two endpoints, one is only composed of Root ACs, and another is only composed of Leaf ACs. It is illegal for any endpoint to have both at same time. 5.2. PW setup Matrix Just as mentioned in Section 3, there is no PW between Leaf-endpoints. Table 1 describes PW setup matrix, +---------------+------------------+------------------+ | Endpoint type + Destination Root + Destination Leaf + +---------------+------------------+------------------+ |Originated Root+ Setup + Setup + +---------------+------------------+------------------+ |Originated Leaf+ Setup + n/a + +---------------+------------------+------------------+ Table 1 PW setup Matrix 5.3. Endpoint type Each endpoint in an E-Tree on PE MUST have an attribute, Root endpoint or Leaf endpoint. For backward compatibility, the default endpoint type MUST be Root for current VPLS standard [RFC4761] [RFC4762]. Cao Expires July 29, 2012 [Page 9] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 - Root endpoint. One of its attachment circuits can communicate with other attachment circuits in its domain or attachment circuits of other endpoints in E-Tree. - Leaf endpoint. Its attachment circuits only can communicate with all attachment circuits of Root endpoints in a VPLS or E-Tree. 5.4. Endpoint identifier designation 5.4.1. Endpoint identifier designation using LDP FEC 128 Endpoint identifier is designated by network administrator. Endpoint identifier can be thought as PW ID. Endpoint identifier and endpoint type are exchanged via signaling. 5.4.2. Endpoint identifier designation using LDP FEC 129 Endpoint identifier is designated by network administrator. Endpoint identifier is thought as AII. Endpoint identifier and type are exchanged among PEs via signaling. 5.4.3. Endpoint identifier designation using BGP Section 3.2.2 in [RFC4761] defines VPLS BGP NLRI with a new AFI and SAFI to exchange VPLS membership and demultiplexors. +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | VE Block Offset (2 octets) | +------------------------------------+ | VE Block Size (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ Figure 3 BGP NLRI for VPLS Information Endpoint identifier is global unique identifier in E-Tree domain, and has same signification as VE ID in Figure 3. A PE participating in an E-Tree must have at least one endpoint identifier, but for a VSI on a PE which has both Root-ACs and Leaf-ACs, at least two endpoint Cao Expires July 29, 2012 [Page 10] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 identifiers are designated. Each endpoint has its attribute, Root or Leaf. Default type is Root. The whole VE ID set is divided into two parts, one is Root VE ID set R, one is Leaf VE ID set L and whole VE ID set is V. L = {l1, l2, ......, ln}, R = { r1, r2,......, rm}, V = { VBO, VBO+1,......, VBO+VBS-1}, Where, - L and R is subset of V; - Intersection of two sets L and R is empty set; - Union of two sets L and R is V; VE ID is typically assigned by the network administrator. The endpoint which is in L set only can establish PW with the endpoint in R set, but the endpoint in R set can establish PW with all VPLS endpoint in RUL. 5.5. Signaling procedures 5.5.1. Signaling endpoint type using LDP 5.5.1.1. Extension to Interface Parameters Sub-TLV 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.5 in [RFC4447] describes interface parameters Sub-TLV which is used to provide interface-specific parameters. Here we use this to carry endpoint type information. Initial Pseudowire Interface Parameter Sub-TLV type allocations are specified in [RFC4446], and prefer parameter ID is given below, Cao Expires July 29, 2012 [Page 11] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 Parameter Length Description Reference ID ===================================================================== 0x0D 4 Endpoint type The parameter field is defined below, 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |R|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where R is expected remote endpoint type, and L is local endpoint type. R and L will take the following value, 0 - - Root endpoint 1 - - Leaf endpoint 5.5.1.2. Extension to the Generalized FEC 129 Generalized PWid FEC Element uses Attachment Identifiers (AI) to indicate forwarders, and an Attachment Identifier would consist of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII). An Attachment Individual Identifier may be thought of as endpoint identifier in this document. 5.5.2. Signaling endpoint type using BGP The extended attribute defined in Section [RFC4761] 3.2.4, the "Layer2 Info Extended Community", is used to signal control information about the pseudowires to be setup for a VPLS, where Control Flags (control information regarding the pseudowires) is used to carry endpoint type information. Cao Expires July 29, 2012 [Page 12] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 +------------------------------------+ | Extended community type (2 octets) | +------------------------------------+ | Encaps Type (1 octet) | +------------------------------------+ | Control Flags (1 octet) | +------------------------------------+ | Layer-2 MTU (2 octet) | +------------------------------------+ | Reserved (2 octets) | +------------------------------------+ Figure 4 Layer2 Info Extended Community With reference to Figure 5, the following bit in the control flags is defined in this document. Bits C, S have been defined in [RFC4761]. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |L|C|S| (MBZ = MUST Be Zero) +-+-+-+-+-+-+-+-+ Figure 5 Control Flags Bit Vector Name Meaning L Carries the E-Tree endpoint information, Leaf endpoint or Root endpoint, depending on whether L is 1 or 0, respectively. If L is 1, the endpoint is Leaf type; otherwise the endpoint is Root type. Default type is Root. 5.6. PW setup and teardown 5.6.1. Signaling procedures using LDP FEC 128 Using the PW id FEC, each of the two pseudowire endpoints independently initiates the setup of a unidirectional LSP. On Root- Leaf-Mixed PE, both root Endpoint identifier and Leaf Endpoint identifier are PW ID. Suppose PE-a and PE-b are parts of E-Tree foo. PE-a must know the address of remote PE-b and vice versa. Cao Expires July 29, 2012 [Page 13] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 1. PE-a initiates the setup by sending a Label Mapping Message to PE- b. The Label Mapping message contains the FEC TLV, carrying the PW ID FEC Element (type 0x80). The PW ID FEC element contains the PW ID (endpoint identifier), local endpoint type and expected remote endpoint type carried in interface parameters TLV. If PE-a is Root-Leaf-Mixed PE, it will send two Label Mapping Messages for those endpoints respectively, and expected remote endpoint type is Root. 2. When PE-b receives such a Label Mapping message, PE-b interprets the message as a request to set up a PW whose identifier is PW ID. If PE-b can not meet PW setup Matrix in 5.2. , then PE2 sends a Label Release message to PE1, with a Status Code of "Mismatch endpoint type", then processing of the Label Mapping message is complete. 3. If PE-b decides to accept the Label Mapping message, then it has to make sure that a PW LSP is set up in the opposite (PE-a-->PE-b) direction. If it has already signaled for the corresponding PW LSP in that direction, pseudowire setup is done. Otherwise, it must take it as Label Request Message, and initiate such signaling by sending a Label Mapping message to PE-a carrying PE-a's local endpoint type as expected remote endpoint type. Normally, PE-a's local endpoint type is Leaf in this case. A bidirectional pseudowire is created. PW teardown process complies with [RFC4447]. 5.6.2. Signaling procedures using the Generalized FEC 129 Suppose PE-a and PE-b are parts of E-Tree foo. PE-a must know the address of remote PE-b and vice versa. This information may be configured at PE1 and PE2, or may have been learned via autodiscovery mentioned in [RFC6074]. 1. PE-a initiates the setup by sending a Label Mapping Message to PE- b. The Label Mapping message contains the FEC TLV, carrying the Generalized PWid FEC Element (type 0x81). The Generalized PWid FEC element contains the AGI, SAII which is local endpoint identifier, TAII which is expected remote endpoint identifier, local endpoint type and expected remote endpoint type carried in interface parameters TLV. Cao Expires July 29, 2012 [Page 14] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 2. When PE-b receives such a Label Mapping message, PE-b interprets the message as a request to set up a PW whose endpoint (at PE-b) is the Forwarder identified by the TAI, and the AGI could be a VPN-id identifying a particular E-Tree instance. If PE-b can not meet PW setup Matrix in 5.2. , then PE2 sends a Label Release message to PE1, with a Status Code of "Mismatch endpoint type", then processing of the Label Mapping message is complete. 3. If PE-b decides to accept the Label Mapping message, then it has to make sure that a PW LSP is set up in the opposite (PE-a-->PE-b) direction. If it has already signaled for the corresponding PW LSP in that direction, bidirectional pseudowire is created. Otherwise, it must take it as Label Request Message, initiate such signaling by sending a Label Mapping message to PE-a carrying PE-a's local endpoint type as expected remote endpoint type. This is similar to the Label Mapping message PE-b received, but the SAI and TAI, local endpoint type and expected endpoint type, are reversed. Thus, a bidirectional PW is established. PW teardown process complies with [RFC4447]. 5.6.3. Signaling using BGP Suppose PE-a and PE-b are parts of E-Tree foo, where PE-a has both Root endpoint and Leaf endpoint. For Leaf endpoint, it is assigned with VE ID l which is in Leaf VE ID set, VE block offset VBO, VE Block Size VBS, and label base lLB; For Root endpoint, it is assigned with VE ID r which is in Root VE ID set, VE Block Offset VBO, VE Block Size VBS, and label base rLB. If PE-b is assigned with VE ID w and gets NLRI advertisement from PE-a, it will do the following according to [RFC4761] section 3.2.3, 5.6.3.1. Originated from Root endpoint Supposed PW setup is originated from Root endpoint r. Checks if w is part of PE-a's 'remote VE set': if VBO <= w < VBO+ VBS, then w is part of PE-a's remote VE set. If not, PE-b ignores this message, and skips the rest of this procedure; 1. Since remote endpoint is Root, PW establishment is allowed and sets up a PW to PE-a: the demultiplexor label to send traffic from PE-b to PE-a is computed as (rLB + w - VBO). 2. Checks if r is part of any 'remote VE set' that PE-b announced, i.e., checks if r belongs to some remote VE set that PE-b announced, say with VE Block Offset VBO', VE Block Size VBS', and label base LB'. If not, PE-b MUST make a new announcement. Cao Expires July 29, 2012 [Page 15] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 3. Sets up a PW from PE-a: the demultiplexor label over which PE-b should expect traffic from PE-a is computed as: (LB' + r - VBO'). If PE-a withdraws an NLRI for r that PE-b was using, then PE-b MUST tear down its ends of the pseudowire between r of PE-a and w of PE-b. 5.6.3.2. Originated from Leaf endpoint 1. Checks if w is Leaf endpoint with local "Layer2 Info Extended Community". If it is, PE-b ignores this message since remote endpoint l is Leaf, and skips the rest of this procedure. 2. Checks if w is part of PE-a's 'remote VE set' if w is Root type: if VBO <= w < VBO+ VBS, then w is part of PE-a's remote Root VE set. If not, PE-b ignores this message, and skips the rest of this procedure. 3. Sets up a PW to PE-a: the demultiplexor label to send traffic from PE-b to PE-a is computed as (lLB + w - VBO). 4. Checks if l is part of any 'remote VE set' that PE-b announced, i.e., PE-b checks if l belongs to some remote VE set that PE-b announced, say with VE Block Offset VBO', VE Block Size VBS', and label base LB'. If not, PE-b MUST make a new announcement. 5. Sets up a PW from PE-a: the demultiplexor label over which PE-b should expect traffic from PE-a is computed as: (LB' + l - VBO'). If PE-a withdraws an NLRI for l that PE-b was using, then PE-b MUST tear down its ends of the pseudowire between PE-a and PE-b. 5.7. Backward Compatibility Root endpoints and Leaf endpoints are used only in cases where PEs support E-Tree and have no impact on VPLS PEs already in operation. In a case where a common VPLS is composed of both PEs supporting the solution and PEs not supporting it, ACs attached to PEs which don't support E-Tree are taken as attachment circuits of Root endpoints. The Leaf-to-Leaf communication restriction will be implemented within the scope of the compliant PEs. 6. Extension to Data Plane for E-Tree This solution has no extension requirements on data forwarding. Cao Expires July 29, 2012 [Page 16] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 Refer to Figure 1, there are 3 bidirectional PWs between PE1 and PE2. In this way, if one broadcast received from AC 3, PE2 needs to replicate it into two copies and transmit them via PW 1 and PW 3. Forwarding performance improvement is outside the scope of this document. On any Root-Leaf-Mixed PE, say PE1 in Figure 1, if one broadcast received from AC 1, it transmits to AC 2 which belongs to another endpoint of the VSI. This is local behavior and outside the scope of this document. 7. Compliance with Requirements The proposed solution in this document meets the requirements mentioned in [Draft VPLS ETree Req] Section 5. The solution prohibits communication between any two Leaf endpoints in an E-Tree domain. The solution allows multiple Root-ACs or multiple Leaf-ACs in an E- Tree instance. The solution allows Root-Leaf-Mixed on any PE in an E-Tree. The solution is applicable to BGP-VPLS [RFC4761] and LDP-VPLS [RFC4762]. The solution is applicable to Case 1: Single technology "VPLS-only". 8. Security Considerations This will be added in later version. 9. IANA Considerations IANA is requested to allocate new interface parameter sub-TLV type for E-Tree. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - Phase 2, April 2008 Cao Expires July 29, 2012 [Page 17] Internet-Draft Extension to signaling in VPLS for E-Tree January 2012 [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 [RFC6074] E. Rosen, B. Davie, V. Radoaca & W. Luo, Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs), January 2011 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 10.2. Informative References [Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-02.txt, October 2010 [Draft Ext VPLS for ETree] Key, et al., Extension to VPLS for E-Tree, draft-key-l2vpn-vpls-etree-04.txt,October 2010 [Draft ETree Frwk] Key, et al., A Framework for E-Tree Service over MPLS Network, draft-key-l2vpn-etree-frwk-04.txt, October 2010 11. Acknowledgments The author would like to thank Raymond Key, Josh Rogers and Neil McGill for their insightful comments on initial version. Authors' Addresses Yuqun (Sam) Cao Ruijie Networks 618 Jinshan Road, Fuzhou 350002, China Email: yuqun.cao@gmail.com Cao Expires July 29, 2012 [Page 18]