Network Working Group              Simon Delord (editor), Alcatel-Lucent
Internet Draft                              Raymond Key (editor), Huawei
Category: Standard Track                      Frederic Jounay, Orange CH
Expires: January 2013                    Yuji Kamite, NTT Communications
                                               Zhihua Liu, China Telecom
                                           Manuel Paul, Deutsche Telekom
                                        Ruediger Kunze, Deutsche Telekom
                                                       Mach Chen, Huawei
                                                        Lizhong Jin, ZTE

                                                           July 30, 2012

       Extension to LDP-VPLS for Ethernet Broadcast and Multicast
              draft-ietf-l2vpn-ldp-vpls-broadcast-exten-04


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 January 30, 2013.

Abstract

   This document proposes a simple extension to LDP-VPLS to improve
   bandwidth efficiency for Ethernet broadcast/multicast traffic
   within a carrier's network. It makes use of unidirectional
   point-to-multipoint PseudoWires to minimise payload frame duplication
   on physical links.

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].

Delord et al.              Expires January 2013                [Page 1]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


  Table of Contents

   1. Introduction.....................................................2
   2. Problem Statement & Motivation...................................3
   2.1. Requirements for Broadcast/Multicast Support in VPLS...........3
   2.2. Motivation.....................................................4
   2.3. Scope of the proposed solution.................................5
   3. Terminology......................................................5
   4. Relevant IETF technologies for the proposed solution.............6
   4.1. P2MP LSPs......................................................6
   4.2. P2MP PWs.......................................................6
   5. Proposed extension to [RFC4762]..................................7
   5.1. VPLS Reference Model...........................................7
   5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW..9
   5.3. Create and associate the P2MP PW to a specific VPLS instance...9
   5.4. Mapping more than one P2MP PW to a specific VPLS Instance
        on a specific root PE.........................................10
   5.5. Flooding and Forwarding.......................................10
   5.6. Address Learning..............................................11
   5.7. Loop Free Topology............................................11
   5.8. Hierarchical VPLS.............................................11
   5.9. P2MP PW Status................................................11
   6. Local PE Implementation.........................................12
   7. Security Considerations.........................................12
   8. IANA Considerations.............................................12
   9. Acknowledgments.................................................12
   10. References.....................................................13
   10.1. Normative References.........................................13
   10.2. Informative References.......................................13
   Author's Addresses.................................................14
   Appendix A. One example for broadcast video delivery...............16


1. Introduction

   This document proposes a simple extension to LDP-VPLS [RFC4762] to
   improve bandwidth efficiency for Ethernet broadcast/multicast traffic
   within a carrier's network. This bandwidth improvement is achieved by
   adding to the existing full-mesh of bidirectional point-to-point
   PseudoWires (P2P PWs) unidirectional point-to-multipoint PseudoWires
   (P2MP PWs) between selected PEs within a VPLS instance. With P2MP
   PWs, the ingress PE is not responsible for replicating the payload
   frame on each P2P PW towards the egress PE, instead the network
   elements along the physical path participate in the replication
   process. The replication is done by the underlying point-to-multi-
   point label switched path. This proposal allows for a large number
   of P2MP PWs to be carried through a single MPLS P2MP tunnel, thus,
   it is never necessary to maintain state in the network core for
   individual P2MP PWs.




Delord et al.              Expires January 2013                [Page 2]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


2. Problem Statement & Motivation

2.1. Requirements for Broadcast/Multicast Support in VPLS

   [RFC5501] provides an in-depth discussion on broadcast/multicast
   related requirements for VPLS. It highlights two specific issues:

      - issue A: replication to non-member site.
      - issue B: replication of PWs on shared physical path.

