[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: January 2006
                                                               Y. Kamite
                                                      NTT Communications

                                                             Luyuan Fang
                                                                    AT&T

                                                               July 2005


     Propagation of VPLS IP Multicast Group Membership Information


              draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

Abstract

   The PEs participating in VPLS need to learn the IP multicast group
   membership information from remote VPLS sites to enable them to send
   an IP multicast packet to only those other PEs in the VPLS that have
   receivers interested in that particular IP multicast packet's
   multicast source and group. This document describes procedures for
   propagating multicast control information, learned from local Virtual



Raggarwa, Kamite & Fang                                         [Page 1]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


   Private LAN Service (VPLS) sites, to remote VPLS sites. IGMP or PIM
   snooping is required only on the customer facing interfaces. The
   procedures do not require IGMP or PIM snooping on the Service
   Provider backbone links. Instead they use reliable protocol messages
   to exchange multicast control information between the PEs.



Table of Contents

 1          Specification of requirements  .........................   2
 2          Contributors  ..........................................   3
 3          Introduction  ..........................................   3
 4          Propagating Multicast Control Information  .............   4
 4.1        IGMP/PIM Snooping  .....................................   4
 4.2        C-Multicast Control Information Propagation in the SP  .   5
 4.2.1      Using PIM   ............................................   5
 4.2.2      Using BGP  .............................................   6
 5          Security Considerations  ...............................   6
 6          Acknowledgments  .......................................   7
 7          References  ............................................   7
 7.1        Normative References  ..................................   7
 7.2        Informative References  ................................   7
 8          Author Information  ....................................   7
 9          Intellectual Property Statement  .......................   8
10          Full Copyright Statement  ..............................   9




1. Specification of requirements

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













Raggarwa, Kamite & Fang                                         [Page 2]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


2. Contributors

   Rahul Aggarwal
   Yakov Rekhter
   Juniper Networks
   Yuji Kamite
   NTT Communications
   Luyuan Fang
   AT&T
   Chaitanya Kodeboniya
   Juniper Networks


3. Introduction

   [VPLS-BGP] and [VPLS-LDP] describe a solution for VPLS multicast that
   relies on ingress replication. [VPLS-MCAST] describes procedures for
   VPLS multicast that enable the use of multicast trees in the service
   provider (SP) network.

   Irrespective of whether ingress replication or multicast trees are
   used for sending IP multicast traffic in a VPLS, the PEs participat-
   ing in VPLS need to learn the IP multicast group membership informa-
   tion from remote VPLS sites to enable them to send an IP multicast
   packet to only those other PEs in the VPLS that have receivers inter-
   ested in that particular IP multicast packet's multicast source and
   group.

   By appropriate IGMP or PIM snooping it is possible for the ingress PE
   to send an IP multicast packet in a VPLS only to the egress PEs that
   have the receivers for that traffic, rather than to all the PEs in
   the VPLS instance.  While PIM/IGMP snooping allows to avoid the situ-
   ation where an IP multicast packet is sent to PEs with no receivers,
   there is a cost for this optimization.  Namely, 1) A PE has to main-
   tain (S,G) state for all the (S,G) of all the VPLSs present on the
   PE. 2) PIM snooping has to be done not only on the CE-PE interfaces,
   but on Pseudo-Wire (PW) interfaces as well, which in turn introduces
   a non-negligeable overhead on the PE. It is desirable to reduce this
   overhead when IGMP/PIM snooping is used.

   This document describes procedures for propagating IP multicast group
   membership information, learned from local Virtual Private LAN Ser-
   vice (VPLS) sites, to remote VPLS sites. IGMP or PIM snooping is
   required only on the customer facing interfaces. The procedures do
   not require IGMP or PIM snooping on the Service Provider backbone
   links. Instead they use reliable protocol messages to exchange multi-
   cast control information between the PEs.




Raggarwa, Kamite & Fang                                         [Page 3]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


   This document uses the prefix 'C' to refer to the customer control or
   data packets and 'P' to refer to the provider control or data pack-
   ets.


