Deployment Issues for the IP Multicast Service and Architecture
Total Page：16
File Type：pdf, Size：1020Kb
Deployment Issues for the IP Multicast Service and Architecture ¢ Christophe Diot* Brian Neil Levine Bryan Lyles* Hassan Kassem ¡ Doug Balensiefen ¦ ¤ ¥ *Sprint Advanced Technology Labs £ Computer Science Department SprintLink Sprint 1 Adrian Court University of Massachusetts 12502 Sunrise Valley Dr. 2002 Edmund Halley Dr. Burlingame, CA Amherst, MA Reston, VA Reston, VA cdiot,[email protected] [email protected] [email protected] [email protected] commercial implementation of multicast. Some of Abstract these issues include: • IP multicast offers scalable point-to-multipoint delivery Group management, including authorization necessary for using group communication applications for group creation, receiver authorization, and on the Internet. However, the IP multicast service has sender authorization. seen slow commercial deployment by ISPs and carriers. • Distributed multicast address allocation. The original service model was designed without a clear • Security, including protection against attacks understanding of commercial requirements or a robust on multicast routes and sessions, as well as implementation strategy. The very limited number of support for data integrity mechanisms. applications and the complexity of the architectural de- • Support for network management. sign — which we believe is a consequence of the open Consequently, the current IP-multicast archi- service model — have deterred widespread deployment tecture deployed by carriers and Internet Service as well. We examine the issues that have limited the Providers (ISPs) to compensate for these issues is commercial deployment of IP-multicast from the view- complex and has limited scalability. Trying to gen- point of carriers. We analyze where the model fails, what it does not offer, and we discuss requirements for suc- eralize and commercialize multicast from the cur- cessful deployment of multicast services. rent service model and protocol architecture is dif- ficult, and in the worst case, adversely impacts the 1 Introduction long-term success of multicast. In this paper, we examine, from the viewpoint Since its introduction [11], IP multicast has seen of ISPs and carriers, the current IP multicast service slow commercial deployment in the Internet. Al- model and the issues that have limited the com- though it has been available through the experi- mercial deployment of IP-multicast. We discuss the mental Mbone for a number of years, it is just be- motivations of ISPs and users for using multicast. ginning to see commercial support from carriers, We show where the architecture has become too ISPs, and common operating systems. IP-based complex, what services are not addressed by the networks offer point-to-multipoint and multipoint- model, and what is required for long-term success- to-multipoint best-effort delivery of datagrams by ful deployment of multicast service. 1 means of the IP-multicast service and architecture . The goal of this paper is not to prove or show The current service model in IP-multicast was de- the current model is wrong. Rather, it is to show fined without a commercial service explicitly in that the open multicast service model and the com- mind, which is one possible reason for its slow de- plexity in providing the necessary functionality for ployment. Although each of these issues is the ISPs are limiting the possibility of Internet-wide subject of current research efforts, the service multicast. model and architecture does not efficiently provide In the next section, we review the current serv- or address many features required of a robust ice model and the architecture that supports it. In 1 Section 3, we analyze the motivations of ISPs and By architecture, we mean the set of protocols supported customers for using a multicast service. In Section by the IETF and vendors to realize the service model. 1 4, we examine the difficulties ISPs have had with 2.2 the deployed architecture has tended towards the current model and architecture. In Section 5, we just a few protocols. discuss the functionalities that are lacking from the The differences in these protocols lies mainly in service model. In Section 6, we propose alternate the type of multicast routing trees that they build. services models that are more aligned with com- DVMRP, MOSPF, and PIM Dense Mode build mercial deployment. Finally, in Section 7, we offer multicast spanning trees that are shortest path from our final remarks. each source. PIM Sparse Mode, CBT, OCBT, and HIP build multicast spanning trees that are shortest 2 IP Multicast path from a known central core, also called a ren- dezvous-point or RP, where all sources in the ses- 2.1 The Current Service Model sion share the same spanning tree. (PIM Sparse Mode is a complicated protocol that at times builds IP-multicast is based on an open service model. source-rooted shortest path trees.) CBT, OCBT, No mechanism restricts the hosts or users from cre- BGMP, and HIP build bi-directional shared trees: ating a multicast group, receiving data from a packets from each source are disseminated along group, or sending data to a group. The notion of the tree starting from any point. PIM Sparse Mode group membership is only a reachability notion for uses a unidirectional shared tree, where packets are receivers and is not meant to provide any kind of sent first to the core, which then sends packets access control. As with all IP datagrams, multicast down the multicast spanning tree to all participants datagrams are best-effort and unreliable. Each of the session. multicast group is named by a class-D multicast address (which is in fact a name [37]). 2.2 The Current Architecture To receive data from the multicast group, hosts must join the group by contacting their routers us- The de facto architecture in routers today is ing the Internet Group Management Protocol based on IGMP version 2, DVMRP, MOSPF, and (IGMP version 2) [18]. Once a host joins a group, it PIM Sparse Mode (PIM-SM), coupled with the receives all data sent to the group address regard- Multicast Source Discovery Protocol (MSDP) [17] less of the sender’s source address. or Multicast Border Gateway Protocol (MBGP) [3]. Hosts can send to a multicast group without be- DVMRP, MOSPF, and PIM-SM are limited in appli- coming a receiver; such hosts are often referred to cability to autonomous systems and administrative as non-member senders. Multiple senders may share domains. Interdomain multicast routing is largely the same multicast address; if those sources shared managed by MSDP. a single multicast routing tree, or if they have sepa- IGMP is used by hosts to announce their interest rate trees leading to the receivers is dependent on in receiving a multicast group to edge routers. the multicast routing protocol. Senders cannot re- These edge routers use multicast routing protocols, serve addresses or prevent another sender from to form multicast spanning trees through the Inter- choosing the same address. The number of hosts net. IGMP version 1 (IGMPv1) [11] was proposed joined to a group as receivers is dynamic and un- in conjunction with DVMRP, the first multicast known. The status of entities (i.e., sender, receiver, routing protocol. IGMP version 2 (IGMPv2) [18] or both) is unknown. In sum, an IP-multicast group adds fast termination of group subscriptions and is is not managed. an IETF standard. IGMP version 3 (IGMPv3) [8] is a The connections between the routers that form work in progress. It allows receivers to subscribe to the multicast spanning tree are maintained by a specific sources of a particular multicast group. multicast routing protocol. Many such protocols DVMRP is a flood-and-prune protocol. The source have been proposed and are in use today on the of a multicast group floods the entire domain with Internet. They include (but are not limited to) multicast datagrams, which also serve to announce DVMRP [40], MOSPF [31], PIM Sparse Mode, PIM the existence of the group. Datagrams that do not Dense mode [12][13][14][15], CBT [4], OCBT [36], arrive at a router on the reverse path interface back HIP [35], and BGMP [24]. As we will see in Section to the source are ignored, and a prune message is 2 sent in reply to the neighboring router. End-routers that do not serv- Unicast Multicast ice any hosts interested in receiving DHCP S Reliable MADCAP/AAP/MASC, RTP/ e H r multicast GLOP SDP RTCP o the multicast group also prune back IANA DNS v s i c t e the spanning tree. DVMRP was s TCP never meant to work beyond a small UDP autonomous domain because its flooding mechanism does not scale to I n r H t o e o u the entire Internet. PIM Dense Mode r f s t a e IGMP ICMP t - c r is very similar in operation to e DVMRP except that it is independent do of the underlying unicast routing r PIM-SM, PIM-DM MOSPF o OSPF, RIP, I n u m t DVMRP r EIGRP, etc. t protocol. i a a ng - i MOSPF is based on OSPF routing n RIP, EIGRP OSPF mechanisms. Group membership do r o I MSDP, BGMP n u information is flooded throughout m t t BGP e i a ng r - i the network, and per-source trees are n MBGP (BGP4+) computed by each router using link- state routing information available from OSPF. Similar to DVMRP, Figure 1. A comparison of protocol components for IP unicast (left MOSPF is regulated to intradomain side) and IP multicast (right side) architectures. scenarios. PIM Sparse Mode (which is provider domains, an interdomain multicast rout- similar to PIM Dense Mode only in name) is based ing solution is required. Currently, the most com- on the concept of rendezvous-points (RPs).