2.1.1. Issue A: replication to non-member site

   The current standard VPLS is a L2VPN service agnostic to customer's
   Layer 3 traffic, hence does not maintain any information about IP
   multicast group membership.  Although a Layer 3 IP multicast packet
   is encapsulated in a Layer 2 Ethernet multicast frame, the current
   standard VPLS treats Ethernet multicast frame in exactly the same way
   as Ethernet broadcast frame. There is therefore an issue that
   multicast traffic is sent to sites with no members.  Since the
   upstream PE does not maintain downstream membership information, it
   simply floods frames to all downstream PEs, and the downstream PEs
   forward them to directly connected CEs; however, those CEs might not
   be the members of any multicast group.

   There are therefore two elements to Issue A:

   - the PE to CE section (e.g. the AC), where a CE will receive
     unintended traffic.

   - the PE to PE section within a VPLS instance, where a PE will
     receive multicast traffic even when it has no CE being member of
     any multicast group.

   To address the PE to CE part, a PE might have to maintain multicast
   group information for CEs that are not kept in the existing VPLS
   solutions.

   To address the PE to PE part and limit the flooding scope across the
   backbone, a PE needs to discover multicast group information from
   other remote PEs.

   Both elements will present scalability concerns about state resources
   (memory, CPU, etc.) and their maintenance complexity.

   Finally, if Layer-3 information is checked for transport,  the
   following  [RFC4665] requirement "a L2VPN service SHOULD be agnostic
   to customer's Layer3 traffic" can no longer be met.






Delord et al.              Expires January 2013                [Page 3]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


2.1.2. Issue B: replication of PWs on shared physical path

   Issue B on the other hand can still be improved without making use of
   any Layer-3-related information.

   Issue B may still be considered acceptable when:

   - Ethernet broadcast/multicast traffic volume is low; and
   - The number of replications on each outgoing physical interface for
     a VPLS instance is small (e.g. not many PEs per VPLS instance).

   However, with more broadcast/multicast applications (e.g. broadcast
   TV), Ethernet broadcast/multicast traffic volume may increase to a
   significant level. Assuming HDTV requires 10Mbps per channel, a
   bundle of 100 channels will require 1Gbps.

   Furthermore, as MPLS networks expand from the core towards
   aggregation/access, more PEs may participate in a single VPLS
   instance. The number of replications on each outgoing physical
   interface for a VPLS instance is likely to increase.

2.2. Motivation

   Based on the previous section, it may still be desirable for some
   carriers to look at improving issue B without having to look at Layer
   3 information (Issue A).

   One reason for this is that sometimes there is no L3 data to snoop.
   Another reason may be that some carriers may not be allowed to look
   above the L2 header, for example there may be regulatory issues with
   inspecting the customer payload. Also, some carriers may not want to
   do L3 snooping as Operations will naturally become more complicated
   if the number of managed objects (e.g. multicast groups) increases.

   Another important point is that some carriers may want a manual and
   granular optimisation process that allows optimizations to certain
   services or areas but does not impact the rest of the network. For
   example, the bandwidth improvement process may only be required at
   specific locations in the network where bandwidth-intensive multicast
   broadcast Ethernet flows exist. It would also be beneficial if the
   optimisation process were incrementally deployable, so that the
   optimisation can still be leveraged even if there are portions of the
   network that are not able to support the features required by the
   optimisation process. A potential case would be a VPLS instance
   composed of both PEs supporting the proposed protocol extension and
   PEs not supporting it, the enhancement is then achieved between the
   compliant PEs only.






Delord et al.              Expires January 2013                [Page 4]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   Finally, some carriers may also prefer a deterministic process to an
   entirely automated path selection algorithm that is network driven.
   [RFC5501] gives several reasons on why this may be the case:

   - Accounting for various operator policies where the logical
     multicast topology within a carrier's network does not change
     dynamically in conjunction with a customer's multicast routing.

   - Operations will naturally become more complicated if topology
     changes occur more frequently.

   - Troubleshooting will tend to be difficult if a solution supports
     frequent dynamic membership changes with optimized transport within
     the carrier's network.

   [VPLS-Multicast-BGP] is a solution that looks at solving both Issue A
   and Issue B. However, [VPLS-Multicast-BGP] proposes that, even for
   carriers who currently use [RFC4762] without auto-discovery
   mechanisms, BGP be introduced (section 7). This may also present
   operational challenges and complexities for some carriers, or this
   feature may simply not be supported on some of the network elements
   deployed.

2.3. Scope of the proposed solution

   This draft therefore explores whether there is a way to improve
   Layer 2 Ethernet broadcast/multicast bandwidth simply and predictably
   with:

   - Minimal extension to [RFC4762] and without the need to add BGP
     (e.g. no auto-discovery)
   - Minimal impact to existing [RFC4762] deployed networks
   - Operator driven optimisation (i.e. the operator decides where and
     how the bandwidth improvement should occur) to minimise the number
     of states and the potential operational complexities associated
     with dynamic changes within a carrier's core network.

