Internet DRAFT - draft-cao-l2vpn-vpls-etree

draft-cao-l2vpn-vpls-etree



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]