[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 RFC 2337

Network Working Group                                     Dino Farinacci
Internet Draft                                             Cisco Systems
                                                             David Meyer
                                                    University of Oregon
                                                           Yakov Rekhter
                                                           Cisco Systems

Expiration Date: February 1997                               August 1997

  Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM


1. Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

2. Abstract

   This document describes how intra-LIS IP multicast can be efficiently
   supported among routers over ATM without using the Multicast Address
   Resolution Server (MARS). The method described here is specific to
   Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism
   inherent in PIM-SM to notify routers when they should create group
   specific point-to-multipoint VCs.

Dino Farinacci, David Meyer, Yakov Rekhter                      [Page 1]

Internet Draft  draft-ietf-ion-intralis-multicast-01.txt     August 1997

3. Overall model

   This document focuses on forwarding of multicast traffic among PIM-SM
   routers connected to an ATM network. Routers on an ATM network are
   partitioned into Logical IP Subnets, or LISs.  This document deals
   with handling multicast within a single LIS. Handling inter-LIS
   multicast traffic, including handling shortcuts, is outside the scope
   of this document.  In addition, this document does not address
   forwarding of multicast traffic to or from hosts connected to an ATM

4. Router behavior

   This document requires that each router within a LIS knows IP and ATM
   addresses of all other routers within the LIS. The mapping between IP
   and ATM addresses may be provided by an ARP server [RFC1577], or by
   any other means (e.g., static configuration).

   Each PIM router within a LIS is required to maintain a single
   (shared) point-to-multipoint distribution VC rooted at the router
   with all other PIM routers in the LIS as the leaf nodes. The VC is
   expected to be used for forwarding of multicast traffic (both data
   and control) among routers within the LIS. For example, this VC would
   be used for distributing PIM [PIM-SM] control messages (Join/Prune

   In addition, if a PIM router receives a IGMP report from an non-PIM
   neighbor, then the router may add the reporter to the existing shared
   distribution VC or to the group specific distribution VC (if it
   exists). The PIM router may also create a specific VC for this IGMP

4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs

   Routers may also maintain group specific, dedicated point-to-
   multipoint VCs. In particular, an upstream router for a group may
   choose to become the root of a group specific point-to-multipoint VC
   whose leaves are the downstream routers that have directly connected
   or downstream receivers for the group. While the criteria for
   establishing a group specific point-to-multipoint VC are local to a
   router, issues such as the volume of traffic associated with the
   group and the fanout factor within the LIS should be considered.
   Finally, note that a router must minimally support a single shared
   point-to-multipoint VC for distribution of control messages and data
   (to all group addresses).

Dino Farinacci, David Meyer, Yakov Rekhter                      [Page 2]

Internet Draft  draft-ietf-ion-intralis-multicast-01.txt     August 1997

   A router can choose to establish a dedicated point-to-multipoint VC
   (or add another leaf to an already established dedicated point-to-
   multipoint VC) when it receives a PIM Join or IGMP report messages
   from another device in the same LIS. When a router that is the root
   of a point-to-multipoint VC receives PIM Prune message or IGMP leave,
   it removes the originator of the message from its dedicated point-
   to-multipoint VC.

4.2. Switching to a Source-Rooted Tree

   If at least one of the routers within a LIS decides to switch to a
   source-rooted tree (by sending (S,G) PIM Joins), then all other
   routers within the LIS that have downstream members for G should
   switch to that source-rooted tree as well. Since a router that
   switches to a source-rooted tree sends PIM Join messages for (S,G)
   over its shared point-to-multipoint VC, the other routers within the
   LIS are able to detect this. Once a router that has downstream
   members for G detects this, the router should send (S,G) PIM Join
   message as well (otherwise the router may receive duplicate traffic
   from S).

   Note that it is possible for a non-PIM router in the LIS to fail to
   receive data if the injection point moves to router to which there is
   not an existing VC.

4.2.1. Adding New Members to a Source-Rooted Tree

   As mentioned above, this document requires that once one router in a
   LIS decides to switch to the source tree for some (S,G), all routers
   in the LIS that have downstream members must also switch to the (S,G)
   source tree. Now, when a new router wants to receive traffic from G,
   it starts sending (*,G)-Joins on it's shared point-to-multipoint VC
   toward the RP for G. The root of the (S,G)-source-rooted tree will
   know to add the new router to the point-to-multipoint VC servicing
   the (S,G)-source-rooted tree by observing the (*,G)-joins on it's
   shared point-to-multipoint VC. However, the new router must also
   switch to the (S,G)-source-rooted tree. In order to accomplish this,
   the newly added router must:

      (i).    Notice that it has been added to a new
              point-to-multipoint VC

      (ii).   Notice (S,G) traffic coming down this new
              point-to-multipoint VC

Dino Farinacci, David Meyer, Yakov Rekhter                      [Page 3]

Internet Draft  draft-ietf-ion-intralis-multicast-01.txt     August 1997

      (iii).  Send (S,G) joins toward S, causing it to switch to the
              source-rooted tree. The router learns that the VC is
              used to distribute (S,G) traffic in the previous

4.3. Handing the "Packet Reflection" Problem

   When a router receives a multicast packet from another router in its
   own LIS, the router should not send the packet on any of the routers
   distribution point-to-multipoint VCs associate with the LIS. This
   eliminates the problem of "packet reflection". Sending the packet on
   the routers' distribution VCs associated with other LISs is
   controlled by the multicast routing procedures.

5. Brief Comparison with MARS

   The intra-LIS multicast scheme described in this document is intended
   to be a less complex solution to an important subset of the
   functionality provided by the Multicast Address Resolution Server, or
   MARS [MARS]. In particular, it is designed to provide intra-LIS
   multicast between routers using PIM-SM, and does not consider the
   case of host-rooted point-to-multicast multicast distribution VCs.

   Although MARS supports both of the current schemes for mapping the IP
   multicast service model to ATM (multicast server and meshes of
   point-to-multipoint VCs), it does so at at cost and complexity higher
   than of the scheme described in this document. In addition, MARS
   requires new encapsulations, whereas this proposal works with either
   LLC/SNAP or with NLPID encapsulation. Another important difference is
   that MARS allows point-to-multipoint VCs rooted either at a source or
   at a multicast server (MCS). The approach taken here is to constrain
   complexity by focusing on PIM-SM (taking advantage of information
   available in explicit joins), and by allowing point-to-multipoint VCs
   to be rooted only at the routers (which is roughly analogous to the
   complexity and functionality of rooting point-to-multipoint VCs at
   the sources).

   In summary, the method described in this document is designed for the
   router-to-router case, and takes advantage of the explicit-join
   mechanism inherent in PIM-SM to provide a simple mechanism for
   intra-LIS multicast between routers. MARS, on the other hand, accepts
   different tradeoffs in complexity-functionality design space. In
   particular, while the MARS paradigm provides a general neighbor
   discovery mechanism, allows host to participate, and is protocol

Dino Farinacci, David Meyer, Yakov Rekhter                      [Page 4]

Internet Draft  draft-ietf-ion-intralis-multicast-01.txt     August 1997

   independent, it does so at considerable cost.

6. Security Considerations

   Security issues are not discussed in this document.

7. References

   [MARS]    G. Armitage, "Support for Multicast over UNI
             3.0/3.1 based ATM Networks.", RFC2022, November

   [PIM-SM]  Estrin, D, et. al., "Protocol Independent Multicast
             Sparse Mode (PIM-SM): Protocol Specification",
             draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.

8. Acknowledgments

   Petri Helenius provided several insightful comments on earlier
   versions of this document.

9. Author Information

Dino Farinacci, David Meyer, Yakov Rekhter                      [Page 5]

Internet Draft  draft-ietf-ion-intralis-multicast-01.txt     August 1997

   Dino Farinacci
   Cisco Systems
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (408) 526-4696
   e-mail: dino@cisco.com

   David Meyer
   University of Oregon
   1225 Kincaid St.
   Eugene, OR 97403
   Phone: (541) 346-1747
   e-mail: meyer@antc.uoregon.edu

   Yakov Rekhter
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (914) 528-0090
   email: yakov@cisco.com

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