3. Terminology

   This document uses terminology described in [RFC4762] and
   [P2MP-PW-REQ].












Delord et al.              Expires January 2013                [Page 5]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


4. Relevant IETF technologies for the proposed solution

   The proposed solution relies on [RFC4762] existing mechanisms and
   complements them with extensions (P2MP LSPs and P2MP PWs) already
   standardised ([RFC4875]) or currently under development by the IETF
   ([RFC6388] and [P2MP-PW-LDP]).

4.1. P2MP LSPs

   Similarly to what is defined in [RFC4762] where P2P PWs are
   multiplexed onto P2P LSPs, before the operator can start deploying
   P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to
   be configured (section 3.2 of [P2MP-PW-REQ]).

   P2MP LSPs are used to minimise packet replication on specific
   physical links and to allow P routers in an MPLS domain to be
   transparent to services (e.g. a P Router will join the P2MP PSN
   tunnel operation but will have no knowledge of the P2MP PWs, same
   as [RFC4762]).

   The mapping of the P2MP LSP over the physical topology is a
   key component of the bandwidth enhancement exercise and the operator
   needs to carefully consider where and how these P2MP LSPs should be
   deployed (see Appendix A for an example of a possible deployment).

   Once configured, it is then possible to aggregate P2MP PWs over a
   particular P2MP LSP (similar to [RFC4762]).

4.2. P2MP PWs

   P2MP PWs can be configured statically (e.g. by the operator) or via
   LDP on top of the P2MP LSPs. This configuration is done on a per PE
   per VPLS instance basis.

   In a P2MP PW, the operator decides to connect one Root PE to at least
   two Leaf PEs (section 3.1 of [P2MP-PW-REQ]).

   The Root PE is the headend of the P2MP PW (where a big Ethernet
   multicast/broadcast talker is connected - see example in Appendix A).

   The Leaf PEs are the endpoints of the P2MP PW (they constitute
   the receivers where the broadcast/multicast traffic needs to be
   distributed to).

   A Root PE may map more than one P2MP PW to a specific VPLS instance.
   In this case, the Root PE MUST NOT associate a leaf PE to more than
   one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE
   to receive duplicate copies of the same Ethernet frame from different
   P2MP PWs).

   P2MP PWs are defined in [P2MP-PW-REQ] and one solution using LDP as
   the signalling mechanism between PEs is defined in [P2MP-PW-LDP].

Delord et al.              Expires January 2013                [Page 6]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


5. Proposed extension to [RFC4762]

   This section updates [RFC4762] by describing the extra rules to be
   applied within a VPLS when unidirectional P2MP PWs are added to the
   existing full-mesh of P2P PWs.

5.1. VPLS Reference Model

   Figure 1 shows a topological model (not the physical topology)
   of a VPLS between four PEs with an arbitrary set of ACs attached to
   each VSI.

                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
                    |  +---+  |            |  +---+  |
                    |  |   |  |            |  |   +-------AC4---
                    |  | V |  |            |  | V |  |
                    |  |   |  |            |  |   |  |
         ----AC1----+--+   |  |  Ethernet  |  |   +--+----AC5---
                    |  | S +--+-----PW-----+--+ S |  |
                    |  |   |  |            |  |   |  |
         ----AC2----+--+   |  |            |  |   |  |
                    |  | I |  |            |  | I |  |
                    |  |   |  | Ethernet   |  |   |  |
         ----AC3----+--+   |  |   PW +-----+--+   |  |
                    |  +-+-+  |     /      |  +-+-+  |
                    |    |  \ |    /       |    |    |
                    +----+---\+   /        +----+----+
                         |    \  /              |
                 Ethernet|     \/               |Ethernet
                       PW|     /\               |PW
                         |    /  \Ethernet      |
                    +----+---/+   \PW      +----+----+
                    |PE3 |  / |    \       |PE4 |    |
                    |  +-+-+  |     \      |  +-+-+  |
         ----AC6----+--+   |  |      \     |  |   +--+----AC8----
                    |  | V |  |       +----+--+ V |  |
                    |  |   |  |            |  |   |  |
         ----AC7----+--+   |  |  Ethernet  |  |   +--+----AC9----
                    |  | S +--+-----PW-----+--+ S |  |
                    |  |   |  |            |  |   |  |
                    |  |   |  |            |  |   |  |
                    |  | I |  |            |  | I |  |
                    |  |   |  |            |  |   |  |
                    |  |   |  |            |  |   |  |
                    |  +---+  |            |  +---+  |
                    |         |            |         |
                    +---------+            +---------+

                     Figure 1: Reference Diagram for VPLS