4. Propagating Multicast Control Information

   PEs participating in VPLS need to learn the <C-S, C-G> information
   for two reasons:
      1. With ingress replication [VPLS-BGP, VPLS-LDP], this allows a PE
   to send the IP multicast packet for a <C-S, C-G> only to other PEs in
   the VPLS instance, that have receivers interested in that particular
   <C-S, C-G>. This eliminates flooding.

      2. It allows the construction of Aggregate Data Trees [VPLS-
   MCAST].

   There are two components for a PE to learn the <C-S, C-G> information
   in a VPLS:

      1. Learning the <C-S, C-G> information from the locally homed Vir-
   tual Switch Instances (VSIs).
      2. Learning the <C-S, C-G> information from the remote VSIs.


4.1. IGMP/PIM Snooping

   In order to learn the <C-S, C-G> information from the locally homed
   VSIs a PE needs to implement IGMP/PIM snooping on the PE-CE inter-
   faces. This is because there is no PIM adjacency between the locally
   homed CEs and the PE.  IGMP/PIM snooping has to be used to build the
   database of C-Joins that are being sent by the customer for a partic-
   ular VSI. This also requires a PE to create a IGMP/PIM instance per
   VSI for which IGMP/PIM snooping is used. This instance is analogous
   to the multicast VRF PIM instance that is created for Multicast Vir-
   tual Private Networks (MVPNs) [MVPN].

   It is conceivable that IGMP/PIM snooping can be used to learn <C-S,
   C-G> information from remote VSIs by snooping VPLS traffic received
   over the SP backbone. However IGMP/PIM snooping is computationally
   expensive.  Furthermore the periodic nature of PIM Join/Prune mes-
   sages implies that snooping PIM messages places even a greater pro-
   cessing burden on a PE.  Hence to learn <C-S, C-G> information from
   remote VSIs, this document proposes the use of a reliable protocol
   machinery to transport <C-S, C-G> information over the SP infrastruc-
   ture. This is described in the next sub-section.





Raggarwa, Kamite & Fang                                         [Page 4]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


4.2. C-Multicast Control Information Propagation in the SP

   A C-Join/Prune message for <C-S, C-G> coming from a customer, that is
   snooped by a PE, has to be propagated to the remote PE that can reach
   C-S.  One way to do this is to forward the C-Join/Prune as a multi-
   cast data packet and let the egress PEs perform IGMP/PIM snooping
   over the pseudo-wire. However PIM is a soft state protocol and peri-
   odically re-transmits C-Join/Prune messages. This places a big burden
   on a PE while snooping PIM messages. It is not possible to eliminate
   this overhead for snooping messages received over the customer facing
   interfaces. However it is possible to alleviate this overhead over SP
   facing interfaces. This is done by converting snooped PIM C-
   Join/Prune messages to reliable protocol messages over the SP net-
   work.  These reliable protocol messages are then sent to the remote
   PEs.

   Each PE maintains the database of IGMP/PIM <C-S, C-G> entries that
   are learnt, usign reliable protocol messages, from remote PEs for
   each VSI. This is in addition to the database of IGMP/PIM <C-S, C-G>
   entries that are learnt from the local CEs, by snooping as described
   in the previous sub-section.

   Compared to MVPNs there is an additional challenge while propagating
   snooped PIM C-Join/Prune messages over the SP network for VPLS. If
   the ingress PE wishes to propagate the C-Join/Prune only to the
   upstream PE which has reachability to C-S, this upstream PE is not
   known. This is because the local PE doesn't have a route to reach C-
   S. This is unlike MVPNs where the route to reach C-S is known from
   the unicast VPN routing table. This implies that the C-Join/Prune
   message has to be sent to all the PEs in the VPLS. This document pro-
   poses two possible solutions for achieving this and one of these will
   be eventually picked after discussion in the WG.


