The Evolution of Multicast: From the MBone to Interdomain Multicast fo Internet2 Deployment Kevin €. Almeroth, University of California Abstract Mubicast communication — the onetomeny or manylomany delivery oF date — is G hot lop. of ineos inthe resscrch community, among sonderds groups, and to. network service providers. Forel the tention multicast hos received, there {0 al isves tha have not been completly resolved. One resi is that protocols ate all evolving, and some standards ore nt ye! finished. From a deployment per Specie, the lock of standards has slowed progress, bur ffs Yo deploy mulicest, 43 on experimental service ore in fact gaining momentum. The question now is iow lng wil be before micas! becomes ¢ ue Iara! service, Th goal of this orice is fo describe the pest, preset, and future of mulicest, Saring with the ‘Mulicast Backbone (Mone), we describe how the emphasis has been on develope ing and refining inadomain mulfcestroulng protocols. Stating inthe midale fo Iale 1990s, particular emphasis has baen placed on developing interdomain mult cos rutng protocls. We provide o funconel overview of the currenly deployed solution. The future of multicast may hinge on several research efforts that ore ‘working to make the provision of ilicast less complex by fundamentally chang ing the multicast model. We brielly suvey these efforts, Foci, aempls are boing imede te deploy native moliast routing in both Inernel2 networks and the com: ‘modi Item. We exomine how mullicos! is being deployed in these networks. thou a doubs, multicast communication — the one-to-many oF many-to-many delivery fof data — has become a hot topic. Ieis the f ‘cus of intense study in the research com i. It has become a highly desired fo ture of many vendors’ network products tis growing into a true deployment challenge for Internet engineers. I is ovoly= ing into a bighly touted service being offered by some Interact fetvice providers (ISPs). And finaly, iis starting to be used bya number of companies offering large-scale Internet appli cations and services. From almost all perspectives, multicast is Sevaloping into oae of the mos interesting Internet services For all the potential multicast has, and forall the advocacy multicast has received, there are still some concerns. Fest, by Internet standards multicast isan old concept; yot by most measures, deployment has been very slow. To put deployment in perspective, compare multicast to the World Wide Web 1d HyperText Transfer Protocol (HTTP). IP multicast was first introduced in Steve Deering’s Ph.D. dissertation in 1988 ‘and tested on a wide scale during an “audiocast" atthe 1992 Internet Engineering Task Force (IETF) meeting in San 30 [1]. The fest Web browser was wetten in 1990, and in 10 890.804400$ 1000 © 200018: 1983 there were about 100 sites on the Web. So while mulkicast and the Web are roughly the same age, multicast is considered tobe inthe early stages of evolution [2), while the Web's suc- 255, fluence, and use seem totally pervasive. Second, IP mol ticastis one of the fist services to be deployed which requires additional “intelligence” In the network. Multicast requires & al amount of state and complexity in both core and edge routers. These requirements are at odds with the long> standing belie? that intelligence should be pushed to the edges fof the network. While many’ in the Iatemnet community realize that the new generation of network services wil put demands fon the network, the difficulty isin deploying and managing these services in an infrastructure that has lengthy history of only offering bes-ffor unicast service, ‘With these concerns in mind, the image of multicast may soem somewhat tarnished. Is multicast then more trouble than its efficiency gains and economies of scale are worth? This, {question is especially relevant if multicast is to be used as & ‘money-making enterprise {or commercial companies. The challenges aze to define elegant protocols, to support an Infrastructure on top of which new applications can be dev ‘oped, and to continue Co investigate new ways of increasing, PEE Network+ Sansaryebrary 2000,Figure 1 4 generic tunne-based topology representative ofthe ean MBione eificoncy and reducing complexity. Doing multicast “the right way” is a noble endeavor and an appropriate long-term esearch topie, but the demand fot working multicast has ere- fated an environment in which even short-term Tinetional sol tions are very attractive Th this article we attemp to describe the past, present, and future of multicast The hietry of mulcst should lp the red- ter understand how multicast has evolved into its current sate [Relevant topes incude a desription of the Multicast Backbone (MBone) asd an overview ofthe common inradermain multicast routing protecos. More recently, multicast evolution has beer Prima focused in the area of iuerdomain protocol develop- ment, Multicast in the present can be characterized as an effort to deplay multicast on a wide scale using a tlumvirace ff routing protocols. These deployments have been carried ‘out in the two Internet? backbone netwarks — very-bigl speed Backbone Network Service (yBNS) and Abilene — as ‘ell asin the commodity Internet (so designated in order to slstinguish i from Tntexne!2 networks). The future of rulth= fast f rooled inthe continued development, evaluation, and Standardization of new protocols. However, unlike current efforts, which are focused primarily on routing, future efforts are likely to include other issues such as address allocation, ‘management, and billing [3]. We ate alveady starting t0 see ome efforts in these areas. The remainder ofthis article is organized as follows. We describe the early evolution of multicast, in particular the evelopment of intradomain multicast, We then focus on interdomain multicast, including the best current practices land several of the efforts to define the next generation of pro- {ovols. We supply details on inter-domain deployment efforts in the commodity Internet and in Internet? networks, and conclude the article, The Evolution of intradomain Multicast From the fist Internet-wide experiments in 1992 to the mide dle of 1997, standardization and deployment in multicast focused on a single Mat topology. Ths topology isin contrast to the Internet topology, which is based on a hierarchies! routing stcture, The inal multieast protocol research and Standardization efforts were aimed at developing routing pro- tocols for this flat topology. Beginning in 1997, when the mul- tleast community realized the need for a hierarchies ralticast infrastructure and interdomain routing, the existing protocols were categorized as intradomain protocols, and work begen on standardizing an interdomain solution, In this setion we deseribe the standard IP multicast model, and the evolution tnd characterization of intradamain multicast protocols. The Standard IP Mulicast Mode! Stephen Deering js responsible for describing the standard ‘multicast model for IP networks [4]. This model describes. hhow end systems are to send and receive multicast packets. ‘The model includes both an explicit set of roquirements and several implicit requirements. A understanding of the model will help the resder understand part ofthe evolutionary path ‘multeast has taken, The model sas follows [5 * TPesvle semantics: source can send micas packets at any time, with no need to register or to schedule transmission, 1P multiast is based on User Datageam Protocol (UDP) (aot TCP), so packets are delivered using a best-effort poi. + Open groups. Sources only need to know a multicast address ‘They do not need to know group membership, and they do not need to be a member of the multicast group to wich they are sending A group can have any numberof sources. + Dynamic groupe: Multicast group members ean join or lave & multicast group at wil. There i no need to register, synchro- zo, oF nagotate with a contealzed aroup management entity. The standard IP mallcast mode i an end-qystem specifica: tion and does not discuss requirements for how the network should perform routing. ‘The model also does not specify any ‘mechanisms for providing quality of service, securily, of address allocation, The Birth of ihe Mulicast Backbone Interost in building maulticast-capable Internet, motivated by Deering’ work [4], began to achieve ertieal mas inthe late 1980s, This wotk led to the creation of multieast inthe Inter net {6 and the creation of the Multiesst Backbone (MBonc) (7,8) In March 1992, the MBone carried its first worldwide event when 20 sites received audio from the meetig of the IETF [1] n San Diego. While the conferencing softwate itself represented a considerable accomplishment, tne most signifi- cant achievement here was the deployment ofa virtual mul cast network. The multicast routing function was provided by ‘workstations running a dacmon process called mrouted (p10 uunced m-route-d}, which received unicast-eneapsulated ulicast packets on an incoming interface and then forward: ed packets over the appropriate set of outgoing interfaces. Connectivity among these machines was provided using point te-point, IP-encapsvlated runels, Each tunnel connected two wipoins va one logical link, but could cross several Internet routers. Once a packet is received, it can be sent to other tua nel endpoints oF broadcast to focal members. Routing dec sions were mde using the Distance Vector Multicast Routing Protocol (DVMRP) [9]. An examplo of connectivity provided via a virtual topology is shown in Fig 1. In this earliest phase bf the MBone, all tunnels were terminated on workstations, and the MBone topology was such that sometimes multiple Tunnels ran over a common physica link. Multicast routing In the carly MBone was actually a controlled form of leoding, ‘The fist versions of mrowed did not implement praning. It was not until several years later that pruning was deployed The original multicast routing protocol, DVMRP, creates ‘multicast trees using a technique known as broadcast-and: rune, Because of the way the tee is constructed by DYMRP, is called a revene shores path te, The steps to creating this {ype of tree are as follows "The source broadcasts e2ch packet on its local network, An attached router receives the packet and sends iton all out- going interfaces, + Each router that receives a packet performs a reverse path forwarding (RPF) check, That is, each router checks to see if the incosaing interface on which a multicast packet is received isthe interface the router Would ake 48 an ext: ing interface to reach the source. in this way, a router will IEEE Nomork + January ebraary 2090chioae to only receive packets on the one interce that it believes isthe most efficent path back tothe soaree All Packets received on the pret Inteace are forwarded on Ul outgoing interiaces, All ters are dscarded sony! Eventually packet wll ach a router with wome number of atiached hosts. This laf router will eheck to see iit Knows of any group members on any of ts attached sub- nets A rovter discover the existence of group members by Petiodizalty issuing Internet Group Mavagetent Protocol (GMP) [5, 10,11] queries. there are member, the teat outer fort the multicast packet on the subnet. Other: Wise, the leaf router wil end 8 pine message toward the Source on the RPT intectace, thatthe interface the leaf Touter would ute to forward packets fo the source. Prune packets are forwarded bask toward the source, routers slong the way create prane sate forthe interface On which the prone message received If prune messages ae received on all interfaces except the REF interface he Touter will send a prune message of is own toward the In his way, revere shortest path trees are created. These trees ean be constructed even on a virtual topology lke the MBone, Brosdeast-and-prune protocols are lso knows dense mode protocol, beeause thoy ae designed to perform best when the topology is densely populated with group mem- bers, Routers assume there are group members downsteam, And ths forwatd packets Only when explicit prone messages ae received does a router not forward maltcast taf. ha {oup it densely populated, routers are unlikely to ever need fo prune, The key disadvantage of dense mode protocols is {hat state information must be kept foreach source st every ter inthe network, regardless of whether downstream ‘group members exist, Ifa group i not deusely populated, ‘flan state most be stored im the network, a significant mount of bandwith may be wasted The Evolution of Inttadomain Multicast Sinco 199, the MBone has grown tremendously Its no longer {simple virtsal network sitting ontop of the Taternt, buts Figure 2. An example multicast topology witha combination of tunel and native mu tient lin, rapidly becoming integrated into the Internet itself. In addition {o simple DVMEP tunnels between workstations the MBone ow has rive multicast capability; that i, routers are capable of handling multicast packets (Fig 2) Furthermore, ongoing research has led to the development and deployment of two ‘ditional dense mode protocols, These are described belo. MOSPF — Multicast Extensions to OSPF (MOSPF) [12] uses the Open Shortest Path First (OSPF) [13] protocol ta provide ‘multicast. Basically, MOSPF routers flood an OSPF area with information about group receivers. This allows sll MOSPF routers in an area fo have the same view of group member- ship. Inthe same way that each OSPF router independently constructs the unicast routing topology, each MOSPF router can construct the shortest-path tree for each source and ip. While group membership repars are flooded through- ut the OSPF area, data is not. MOSPF is something of an code in terms of clasificalion. I is considered a dense mode protocol because membership information is broadcast 10 each MOSPF router, but it is also considered an explicit join protocol because data is only sent to those receivers that specifically request it, The key to understanding MOSPF is to realize that itis heavily dependent on OSPF and its Tink state routing paradigm, PIMDM.— Protocol Independent Multicast (PIM) [14] has bbeen split into two protocols, a dense mode version called PIM-DM [15] and a sparse mode version called PIM-SM [16] PIM-DM is very similar to DYMRP; there are only two major differences. The first is that PIM (both dense mode and sparse mode) uses the unicast routing table to perform RPF checks. While DVMRP maintains its own routing table, PIM uses whatever unicast table is available, The name PIM is erived from the fact thatthe unicast table cen be built using any unicast routing algorithm. PIM simply requires the unicast uting table to exist, and thus is independent of the algorithm used to build it. The second difference between PIM-DM and DVMRP is that DVMRP tries to avoid sending unnecessary packets to neighbors who will then generato prune messages ‘based on a failed RPF check. The set cf outgoing intexfaces built by a given DVMRP router will inelude only those downstream routers that use the given router to reach the source (successful IRPF check). PIM-DM avoids this com= plesty, but the trade-off is that packets fre forwarded on all outgoing inter~ faves, Unnecessary packets are often forwarded to routers which must then enerate prune messages because of the resulting RPF failure, "The next evolutionary step in intezdomeia routing was to develop protocols that addressed the disadvan- tages of dense mode protocols. A new class of protocols, called sparse mode protocols, was ereated, Instead of opti= nizing only for the ease when @ group, thas many members, sparse mode pro- tovols are designed to work more effi- ciently when there are only a few 1 real the action fo a pace hat falls a [RPP check depos onthe protocol. Same pro= toca tl all psream riers except the RPF ‘rower i stop foosrdg packers 2 IEEE Network Janey 2000