Delord et al.              Expires January 2013                [Page 7]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast
   and multicast.  On top of the topology presented in Figure 2, two
   P2MP PWs have been added to the existing set of P2P PWs.

                    +---------+            +---------+
                    |   PE1   |            |   PE2   |
                    |  +---+  |            |  +---+  |
                    |  |   |  |            |  |   +-------AC4---
                    |  | V |  |  Ethernet  |  | V |  |
                    |  |   |  |    P2MP    |  |   |  |
         ----AC1----+--+   |  |     PW1    |  |   +--+----AC5---
                    |  | S +--+->--+-->----+--+ S |  |
                    |  |   |  |    |       |  |   |  |
         ----AC2----+--+   |  |    |       |  |   |  |
                    |  | I |  |    |   +->-+--+ I |  |
                    |  |   |  |    |   |   |  |   |  |
         ----AC3----+--+   |  |    |   |   |  |   |  |
                    |  +---+  |    |   |   |  +---+  |
                    |         |    |   |   |         |
                    +---------+    |   |   +---------+
                                   |   |
                                   |   |
                                   |   |
                                   |   |
                    +---------+    |   |   +---------+
                    |PE3      |    |   |   |PE4      |
                    |  +---+  |    |   |   |  +---+  |
         ----AC6----+--+   |  |    +->-----+--+   +--+----AC8----
                    |  | V |  |        |   |  | V |  |
                    |  |   |  |        |   |  |   |  |
         ----AC7----+--+   |  |        |   |  |   +--+----AC9----
                    |  | S +--+->------+->-+--+ S |  |
                    |  |   |  |   Ethernet |  |   |  |
                    |  |   |  |     P2MP   |  |   |  |
                    |  | I |  |     PW2    |  | I |  |
                    |  |   |  |            |  |   |  |
                    |  |   |  |            |  |   |  |
                    |  +---+  |            |  +---+  |
                    |         |            |         |
                    +---------+            +---------+

  Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast


   P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf
   PEs.

   P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf
   PEs.

   Note that for sake of clarity, Figure 2 does not show the full-mesh
   of P2P PWs presented in Figure 1.

Delord et al.              Expires January 2013                [Page 8]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   Also note that the solution does not require that P2MP PWs be used on
   all PEs in the VPLS. For example, PE3 is not leaf of P2MP PW1 and PE1
   is not leaf of P2MP PW2 and therefore, there is only a P2P PW between
   PE1 and PE3, and a P2P PW between PE2 and PE4.

5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW

   This updates section 4.3 of [RFC4762].

   VPLS is a full-mesh of P2P PWs and optionally a number of
   unidirectional P2MP PWs. At the difference of P2P PWs, not all PEs in
   a VPLS instance need to be connected via P2MP PWs.

   For each P2MP PW on this VPLS instance:

     - The operator selects one PE as the Root of the P2MP PW.

     - The operator also selects two or more PEs belonging to the same
       VPLS instance to be Leafs of the P2MP PW

     - Because there is already a full-mesh of bidirectional P2P PWs
       between all PEs, the P2MP PW is unidirectional only (e.g. from
       the Root PE to all the Leaf PEs connected to it).

     - The operator also needs to make sure that there is an active P2MP
       LSP setup between the Root PE and the Leaf PEs:

     - If there is already an active P2MP LSP setup between the Root
       PE and the Leaf PEs, then procedures described in 5.3 can be
       followed.

     - If there is no P2MP LSP between the Root PE and the Leaf PEs
       then the operator needs to create first a P2MP LSP in order for
       procedures in 5.3 to be followed. Procedures to setup a P2MP LSP
       will vary based on the technology used and are described in
       [RFC6388] and [RFC4875].

