Network Working Group Internet 2 Internet-Draft September 1997 Internet Protocol Multicast Problem Statement 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). Abstract This document outlines the evolving requirements for Multicast functionality within next generation Internet Protocol networks, and is the product of an ad hoc Internet2 working group meeting held August 25-27, 1997 hosted by Cisco Systems, Inc. This document is offered to the IP community for its consideration and comments. 1.0 Introduction Multicast technology is important to data networks such as Internet2 because it can be used to conserve resources in the network such as circuit bandwidth and router resources. By reducing the amount of duplicate traffic in the network, it makes applications that operate in one-to-many and many-to-many configuration operate in a more efficient manner. This in turn allows the developers of these applications to add more functionality without significantly impacting the network. Many applications including distance learning and videoconferencing are natural users of multicast technology. Others like scientific data distribution, global resource announcement, and distributed simulation are emerging applications that will be hindered without native multicast support. In some cases, using multicast technology in place of multiple unicast streams improves the quality of existing applications. In the case of videoconferencing, this may result in a higher frame rate or improved conference control. In other cases, such applications as I2 [Page 1] Internet-Draft Multicast Problem Statement September 1997 distributed virtual reality or multi-user scientific visualization are impossible to build without multicast due to the shear volume of data that needs to be transmitted. Experience with technologies like "Internet broadcasting" (RealAudio) and "information-push" (Pointcast) technologies has shown that if a dependable, ubiquitous multicast service does not exist, application builders will come up with their own sub-optimal unicast-based distribution methods. In order to circumvent inefficient use of network resources by their users, Internet2 designers hope that native multicast support will provide the basis for efficient application design. 1.1 Requirement for a 2nd generation multicast backbone Internet2 represents an opportunity to deploy a second generation multicast backbone. In our view, the current multicast experience with the MBONE has demonstrated the limitations of this implementation of multicast technology. Interoperability with the existing MBONE infrastructure need not be a requirement for this deployment. At this point, there is no reason to believe that existing IGMP-based multicast clients will not be supportable. 1.1.1 Existing MBONE technology experience A second generation multicast backbone must avoid several problems that have characterized the MBONE and have inhibited its deployment within the Internet. The historical channel rate limitation has restricted multimedia sessions to a largely unacceptable production quality. The historical overall rate constraint and the lack of a coherent scoping mechanism have limited the number and diversity of simultaneous sessions. Much of the current MBONE is built upon uncoordinated multicast tunnels that are inconsistent with the underlying unicast topology. Finally, interprovider multicast traffic exchange across multiple access media at exchange points has proven both difficult and inefficient. 1) The management model for the current multicast "service" is "the MBONE staff" which is a collection of researchers and engineers that maintain the experiment. The new multicast backbone can't have a single staff. That is, management must be distributed (much like the unicast Internet is today). 2) The existing routing technology uses a flat routing architecture as one might deploy in a small AS. This can not scale to a generally useful level. The current MBONE does not easily provide a way to introduce new multicast routing protocols. 3) Multicast policy and access-control are non-existent. Route filtering and packet filtering are the only means today to achieve crude forms of policy routing. 4) The current MBONE is free access and generaltes no specific I2 [Page 2] Internet-Draft Multicast Problem Statement September 1997 revenue. Therefore, you can't get people to manage it with any urgency. 2.0 Next generation multicast backbone goals Some of the high performance applications envisioned by the designers of Internet2 would benefit from the availability of a ubiquitous IP multicast service. Examples of these applications include distribution of software updates, propagation of realtime scientific data, efficient network news delivery, distance learning classes, and video conferences (local, regional, national, international). The diversity of these applications requires that differential QoS support be inherent in the multicast services providing for requested characteristics of delay, reliability, and bandwidth as outlined in [I2 QoS doc]. Multicast distribution must be controllable according to the specifications outlined in the [I2 policy routing doc]. The multicast services must be robust. The presence of multicast traffic on a network must not disproportionately degrade unicast traffic. 1) The multicast service must provide 1-to-many communication, where many may reach into the tens of thousands. In addition, the multicast service must be able to provide low delay many-to-many communication for groups consisting of hundreds of hosts. And the multicast service must be able to provide best-effort service for many-to-many communication for groups consisting of thousands of hosts. 2) IP Multicast functionality must be supported on all future media (Sonet rings, cable, etc). 2.1 Control It is desirable to have robust admission control at both the core and edges of a multicast tree. There are a number of distinct components to control that are described below. 2.1.1 Administrative Scoping It is vital that network and system administrators be able to control who can use multicasting services in a network. Administrators must be able to put specific limitations on the total amount of multicast traffic present on their networks, control which LAN segments can receive a specific multicast group, and control which users can send into each multicast group. Implementing such controls could require wide spread distribution of control information. A network of cooperating multicast policy servers would be one way to enable the distribution of the control information required to implement these types of access controls. I2 [Page 3] Internet-Draft Multicast Problem Statement September 1997 2.1.2 Content Privacy There are instances where the content of a particular multicast group must be accessible only a specific set of users. Administrative scoping as described above is not sufficient to ensure this level of access control since anyone on a LAN with one or more legitimate users would be able to receive the multicast group. Encryption of the datastream in the multicast group would be a way to ensure the privacy of the group but the implementation of any such function is the responsibility of both the application on the end system and its user and specifically not of the multicast infrastructure itself. Encrpytion for privacy is a strong requirement and must be ubiquitous in all applications. It must not be assumed that the problem is solved by the network layer. 2.1.3 Control privacy Privacy of multicast control traffic in the application control stream is a requirement. For example, this may be implemented through encryption of control traffic. 2.1.4 Multicast traffic only upon request In the large scale multicast operations that we expect to develop in the future Internet, global flooding of all multicast groups to all possible LAN segments is not a reasonable policy. Traffic for a specific multicast group should only be forwarded to a network infrastructure and onto a LAN segment in response to a specific and authorized request from a end system on that LAN to receive or join that group or as a result of a specific managerial configuration decision. Specifically client attachments must use an explicit joining type protocol 2.2 Routing The IETF's Inter-Domain Multicast Routing (IDMR) working group has produced several multicast routing protocols, including Core Based Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In addition, the IDMR WG has formalized the specification of the Distance Vector Multicast Routing Protocol [DVMRP]. Various specifications for protocol interoperation have also been produced (see, for example, [THALER96] and [PIMMBR]). 2.2.1 Recommendations Since multicast will be a ubiquitous service, the next generation Internet will require both Multicast Interior Gateway Protocols (MIGPs) and Multicast Exterior Gateway Protocols (MEGPs) to field multicast services. Some of these recommendations can be expressed in terms of the ongoing IETF standards process as follows: a. We encourage the IETF to converge on a single Internet standard for intradomain multicast routing. I2 [Page 4] Internet-Draft Multicast Problem Statement September 1997 b. We encourage the IETF to expedite work on a single inter-domain multicast routing protocol. c. We encourage the IETF to expedite work on a multi-protocol policy based routing protocol. A protocol that allows for both unicast and multicast Network Layer Reachability Information is a near term requirement. 2.3 Management Multicast management tools must expose the underlying group forwarding topology, group membership, compliance with requested transmission properties, and source reachability. To enable the integration of standard network management techniques with the operation of multicast network services, additional SNMP MIBs are required so that typical network management stations can plainly display the state of the multicast service. The development of multicast troubleshooting tools that are analogous to common unicast tools is required to further this integration. The multicast equivalents of traceroute and ping should support troubleshooting of both member-to-source and source-to-member modes. Management tools should be aware of multicast policy and should be able to interact with any multicast policy control mechanisms. Multicast forwarding agents should be able to generate traps that alert management systems to changes in group membership, forwarding tree changes, and high resource utilization. 2.4 Implementation requirements Since multicast deployment is necessary for scaling of the Internet, vendor implementations must not hinder - and ideally should facilitate - this deployment. In particular, the low-level multicast management tools provided by manufacturers should be designed so that they can be readily incorporated into the routine operations of ISPs, exchange points, and campus networks and their NOCs. Administrative tools should, insofar as possible, be extensions of their unicast counterparts. It is also important that the multicast software implementation in routers and switches be on a par with the unicast code; i.e., the proportion of resources consumed by servicing the multicast environment should be commensurate with the proportion of multicast traffic. 3.0 Security Considerations It is quite easy to have multicast distributions be perceived as a denial of service attack on local networks. Secure mechanisms are required to ensure that network operators have adequate capabilities to manage multicast environments including being able to control who I2 [Page 5] Internet-Draft Multicast Problem Statement September 1997 can send into a multicast group and who can subscribe to receive a group. (See section 2.1.) Additionally implementations should honor source-specific IGMP prunes so that a denial of service attack can be pruned all the way to the first hop network segment. 4.0 Participants Scott Bradner Chris Buja Steve Corbato Bruce Davie Ken Hays Ron Hutchins Paul Hyder Jim Leighton David Meyer John Meylor Becca Nitzan Achutha Rao Steve Shultz Ben Teitelbaum Kevin Thompson Alex Tweedly Steven Wallace David Wasley Steve Wolff Paul J. Zawada 5.0 Author's Address editor Scott Bradner Harvard University 1350 Mass Ave. Cambridge MA 02138 +1 617 495 3864 sob@harvard.edu 6.0 References [CBT] A. Ballardie, et. al., "Core Based Trees (CBT) Multicast -- Protocol Specification --", draft-ietf-idmr-cbt-spec-06.txt, September, 1996. [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 1996. [PIMARCH] D. Estrin, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Motivation and Architecture", I2 [Page 6] Internet-Draft Multicast Problem Statement September 1997 draft-ietf-idmr-pim-arch-04.ps , October, 1996. [PIMMBR] D. Estrin, et. al., "PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps, September, 1996. [THALER96] D. Thaler, "Interoperability Rules for Multicast Routing Protocols", draft-thaler-interop-00.ps, November, 1996. [I2 QoS doc] Internet 2, "Internet Protocol Quality of Service Problem Statement", draft-internet2-qos-problem-00.txt, Sept. 1997 I2 [Page 7]