Network Working Group                                        Raymond Key
Internet Draft                                              Simon Delord
Category: Informational                  Frederic Jounay, France Telecom
Expires: October 2010



                                                           April 7, 2010


              Requirements for MEF E-Tree Support in VPLS
                draft-key-l2vpn-vpls-etree-reqt-00.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 October 7, 2010.


Abstract

   This document provides functional requirements for Metro Ethernet
   Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN
   Service (VPLS). It is intended that potential solutions will use
   these requirements as guidelines.









Key, et al.               Expires October 2010                 [Page 1]


Internet Draft         Requirement E-Tree in VPLS             April 2010


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. Virtual Private LAN Service.....................................3
   3. MEF Multipoint Ethernet Services................................3
   3.1. Similarity between E-LAN and E-Tree...........................3
   3.2. Difference between E-LAN and E-Tree...........................3
   3.3. E-Tree Use Cases..............................................4
   4. Problem Statement...............................................5
   4.1. Motivation....................................................5
   4.2. Leaf-to-Leaf Communication Restriction........................5
   5. Requirements....................................................6
   5.1. Functional Requirements.......................................6
   5.2. Applicability.................................................6
   5.3. Backward Compatibility........................................6
   6. Security Consideration..........................................7
   7. IANA Considerations.............................................7
   8. Acknowledgements................................................7
   9. References......................................................7
   9.1. Normative References..........................................7
   9.2. Informative References........................................7
   Authors' Addresses.................................................8
   Intellectual Property and Copyright Statements.....................8























Key, et al.               Expires October 2010                 [Page 2]


Internet Draft         Requirement E-Tree in VPLS             April 2010


1. Introduction

   This document provides functional requirements for Metro Ethernet
   Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN
   Service (VPLS). It is intended that potential solutions will use
   these requirements as guidelines.

   Considerable number of service providers have adopted VPLS to provide
   MEF Ethernet LAN (E-LAN) services to customers. Service Providers
   currently need a simple and effective solution to emulate E-Tree
   services in addition to E-LAN services on their MPLS networks.

2. Virtual Private LAN Service

   VPLS is a L2VPN service that provides multipoint-to-multipoint
   connectivity for Ethernet across an IP or MPLS-enabled IP Packet
   Switched Network. VPLS emulates the Ethernet VLAN functionality of
   traditional Ethernet network.

   VPLS is a current IETF standard, please refer to [RFC4761] [RFC4762].

   Data frame is Ethernet frame.

   Data forwarding is MAC-based forwarding, which includes MAC address
   learning and aging.

3. MEF Multipoint Ethernet Services

   MEF has defined two multipoint Ethernet Service types:
     - E-LAN (Ethernet LAN), multipoint-to-multipoint service
     - E-Tree (Ethernet Tree), rooted-multipoint service

   For full specification, please refer to [MEF6.1] [MEF10.2].

3.1. Similarity between E-LAN and E-Tree

   Data frame MUST be Ethernet frame.

   Data forwarding can be MAC-based forwarding or something else, to be
   specified by service provider as service frame delivery attributes
   in the particular service definition.

   A generic E-LAN/E-Tree service is always bidirectional in the sense
   that ingress frames can originate at any endpoint in the service.

3.2. Difference between E-LAN and E-Tree

   Within the context of a multipoint Ethernet service, each endpoint is
   designated as either a Root or a Leaf. A Root can communicate with
   all other endpoints in the same multipoint Ethernet service, however
   a Leaf can only communicate with Roots but not Leafs.


Key, et al.               Expires October 2010                 [Page 3]


Internet Draft         Requirement E-Tree in VPLS             April 2010


   The only difference between E-LAN and E-Tree is:
     - E-LAN has Root endpoints only, which implies there is no
       communication restriction between endpoints
     - E-Tree has both Root and Leaf endpoints, which implies there is a
       need to enforce communication restriction between Leaf endpoints

3.3. E-Tree Use Cases

   Table 1 below presents some major E-Tree use cases.

       +---------------------------+--------------+------------+
       | Use Case                  | Root         | Leaf       |
   +---+---------------------------+--------------+------------+
   | 1 | Broadcast Video           | Video Source | Subscriber |
   |   | (unidirectional only)     |              |            |
   +---+---------------------------+--------------+------------+
   | 2 | Broadcast/Multicast Video | Video Source | Subscriber |
   |   | plus Control Channel      |              |            |
   +---+---------------------------+--------------+------------+
   | 3 | Internet Access           | BNG Router   | Subscriber |
   +---+---------------------------+--------------+------------+
   | 4 | IEEE 1588 PTPv2           | PTP Server   | PTP Client |
   |   | Clock Synchronisation     |              |            |
   +---+---------------------------+--------------+------------+
   | 5 | Mobile Backhaul           | RAN NC       | RAN BS     |
   +---+---------------------------+--------------+------------+
   | 6 | Hub & Spoke VPN           | Hub Site     | Spoke Site |
   +---+---------------------------+--------------+------------+
   | 7 | Wholesale Access          | Customer's   | Customer's |
   |   |                           | Interconnect | Subscriber |
   +---+---------------------------+--------------+------------+
   | 8 | Device Management         | Management   | Managed    |
   |   |                           | System       | Device     |
   +---+---------------------------+--------------+------------+

                     Table 1: E-Tree Use Cases

   Common to all use cases, direct Leaf-to-Leaf communication is not
   required. For Mobile backhaul, this may not be valid for LTE X2
   interfaces in the future.

   If direct Leaf-to-Leaf communication is not allowed due to security
   concern, then E-Tree should be used to prohibit communication between
   Leaf endpoints, otherwise E-LAN is also a feasible option.

   Also common to the use cases mentioned above, there may be single or
   multiple Root endpoints in one E-Tree service. The need for multiple
   Root endpoints is usually driven by redundancy requirement. Whether a
   particular E-Tree service needs to support single or multiple Root
   endpoints depends on the target application.