5.3. Create and associate the P2MP PW to a specific VPLS Instance

   This updates section 4.3 of [RFC4762].

   Once that the endpoints of the P2MP PW have been selected and that
   there is an active P2MP LSP between them, the operator can then
   create and associate the P2MP PW to a specific VPLS instance.
   This activity can be done statically or via LDP [P2MP-PW-LDP].

   Because P2MP PWs are used to demultiplex encapsulated Ethernet frames
   from multiple VPLS instances that are aggregated over the same P2MP
   transport LSP, it is necessary that a Leaf PE can associate
   unambiguously a P2MP PW aggregated within a P2MP LSP to both a
   specific VPLS instance and a Root PE.


Delord et al.              Expires January 2013                [Page 9]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   In the static case, the operator is responsible for configuring all
   the required information on all PEs belonging to the P2MP PW.

   In the LDP case, the P2MP PW is initiated by the Root PE by sending a
   P2MP PW LDP Label Mapping Message to each of the Leaf PEs.

   This label mapping contains, the VPLS instance the P2MP PW is
   associated to, the P2MP LSP used to transport the P2MP PW and the
   P2MP PW MPLS Label.

   The P2MP PW MPLS Label is upstream assigned and allocated according
   to the rules in [RFC5331].

   The root PE imposes the upstream-assigned label on the outbound
   packets sent over the P2MP-PW and using this label a Leaf PE can
   identify the inbound packets arriving over the P2MP PW.

   Detailed LDP message formats and P2MP PW setup procedures are
   described in [P2MP-PW-LDP].

5.4. Mapping more than one P2MP PW to a specific VPLS Instance on a
     specific Root PE

   The proposed solution allows for a Root PE to map more than one P2MP
   PW to a specific VPLS instance (see example in Appendix A).

   However in this case, the Root PE MUST NOT associate a leaf PE to
   more than one P2MP PW for a specific VPLS instance (this is to avoid
   a Leaf PE to receive duplicate copies of the same Ethernet frame from
   different P2MP PWs).

5.5. Flooding and Forwarding

   This section updates section 4.1. of [RFC4762].

   A root PE MUST NOT flood frames simultaneously over P2MP PW and P2P
   PW toward the same leaf PE.

   For the flooding of an Ethernet broadcast/multicast frame over PWs to
   remote PEs participating in the VPLS:

        - If there is P2MP PW towards a remote PE, the P2P PW
          associated with this remote PE will not be used. One copy
          of the frame will be forwarded on the P2MP PW for all the
          remote PEs associated with it.
        - If there is no P2MP PW towards a remote PE, the P2P PW
          associated with this remote PE is used.

   It should be noted that local policy on the Root PE at the operator's
   operational request can override any decision to flood and forward
   traffic over a P2MP PW for a VPLS instance. In that case, normal
   flooding procedures over P2P PWs described in 4.1 of [RFC4762] apply.

Delord et al.              Expires January 2013                [Page 10]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


5.5.1. Flooding and Forwarding for Ethernet unknown unicast

   In traditional Ethernet switched networks unknown unicast frames are
   handled the same way as broadcast and multicast Ethernet traffic
   (e.g. flooding). Similarly, current VPLS standards also handle
   unknown unicast traffic by flooding it across all P2P PWs.

   The main purpose of this document is to address Ethernet broadcast
   and multicast traffic. For Ethernet unknown unicast frames there are
   two possibilities:

    (1) forward the unknown unicast traffic on the P2MP PW, same as for
        Ethernet broadcast and multicast.
    (2) keep the existing mechanism of [RFC4762] and flood over the mesh
        of P2P PWs.

   A Root PE SHOULD support both the above as configurable options per
   VPLS instance. For a particular VPLS instance where frame reordering
   is considered unacceptable, option (2) is recommended.

5.6. Address Learning

   This section updates section 4.2. of [RFC4762].

   A Leaf PE MUST support the ability to perform MAC address learning
   for packets received on a P2MP PW.

   When a Leaf PE receives an Ethernet frame on a P2MP PW it:
        - First determines the VSI associated to the P2MP PW
        - Then determines the Root PE of the P2MP PW
        - Then determines the P2P PW associated with that Root PE
        - Finally, creates a forwarding state in the VPLS instance for
          the P2P PW associated with the Root PE with a destination
          MAC address being the same as the source MAC address being
          learned.

5.7. Loop Free Topology

   This updates section 4.4. of [RFC4762]

   Paragraph 2 "must not forward from one PW to another" is applicable
   to P2MP PW & P2P PW.

5.8. Hierarchical VPLS

   This refers to section 10 and 11 in [RFC4762]. No change is required.

