[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
   INTERNET DRAFT                                            Y. Serbest
   Internet Engineering Task Force                                  SBC
   Document:                                              Marc Lasserre
   draft-serbest-l2vpn-vpls-mcast-00.txt                       Rob Nath
   October 2004                                              Riverstone
   Category: Informational                                Vach Kompella
   Expires: April 2005                                          Ray Qiu
                                                        Sunil Khandekar
                                                                Alcatel


                   Supporting IP Multicast over VPLS

   Status of this memo

   By submitting this Internet-Draft, we represent that any applicable
   patent or other IPR claims of which we are aware have been
   disclosed, or will be disclosed, and any of which we are aware have
   been or will be disclosed, and any of which we become aware will be
   disclosed in accordance with RFC 3668.

   This document is an Internet-Draft and is in full conformance with
   Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668.

   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.

   Abstract

   In Virtual Private LAN Service (VPLS), the PE devices provide a
   logical interconnect such that CE devices belonging to a specific
   VPLS instance appear to be connected by a single LAN.  A VPLS
   solution performs replication for multicast traffic at the ingress
   PE devices.  When replicated at the ingress PE, multicast traffic
   wastes bandwidth when 1. Multicast traffic is sent to sites with no
   members, and 2. Pseudo wires to different sites go through a shared
   path.  This document is addressing the former by IGMP and PIM
   snooping.

   Conventions used in this document

                                                              [Page 1]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   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.

   Table of Contents
1  Introduction......................................................3
2  Overview of VPLS..................................................3
3  Multicast Traffic over VPLS.......................................4
4  Constraining of IP Multicast in a VPLS............................5
 4.1General Rules for IGMP/PIM Snooping in VPLS......................6
 4.2IGMP Snooping for VPLS...........................................6
   4.2.1   IGMP Join.................................................7
   4.2.2   IGMP Leave...............................................11
   4.2.3   Failure Scenarios........................................11
 4.3PIM Snooping for VPLS...........................................12
   4.3.1   PIM-DM...................................................13
   4.3.2   PIM-SM...................................................17
   4.3.3   PIM-SSM..................................................21
   4.3.4   Bidirectional-PIM (BIDIR-PIM)............................23
5  Security Considerations..........................................27
6  References.......................................................27
 6.1Normative References............................................28
 6.2Informative References..........................................28
7  Authors' Addresses...............................................28
8  Intellectual Property Statement..................................29
9  Full copyright statement.........................................29




























                                                              [Page 2]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



1 Introduction
   In Virtual Private LAN Service (VPLS), the Provider Edge (PE)
   devices provide a logical interconnect such that Customer Edge (CE)
   devices belonging to a specific VPLS instance appear to be connected
   by a single LAN. Forwarding information base for particular VPLS
   instance is populated dynamically by source MAC address learning.
   This is a straightforward solution to support unicast traffic, with
   reasonable flooding for unicast unknown traffic.  Since a VPLS
   provides LAN emulation for IEEE bridges as wells as for routers, the
   unicast and multicast traffic need to follow the same path for
   layer-2 protocols to work properly.  As such, multicast traffic is
   treated as broadcast traffic and is flooded to every site in the
   VPLS instance.

   VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication
   for multicast traffic at the ingress PE devices.  When replicated at
   the ingress PE, multicast traffic wastes bandwidth when: 1.
   Multicast traffic is sent to sites with no members, 2. Pseudo wires
   to different sites go through a shared path, and 3. Multicast
   traffic is forwarded along a shortest path tree as opposed to the
   minimum cost spanning tree.  This document is addressing the first
   problem by IGMP and PIM snooping.  Using VPLS in conjunction with
   IGMP and/or PIM snooping has the following advantages:
     - It improves VPLS to support IP multicast efficiently (not
        necessarily optimum, as there can still be bandwidth waste),
     - It prevents sending multicast traffic to sites with no members,
     - It keeps P routers in the core stateless,
     - The Service Provider (SP) does not need to perform the tasks to
        provide multicast service (e.g., running PIM, managing P-group
        addresses, managing multicast tunnels etcà)
     - The SP does not need to maintain PIM adjacencies with the
        customers.

   In this document, we describe the procedures for Internet Group
   Management Protocol (IGMP) and Protocol Independent Multicast (PIM)
   snooping over VPLS for efficient distribution of IP multicast
   traffic.

2 Overview of VPLS
   In case of VPLS, the PE devices provide a logical interconnect such
   that CE devices belonging to a specific VPLS appear to be connected
   by a single LAN.  End-to-end VPLS consists of a bridge module and a
   LAN emulation module ([L2VPN-FR]).

   In a VPLS, a customer site receives Layer-2 service from the SP.
   The PE is attached via an access connection to one or more CEs.  The
   PE performs forwarding of user data packets based on information in
   the Layer-2 header, that is, MAC destination address.  The CE sees a
   bridge.



                                                              [Page 3]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



   The details of VPLS reference model, which we summarize here, can be
   found in [L2VPN_FR].  In VPLS, the PE can be viewed as containing a
   Virtual Switching Instance (VSI) for each L2VPN that it serves.  A
   CE device attaches, possibly through an access network, to a bridge
   module of a PE.  Within the PE, the bridge module attaches, through
   an Emulated LAN Interface to an Emulated LAN.  For each VPLS, there
   is an Emulated LAN instance.  The Emulated LAN consists of VPLS
   Forwarder module (one per PE per VPLS service instance) connected by
   pseudo wires (PW), where the PWs may be traveling through Packet
   Switched Network (PSN) tunnels over a routed backbone.  VSI is a
   logical entity that contains a VPLS forwarder module and part of the
   bridge module relevant to the VPLS service instance [L2VPN-FR].
   Hence, the VSI terminates PWs for interconnection with other VSIs
   and also terminates attachment circuits (ACs) for accommodating CEs.
   A VSI includes the forwarding information base for a L2VPN [L2VPN-
   FR] which is the set of information regarding how to forward Layer-2
   frames received over the AC from the CE to VSIs in other PEs
   supporting the same L2VPN service (and/or to other ACs), and
   contains information regarding how to forward Layer-2 frames
   received from PWs to ACs.  Forwarding information bases can be
   populated dynamically (such as by source MAC address learning) or
   statically (e.g., by configuration).  Each PE device is responsible
   for proper forwarding of the customer traffic to the appropriate
   destination(s) based on the forwarding information base of the
   corresponding VSI.

3 Multicast Traffic over VPLS
   In VPLS, if a PE receives a frame from an Attachment Circuit (AC)
   with no matching entry in the forwarding information base for that
   particular VPLS instance, it floods the frame to all other PEs
   (which are part of this VPLS instance) and to directly connected ACs
   (other than the one that the frame is received from).  The flooding
   of a frame occurs when:
     - The destination MAC address has not been learned,
     - The destination MAC address is a broadcast address,
     - The destination MAC address is a multicast address.

   Malicious attacks (e.g., receiving unknown frames constantly) aside,
   the first situation is handled by VPLS solutions as long as
   destination MAC address can be learned.  After that point on, the
   frames will not be flooded.  A PE is REQUIRED to have safeguards,
   such as unknown unicast limiting and MAC table limiting, against
   malicious unknown unicast attacks.

   There is no way around flooding broadcast frames.  To prevent
   runaway broadcast traffic from adversely affecting the VPLS service
   and the SP network, a PE is REQUIRED to have tools to rate limit the
   broadcast traffic as well.




                                                              [Page 4]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   Similar to broadcast frames, multicast frames are flooded as well,
   as a PE can not know where multicast members reside.  Rate limiting
   multicast traffic, while possible, should be should be done
   carefully since several network control protocols relies on
   multicast.  For one thing, layer-2 and layer-3 protocols utilize
   multicast for their operation.  For instance, Bridge Protocol Data
   Units (BPDUs) use an IEEE assigned all bridges multicast MAC
   address, and OSPF is multicast to all OSPF routers multicast MAC
   address.  If the rate-limiting of multicast traffic is not done
   properly, the customer network will experience instability and poor
   performance.  For the other, it is not straightforward to determine
   the right rate limiting parameters for multicast.

   A VPLS solution MUST NOT affect the operation of customer layer-2
   protocols (e.g., BPDUs).  Additionally, a VPLS solution MUST NOT
   affect the operation of layer-3 protocols.

   In the following section, we describe procedures to constrain the
   flooding of IP multicast traffic in a VPLS.

4 Constraining of IP Multicast in a VPLS
   The objective of improving the efficiency of VPLS for multicast
   traffic that we are trying to optimize here has the following
   constraints:
     - The service is VPLS, i.e., a layer-2 VPN,
     - In VPLS, ingress replication is required,
     - There is no layer-3 adjacency (e.g., PIM) between a CE and a
        PE.

   Under these circumstances, the most obvious approach is
   implementation of IGMP and PIM snooping in VPLS.  Other multicast
   routing protocols such as DVMRP and MOSPF are outside the scope of
   this document.

   Another approach to constrain multicast traffic in a VPLS is to
   utilize point-multipoint LSPs (e.g., [PMP-RSVP-TE]).  In such case,
   one has to establish a point-multipoint LSP from a source PE (i.e.,
   the PE to which the source router is connected to) to all other PEs
   participating in the VPLS instance.  In this case, if nothing is
   done, all PEs will receive multicast traffic even if they donÆt have
   any members hanging off of them.  One can apply IGMP/PIM snooping,
   but this time IGMP/PIM snooping should be done in P routers as well.
   One can propose a dynamic way of establishing point-multipoint LSPs,
   for instance by mapping IGMP/PIM messages to RSVP-TE signaling.  One
   should consider the effect of such approach on the signaling load
   and on the delay between the time the join request received and the
   traffic is received (this is important for IPTV application for
   instance).  This approach is outside the scope of this document.

   Although, in some extremely controlled cases, such as a ring
   topology of PE routers with no P routers or a tree topology, the


                                                              [Page 5]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   efficiency of the replication of IP multicast can be improved.  For
   instance, spoke PWs of a hierarchical VPLS can be daisy-chained
   together and some replication rules can be devised.  These cases are
   not expected to be common and will not be considered in this
   document.

   In the following sections, we provide some guidelines for the
   implementation of IGMP and PIM snooping in VPLS.

4.1 General Rules for IGMP/PIM Snooping in VPLS
   The following rules for the correct operation of IGMP/PIM snooping
   MUST be followed.

   Rule 1: IGMP and PIM messages forwarded by PEs MUST follow the
   split-horizon rule for mesh PWs as defined in [VPLS-LDP].

   Rule 2: IGMP/PIM snooping states in a PE MUST be per VPLS instance.

   Rule 3: If a PE does not have any entry in a IGMP/PIM snooping state
   for multicast group (*,G) or (S,G), the multicast traffic to that
   group in the VPLS instance MUST be flooded.

   Rule 4: A PE MUST support PIM mode selection per VPLS instance via
   CLI and/or EMS. Another option could be to deduce the PIM mode from
   RP address for a specific multicast group. For instance, a RP
   address can be learned during the Designated Forwarder (DF) election
   stage for Bidirectional-PIM.

4.2 IGMP Snooping for VPLS
   IGMP is a mechanism to inform the routers on a subnet of a hostÆs
   request to become a member of a particular multicast group.  IGMP is
   a stateful protocol.  The router (i.e., the querier) regularly
   verifies that the hosts want to continue to participate in the
   multicast groups by sending periodic queries, transmitted to all
   hosts multicast group (IP:224.0.0.1, MAC:01-00-5E-00-00-01) on the
   subnet.  If the hosts are still interested in that particular
   multicast group, they respond with membership report message,
   transmitted to the multicast group of which they are members.  In
   IGMPv1 [RFC1112], the hosts simply stop responding to IGMP queries
   with membership reports, when they want to leave a multicast group.
   IGMPv2 [RFC2236] adds a leave message that a host will use when it
   needs to leave a particular multicast group.  IGMPv3 [RFC3376]
   extends the report/leave mechanism beyond multicast group to permit
   joins and leaves to be issued for specific source/group (S,G) pairs.

   In IGMP snooping, a PE snoops on the IGMP protocol exchange between
   hosts and routers, and based on that restricts the flooding of IP
   multicast traffic.  In the following, we explore the mechanisms
   involved in implementing IGMP snooping for VPLS.  Please refer to
   Figure 1 as an example of VPLS with IGMP snooping.  In the figure,
   Router 1 is the Querier.  If multiple routers exist on a single
   subnet (basically that is what a VPLS instance is), they can


                                                              [Page 6]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   mutually elect a designated router (DR) that will manage all of the
   IGMP messages for that subnet.


                                  VPLS Instance
            +------+ AC1 +------+             +------+ AC4 +------+
            | Host |-----|  PE  |-------------|  PE  |-----|Router|
            |   1  |     |   1  |\   PW1to3  /|   3  |     |   1  |
            +------+     +------+ \         / +------+     +------+
                             |     \       /     |
                             |      \     /      |
                             |       \   /PW2to3 |
                             |        \ /        |
                       PW1to2|         \         |PW3to4
                             |        / \        |
                             |       /   \PW1to4 |
                             |      /     \      |
                             |     /       \     |
            +------+     +------+ /         \ +------+     +------+
            | Host |     |  PE  |/   PW2to4  \|  PE  |     |Router|
            |   2  |-----|   2  |-------------|   4  |-----|   2  |
            +------+ AC2 +------+             +------+ AC5 +------+
                             |
                             |AC3
                         +------+
                         | Host |
                         |   3  |
                         +------+


         Figure 1 Reference Diagram for IGMP Snooping for VPLS

4.2.1  IGMP Join
   The IGMP snooping mechanism for joining a multicast group (for all
   IGMP versions) works as follows:
     - The Querier sends a membership query to all hosts
        (IP:224.0.0.1, MAC:01-00-5E-00-00-01).  The membership query
        can be either general query or group specific query.
     - PE 3 replicates the query message and forwards it to all PEs
        participating in the VPLS instance (i.e., PE 1, PE 2, PE 4).
     - PE 3 notes that there is already a directly connected Querier.
        Basically, it keeps a state of [(*,G);Querier: AC4], if it is a
        group specific query.  It keeps a state of [(*,*);Querier:AC4],
        if it is a general query.
     - All PEs then forward the query to ACs which are part of the
        VPLS instance.
     - At this point all PEs learn the place of the Querier.  For
        instance, for PE 1 it is behind PW1to3, for PE 2 behind PW2to3,
        for PE 3 behind AC4, for PE 4 behind PW3to4.



                                                              [Page 7]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - Suppose that all hosts (Host 1, Host 2, and Host 3) want to
        participate in the multicast group.
     - Host 2 first (for the sake of the example) sends a membership
        report to the multicast group (e.g., IP: 239.1.1.1, MAC: 01-00-
        5E-01-01-01), of which Host 2 wants to be a member.
     - PE 2 replicates the membership report message and forwards it
        to all PEs participating in the VPLS instance (i.e., PE 1, PE
        3, PE 4).
     - PE 2 notes that there is a directly connected host, which is
        willing to participate in the multicast group and updates its
        state to [(*,G);Querier:PW2to3;Hosts:AC2].

     Guideline 1: A PE MUST NOT forward a membership report message to
     ACs participating in the VPLS instance, unless it received query
     message from that AC.  This is necessary to avoid report
     suppression for other members in order for the PEs to construct
     correct states and to not have any orphan receiver hosts.

     - PE 2 does not forward the membership report of Host 2 to Host
        3.
     - Per the guideline above, PE 1 does not forward the membership
        report of Host 2 to Host 1.
     - Per the guideline above, PE 3 does forward the membership
        report of Host 2 to Router 1 (the Querier).
     - PE 3 notes that there is a host in the VPLS instance, which is
        willing to participate in the multicast group and updates its
        state to [(*,G);Querier:AC4;Hosts:PW2to3] regardless of the
        type of the query.
     - LetÆs assume that Host 1 subsequently sends a membership report
        to the same multicast group.
     - PE 1 replicates the membership report message and forwards it
        to all PEs participating in the VPLS instance (i.e., PE 2, PE
        3, PE 4).
     - PE 1 notes that there is a directly connected host, which is
        willing to participate in the multicast group.  Basically, it
        keeps a state of [(*,G);Querier:PW1to3;Hosts:AC1,PW1to2].
     - Per Guideline 1, PE 2 does not forward the membership report of
        Host 1 to Host 2 and Host 3.
     - PE 3 receives the membership report message of Host 1 and
        checks its states.  Per Guideline 1, it sends the report to
        Router 1.  It also updates its state to
        [(*,G);Querier:AC4;Hosts:PW2to3,PW1to3].
     - Now, Host 3 sends a membership report to the same multicast
        group.




                                                              [Page 8]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - PE 2 updates its state to
        [(*,G);Querier:PW2to3;Hosts:AC2,AC3,PW1to2]. It then floods the
        report message to all PEs participating in the VPLS instance.
        Per Guideline 1, only PE 3 forwards the membership report of
        Host 3 to Router 1.
     - At this point, all PEs have necessary states to ensure that no
        multicast traffic will be sent to sites with no members.

   The previous steps work the same way for all three (IGMPv1, IGMPv2,
   and IGMPv3), when the query is general or source specific.

   The group and source specific query for IGMPv3 is considered
   separately below.

   The IGMP snooping mechanism for joining a multicast group (for
   IGMPv3) works as follows:
     - The Querier sends a membership query to all hosts
        (IP:224.0.0.1, MAC:01-00-5E-00-00-01).  The membership query is
        group and source specific query with a list of sources (e.g.,
        S1, S2, à, Sn).
     - PE 3 replicates the query message and forwards it to all PEs
        participating in the VPLS instance (i.e., PE 1, PE 2, PE 4).
     - PE 3 notes that there is already a directly connected Querier.
        Basically, it keeps a state of {[(S1,G);Querier: AC4],
        [(S2,G);Querier: AC4], à, [(Sn,G);Querier: AC4]}.
     - All PEs then forward the query to ACs which are part of the
        VPLS instance.
     - At this point, all PEs learn the place of the Querier.  For
        instance, for PE 1 it is behind PW1to3, for PE 2 behind PW2to3,
        for PE 3 behind AC4, for PE 4 behind PW3to4.
     - Suppose that all hosts (Host 1, Host 2, and Host 3) want to
        participate in the multicast group.  Host 1 and Host 2 want to
        subscribe to (Sn,G), and Host 3 wants to subscribe to (S3,G).
     - Host 2 first (for the sake of the example) sends a membership
        report message for (Sn,G) to IP address of 224.0.0.22 (MAC:01-
        00-5E-00-00-16).
     - PE 2 replicates the membership report message and forwards it
        to all PEs participating in the VPLS instance (i.e., PE 1, PE
        3, PE 4).
     - PE 2 notes that there is a directly connected host, which is
        willing to participate in the multicast group and updates its
        state to {[(Sn,G);Querier:PW2to3;Hosts:AC2]}.
     - Per Guideline 1, PE 2 does not forward the membership report of
        Host 2 to Host 3.
     - Per Guideline 1, PE 1 does not forward the membership report of
        Host 2 to Host 1.



                                                              [Page 9]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - Per Guideline 1, PE 3 does forward the membership report of
        Host 2 to Router 1 (the Querier).
     - PE 3 notes that there is a host in the VPLS instance, which is
        willing to participate in the multicast group.  Basically, it
        updates its state to {[(S1,G);Querier: AC4], [(S2,G);Querier:
        AC4], à, [(Sn,G);Querier: AC4;Hosts: PW2to3]}.
     - LetÆs say Host 1 now sends a membership report to the same
        multicast group.
     - PE 1 replicates the membership report message and forwards it
        to all PEs participating in the VPLS instance (i.e., PE 2, PE
        3, PE 4).
     - PE 1 notes that there is a directly connected host, which is
        willing to participate in the multicast group.  Basically, it
        keeps a state of {[(Sn,G);Querier:PW1to3;Hosts:AC1,PW1to2]}.
     - Per Guideline 1, PE 2 does not forward the membership report of
        Host 1 to Host 2 and Host 3.
     - PE 3 receives the membership report message of Host 1 and
        checks its states.  It updates its state to {[(S1,G);Querier:
        AC4], [(S2,G);Querier: AC4], à, [(Sn,G);Querier: AC4;Hosts:
        PW2to3,PW1to3]}. It then forwards the membership report of Host
        1 to Router 1 per Guideline 1.
     - Finally, Host 3 sends a membership report to the same multicast
        group (S3,G).
     - PE 2 replicates the membership report message and forwards it
        to all PEs participating in the VPLS instance (i.e., PE 1, PE
        3, PE 4).
     - Per Guideline 1, PE 2 does not forward the membership report of
        Host 3 to Host 2.
     - Per Guideline 1, PE 1 does not forward the membership report of
        Host 3 to Host 1.
     - Per Guideline 1, PE 3 does forward the membership report of
        Host 3 to Router 1 (the Querier).
     - PE 2 notes that there is a directly connected host, which is
        willing to participate in the multicast group and updates its
        state to {[(S3,G);Querier:PW2to3;Hosts:AC3] ,
        [(Sn,G);Querier:PW2to3;Hosts:AC2,PW1to2]}.
     - PE 3 receives the membership report message of Host 3 and
        checks its states.  It updates its state to {[(S1,G);Querier:
        AC4], [(S2,G);Querier: AC4], [(S3,G);Querier:
        AC4;Hosts:PW2to3], à, [(Sn,G);Querier: AC4;Hosts:
        PW2to3,PW1to3]}.  It then forwards the membership report to the
        Querier (Router 1).

   At this point, all PEs have necessary states to not send multicast
   traffic to sites with no members.



                                                             [Page 10]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   Based on above description of IGMPv3 based snooping for VPLS, one
   may conclude that the PEs MUST have the capability to store (S,G)
   state and MUST forward/replicate traffic accordingly.  This is,
   however, not MANDATORY.  A PE MAY only keep (*,G) based states
   rather than on a per (S,G) basis with the understanding that this
   will result in a less efficient IP multicast forwarding within each
   VPLS instance.

   Guideline 2: If a PE receives unsolicited report message and if it
   does not possess a state for that particular multicast group, it
   MUST flood that unsolicited membership report message to all PEs
   participating in the VPLS instance, as well as to the Querier if it
   is locally attached.

4.2.2  IGMP Leave
   The IGMP snooping mechanism for leaving a multicast group works as
   follows:
     - In the case of IGMPv2/IGMPv3, when a PE receives a leave
        (*,G)/(S,G) message from a host via its AC, first it removes
        the AC from its state.

     Guideline 3: A PE MUST NOT forward a leave (*,G)/(S,G) message to
     ACs participating in the VPLS instance, If the PE still has
     locally connected hosts or hosts connected over a H-VPLS spoke in
     its state.

     Guideline 4: A PE MUST forward a leave (*,G)/(S,G) message to all
     PEs participating in the VPLS instance.  A PE MAY forward the
     leave (*,G)/(S,G) message to the Querier ONLY, if there are no
     member hosts in its state.

     Guideline 5: If a PE does not receive a membership report from an
     AC for the three consecutive queries, the PE MUST remove the AC
     from its state.

4.2.3  Failure Scenarios
   Up to now, we did not consider any failures, which we will focus in
   this section.
     - In case the Querier fails (e.g., AC to the querier fails),
        another router in the VPLS instance will be selected as the DR.
        The new DR will be sending queries.  In such circumstances, the
        IGMP snooping states in the PEs will be updated/overwritten by
        the same procedure explained above.
     - In case a host fails (e.g., AC to the host fails), a PE removes
        the host from its IGMP snooping state for that particular
        multicast group.  Guidelines 3, 4 and 5 still apply here.
     - In case a PW (which is in IGMP snooping state) fails, the PEs
        will remove the PW from their IGMP snooping state.  For


                                                             [Page 11]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        instance, if PW1to3 fails, then PE 1 will remove PW1to3 from
        its state as the Querier connection, and PE 3 will remove
        PW1to3 from its state as one of the host connections.
        Guidelines 3, 4 and 5 still apply here.  After PW is restored,
        the IGMP snooping states in the PEs will be updated/overwritten
        by the same procedure explained above.  One can implement a
        dead timer before making any changes to IGMP snooping states
        upon PW failure.  In that case, IGMP snooping states will be
        altered if the PW can not be restored before the dead timer
        expires.

4.3 PIM Snooping for VPLS
   IGMP snooping procedures described above provide efficient delivery
   of IP multicast traffic in a given VPLS service when end stations
   are connected to the VPLS.  However, when VPLS is offered as a WAN
   service it is likely that the CE devices are routers and would run
   PIM between them.  To provide efficient IP multicasting in such
   cases, it is necessary that the PE routers offering the VPLS service
   do PIM snooping.  This section describes the procedures for PIM
   snooping.

   PIM is a multicast routing protocol, which runs exclusively between
   routers. PIM shares many of the common characteristics of a routing
   protocol, such as discovery messages (e.g., neighbor discovery using
   Hello messages), topology information (e.g., multicast tree), and
   error detection and notification (e.g., dead timer and designated
   router election).  On the other hand, PIM does not participate in
   any kind of exchange of databases, as it uses the unicast routing
   table to provide reverse path information for building multicast
   trees.  There are a few variants of PIM.  In PIM-DM ([PIM-DM]),
   multicast data is pushed towards the members similar to broadcast
   mechanism.  PIM-DM constructs a separate delivery tree for each
   multicast group.  As opposed to PIM-DM, other PIM versions (PIM-SM
   [RFC2362], PIM-SSM [PIM-SSM], and BIDIR-PIM [BIDIR-PIM]) invokes a
   pull methodology instead of push technique.

   PIM routers periodically exchange Hello messages to discover and
   maintain stateful sessions with neighbors.  After neighbors are
   discovered, PIM routers can signal their intentions to join/prune
   specific multicast groups.  This is accomplished by having
   downstream routers send an explicit join message (for the sake of
   generalization, consider Graft messages for PIM-DM as join messages)
   to the upstream routers.  The join/prune message can be group
   specific (*,G) or group and source specific (S,G).

   In PIM snooping, a PE snoops on the PIM message exchange between
   routers, and builds its multicast states.  Based on the multicast
   states, it forwards IP multicast traffic accordingly to avoid
   unnecessary flooding.



                                                             [Page 12]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   In the following, the mechanisms involved for implementing PIMv2
   ([RFC2362]) snooping in VPLS are specified.  PIMv1 is out of the
   scope of this document.  Please refer to Figure 2 as an example of
   VPLS with PIM snooping.


                                  VPLS Instance
            +------+ AC1 +------+             +------+ AC4 +------+
            |Router|-----|  PE  |-------------|  PE  |-----|Router|
            |   1  |     |   1  |\   PW1to3  /|   3  |     |   4  |
            +------+     +------+ \         / +------+     +------+
                             |     \       /     |
                             |      \     /      |
                             |       \   /PW2to3 |
                             |        \ /        |
                       PW1to2|         \         |PW3to4
                             |        / \        |
                             |       /   \PW1to4 |
                             |      /     \      |
                             |     /       \     |
            +------+     +------+ /         \ +------+     +------+
            |Router|     |  PE  |/   PW2to4  \|  PE  |     |Router|
            |   2  |-----|   2  |-------------|   4  |-----|   5  |
            +------+ AC2 +------+             +------+ AC5 +------+
                             |
                             |AC3
                         +------+
                         |Router|
                         |   3  |
                         +------+


          Figure 2 Reference Diagram for PIM Snooping for VPLS

   In the following sub-sections, snooping mechanisms for each variety
   of PIM are specified.

4.3.1  PIM-DM
   The characteristics of PIM-DM is flood and prune behavior.  Shortest
   path trees are built as a multicast source starts transmitting.

   In Figure 2, the multicast source is behind Router 4, and all
   routers have at least one receiver except Router 3 and Router 5.

   The PIM-DM snooping mechanism for neighbor discovery works as
   follows:
     - To establish PIM neighbor adjacencies, PIM multicast routers
        (all routers in this example) send PIM Hello messages to the
        ALL PIM Routers group address (IPv4: 224.0.0.13, MAC: 01-00-5E-
        00-00-0D) on every PIM enabled interfaces.  The IPv6 ALL PIM
        Routers group is "ff02::d".  In addition, PIM Hello messages


                                                             [Page 13]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        are used to elect Designated Router for a multi-access network.
        In PIM-DM, the DR acts as the Querier if IGMPv1 is used.
        Otherwise, DR has no function in PIM-DM.

     Guideline 6: PIM Hello messages MUST be flooded in the VPLS
     instance.  A PE MUST populate its "PIM Neighbors" list according
     to the snooping results.  This is a general PIM snooping guideline
     and applies to all variants of PIM snooping.

     Guideline 7: For PIM-DM only.  The "Flood to" list is populated
     with the ACs/PWs in the "PIM Neighbors" list.  Changes to the "PIM
     Neighbors" list MUST be replicated to the "Flood to" list.

     - Every router starts sending PIM Hello messages.  Per Guideline
        6, every PE replicates Hello messages and forwards them to all
        PEs participating in the VPLS instance.
     - Based on PIM Hello exchanges PE routers populate PIM snooping
        states as follows.  PE 1: {[(,); Source:; Flood to: AC1,
        PW1to2, PW1to3, PW1to4], [PIM Neighbors: (Router 1,AC1),
        (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router
        5,PW1to4)] }, PE 2: {[(,); Source:; Flood to: AC2, AC3, PW1to2,
        PW2to3, PW2to4], [PIM Neighbors: (Router 1,PW1to2), (Router
        2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]},
        PE 3: {[(,); Source:; Flood to: AC4, PW1to3, PW2to3, PW3to4],
        [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Source:;
        Flood to: AC5, PW1to4, PW2to4, PW3to4], [PIM Neighbors: (Router
        1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4),
        (Router 5,AC5)]}.  The original "Flood to" list is populated
        with ACs/PWs in the PIM neighbor list per Guideline 7..
     - PIM Hello messages contain a Holdtime value, which tells the
        receiver when to expire the neighbor adjacency (which is three
        times the Hello period).

     Guideline 8: If a PE does not receive a Hello message from a
     router within its Holdtime, the PE MUST remove that router from
     the PIM snooping state. If a PE receives a Hello message from a
     router with Holdtime value set to zero, the PE MUST remove that
     router from the PIM snooping state immediately.  PEs MUST track
     the Hello Holdtime value per PIM neighbor.

   The PIM-DM snooping mechanism for multicast forwarding works as
   follows:
     - When the source starts sending traffic to multicast group
        (S,G), PE 3 updates its state to PE 3: {[(S,G) ; Source:
        (Router 4,AC4); Flood to: PW1to3, PW2to3, PW3to4], [PIM


                                                             [Page 14]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}.  AC4 is removed from the
        "Flood to" list for (S,G), since it is where the multicast
        traffic comes from.

     Guideline 9: Multicast traffic MUST be replicated per PW and AC
     basis, i.e., even if there are more than one PIM neighbor behind a
     PW/AC, only one replication MUST be sent to that PW/AC.

     - PE 3 replicates the multicast traffic and sends it to the other
        PE routers in its "Flood to" list.
     - Consequently, all PEs update their states as follows. PE 1:
        {[(S,G); Source: (Router 4,PW1to3); Flood to: AC1], [PIM
        Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router
        4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S,G); Source: (Router
        4,PW2to3); Flood to: AC2, AC3], [PIM Neighbors: (Router
        1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3),
        (Router 5,PW2to4)]}, PE 4: {[(S,G); Source: (Router 4,PW3to4);
        Flood to: AC5], [PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.

   At this point all the routers (Router 1, Router 2,Router 3, Router
   5) receive the multicast traffic.

     - However, Router 3 and Router 5 do not have any members for that
        multicast group, so they send prune messages to leave the
        multicast group to the ALL PIM Routers group.  PE 2 updates its
        state to PE 2: {[(S,G); Source: (Router 4,PW2to3); Flood to:
        AC2], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2),
        (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}.  PE 4
        also remove Router 3 and Router 5 from its state as well.

     Guideline 10: PIM join and prune messages MUST be flooded in the
     VPLS instance.

     - PE 2 and PE 4 then flood the prune message and forward it to
        all PEs participating in the VPLS instance per Guideline 10.
        PE 4 updates its state to PE 4: {[(S,G); Source: (Router
        4,AC4); Flood to:], [PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.
     - PIM-DM prune messages contain a Holdtime value, which specifies
        how many seconds the prune state should last.

     Guideline 11: For PIM-DM only.  A PE MUST keep the prune state for
     a PW/AC according to the Holdtime in the prune message, unless a
     corresponding Graft message is received.


                                                             [Page 15]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



     - Upon receiving the prune messages, each PE updates its state
        accordingly. PE 1: {[(S,G); Source: (Router 4,PW1to3); Flood
        to: AC1], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,
        PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S,G);
        Source: (Router 4,PW2to3); Flood to: AC2], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(S,G); Source: (Router
        4,AC4); Flood to: PW1to3, PW2to3], [PIM Neighbors: (Router
        1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router
        5, PW3to4)]}, PE 4: {[(S,G); Source: (Router 4,PW3to4); Flood
        to:], [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router
        3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.

     Guideline 12: To avoid overriding joins, a PE SHOULD suppress the
     PIM prune messages to directly connected routers (i.e., ACs), as
     long as there is a PW/AC in its corresponding "Flood to" list.

     - In this case, PE 1, PE 2, and PE 3 do not forward the prune
        messages to their directly connected routers.

   The multicast traffic is now flowing only to points in the network
   where receivers are present.

     Guideline 13: For PIM-DM only.  A PE MUST remove the AC/PW from
     its corresponding prune state when it receives a graft message
     from the AC/PW.  That is, the corresponding AC/PW MUST be added to
     the "Flood to" list.

     Guideline 14: For PIM-DM only.  PIM-DM graft messages MUST be
     forwarded based on the destination MAC address.  If the
     destination MAC address is 01-00-5E-00-00-0D, then the graft
     message MUST be flooded in the VPLS instance.

     - For the sake of example, suppose now Router 3 has a receiver
        the multicast group (S,G).  Assuming Router 3 sends a graft
        message in IP unicast to Router 4 to restart the flow of
        multicast traffic.  PE 2 updates its state to PE 2: {[(S,G);
        Source: (Router 4,PW2to3); Flood to: AC2, AC3], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)]}.  PE 2 then forwards the graft
        message to PE 3 according to Guideline 14.
     - Upon receiving the graft message, PE 3 updates its state
        accordingly to PE 3: {[(S,G); Source: (Router 4,AC4); Flood to:
        PW1to3, PW2to3], [PIM Neighbors: (Router 1,PW1to3), (Router
        2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}.


                                                             [Page 16]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



     Guideline 15: PIM Assert messages MUST be flooded in the VPLS
     instance.

     Guideline 16: If an AC/PW goes down, a PE MUST remove it from its
     PIM snooping state.

   Failures can be easily handled in PIM-DM snooping, as it uses push
   technique.  If an AC or a PW goes down, PEs in the VPLS instance
   will remove it from their snooping state (if the AC/PW is not
   already pruned).  After the AC/PW comes back up, it will be
   automatically added to the snooping state by PE routers, as all
   PWs/ACs MUST be in the snooping state, unless they are pruned later
   on.

4.3.2  PIM-SM
   The key characteristics of PIM-SM is explicit join behavior.  In
   this model, the multicast traffic is only sent to locations that
   specifically request it.  The root node of a tree is the Rendezvous
   Point (RP) in case of a shared tree or the first hop router that is
   directly connected to the multicast source in the case of a shortest
   path tree.

   In Figure 2, the RP is behind Router 4, and all routers have at
   least one member except Router 3 and Router 5.

   The PIM-SM snooping mechanism for neighbor discovery works the same
   way as t procedure defined in PIM-DM section, with the exception of
   PIM-DM only guidelines.
     - Based on PIM Hello exchanges PE routers populate PIM snooping
        states as follows.  PE 1: {[(,); Flood to:], [PIM Neighbors:
        (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3),
        (Router 5,PW1to4)]}, PE 2: {[(,); Flood to:], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(,); Flood to:], [PIM
        Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to:],
        [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.

   For PIM-SM to work properly, all routers within the domain must use
   the same mappings of group addresses to RP addresses.  Currently,
   there are three methods for RP discovery: 1. Static RP
   configuration, 2, Auto-RP, and 3. PIMv2 Bootstrap Router mechanism.

     Guideline 17: Cisco RP-Discovery (IP:224.0.1.40, MAC:01-00-5E-00-
     01-28), Cisco-RP-Announce (IP:224.0.1.39, MAC:01-00-5E-00-01-27),
     all bootstrap router (BSR) (IP:224.0.0.13, MAC:01-00-5E-00-00-0D)
     messages MUST be flooded in the VPLS instance.


                                                             [Page 17]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



   The PIM-SM snooping mechanism for joining a multicast group (*,G)
   works as follows:
     - Assume Router 1 wants to join the multicast group (*,G) sends a
        join message for the multicsat group (*,G).  PE 1 replicates
        the join message and forwards it to all PE routers in the VPLS
        instance.

     Guideline 18: A PE MUST add a PW/AC to its (*,G) "Flood to" list,
     if it receives a (*,G) join message from the PW/AC.

     - PE 1 updates their states as follows: PE 1: {[(*,G); Flood to:
        AC1], [PIM Neighbors: (Router 1,AC1), (Router 2,Router
        3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}.

   A periodic refresh mechanism is used in PIM-SM to maintain the
   proper state.  PIM-SM join messages contain a Holdtime value, which
   specifies for how many seconds the join state should be kept.

     Guideline 19: If a PE does not receive a refresh join message from
     a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its
     "Flood to" list.

     - PE 1 floods the join message to all PEs in the VPLS instance
        per Guideline 10.
     - All PEs update their states accordingly as follows: PE 1:
        {[(*,G); Flood to: AC1], [PIM Neighbors: (Router 1,AC1),
        (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router
        5,PW1to4)]}, PE 2: {[(*,G); Flood to: PW1to2], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood to:
        PW1to3], [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router
        3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(*,G);
        Flood to: PW1to4], [PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.
     - After Router 2 joins the same multicast group, the states
        become as follows: PE 1: {[(*,G); Flood to: AC1,PW1to2], [PIM
        Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router
        4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(*,G); Flood to: AC2,
        PW1to2], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2),
        (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3:
        {[(*,G); Flood to: PW1to3, PW2to3], [PIM Neighbors: (Router
        1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router
        5,PW3to4)]}, PE 4: {[(*,G); Flood to: PW1to4, PW2to4], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.


                                                             [Page 18]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - For the sake of example, Router 3 joins the multicast group.
        PE 2 floods the join message to the VPLS instance (including
        the Router 2 via AC2).  In turn, PE routers forward the join
        message to their directly connected routers. The states of the
        PEs become as follows: PE 1: {[(*,G); Flood to: AC1,PW1to2],
        [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2),
        (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(*,G); Flood
        to: AC2, AC3, PW1to2], [PIM Neighbors: (Router 1,PW1to2),
        (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router
        5,PW2to4)]}, PE 3: {[(*,G); Flood to: PW1to3, PW2to3], [PIM
        Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(*,G); Flood to:
        PW1to4,PW2to4],[ PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.
     - Next Router 5 joins the group, and the states are updated
        accordingly.

   At this point, all PEs have necessary states to not send multicast
   traffic to sites with no members.

   The PIM-SM snooping mechanism for leaving a multicast group works as
   follows:
     - Assume Router 5 sends a prune message.

     Guideline 20: A PE MUST remove a PW/AC from its (*,G) "Flood to"
     list if it receives a (*,G) prune message from the PW/AC.  A
     prune-delay timer SHOULD be implemented to support prune override.

     - PE 4 floods the (*,G) prune to the VPLS instance.  PE routers
        participating in the VPLS instance also forward the (*,G) prune
        to the ACs, which are connected to the VPLS instance. The
        states are updated as follows: PE 1: {[(*,G); Flood to:
        AC1,PW1to2], [PIM Neighbors: (Router 1,AC1), (Router 2,Router
        3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2:
        {[(*,G); Flood to: AC2, AC3, PW1to2], [PIM Neighbors: (Router
        1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3),
        (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood to: PW1to3, PW2to3],
        [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(*,G); Flood to:
        AC5, PW1to4], [PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}.

   The PIM-SM snooping mechanism for source and group specific join
   works as follows:

     Guideline 21: A PE MUST add a PW/AC to its (S,G) "Flood to" list
     if it receives a (S,G) join message from the PW/AC.


                                                             [Page 19]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



     Guideline 22: A PE MUST remove a PW/AC from its (S,G) "Flood to"
     list if it receives a (S,G) prune message from the PW/AC.  A
     prune-delay timer SHOULD be implemented to support prune override.

     Guideline 23: A PE MUST prefer (S,G) state to (*,G), if both S and
     G match.

     Guideline 24: When a (S,G) is state is first created, the initial
     "Flood to" list MUST be populated by copying the "Flood to" list
     from its parent (*,G) state.

     Guideline 25: In case (*,G) state changes in a PE, all changes to
     (*,G) state MUST (additions and deletions in "Flood to" list) be
     replicated to (S,G) state.

     - Now, we assume Router 5 sends a source and group specific join
        (S,G).  PE 4 floods the (S,G) join to the VPLS instance.  PE
        routers participating in the VPLS instance also forward the
        (S,G) join to the ACs, which are connected to the VPLS
        instance. The states are updated as follows: PE 1: {[(*,G);
        Flood to: AC1,PW1to2],[(S,G); Flood to: AC1,PW1to2,PW1to4],
        [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2),
        (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(*,G); Flood
        to: AC2, AC3, PW1to2], [(S,G); Flood to:
        AC2,AC3,PW1to2,PW2to4], [PIM Neighbors: (Router 1,PW1to2),
        (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router
        5,PW2to4)]}, PE 3: {[(*,G); Flood to: PW1to3, PW2to3], [(S,G);
        Flood to: PW1to3,PW2to3,PW3to4], [PIM Neighbors: (Router
        1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router
        5,PW3to4)]}, PE 4: {[(*,G); Flood to: AC5, PW1to4], [(S,G);
        Flood to: AC5,PW1to4], [PIM Neighbors: (Router 1,PW1to4),
        (Router 2,Router 3,PW2to4), (Router 4,PW3to4), (Router
        5,AC5)]}.
     - Afterwards, we assume Router 5 sends a (S,G)RP-bit prune, also
        known as (S,G,RPT) prune.  PE routers flood this prune message
        and do not take any action.

   As in the case with IGMPv3 snooping, we assume that the PEs have the
   capability to store (S,G) states for PIM-SM snooping and
   forward/replicate traffic accordingly.  This is not mandatory.  An
   implementation, can fall back to (*,G) states, if its hardware can
   not support it.  In such case, the efficiency of multicast
   forwarding will be less.

   Failures can be easily handled in PIM-SM snooping, as it employs
   state-refresh technique.  PEs in the VPLS instance will remove any
   entry for non-refreshing routers from their states.



                                                             [Page 20]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004



   There are some special cases to consider for PIM-SM snooping.  First
   one is the RP-on-a-stick.  The RP-on-a-stick scenario may occur when
   the Shortest Path Tree and the Shared Tree shares a common Ethernet
   segment, as all routers will be connected over a multicast access
   network (i.e., VPLS).  Such a scenario will be handled by PIM-SM
   rules (particularly, the incoming interface can not also appear in
   the outgoing interface list) very nicely.  Second scenario is the
   turnaround router.  The turnaround router scenario occurs when
   shortest path tree and shared tree share a common path.  The router
   at which these tree merge is the turnaround router.  PIM-SM handles
   this case by proxy (S,G) join implementation by the turnaround
   router.

   In PIM-SM snooping, prune messages are flooded by PE routers.  In
   such implementation, PE routers may receive overriding join
   messages, which will not affect anything.  A PE can do prune
   suppression to optimize prune messages.  Future versions will
   include such a mechanism.

4.3.3  PIM-SSM
   The key characteristics of PIM-SSM is explicit join behavior, but it
   eliminates the shared tree and the rendezvous point in PIM-SM.  In
   this model, a shortest path tree for each (S,G) is built with the
   first hop router (that is directly connected to the multicast
   source) being the root node.  PIM-SSM is ideal for one-to-many
   multicast services.

   In Figure 2, S1 is behind Router 1, and S4 is behind Router 4.
   Routers 2 and 4 want to join (S1,G), while Router 5 wants to join
   (S4,G).

   The PIM-SSM snooping mechanism for neighbor discovery works the same
   way as t procedure defined in PIM-DM section, with the exception of
   PIM-DM only guidelines.
     - Based on PIM Hello exchanges PE routers populate PIM snooping
        states as follows.  PE 1: {[(,); Flood to:], [PIM Neighbors:
        (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3),
        (Router 5,PW1to4)]}, PE 2: {[(,); Flood to:], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(,); Flood to:], [PIM
        Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to:],
        [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.

   PIM-SSM snooping is actually simpler than PIM-SM and only the
   following guidelines (some of which are repetitions from PIM-SM
   section) apply.



                                                             [Page 21]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     Guideline 26: A PE MUST add a PW/AC to its (S,G) "Flood to" list
     if it receives a (S,G) join message from the PW/AC.

     Guideline 27: PIM join and prune messages MUST be flooded in the
     VPLS instance.

     Guideline 28: If A PE does not receive a refresh join message from
     a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its
     "Flood to" list.

     Guideline 29: A PE MUST remove a PW/AC from its (S,G) "Flood to"
     list if it receives a (S,G) prune message from the PW/AC.  A
     prune-delay timer SHOULD be implemented to support prune override.

   The PIM-SSM snooping mechanism for joining a multicast group works
   as follows:
     - Assume Router 2 requests to join the multicast group (S1,G).
     - PE 2 updates its state, and then flood the join message in the
        VPLS instance.
     - All PEs update their states as follows: PE 1: {[(S1,G); Flood
        to: PW1to2], [PIM Neighbors: (Router 1,AC1), (Router 2,Router
        3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2:
        {[(S1,G); Flood to: AC2], [PIM Neighbors: (Router 1,PW1to2),
        (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router
        5,PW2to4)]}, PE 3: {[(S1,G); Flood to: PW2to3], [PIM Neighbors:
        (Router 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4),
        (Router 5,PW3to4)]}, PE 4: {[(S1,G); Flood to: PW2to4], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.
     - Next, assume Router 4 sends a join (S1,G) message.  Following
        the same procedures,  all PEs update their states as follows:
        PE 1: {[(S1,G); Flood to: PW1to2, PW1to3], [PIM Neighbors:
        (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3),
        (Router 5,PW1to4)]}, PE 2: {[(S1,G); Flood to: AC2, PW2to3],
        [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router
        3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(S1,G);
        Flood to: PW2to3, AC4], [PIM Neighbors: (Router 1,PW1to3),
        (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router
        5,PW3to4)]}, PE 4: {[(S1,G); Flood to: PW2to4, PW3to4], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.
     - Then, assume Router 5 requests to join the multicast group
        (S4,G).  After the same procedures are applied,  all PEs update
        their states as follows: PE 1: {[(S1,G); Flood to: PW1to2,
        PW1to3], [(S4,G); Flood to: PW1to4], [PIM Neighbors: (Router
        1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router


                                                             [Page 22]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        5,PW1to4)]}, PE 2: {[(S1,G); Flood to: AC2, PW2to3], [(S4,G);
        Flood to: PW2to4], [PIM Neighbors: (Router 1,PW1to2), (Router
        2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]},
        PE 3: {[(S1,G); Flood to: PW2to3, AC4], [(S4,G); Flood to:
        PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router
        3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(S1,G);
        Flood to: PW2to4, PW3to4], [(S4,G); Flood to: AC5], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.

   At this point, all PEs have necessary states to not send multicast
   traffic to sites with no members.

   The PIM-SSM snooping mechanism for leaving a multicast group works
   as follows:
     - Assume Router 2 sends a (S1,G) prune message to leave the
        multicast group.  The prune message gets flooded in the VPLS
        instance.  All PEs update their states as follows: PE 1:
        {[(S1,G); Flood to: PW1to3], [(S4,G); Flood to: PW1to4], [PIM
        Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router
        4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S1,G); Flood to:
        PW2to3], [(S4,G); Flood to: PW2to4], [PIM Neighbors: (Router
        1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3),
        (Router 5,PW2to4)]}, PE 3: {[(S1,G); Flood to: AC4], [(S4,G);
        Flood to: PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router
        2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4:
        {[(S1,G); Flood to: PW3to4], [(S4,G); Flood to: AC5], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)]}.

   We assume that the PEs have the capability to store (S,G) states for
   PIM-SSM snooping and constrain multicast flooding scope accordingly.
   An implementation, can fall back to (*,G) states, if its hardware
   can not support it.  In such case, the efficiency of multicast
   forwarding will be less.

   Similar to PIM-SSM snooping, failures can be easily handled in PIM-
   SSM snooping, as it employs state-refresh technique.  PEs in the
   VPLS instance will remove entry for non-refreshing routers from
   their states.

   In PIM-SSM snooping, prune messages are flooded by PE routers.
   However, a PE can do prune suppression to optimize prune messages.
   Future versions might include such a mechanism.

4.3.4  Bidirectional-PIM (BIDIR-PIM)
   BIDIR-PIM is a variation of PIM-SM.  The main differences between
   PIM-SM and Bidirectional-PIM are as follows:



                                                             [Page 23]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - There are no source-based trees, and source-specific multicast
        is not supported (i.e., no (S,G) states) in BIDIR-PIM.
     - Multicast traffic can flow up the shared tree in BIDIR-PIM.
     - To avoid forwarding loops, one router on each link is elected
        as the Designated Forwarder (DF) for each RP in BIDIR-PIM.

   The main advantage of BIDIR-PIM is that it scales well for many-to-
   many applications.  However, the lack of source-based trees means
   that multicast traffic is forced to remain on the shared tree.

   In Figure 2, the RP for (*,G4) is behind Router 4, and the RP for
   (*,G1) is behind Router 1.  Router 2 and Router 4 want to join
   (*,G1), whereas Router 5 wants to join (*,G4).  On the VPLS
   instance, Router 4 is the DF for the RP of (*,G4), and Router 1 is
   the DF of the RP for (*,G1).

   The PIM-SSM snooping mechanism for neighbor discovery works the same
   way as t procedure defined in PIM-DM section, with the exception of
   PIM-DM only guidelines.
     - Based on PIM Hello exchanges PE routers populate PIM snooping
        Based on PIM Hello exchanges PE routers populate PIM snooping
        states as follows.  PE 1: {[(,); Upstream to:; Downstream to:],
        [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2),
        (Router 4,PW1to3), (Router 5,PW1to4)], [(,), DF:]}, PE 2:
        {[(,); Upstream to:; Downstream to:], [PIM Neighbors: (Router
        1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3),
        (Router 5,PW2to4)], [(,), DF:]}, PE 3: {[(,); Upstream to:;
        Downstream to:], [PIM Neighbors: (Router 1,PW1to3), (Router
        2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)], [(,),
        DF:]}, PE 4: {[(,); Upstream to:; Downstream to:], [PIM
        Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)], [(,), DF:]}.

   For BIDIR-PIM to work properly, all routers within the domain must
   know the address of the RP.  There are three methods to do that: 1.
   Static RP configuration, 2, Auto-RP, and 3. PIMv2 Bootstrap.
   Guideline 17 applies here as well.

   During RP discovery time, PIM routers elect DF per subnet for each
   RP.  The algorithm to elect the DF is as follows: all PIM neighbors
   in a subnet advertise their unicast route to elect the RP and the
   router with the best route is elected.

     Guideline 30: All PEs MUST snoop the DF elections messages and
     determine the DF for each [(*,G),RP)] pair.  The "Upstream" list
     MUST be updated with PW/AC that leads to the DF.  When the DF
     changes, the "Upstream" list MUST be updated accordingly.




                                                             [Page 24]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


     - Based on DF election messages, PE routers populate PIM snooping
        states as follows: PE 1: {[(*,G1); Upstream to: AC1; Downstream
        to:], [(*,G4); Upstream to: PW1to3; Downstream to:], [PIM
        Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router
        4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF:
        PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2; Downstream to:],
        [(*,G4); Upstream to: PW2to3; Downstream to:], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4),
        DF:PW2to3]}, PE 3: {[(*,G1); Upstream to: PW1to3; Downstream
        to:], [(*,G4); Upstream to: AC4; Downstream to:], [PIM
        Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)], [(*,G1), DF: PW1to3],
        [(*,G4), DF: AC4]}, PE 4: {[(*,G1); Upstream to: PW1to4;
        Downstream to:], [(*,G4); Upstream to: PW3to4; Downstream to:],
        [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4),
        (Router 4,PW3to4), (Router 5,AC5)], [(*,G1), DF: PW1to4],
        [(*,G4), DF: PW3to4]}.

   The BIDIR-PIM snooping for Join and Prune messages is similar to
   PIM-SM and the following guidelines (some of which are repetitions
   from PIM-SM section) apply.

     Guideline 31: A PE MUST add a PW/AC to its (*,G) "Downstream" list
     if it receives a (*,G) join message from the PW/AC.

     Guideline 32: PIM join and prune messages MUST be flooded in the
     VPLS instance.

     Guideline 33: If A PE does not receive a refresh join message from
     a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its
     "Downstream" list.

     Guideline 34: A PE MUST remove a PW/AC from its (*,G) "Downstream"
     list if it receives a (*,G) prune message from the PW/AC.  A
     prune-delay timer SHOULD be implemented to support prune override.

     Guideline 35: A PE MUST replicate multicast traffic for (*,G) to
     the members in its (*,G) "Upstream" and "Downstream" lists.

   The BIDIR-PIM snooping mechanism for joining a multicast group works
   as follows:
     - Assume Router 2 wants to join the multicast group (*,G1).  PE 2
        floods the join message in the VPLS instance. All PEs update
        their states as follows: PE 1: {[(*,G1); Upstream to: AC1;
        Downstream to: PW1to2], [(*,G4); Upstream to: PW1to3;


                                                             [Page 25]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        Downstream to:], [PIM Neighbors: (Router 1,AC1), (Router
        2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)],
        [(*,G1), DF: AC1], [(*,G4), DF: PW1to4]}, PE 2: {[(*,G1);
        Upstream to: PW1to2; Downstream to: AC2], [(*,G4); Upstream to:
        PW2to3; Downstream to:], [PIM Neighbors: (Router 1,PW1to2),
        (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router
        5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4), DF:PW2to3]}, PE 3:
        {[(*,G1); Upstream to: PW1to3; Downstream to: PW2to3], [(*,G4);
        Upstream to: AC4; Downstream to:], [PIM Neighbors: (Router
        1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router
        5,PW3to4)], [(*,G1), DF: PW1to3], [(*,G4), DF: AC4]}, PE 4:
        {[(*,G1); Upstream to: PW1to4; Downstream to: PW2to4], [(*,G4);
        Upstream to: PW3to4; Downstream to:], [PIM Neighbors: (Router
        1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4),
        (Router 5,AC5)], [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}.
     - Next, assume Router 4 wants to join the multicast group (*,G1).
        All PEs update their states as follows: PE 1: {[(*,G1);
        Upstream to: AC1; Downstream to: PW1to2, PW1to3], [(*,G4);
        Upstream to: PW1to3; Downstream to:], [PIM Neighbors: (Router
        1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router
        5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF: PW1to4]}, PE 2:
        {[(*,G1); Upstream to: PW1to2; Downstream to: AC2, PW2to3],
        [(*,G4); Upstream to: PW2to3; Downstream to:], [PIM Neighbors:
        (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router
        4,PW2to3), (Router 5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4),
        DF:PW2to3]}, PE 3: {[(*,G1); Upstream to: PW1to3; Downstream
        to: PW2to3, AC4], [(*,G4); Upstream to: AC4; Downstream to:],
        [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3),
        (Router 4,AC4), (Router 5,PW3to4)], [(*,G1), DF: PW1to3],
        [(*,G4), DF: AC4]}, PE 4: {[(*,G1); Upstream to: PW1to4;
        Downstream to: PW2to4, PW3to4], [(*,G4); Upstream to: PW3to4;
        Downstream to:], [PIM Neighbors: (Router 1,PW1to4), (Router
        2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)],
        [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}.
     - Then, assume Router 5 wants to join the multicast group (*,G4).
        Following the same procedures, all PEs update their states as
        follows: PE 1: {[(*,G1); Upstream to: AC1; Downstream to:
        PW1to2], [(*,G4); Upstream to: PW1to3; Downstream to:PW1to4],
        [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2),
        (Router 4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1],
        [(*,G4), DF: PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2;
        Downstream to: AC2], [(*,G4); Upstream to: PW2to3; Downstream
        to: PW2to4], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2),
        (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)], [(*,G1),
        DF:PW1to2], [(*,G4), DF:PW2to3]}, PE 3: {[(*,G1); Upstream to:



                                                             [Page 26]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


        PW1to3; Downstream to: PW2to3], [(*,G4); Upstream to: AC4;
        Downstream to:PW3to4], [PIM Neighbors: (Router 1,PW1to3),
        (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)],
        [(*,G1), DF: PW1to3], [(*,G4), DF: AC4]}, PE 4: {[(*,G1);
        Upstream to: PW1to4; Downstream to: PW2to4], [(*,G4); Upstream
        to: PW3to4; Downstream to: AC5], [PIM Neighbors: (Router
        1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4),
        (Router 5,AC5)], [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}.

   At this point, all PEs have necessary states to not send multicast
   traffic to sites with no members.

   One example of the BIDIR-PIM snooping mechanism for leaving a
   multicast group works as follows:
     - Assume Router 2 wants to leave the multicast group (*,G1) and
        sends a (*,G1) prune message.  The prune message gets flooded
        in the VPLS instance.  All PEs update their states as follows:
        PE 1: {[(*,G1); Upstream to: AC1; Downstream to: PW1to3],
        [(*,G4); Upstream to: PW1to3; Downstream to:PW1to4], [PIM
        Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router
        4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF:
        PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2; Downstream to:
        PW2to3], [(*,G4); Upstream to: PW2to3; Downstream to: PW2to4],
        [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router
        3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)], [(*,G1),
        DF:PW1to2], [(*,G4), DF:PW2to3]}, PE 3: {[(*,G1); Upstream to:
        PW1to3; Downstream to: AC4], [(*,G4); Upstream to: AC4;
        Downstream to:PW3to4], [PIM Neighbors: (Router 1,PW1to3),
        (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)],
        [(*,G1), DF: PW1to3], [(*,G4), DF: AC4]}, PE 4: {[(*,G1);
        Upstream to: PW1to4; Downstream to: PW3to4], [(*,G4); Upstream
        to: PW3to4; Downstream to: AC5], [PIM Neighbors: (Router
        1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4),
        (Router 5,AC5)], [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}.

   Once again, failures can be easily handled in BIDIR-PIM snooping, as
   it employs state-refresh technique.  PEs in the VPLS instance will
   remove entry for non-refreshing routers from their states.

   Optionally, prune suppression can be done on a PE to optimize prune
   message handling.  Future versions might include such a mechanism.

5 Security Considerations
   Security considerations provided in VPLS solution documents (i.e.,
   [VPLS-LDP] and [VPLS-BGP) apply to this document as well.

6 References



                                                             [Page 27]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


6.1 Normative References

6.2 Informative References
   [VPLS-LDP]       Lasserre, M, et al. "Virtual Private LAN Services
                    over MPLS", work in progress
   [VPLSD-BGP]      Kompella, K, et al. "Virtual Private LAN Service",
                    work in progress
   [L2VPN-FR]       Andersson, L, et al. "L2VPN Framework", work in
                    progress
   [PMP-RSVP-TE]    Aggarwal, R, et al. "Extensions to RSVP-TE for
                    Point to Multipoint TE LSPs", work in progress
   [RFC1112]        Deering, S., "Host Extensions for IP Multicasting",
                    RFC 1112, August 1989.
   [RFC2236]        Fenner, W., "Internet Group Management Protocol,
                    Version 2", RFC 2236, November 1997.
   [RFC3376]        Cain, B., et al. "Internet Group Management
                    Protocol, Version 3", RFC 3376, October 2002.
   [PIM-DM]         Deering, S., et al. "Protocol Independent Multicast
                    Version 2 û Dense Mode Specification", draft-ietf-
                    pim-v2-dm-03.txt, June 1999.
   [RFC2362]        Estrin, D, et al. "Protocol Independent Multicast-
                    Sparse Mode (PIM-SM): Protocol Specification", RFC
                    2362, June 1998.
   [PIM-SSM]        Holbrook, H., et al. "Source-Specific Multicast for
                    IP", work in progress
   [BIDIR-PIM]      Handley, M., et al. "Bi-directional Protocol
                    Independent Multicast (BIDIR-PIM)", work in
                    progress

7 Authors' Addresses

   Yetik Serbest
   SBC Labs
   9505 Arboretum Blvd.
   Austin, TX 78759
   Yetik_serbest@labs.sbc.com

   Marc Lasserre
   Riverstone Networks
   Marc@riverstonenet.com

   Rob Nath
   Riverstone Networks
   5200 Great America Parkway
   Santa Clara, CA 95054
   Rnath@riverstonenet.com

   Vach Kompella
   Alcatel North America
   701 East Middlefield Rd.
   Mountain View, CA 94043



                                                             [Page 28]


Internet Draft draft-serbest-l2vpn-vpls-mcast-00.txt     October, 2004


   Ray Qiu
   Alcatel North America
   701 East Middlefield Rd.
   Mountain View, CA 94043
   Ray_Qiu@alcatel.com

   Sunil Khandekar
   Alcatel North America
   701 East Middlefield Rd.
   Mountain View, CA 94043
   Sunil_khandekar@alcatel.com

8 Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

9 Full copyright statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





                                                             [Page 29]