Key, et al.               Expires October 2010                 [Page 4]


Internet Draft         Requirement E-Tree in VPLS             April 2010


   A generic E-Tree service supports the following traffic flows:
     - Unicast bidirectional Root to/from Root
     - Unicast bidirectional Root to/from Leaf
     - Broadcast/Multicast unidirectional Root to all Roots and Leafs
     - Broadcast/Multicast unidirectional Leaf to all Roots
   A particular E-Tree service may need to support all the above or only
   a subset depending on the target application.

4. Problem Statement

4.1. Motivation

   VPLS can be used to emulate MEF E-LAN service over MPLS network
   provided that the E-LAN service uses MAC-based forwarding as service
   frame delivery attributes.

   Considerable number of service providers have adopted VPLS to provide
   MEF E-LAN services to customers. Service Providers currently need a
   simple and effective solution to emulate E-Tree services in addition
   to E-LAN services on their MPLS networks.

4.2. Leaf-to-Leaf Communication Restriction

   Current standard VPLS treats all ACs equal (i.e. not classified into
   Root or Leaf) and provides any-to-any connectivity among all ACs. The
   current standard VPLS does not include any mechanism of communication
   restriction between specific ACs, therefore is insufficient for
   emulating generic E-Tree service over MPLS network.

   Let's look at the scenario illustrated in Figure 1 below. VPLS is
   used to emulate an E-Tree service over a MPLS network.

                     <------------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) +----+
                    |         |            |         |
                    +---------+            +---------+

   Figure 1: Reference Model for Leaf-to-Leaf Communication Restriction


Key, et al.               Expires October 2010                 [Page 5]


Internet Draft         Requirement E-Tree in VPLS             April 2010


   When PE2 receives a frame from PE1 via the PW,
     - PE2 does not know which AC on PE1 is the ingress AC
     - PE2 does not know whether the ingress AC is a Leaf AC or not
     - PE2 does not have sufficient information to enforce the
       Leaf-to-Leaf communication restriction

5. Requirements

5.1. Functional Requirements

   A solution MUST prohibit communication between any two Leaf ACs in a
   VPLS instance.

   A solution MUST allow multiple Root ACs in a VPLS instance.

   A solution MUST allow Root AC and Leaf AC of a VPLS instance co-exist
   on any PE.

5.2. Applicability

   There are two distinct VPLS standards, performing similar functions
   in different manners.

     - [RFC4761], commonly known as BGP-VPLS

     - [RFC4762], commonly known as LDP-VPLS

   A solution MUST identify which VPLS standards the solution is
   applicable to, [RFC4761] or [RFC4762] or both.

   Service providers may use single or multiple technologies to deliver
   an end-to-end E-Tree service.

     - Case 1: Single technology "Just VPLS"

     - Case 2: Multiple technologies "VPLS + Others"
         - e.g. VPLS + Ethernet network, VPLS + OTN

     - Case 3: Single/multiple technologies "No VPLS"
         - e.g. Ethernet network, Ethernet network + OTN
         - out of scope for this document

   A solution MUST identify which of the above cases the solution is
   applicable to. For Case 2, further details may be required to specify
   the applicable deployment scenarios.

5.3. Backward Compatibility

   A solution should minimise the impact on existing VPLS solution,
   especially for the MEF E-LAN services already in operation.



Key, et al.               Expires October 2010                 [Page 6]


Internet Draft         Requirement E-Tree in VPLS             April 2010


   A solution should be backward compatible with the existing VPLS
   solution. It should allow a case where a common VPLS instance is
   composed of both PEs supporting the solution and PEs not supporting
   it, and the Leaf-to-Leaf communication restriction is enforced
   within the scope of the compliant PEs.

6. Security Considerations

   This will be added in later version of this document.

7. IANA Considerations

   This will be added in later version of this document.

8. Acknowledgements

   This will be added in later version of this document.

9. References

9.1. Normative References

   [MEF6.1]     Metro Ethernet Forum, Ethernet Services Definitions -
                Phase 2, April 2008

   [MEF10.2]    Metro Ethernet Forum, Ethernet Services Attributes
                Phase 2, October 2009

   [RFC2119]    Bradner, S., Key words for use in RFCs to Indicate
                Requirement Levels, BCP 14, RFC 2119, March 1997

   [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

9.2. Informative References














Key, et al.               Expires October 2010                 [Page 7]


Internet Draft         Requirement E-Tree in VPLS             April 2010


Authors' Addresses

   Raymond Key
   Australia
   Email: raymond.key@ieee.org

   Simon Delord
   Australia
   Email: simon.delord@gmail.com

   Frederic Jounay
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex, France
   Email: frederic.jounay@orange-ftgroup.com



Copyright Notice

   Copyright (c) 2010 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.

























Key, et al.               Expires October 2010                 [Page 8]