5.9 P2MP PW Status

   In case of a P2MP PW status change to not operational as per
   [P2MP-PW-LDP], then this should be treated as if this P2MP PW does
   not exist.

Delord et al.              Expires January 2013                [Page 11]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


6. Local PE Implementation

   This section is OPTIONAL.

   As described in section 2.1.1, a PE receiving an IP multicast frame,
   will forward it to all ACs, including those with no member of the
   specific IP multicast group attached.

   Unnecessary traffic consumes bandwidth on the access link and may
   become a concern from the customer perspective. In some cases, it may
   also be a security concern as the multicast frame may be forwarded to
   an endpoint other than the intended destinations.

   Consequently, the use of some L3 related supplementary information in
   order to improve bandwidth consumption on the AC may be considered.
   Enabling L3 snooping on an AC basis only has an impact on the PE
   where the AC belongs, it does not impact the number of P2MP PW/LSPs
   used within the carrier's network and the state resources or the
   maintenance complexity associated with it.

   Alternatives to L3 snooping such as static configuration of multicast
   Ethernet addresses & ports / interfaces for example are also
   possible.

7. Security Considerations

   This document does not introduce any new security issues beyond those
   already described in [RFC4762].

8. IANA Considerations

   This document does not require IANA assignment.

9. Acknowledgments

   The authors would like to thank Marc Lasserre, Cesar Garrido, Lucy
   Yong, Neil Harrison, Samer Salam, Nocolai Leymann, Florin Balus, Olen
   Stokes, Ali Sajassi, Phil Bedard, Thomas Beckhaus, Linda Dunbar, Max
   Ng, Asaf Henig, Mark Whalley and Cary Wright for their valuable
   comments.