4.2.1. Using PIM

   The PIM Neighbor discovery and maintenance is based on the VPLS mem-
   bership information learnt as part of VPLS auto-discovery [BGP-AUTO].
   VPLS auto-discovery allows a particular PE to learn which of the
   other PEs belong to a particular VPLS instance. Each of these PEs can
   be treated as a neighbor for PIM procedures while sending PIM  C-
   Join/Prune messages to other PEs. The neighbor is considered up as
   long as the VPLS auto-discovery mechanism does not withdraw the
   neighbor membership in the VPLS instance.

   The C-Join/Prune messages is sent to all the PEs in the VPLS using
   unicast PIM messages. The use of unicast PIM implies that there is no
   PIM Join suppression for P-PIM messages. PIM refresh reduction



Raggarwa, Kamite & Fang                                         [Page 5]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


   mechanisms, that are currently being worked upon in the PIM WG, MUST
   be used. These mechanisms aim at introducing reliability into PIM
   protocol messages, thereby reducing the overhead from the current
   periodic nature of PIM messages. To send the C-Join/Prune message to
   a particular remote PE, the message is encapsulated in the PW used to
   reach the PE, for the VPLS that the C-Join/Prune message belongs to.


4.2.2. Using BGP

   The use of PIM for propagation of VPLS C-Join/Prune information may
   have scalability limitations. This is because even after building PIM
   refresh reduction mechanisms PIM will not have optimized transport
   when there is one sender and multiple receivers. BGP provides such
   transport as it has route-reflector machinery. Hence a reasonable
   option to propagate the C-Join/Prune information is to use BGP.

   We describe the information elements needed if BGP were to be used to
   propagate the VPLS C-Join/Prune information in the SP network. The
   encoding details will be described in the future.

   The following information is required to be advertised by BGP for a
   VPLS <C-Source, C-Group> for VPLS C-Join propagation and withdrawn by
   BGP for VPLS C-Prune propagation.
      1. The RD configured for the VPLS instance. This is required to
   uniquely identify the <C-Source, C-Group> as the addresses could
   overlap between different VPLS instances.
      2. The C-Source address. This can be a prefix.
      3. The C-Group address. This can be a prefix.

   When a PE distributes this information via BGP, it must include the
   Route Target (RT) Extended Communities attribute. This RT must be an
   "Import RT" of each VSI in the VPLS. The BGP distribution procedures
   used by [VPLS-BGP] or [BGP-AUTO] will then ensure that the advertised
   information gets associated with the right VSIs.


5. Security Considerations

   Security considerations discussed in [VPLS-BGP] and [VPLS-LDP] apply
   to this document.










Raggarwa, Kamite & Fang                                         [Page 6]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


6. Acknowledgments

   Many thanks to Thomas Morin for his support of this work.


7. References

7.1. Normative References

   [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev-
   els.", Bradner, March 1997

   [RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in
   BGP-4", RFC3107.

   [VPLS-BGP] K. Kompella, Y. Rekther, "Virtual Private LAN Service",
   draft-ietf-l2vpn-vpls-bgp-02.txt

   [VPLS-LDP] M. Lasserre, V. Kompella, "Virtual Private LAN Services
   over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt

   [BGP-AUTO] H. Ould-Brahim et al., "Using BGP as an Auto-Discovery
   Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-
   auto-04.txt


7.2. Informative References

   [VPLS-MCAST] R. Aggarwal, Y. Kamite, L. Fang, "VPLS Multicast",
   draft-raggarwa-l2vpn-vpls-mcast-01.txt

   [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",
   draft-ietf-l3vpn-2547bis-mcast-00.txt


8. Author Information

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: yakov@juniper.net



Raggarwa, Kamite & Fang                                         [Page 7]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


   Yuji Kamite
   NTT Communications Corporation
   Tokyo Opera City Tower
   3-20-2 Nishi Shinjuku, Shinjuku-ku,
   Tokyo 163-1421,
   Japan
   Email: y.kamite@ntt.com

   Luyuan Fang
   AT&T
   200 Laurel Avenue, Room C2-3B35
   Middletown, NJ 07748
   Phone: 732-420-1921
   Email: luyuanfang@att.com

   Chaitanya Kodeboniya
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: ck@juniper.net



9. 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 assur-
   ances 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.





Raggarwa, Kamite & Fang                                         [Page 8]


Internet Draft draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt     July 2005


10. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  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.






































Raggarwa, Kamite & Fang                                         [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/