Network Working Group Dino Farinacci Internet Draft Cisco Systems David Meyer University of Oregon Yakov Rekhter Cisco Systems Expiration Date: August 1997 February 1997 Intra-LIS IP multicast among routers over ATM draft-farinacci-intralis-multicast-00.txt 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 could be supported among routers over ATM without using the Multicast Address Resolution Server (MARS), by using just the existing IP multicast protocols (IGMP, PIM). Dino Farinacci, David Meyer, Yakov Rekhter [Page 1] Internet Draft draft-farinacci-intralis-multicast-00.txt February 1997 3. Overall model This document focuses on forwarding of multicast traffic among 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 network. 4. Router behavior This document assumes 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 router within a LIS is expected to maintain a single (shared) router distribution point-to-multipoint VC rooted at the router with all other routers in the LIS as the leaf nodes of that VC. 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 messages). In addition a router may maintain a single (dedicated) point-to- multipoint VC (rooted at the router) for each group address. The leafs of that VC would be the routers within the LIS that have downstream receivers for that group. It is expected that at a minimum a router supports the first alternative (single (shared) routers distribution point-to-multipoint VC for all group addresses). Criteria for establishing a dedicating point-to-multipoint VC are local to a router, but should include such factors, as the volume of traffic associated with the group, and the fanout factor within the LIS. A router establishes a dedicated point-to-multipoint VC, or adds another leaf to an already established dedicated point-to-multipoint VC when the router receives PIM Join messages from other router(s) in the same LIS (the router sending these messages uses its shared point-to-multipoint VC for sending these messages). When the router receives PIM Prune message, and the router that sends the message is Dino Farinacci, David Meyer, Yakov Rekhter [Page 2] Internet Draft draft-farinacci-intralis-multicast-00.txt February 1997 on a dedicated point-to-multipoint VC, the router removes the originator of the message from its dedicated point-to-multipoint VC. If at least one of the routers within a LIS decides to switch to a source-rooted tree (by sending (S, G) PIM Join), then all other routers within the LIS that are members of G need to switch to that source-rooted tree as well. Since a router that switches to a source-rooted tree would send its PIM Join message for (S, G) over its shared point-to-multipoint VC, all other routers within the LIS would be able to detect this. Once a router that is a member of G detects this, the router should send PIM Join message for (S, G) as well, or otherwise, the router may receive duplicate traffic from S. Likewise, if at least one of the routers within the LIS prunes itself off the source-rooted VC, all other routers on that VC should be pruned off as well. To support Dense Mode PIM [PIM-DM] this document requires a router that has downstream receivers to generate PIM Join in response to receiving multicast traffic in the dense mode. This document requires a router to maintain routers distribution VCs on a per LIS basis. 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 routers distribution VCs associated with other LISs is controlled by the multicast routing procedures. 5. 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]. While the 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 considerable cost and complexity. In addition, MARS requires new encapsulations, where as 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 allowing point-to- multipoint VCs to be rooted only at the routers (which is roughly Dino Farinacci, David Meyer, Yakov Rekhter [Page 3] Internet Draft draft-farinacci-intralis-multicast-00.txt February 1997 analogous to the complexity and functionality of rooting point-to- multipoint VCs at the sources). 6. Security Considerations Security issues are not discussed in this document. 7. References [IGMP] Fenner, W., "Internet Group Management Protocol, Version 2", Internet Draft, September 1995 [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", RFC2022, November 1996. [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. [PIM-DM] Estrin, D, et. al., "Protocol Independent Multicast Dense Mode (PIM-DM): Protocol Specification", draft-ietf-idmr-PIM-DM-spec-04.ps, September, 1996. 8. Acknowledgments To be supplied. 9. Author Information Dino Farinacci, David Meyer, Yakov Rekhter [Page 4] Internet Draft draft-farinacci-intralis-multicast-00.txt February 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