Delord et al.              Expires January 2013                [Page 12]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


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.

   [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS)
             Using Label Distribution Protocol (LDP) Signaling",
             RFC 4762, January 2007.

   [P2MP-PW-LDP] Sivabalan, et. al, "Signaling Root-Initiated
                 Point-to-Multipoint Pseudowires using LDP",
                 draft-ietf-pwe3-p2mp-pw-04, work in Progress,
                 March 2012.

   [RFC6388] Wijnands, et. al, "Label Distribution Protocol Extensions
             for Point-to-Multipoint and Multipoint-to-Multipoint Label
             Switched Paths", RFC 6388, November 2011.

   [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.,
             "Extensions to Resource Reservation Protocol - Traffic
             Engineering (RSVP-TE) for Point-to-Multipoint TE Label
             Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
             Assignment and Context Specific Label Space", RFC 5331,
             August 2008.

10.2. Informative References

   [RFC5501] Kamite, et al., "Requirements for Multicast Support in
             Virtual Private LAN Services", RFC 5501, March 2009.

   [P2MP-PW-REQ] Jounay, et. al, "Requirements and Framework for
                 Point-to-Multipoint Pseudowire over MPLS PSNs",
                 draft-ietf-pwe3-p2mp-pw-requirements-05, work in
                 progress, September 2011.

   [VPLS-Multicast-BGP] Raggarwa, Kamite & Fang, "Multicast in VPLS",
                        draft-ietf-l2vpn-vpls-mcast-11, work in
                        progress, July 2012.

   [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
             Layer 2 Provider-Provisioned Virtual Private Networks",
             RFC 4665, September 2006.







Delord et al.              Expires January 2013                [Page 13]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


Author's Addresses

   Simon Delord (editor)
   Alcatel-Lucent
   Email: simon.delord@gmail.com

   Raymond Key (editor)
   Huawei
   E-mail: raymond.key@ieee.org

   Frederic Jounay
   Orange CH
   4 rue caudray 1020 Renens
   Switzerland
   Email: frederic.jounay@orange.ch

   Yuji Kamite
   NTT Communications Corporation
   Granpark Tower
   3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan
   Email: y.kamite@ntt.com

   Zhihua Liu
   China Telecom
   109 Zhongshan Ave.
   Guangzhou 510630
   China
   Email: zhliu@gsta.com

   Manuel Paul
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin, Germany
   Email: manuel.paul@telekom.de

   Ruediger Kunze
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin, Germany
   Email: ruediger.kunze@telekom.de

   Mach(Guoyi) Chen
   Huawei Technology Co., Ltd.
   Q14 Huawei Campus, No. 156 Beiqing Road
   Hai-dian District, Beijing  100095
   China
   Email: mach.chen@huawei.com




Delord et al.              Expires January 2013                [Page 14]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   Lizhong Jin
   ZTE Corporation
   889, Bibo Road
   Shanghai, 201203, China
   Email: lizhong.jin@zte.com.cn
















































Delord et al.              Expires January 2013                [Page 15]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


Appendix A. One example for broadcast video delivery

   This section describes one deployment scenario in relation to
   broadcast video delivery and how the proposed solution would work.

   One requirement of the model is that the application needs unicast
   data exchange (IP unicast transfer or control messages etc.) as a
   background environment. MAC-learning (and therefore VPLS) is
   effective to support it.

A.1. Broadcast Video Delivery Topology

   Figure 3 presents the physical topology of one broadcast video
   deployment.

                              |     |     |
                              AC    AC    AC
                              |     |     |
                            +---+ +---+ +---+
                            |PE3| |PE4| |PE5|
                            +---+ +---+ +---+
                               \    |    /
                                \   |   /                 +----+
                                 \  |  /              +---|PE9 |--AC--
                                  \ | /              /    +----+
   Ethernet        +---+          +---+        +---+/     +----+
   Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC--
   Source          +---+\        /+---+        +---+\     +----+
                         \      /   |            |   \    +----+
                          \    /    |            |    +---|PE11|--AC--
                           \  /     |            |        +----+
                            \/      |            |
                            /\      |            |
                           /  \     |            |        +----+
                          /    \    |            |    +---|PE12|--AC--
                         /      \   |            |   /    +----+
   Ethernet        +---+/        \+---+        +---+/     +----+
   Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC--
   Source          +---+          +---+        +---+\     +----+
                                  / | \              \    +----+
                                 /  |  \              +---|PE14|--AC--
                                /   |   \                 +----+
                               /    |    \
                            +---+ +---+ +---+
                            |PE6| |PE7| |PE8|
                            +---+ +---+ +---+
                              |     |     |
                              AC    AC    AC
                              |     |     |

          Figure 3 - Physical Topology for Broadcast video


Delord et al.              Expires January 2013                [Page 16]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   Figure 3 is split in three logical components:

     - The Core network composed of P1, P2, P3 & P4. These 4 network
       elements are P routers connected in a ring.

     - The Data Centers. These are a few large PoPs with high resiliency
       that hold the video content. PE1 & PE2 are located in one Data
       Center and are dual-homed to the core network. An Ethernet
       broadcast source is connected to each PE in the Data Center.

     - The Aggregation network. The Aggregation network is responsible
       for aggregating last mile technology towards endusers (direct
       fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers
       in an aggregation PoP and single-homed to the Core network.

   There are two different video distribution services organised as
   follows:

     - PE1 is connected to PE3, PE4, ... PE14 via VPLS instance-1.
     - One Ethernet broadcast source is connected to PE1 into VPLS
       instance-1.
     - PE2 is connected to PE3, PE4  ...PE14 via VPLS instance-2.
     - One Ethernet broadcast source is connected to PE2 into VPLS
       instance-2.

A.2. Impact of Physical Topologies on Ethernet Broadcast/multicast
     replication

   Following the standard VPLS flooding mechanism, each time PE1
   receives one broadcast frame from the Ethernet broadcast source on
   VPLS-1, PE1 will replicate 12 times the incoming frame.

   Similarly, each time PE2 receives one broadcast frame from the
   Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the
   incoming frame.


















Delord et al.              Expires January 2013                [Page 17]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


A.3. Proposed enhancement of Ethernet broadcast/multicast

   The proposed enhancements are done in three steps:

     - create P2MP LSPs for the infrastructure. These P2MP LSPs are
       used to carry one or more P2MP PWs.

     - create unidirectional P2MP PWs by selectively choosing PEs where
       the optimisation should occur.

     - forward Ethernet broadcast/multicast frames onto the P2MP PWs
       where these P2MP PWs have been created.

   It is up to the network operator to decide how the distribution of
   the loading on physical link should occur.

   Two different examples are presented below.

A.3.1. One possible enhancement scenario

A.3.1.1. Initial Deployment

    In this scenario, the operator decides to create the following P2MP
    LSPs:

     - PE1->PE3-5 via P1 called LSP1
     - PE1->PE6-8 via P2 called LSP2
     - PE1->PE9-11 via P3 called LSP3

     - PE2->PE3-5 via P1 called LSP4
     - PE2->PE6-8 via P2 called LSP5
     - PE2->PE9-11 via P3 called LSP6

    The operator then creates the following P2MP PWs:

     - PE1->PE3-5 via P2MP PW1 over LSP1
     - PE1->PE6-8 via P2MP PW2 over LSP2
     - PE1->PE9-11 via P2MP PW3 over LSP3

     - PE2->PE3-5 via P2MP PW4 over LSP4
     - PE2->PE6-8 via P2MP PW5 over LSP5
     - PE2->PE9-11 via P2MP PW6 over LSP6

    There is no P2MP PWs between PE1 and PE12, PE13 and PE14.
    There is no P2MP PWs between PE2 and PE12, PE13 and PE14.








Delord et al.              Expires January 2013                [Page 18]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


   There are several reasons why a P2MP PW may not be available on this
   part of the network (e.g. PE12, PE13 and PE14), for example:

      - the hardware/software may not allow the support of the
        required features (P2MP LSPs and/or P2MP PWs).
      - the operator does not need to improve multicast/broadcast
        services there (e.g. no specific bandwidth issue).
      - the operator is currently under a migration phase where only
        part of the network is migrated at a time.

   In this case, when PE1 receives one broadcast frame from the
   Ethernet broadcast source on VPLS-1:
      - PE1 sends one copy of the broadcast frame onto P2MP PW1
      - PE1 sends one copy of the broadcast frame onto P2MP PW2
      - PE1 sends one copy of the broadcast frame onto P2MP PW3
      - PE1 sends one copy onto the P2P PW towards PE12
      - PE1 sends one copy onto the P2P PW towards PE13
      - PE1 sends one copy onto the P2P PW towards PE14

   PE1 only replicates 6 copies now (this is an improvement from 12
   copies if only using P2P PWs).

A.3.1.2 Multiple P2MP PWs

   Let's assume now that a new broadcast service is targeted at covering
   endusers geographically connected to PE9, PE10 and PE11.

   For example, this could be a wholesale service, where another carrier
   with limited footprint for the region covered by PE9, PE10 and PE11
   is seeking access for deploying its own broadcast application.

   Based on the proposal in this document, and assuming that the
   application also needs unicast data exchange, if the new broadcast
   source is connected to PE1, it is then possible to:

   - Create a new VPLS instance on PE1, PE9, PE10 and PE11 and a full-
     mesh of P2P PWs between all 4 PEs.

   - Build a new P2MP PW, called P2MP PW7 between PE1, PE9, PE10 & PE11
     that uses the existing P2MP LSP - LSP3.

   This proposal allows for both P2MP PW3 and P2MP PW7 to be carried
   through a single MPLS P2MP tunnel, thus, removing the need to
   maintain state in the network core for individual P2MP PWs. The P
   routers in the core only need to be aware of the P2MP LSPs.








Delord et al.              Expires January 2013                [Page 19]


Internet Draft   Ext to LDP-VPLS for broadcast multicast       July 2012


A.3.2. Another possible enhancement scenario

   In this scenario, the operator decides to create the following two
   P2MP LSPs:

     - PE1-> PE3-14 via LSP1:
            - P1 as a branch towards PE3, PE4, PE5, P2 and P3
            - P2 as a branch towards PE6, PE7, PE8 and P4
            - P3 as a branch towards PE9, PE10 and PE11
            - P4 as a branch towards PE12, PE13 and PE14

     - PE2-> PE3-14 via LSP2:
            - P2 as a branch towards PE6, PE7, PE8, P1 and P4
            - P1 as a branch towards PE3, PE4, PE5 and P3
            - P3 as a branch towards PE9, PE10 and PE11
            - P4 as a branch towards PE12, PE13 and PE14

   The operator then creates the following P2MP PWs:

     - PE1-> PE3-14 via P2MP PW1 over LSP1
     - PE2-> PE3-14 via P2MP PW2 over LSP2

   This case improves the P2P PW scenario as PE1 only replicates a
   single copy of the broadcast frame received from the Ethernet
   broadcast source.


Copyright Notice

   Copyright (c) 2011 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.












Delord et al.              Expires January 2013                [Page 20]