Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET Obsoletes: 2189,2201,1584,1585 (if November 24, 2004 approved) Expires: May 25, 2005 Overview of the Internet Multicast Routing Architecture draft-savola-mboned-routingarch-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with 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. This Internet-Draft will expire on May 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The lack of up-to-date documentation on IP multicast routing protocols and procedures has caused a great deal of confusion. To clarify the situation, this memo describes the routing protocols and techniques currently (as of this writing) in use. Savola Expires May 23, 2005 [Page 1] Internet-Draft Multicast Routing Overview November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Distributing Topology Information . . . . . . . . . . . . 3 2.1.1 MBGP . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 4 2.1.3 Issue: Overlapping Unicast/multicast Topology . . . . 4 2.2 Learning Active Sources . . . . . . . . . . . . . . . . . 5 2.2.1 SSM . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 6 2.3 Setting up Multicast Forwarding State . . . . . . . . . . 6 2.3.1 PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.3 Bidirectional PIM . . . . . . . . . . . . . . . . . . 6 2.3.4 DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.5 Obsolete Protocols . . . . . . . . . . . . . . . . . . 7 2.4 Configuring Multicast Network Elements . . . . . . . . . . 7 2.4.1 Manual Configuration . . . . . . . . . . . . . . . . . 7 2.4.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 7 2.4.3 BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 7 2.5 Interactions with Hosts . . . . . . . . . . . . . . . . . 8 2.5.1 Hosts Sending Multicast . . . . . . . . . . . . . . . 8 2.5.2 Hosts Receiving Multicast . . . . . . . . . . . . . . 8 2.6 Restricting Multicast Flooding in the Link Layer . . . . . 8 2.6.1 Router-to-Router Flooding Reduction . . . . . . . . . 9 2.6.2 Host/Router Flooding Reduction . . . . . . . . . . . . 9 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Savola Expires May 23, 2005 [Page 2] Internet-Draft Multicast Routing Overview November 2004 1. Introduction Good, up-to-date documentation of IP multicast is close to non-existent. This issue severely felt with multicast routing protocols and techniques. The consequence is that those who wish to learn of IP multicast and how the routing works in the real world do not know where to begin. The aim of this document is to provide a brief overview of multicast routing protocols and techniques. This memo deals with: o distributing multicast topology information (Section 2.1), o learning active sources (Section 2.2), o setting up multicast forwarding state (Section 2.3), o configuring the multicast network elements (Section 2.4), o interacting with hosts (Section 2.5), and o restricting the multicast flooding in the link layer (Section 2.6). This memo obsoletes and re-classifies to Historic both Core-based Trees (CBT) and Multicast OSPF (MOSPF) RFCs: [RFC2189], [RFC2201], [RFC1584], and [RFC1585]. 2. Multicast Routing 2.1 Distributing Topology Information When unicast and multicast topologies are the same ("congruent"), it has been considered sufficient to just distribute one set of reachability information. However, when PIM -- which by default built multicast topology based on the unicast topology -- gained popularity, it became apparent that it would be necessary to be able to distribute also non-congruent multicast reachability information in the regular unicast protocols. The topology information is needed to perform efficient distribution of multicast transmissions and to prevent transmission loops by applying it to Reverse Path Forwarding (RPF) check. This subsection introduces these protocols. Savola Expires May 23, 2005 [Page 3] Internet-Draft Multicast Routing Overview November 2004 2.1.1 MBGP Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as "MBGP") specifies a mechanism how BGP can be used to distribute different reachability information for unicast and multicast traffic. MBGP has been widely deployed for years, and is also neded for routing for example IPv6. These extensions are in widespread use wherever BGP is used to distribute unicast topology information. Those having multicast infrastructure and using BGP should use MBGP to also distribute multicast reachability information explicitly. 2.1.2 OSPF/IS-IS Multi-topology Extensions Similar to BGP, some IGPs also provide the capability for signalling a differing multicast topology, for example IS-IS multi-topology extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists for OSPF [I-D.ietf-ospf-mt]. Regardless of features for having different topologies for unicast and multicast, commonly deployed networks have managed well without them by deploying multicast same unicast routers. 2.1.3 Issue: Overlapping Unicast/multicast Topology XXX: does this belong into an appendix? An interesting case occurs when some do not distribute multicast topology explicitly while some do. In particular, this happens when some multicast sites in the Internet are using plain BGP while some use MBGP. Different implementations deal with this using different means. Sometimes, multicast RPF mechanisms first look up the multicast routing table ("topology database") with longest prefix match algorithm, and if they find any entry (even a default route), that is used; if no match is found, unicast routing table is looked instead. An alternative approach is to use longest prefix match on the union of multicast and unicast routing tables; an implementation technique here is to copy the whole unicast routing table over to the multicast routing table. The important point to remember here, though, is to not override the multicast-only routes; if the longest prefix match would find both a (copied) unicast route and a multicast-only route, the latter should be treated as preferable. One implemented approach is to just look up the information in the Savola Expires May 23, 2005 [Page 4] Internet-Draft Multicast Routing Overview November 2004 unicast routing table, and provide the user capabilities to change that as appropriate, using for example copying functions discussed above. 2.2 Learning Active Sources Typically, multicast routing protocols must either assume that they know the IP addresses of the active sources for a group a priori (SSM), or they must be discovered by the network protocols automatically (ASM). Learning active sources is a relatively straightforward process with a single PIM-SM domain and with a single RP, but this is a completely unscalable model for many reasons for the whole Internet. Therefore it is required to be able to split up the multicast routing infrastructures to smaller domains, and there must be a way to share information about active sources using some mechanism, if ASM model is to be supported. This section discusses the options. 2.2.1 SSM Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also referred to as "Single-source Multicast") does not count on learning active sources in the network; it is assumed that the recipients know these using out of band mechanisms, and when subscribing to a (S,G) channel, indicate toward which source(s) the multicast routing protocol should send the Join messages. 2.2.2 MSDP Multicast Source Discovery Mechanism [RFC3618] was invented as a stop-gap mechanism, when it became apparent that multiple PIM-SM domains (and RPs) were needed in the network, and information about the active sources needed to be propagated between the PIM-SM domains using some other protocol. MSDP is also used to share the state about sources between multiple RPs in a single domain for, e.g., redundancy purposes [RFC3446]. There is also work in progress to achieve the same using PIM extensions [I-D.ietf-pim-anycast-rp]. There is no intent to define MSDP for IPv6, but instead use only SSM and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. Savola Expires May 23, 2005 [Page 5] Internet-Draft Multicast Routing Overview November 2004 2.2.3 Embedded-RP Embedded-RP [RFC3956] is an IPv6-only technique to map the address of the RP to the multicast group address. Using this method, it is possible to avoid the use of MSDP while still allowing multiple multicast domains (in the traditional sense). The model works by defining a single RP for a particular group for all of the Internet, so there is no need to share state about that with any other RPs (except, possibly, for redundandy purposes with Anycast-RP using PIM). 2.3 Setting up Multicast Forwarding State The most important part of multicast routing is setting up the multicast forwarding state. This section describes the protocols commonly used for this purpose. 2.3.1 PIM-SM By far, the most common multicast routing protocol is PIM-SM [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both ASM and SSM functionality; PIM-SSM is a subset of PIM-SM. Almost all current routing platforms support PIM-SM. 2.3.2 PIM-DM While PIM-SM is designed to avoid unnecessary flooding of multicast data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode, flooding the multicast transmissions throughout the network unless the leaf parts of the network periodically indicate that they are not interested in that particular traffic. PIM-DM may fit in small and/or simple networks, where setting up an RP would be unnecessary, and possibly in cases where a large number of users is expected to be able to wish to receive the transmission. Therefore PIM-DM is typically only used in special deployments, never in, e.g., ISPs' networks. 2.3.3 Bidirectional PIM Bidirectional-PIM [I-D.ietf-pim-bidir] aims to offer streamlined PIM-SM operation, without data-driven events and data-encapsulation, inside a PIM-SM domain. As of this writing, it cannot be applied in Inter-domain multicast or for Embedded-RP. The usage of bidir-PIM may be on the increase especially inside sites leveraging multicast. Savola Expires May 23, 2005 [Page 6] Internet-Draft Multicast Routing Overview November 2004 2.3.4 DVMRP DVMRP [RFC1075][I-D.ietf-idmr-dvmrp-v3][I-D.ietf-idmr-dvmrp-v3-as] is the first protocol designed for multicasting, and to get around initial deployment hurdles, it also included the tunneling capabilities which were part of its multicast topology functions. Nowadays, DVMRP is used only very rarely in operator networks, having been replaced with PIM-SM. The most typical deployment of DVMRP is at a leaf network, to run from a legacy firewall only supporting DVMRP to the internal network. However, GRE tunneling [RFC2784] has overtaken DVMRP in this functionality, and there is actually relatively little use for DVMRP except in legacy deployments. 2.3.5 Obsolete Protocols Two protocols which are considered completely obsolete are MOSPF [RFC1584] (which was never seriously implemented or deployed), and CBT [RFC2201] (which was overtaken by PIM). 2.4 Configuring Multicast Network Elements For PIM-SM, there exist configuration mechanisms which are used to configure the RP addresses and which groups are to use those RPs in the routers. This section outlines the approaches. 2.4.1 Manual Configuration It is often the easiest to just manually configure the RP information on the routers when PIM-SM is used. The problem with this approach is that if the number of routers is huge, it may be a pain to configure the information on all of them. Additionally, good design is needed to avoid unnecessary renumbering and reconfiguration when having to change the routers acting as RPs: for example, this can be achieved using "service addresses" which are configured on the loopback interfaces for the RPs, ensuring easy portability without renumbering. 2.4.2 Embedded-RP Embedded-RP provides the information about the RP's address in the group addresses which are delegated to those who use the RP, so there is no actual need to configure any RPs in the network (if no other ASM than Embedded-RP is used). 2.4.3 BSR and Auto-RP BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP Savola Expires May 23, 2005 [Page 7] Internet-Draft Multicast Routing Overview November 2004 address for groups. It is in relative wide use for IPv4, but Embedded-RP makes this unnecessary for IPv6 ASM. Cisco's Auto-RP is a similar, but proprietary, older technology as BSR. There is typically no use to run Auto-RP if BSR is used. 2.5 Interactions with Hosts XXX: should this section be here at all? Previous sections have dealt with the components required by routers to be able to do multicast routing. Obviously, the the real users of multicast are the hosts: either sending or receiving multicast. This section describes the required interactions with hosts. 2.5.1 Hosts Sending Multicast Hosts don't need to do any signalling prior to sending multicast to a group; they just send it to the link-layer multicast address, and the designated router will listen to the multicast packets and start forwarding them as appropriate. There is a proposal, Multicast Source Notification of Interest (MSNIP) [I-D.ietf-magma-msnip] which could be used for both the sending hosts to register as having interest in sending if there would be receivers, and for the receivers (or routers) to signal their interest in receiving the multicast transmission. XXX: to be removed if MSNIP is not finalized before this goes forward. 2.5.2 Hosts Receiving Multicast Hosts signal their interest in receiving a multicast group or channel by the use of IGMP [RFC3376] and MLD [RFC3810]. 2.6 Restricting Multicast Flooding in the Link Layer Multicast transmission in the link layer, for example Ethernet, typically includes some form of flooding the packets through a LAN. This causes unnecessary bandwidth usage and discarding unwanted frames on those nodes which did not want to receive the multicast transmission. Therefore a number of techniques have been developed, to be used in Ethernet switches between routers, or between routers and hosts, to limit the flooding. These options are discussed in this section. Savola Expires May 23, 2005 [Page 8] Internet-Draft Multicast Routing Overview November 2004 2.6.1 Router-to-Router Flooding Reduction Only a proprietary solution, Cisco's RGMP [RFC3488] is known to have been developed to reduce the amount of router-to-router flooding on a LAN. This is typically only considered a problem in some Ethernet-based Internet Exchange points. 2.6.2 Host/Router Flooding Reduction There are a number of techniques to help reduce flooding both from a router to hosts, and from a host to the routers (and other hosts). Cisco's proprietary CGMP [CGMP] provides a relatively clean solution where the routers notify the switches. IEEE specifications mention GARP [GARP] as a link-layer method to perform the same functionality. Its implementation status is unknown. IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely implemented technique, often used alongside with IGMP proxying [I-D.ietf-magma-igmp-proxy]. IGMP snooping requires that the switches implement a significant amount of IP-level packet inspection; this appears to be something that is difficult to get right, and often the upgrades are also a challenge. To allow the snooping switches to identify at which ports the routers reside (and therefore where to flood the packets) instead of requiring manual configuration, Multicast Router Discovery protocol is being specified [I-D.ietf-magma-mrdisc]. 3. Acknowledgements Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that the up-to-date multicast routing and address assignment/allocation documentation is necessary. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This memo only describes different approaches to multicast routing, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo. Savola Expires May 23, 2005 [Page 9] Internet-Draft Multicast Routing Overview November 2004 6. References 6.1 Normative References [I-D.ietf-idmr-dvmrp-v3] Pusateri, T., "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), December 2003. [I-D.ietf-idmr-dvmrp-v3-as] Pusateri, T., "Distance Vector Multicast Routing Protocol Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 (work in progress), May 2004. [I-D.ietf-isis-wg-multi-topology] Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi Topology (MT)Routing in IS-IS", draft-ietf-isis-wg-multi-topology-07 (work in progress), June 2004. [I-D.ietf-ospf-mt] Psenak, P., "MT-OSPF: Multi Topology (MT) Routing in OSPF", draft-ietf-ospf-mt-00 (work in progress), October 2004. [I-D.ietf-pim-bidir] Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-07 (work in progress), July 2004. [I-D.ietf-pim-dm-new-v2] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", draft-ietf-pim-dm-new-v2-05 (work in progress), June 2004. [I-D.ietf-pim-sm-v2-new] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11 (work in progress), October 2004. [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-06 (work in progress), September 2004. Savola Expires May 23, 2005 [Page 10] Internet-Draft Multicast Routing Overview November 2004 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. 6.2 Informative References [CGMP] "Cisco Group Management Protocol", . [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of IEEE 802.1p GARP/GMRP Timer Values", 1997. [I-D.ietf-magma-igmp-proxy] Fenner, B., He, H., Haberman, B. and H. Sandick, "IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", draft-ietf-magma-igmp-proxy-06 (work in progress), April 2004. [I-D.ietf-magma-mrdisc] Haberman, B. and J. Martin, "Multicast Router Discovery", draft-ietf-magma-mrdisc-03 (work in progress), October 2004. [I-D.ietf-magma-msnip] Fenner, B., "Multicast Source Notification of Interest Protocol (MSNIP)", draft-ietf-magma-msnip-05 (work in progress), March 2004. [I-D.ietf-magma-snoop] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 (work in progress), May 2004. [I-D.ietf-mboned-ipv6-multicast-issues] Savola, P., "IPv6 Multicast Deployment Issues", Savola Expires May 23, 2005 [Page 11] Internet-Draft Multicast Routing Overview November 2004 draft-ietf-mboned-ipv6-multicast-issues-01 (work in progress), September 2004. [I-D.ietf-pim-anycast-rp] Farinacci, D., "Anycast-RP using PIM", draft-ietf-pim-anycast-rp-02 (work in progress), June 2004. [I-D.ietf-pim-sm-bsr] Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", draft-ietf-pim-sm-bsr-04 (work in progress), July 2004. [RFC1075] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, March 1994. [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --", RFC 2189, September 1997. [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003. [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003. [RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, . Savola Expires May 23, 2005 [Page 12] Internet-Draft Multicast Routing Overview November 2004 Author's Address Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland EMail: psavola@funet.fi Savola Expires May 23, 2005 [Page 13] Internet-Draft Multicast Routing Overview November 2004 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savola Expires May 23, 2005 [Page 14]