Deployment Issues for the IP 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 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 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 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 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 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). RPs are monly employed solution is the Multicast Source pre-defined points in the network known by all Discovery Protocol (MSDP), which distributes this edge-routers. The edge-routers with attached hosts mapping and announces sources via TCP connec- interested in joining the multicast group start a tions between RPs. MSDP runs over a multicast- multicast tree by sending join messages on the capable Border Gateway Protocol (commonly shortest reverse path to the RP, which instantiates a known as BGP4+ or MBGP) [3], which is a set of new branch of the RP’s unidirectional shared tree. multicast extensions for BGP version 4 that sepa- After forming a branch to the RP of a session, the rates unicast and multicast policy. We discuss newly joined edge-routers learn of each source MSDP in detail in Section 4. joined in the same session (i.e., member senders). Because there is no standard, globally- The edge routers then switch to a shortest path tree recognized method of allocating addresses for sources that transmit over a certain threshold. uniquely in the current model, the IETF is experi- PIM-SM builds shortest path trees by sending join menting with static allocation of blocks of multicast messages to each source in the session. The edge addresses. This scheme is often referred to as GLOP routers then prune back on the RP’s tree for that [30]. This experiment should last until May 2000, source. This results in per-source-per-group rout- when it is expected that protocols developed under ing table entries in the multicast tree. As we discuss the Multicast Address Allocation Architecture in Section 3, the current operation of PIM is differ- (MAAA) [21] will be implemented (see Section 5.3). ent from its intended design. In the near future, interdomain multicast is ex- If receivers using PIM-SM wish to join multicast pected to be managed by the Border Gateway Mul- groups with sources located in remote domains ticast Protocol (BGMP) [24]. BGMP is an interdo- (with remote RPs), PIM-SM requires that the main protocol used to manage interoperability group-to-RP mapping must be advertised to all between multicast routing protocols in different edge-routers in PIM-SM domains. When crossing domains. It uses bi-directional shared trees be-

3 tween domains and relies on MAAA protocols or drive Internet-wide multicast connectivity. The use GLOP to designate the core-domains of multicast of multicast results in bandwidth savings that make groups and to solve address allocation and core it an attractive service mainly to sources and ad- placement. (In BGMP and HIP, entire domains act ministrators of low-capacity domains, such as cor- as cores.) porate networks. Receivers do not care whether The right side of Figure 1 illustrates the IP mul- they receive their audio streams from unicast or ticast architecture. Interdomain support, if present, multicast. As receivers, they require the same is based on MSDP or BGMP, which rely on MBGP. amount of bandwidth that they would obtain with Intradomain multicast routing trees are built by unicast transmission (this argument may be gener- CBT, PIM Sparse mode, or PIM Dense mode, which alized to other aspects such as real-timeliness or rely on the presence of an underlying unicast quality of service). Moreover, users will find uni- routing protocol. MOSPF relies specifically on cast delivery a more stable service at this point. OSPF. DVMRP includes its own unicast routing Sources require multicast so that they may scale protocol. Hosts ask routers to join multicast groups their services to extremely large audiences. Low- with the Internet Group Management Protocol capacity domains require multicast only when (IGMP). Multicast address allocation is not defined many redundant high-bandwidth streams threaten in the IP-multicast service model. Presently, alloca- the capacity of incoming links. For example, many tion defaults to the static GLOP model. An alterna- employees in a company may choose to all receive tive proposed option is the combination of MAD- unicast streams of a popular video event, over- CAP, AAP, and MASC that make up MAAA. Ses- whelming the incoming bandwidth capacity. sion announcement may be performed with SAP. The current set of applications driving multicast protocols provide error correc- deployment are typically one-to-many, or few-to- tion and congestion control for multicast sessions. few, and fall into four categories: Not shown are Group-Key Distributions protocols, • Audio and video distribution, also referred to which manage shared encryption keys across large as webcasting, involves one source sending receiver sets to provide receiver authorization real-time audio and video over the Internet to services. On the left side of Figure 1 are corre- one or more receivers simultaneously. Many sponding unicast protocols. web sites have already made video distribution An in-depth description of the IP multicast ar- an integral part of their content. chitecture, including the history of its design and • Push applications (information delivery) allow deployment, is available elsewhere [2]. individual users to select from a variety of in- formation or content bundles, called channels. 3 Motivations and Requirements This information is then automatically spooled Multicast is included with the standard set of and pushed to them at regular intervals. Point- protocols shipped with most commercial routers, Cast is an example of an existing push applica- but most IP carriers have not yet enabled the serv- tion. This application is always downloading ice in their networks. A number of issues have information, up to 100KB per hour, even if the stalled the widespread use of multicast. We preface user is otherwise occupied and not actively a discussion of what has stalled multicast deploy- reading the information. Because of this, the ment, presented in Section 4 with a review of the impact of unicast bandwidth for PointCast and applications that are driving multicast and the re- others like it has been substantial and trouble- quirements of ISP customers. some for corporate networks. Companies that provide push technology are looking for ways 3.1 Market Motivations to conserve bandwidth to keep corporations from banning these applications entirely. Businesses have been encouraged to connect to • Audio and video conferencing and group col- the Internet ISPs by the phenomenal success of uni- laboration applications build on the capabilities cast-based email and web applications. However, used for webcasting, but allow users to interact general users of the Internet (i.e., receivers) will not

4 with each other. However, because of social is- for selecting service providers. Similarly, set-up sues, these applications that appear to be and configuration of a multicast session must many-to-many are likely to in reality be few-to- have low latency and be straightforward. Net- few, or multiple instances of one-to-many work management for customers should be • File transfer involves sending data (typically easy. Corporate customers regularly rely on large amounts of data) from one location to one management services to provide granular us- or more locations. As the amount of data grows age statistics and billing information that can and the number of recipients increases, the be used to plan network expansion, bill back bandwidth requirements and the time to com- users, and verify service-level agreements. plete file transfers can become unmanageable. • Senders expect group membership to be con- Multicast file transfer services support web trolled, for both senders and receivers. For caching, distributed databases, and remote senders it is important that only authorized logging. sources send to a multicast group; either be- Longer term, more applications with more in- cause a content provider wishes to be the only teraction among users will appear. We believe such source of data being sent to the group, or be- interaction will appear first at a low level, in cause of concerns about denial-of-service at- streaming applications (e.g., interaction with the tacks via flooding. Likewise, the set of receiv- content), and then with the deployment of shared ers, or scope, of the group must be controlled. virtual worlds and distributed games. Multicast is Note that this may be more complex than a then a mandatory technology to allow such inter- simple time-to-live or domain scoping. Sources action because of its scalable dissemination of data may wish to authorize receivers in several do- and because it minimizes delay among participants mains without delivering content to the entire [9]. The scale of the multicast groups for these ap- Internet. plications is likely to be tightly tied to social and • Similarly, content providers will expect that human-factors issues, and should not automatically their assigned multicast addresses are unique be assumed to require large-scale many-to-many (minimally, for the duration of their session). multicast. This is for several reasons. First, applications will not expect data from separate sessions to 3.2 Customer Requirements arrive on the same multicast address. Second, Customer requirements and market motivations separate sessions may have different band- dictate to carriers and ISPs which functions to pro- width requirements, and if they are on the vide, and consequently, what service model to im- same multicast–tree, a high-bandwidth session plement. Commercial use of multicast will require will drown out a low-bandwidth session un- at least the same level of availability and maintain- necessarily. Finally, placing separate sessions ability as unicast. The following customer require- on separate multicast addresses makes network ments can be extrapolated from the market moti- management easier (for tracking of problems). vations and experiences with IP unicast services. Other reasons can be found. • They are partially motivated by the fact that multi- Finally, reliable transmission may be required. cast is not a service which adds value for the re- Today it is provided experimentally at the ap- ceiver: plication level, but it is unclear whether a ro- • ISP customers must have ubiquitous global bust, reliable multicast can be built without access to multicast services. This requires scal- support from the network. able interdomain access to multicast services. Sections 4 and 5 show why these requirements • Multicast will be an attractive service only if it are not easy to provide to customers with the cur- is easy and transparent to install. The ISPs abil- rent service model. ity to install, manage, and maintain the multi- cast service is an important customer criteria

5 4 Deployment Issues

Multicast currently relies on a protocol archi- OC-12 to OC-48 tecture that requires more setup and administration Backbone than the unicast architecture. In this section, we Routers (some redundant) report and analyze experiences in deploying the OC-3 multicast architecture for commercial use. It has Access been noticed by major carriers that the current ar- Routers chitecture is unstable [27]. In this section, we try to understand whether it is the result of bugs in pro- Customer T1 to OC-3 Lines tocol implementations or if the architecture is bro- ken. Figure 2. A typical ISP point-of-presence (POP) structure. 4.1 Router Migration Multicast deployment at a customer’s premise is For example, deploying native support for not a simple issue due to the legacy of existing multicast for dial-up customers might require re- network infrastructure. A long-term problem for placing dial-up servers before their fully- multicast deployment is that it upsets the router depreciated value can be written off, and before migration model that ISPs follow, which is where their planned longevity as part of the network in- routers are initially deployed in the backbone, and frastructure. In some cases, multicast is provided over time, pushed towards customer access points. by forcing dial-up customers to send multicast da- Figure 2 illustrates a typical ISP point-of-presence tagrams encapsulated in UDP packets to a proxy, (POP). Customer access lines are fed into edge which then the data to receivers. routers, which in turn are connected to higher- Router migration has another implication for capacity backbone routers. As customer acquire multicast architecture designs. New routers that are higher-speed access lines, backbone routers are mi- deployed in the backbone are generally less intelli- grated towards customers access points to handle gent routers, lacking complicated services such as the higher speed access lines. Newer routers that congestion and admission control. Routers that are support even higher bandwidth are added to the simple and unintelligent can handle higher capac- backbone. In other words, routers are generally ity traffic more efficiently. Therefore, complex installed in the backbone and pushed towards services, like multicast, would be better deployed customer access lines as technology moves for- in the edge routers, except that replacing such ward. routers upsets the business model. Therefore, both Multicast upsets this model because older backbone routers and edge routers resist multicast hardware generally does not support multicast. deployment. And despite frequent software up- When there are no offered software upgrades, the dates, multicast will not be fully deployed in net- routers are forced into early retirement. Companies works managed by carriers before a new genera- rely on the depreciation of their hardware’s value tion of routers has been installed at all levels of the in their business models. However, removing network architecture. hardware for upgrades prevents a normally avail- able tax write-off of the depreciation. Furthermore, 4.2 Domain Independence the natural cycle of cost of migration results in the use of equipment longer than a simple model of its For applications with many low-rate sources, value would predict. Hardware is typically re- like distributed games and DIS applications, it moved when the cost to remove and replace it is might be more efficient to have all sources share a less than or equivalent to the cost to maintain or tree. Such trees are more efficient in terms of the upgrade vital components that would make the amount of state at routers (although not with the hardware support new features. data carried to receivers [25]). Protocols like PIM-

6 SM and CBT were designed to support shared not scale due to its periodic flood-and-prune trees. mechanism. It also has dramatic effects on the However, ISPs using PIM-SM, or other transmission delay and breaks the IP-multicast RP/core-based protocols, face a number of prob- service model by carrying data over TCP. How- lems regarding domain independence. Many ever, it does eliminate the problems related to RPs problems are present when RPs and their associ- that are not located in a source’s domain. ated sources are in distinct domains: Specific to PIM-SM are problems due to the dif- • Traffic sources in other domains potentially ference in its deployment as compared to its in- require traffic controls, such as rate or conges- tended design. PIM-SM uses RPs so that applica- tion control. tions with multiple low-rate sources can benefit • An ISP that relies on a RP located in another from shared trees. However, deployed PIM-SM domain has very little control over the service never uses shared trees for transport for two rea- that its customers receive via the remote RP. sons: MSDP and incorrect variable settings. • ISPs do not want to be the core of a session for First, MSDP prevents the use of shared trees which they have no receivers or sources as it is between domains. This is because when remote a waste of their resources. RPs receive source active messages, they join di- • Advertisement of the address of the RP or core rectly to the source and not to the RP of the source. must occur in a scalable fashion with low la- Even when two sources are co-located in the same tency. domain, RPs in remote domains will form two MSDP was introduced to announce PIM-SM separate per-source branches, one to each source. source-to-group mapping information so that trees Accordingly, MSDP defeats the shared tree support could be built directly towards the source’s domain in PIM-SM between domains. without third-party dependencies. (This also Second, although PIM-SM specifies that receiv- amounts to solving the problem of announcing RP- ers should only switch to a per-source tree when to-group mappings.) In MSDP, neighboring do- the rate of a source passes a threshold, in practice mains (i.e., peers) announce sources to each other major vendors have set the default setting of the using source active messages. MSDP floods source threshold to zero kbs. With such a setting, the fol- information to all other RPs on the Internet using lowing steps occur in deployed-PIM. Receivers be- TCP links between RPs. RPs servicing receivers that gin by joining to an RP’s unidirectional shared tree. are interested in a particular source then join on the Next, receivers immediately learn of all other par- shortest path to the source. ticipants in the session. Finally, receivers immedi- MSDP occasionally carries multicast data within ately form per-source trees to each participant in the source active message to avoid the delay in the session. Therefore, in practice, PIM does not transmitting data while these messages are propa- construct shared trees within for any source with gated, and to avoid the timeout of bursty sources at more than ephemeral traffic. remote RPs. TCP is used in MSDP for two reasons: PIM-SM was designed to support both per- first, to ensure source active messages that contain source trees and unidirectional shared trees. The encapsulated multicast data are delivered in order; deployment of PIM-SM and MSDP defeats these and second, because the information sent may be design goals: deployed PIM-SM is de facto a per- too large for a single UDP and may ar- source protocol that also suffers from the problems rive out of order. Unfortunately, RTCP and many of shared tree protocols, such as third-party de- reliable multicast applications perform multicast pendencies and RP advertisement. This set of roundtrip time estimation with low-rate session problems disconnects the deployed architecture messages, but if a TCP retransmit timer is used, from the intended designs. then RTCP will return unrepresentative results for An alternative solution to the problems of core- the high-rate data flows. For this reason, MSDP is based protocols is given by the Simple Multicast being modified by the IETF to use unreliable GRE [33] model. Core advertisement is left to a session tunnels between peers. Unfortunately, MSDP does discovery tool, email, or web pages. The core of a

7 multicast group is told to routers by hosts by in- C cluding a core-multicast (C, M) tuple in the header o s t of all packets destined for a particular group. The pe r

use of a core-multicast tuple makes the architecture u s

e Unicast simpler. r Multicast 4.3 Management Due to the complexity of the protocol architec- $0 ture described in the previous section and to the 1 Number of Users poor interoperability with existing services, multi- cast is extremely difficult to install and manage. Multicast deployment at a customer’s premise is Figure 3. The multicast sweet spot occurs not a simple issue due to the legacy of existing when the performance benefits of a new network infrastructure. Problems common to mul- service outweigh the costs as compared to ticast deployment today include firewalls and a unicast. lack of support for Network Address Translation multicast makes sense today for an ISP or corporate (NAT). An Internet draft on NAT has been issued customer only when the bandwidth savings are [19], but it is not yet implemented as a standard higher than the deployment and management solution in commercial equipment. The main costs. Cain suggests this is multicast deployment’s problem with most firewalls is that multicast (i.e., sweet spot [6]. Because multicast is more complex class-D) addresses are not recognized. The only and more difficult to manage than unicast, it is only solution to this problem is to tunnel multicast cost effective for an ISP to deploy multicast and packets through the firewall. This creates a serious manage it for customers when doing so saves sig- security hole in the system where multicast is de- nificant bandwidth. The sweet spot is where the ployed. Until these problems can be fixed by ven- additional cost of providing the service is out- dors, the solution supported by vendors to solve weighed by the gained performance benefit. firewall incompatibilities is to use static routes to The cost of a network service can be defined as all multicast enabled routers. the sum of network related costs (router state, ISPs are having a difficult time managing multi- processing, and signaling, inter-domain routing cast, although it is yet to become a popular service. scalability) and management costs (ease of de- While intradomain multicast is relatively easier to ployment and maintenance; in terms of human re- deploy, providing interdomain multicast is compli- sources and infrastructure). Figure 3 illustrates this cated. Interdomain multicast precludes complete principle. Unicast is represented as an increasing control of the network, which makes it difficult to straight line because each new receiver adds a new debug problems. This is important with protocols cost (mostly network cost). Multicast however has like BGMP or MSDP, which involve contact with a high initial cost which is higher than unicast. But other domains. We review multicast management the cost of adding new receivers should not be as tools in the Section 5.4. costly to support as in the unicast case. This sce- nario is ideal, and is represented as the downward- 4.4 Justifying the cost of Multicast sloping curved line in Figure 3. It corresponds to a Multicast is currently a service that reduces the group where all members would join the same amount of bandwidth required to transport data to source in the same AS. Therefore, there is an op- multiple recipients. Longer term, it may also be portunity to amortize the cost of multicast over used to minimize network delays in interactive ap- each receiver. To date, multicast is in fact very plication sessions. Multicast services are currently costly. A more accurate representation of multicast significantly more expensive than the unicast serv- may be the less-optimistic, second curved line: each ice, in terms of deployment, installation at cus- additional multicast receiver may exist in a differ- tomer premises, and management. Consequently, ent domain, causing management and networks

8 costs that exceed the benefit of efficient multicast each adds to the current model. For most of these routing. In the best case, multicast is advantageous functionalities, solutions exist that are either cur- to use over unicast services for low numbers of re- rently proposed for IETF standardization with no ceivers (occurring at the intersection point on the modification to the service model, or are being graph). Less optimistically, multicast requires a studied in the context of a new service model. larger receiver set (that might be an order of magintude larger compared to the optimistic case) 5.1 Group management before there exists a benefit over unicast. The current service model does not consider Consequently, there is an incentive for ISPs and group management, including receiver authoriza- content providers for supporting small group ses- tion, transmission authorization, and group crea- sions with unicast rather than multicast. Broad- tion. Group management may also include billing cast.com, for example, follows this philosophy. policy and address discovery. We address such Web events where the expected audience is small issues separately, choosing to define group man- are supported by unicast connections because the agement as access control functions that limit who bandwidth saved is not worth the overhead of may send and receive on a particular multicast ad- multicast management. For events as large as the dress. Victoria’s Secret fashion show, which attracted 1.5 The lack of access control functions presents a million visitors [5], multicast bandwidth savings danger for companies providing content over mul- were sought whenever possible. Such a large audi- ticast groups as well as for receivers that pay for a ence has the potential to overwhelm any large col- given service. Just as web sites require protection lection of servers and available network band- from hackers attempting to change the content of a width, making multicast a profitable and useful web site, multicast-based content providers require service for both servers and the network. access controls as protection from outsiders Cain’s sweet-spot principle predicts that while launching a number of possible attacks, including: the multicast architecture remains complex and • Flooding attacks, where high-rate, useless difficult to manage, it will face difficulty in reach- data is transmitted on the same multicast ing wide deployment. group causing congestion and packet loss. The next section enumerates additional carrier Flooding attacks prevent reception of data and ISP requirements not yet met by the multicast by valid receivers. Although this is a prob- service model. These additional requirements raise lem for unicast as well, multicast affords the questions about whether the complexity of a com- opportunity for attacks of much larger mercially viable Internet-wide multicast architec- magnitude and scope. ture will ever be simple enough to inspire Internet- • Collisions of sessions. Due to the lack of wide connectivity. group creation controls, two sessions using the same address can interleave their data. 5 Functionality Not Addressed • Unauthorized reception of multicast data, In Section 3, we reviewed market motivations including pay-for content, such as pay-per- that drive customer requirements of multicast view events. This represents a source of lost services. In Section 4, we reviewed the difficulties revenue for content providers. This problem faced by ISPs when deploying multicast. In addi- exists for unicast, however, the solutions for tion to these difficulties, there are functionalities multicast require group-key management, a not well addressed by the current model and ar- topic which is just beginning to see solu- chitecture, which we analyze in this section. Many tions. customer requirements concern missing compo- • Drowning out of authentic sources with al- nents of the IP-multicast service model. These ternate data, changing the content of the components are a prerequisite to successful com- session. This is also a source of lost revenue. mercial deployment of multicast. We review the Without access control mechanisms, such attacks seriousness of these concerns and the complexity are trivial to implement.

9 One enhancement over current IP group man- rently under study by the IETF. Other solutions to agement is IGMP version 3 [8], which provides this problem have been proposed end-to-end and source pruning for specific multicast groups, as at the network level. well as source-specific joins. IGMPv3 prevents data Encryption is often cited as the appropriate from entering the backbone when the routing pro- mechanism to preserve data privacy at the applica- tocols support this option. Unfortunately, it is not tion level. Unfortunately, for large heterogeneous possible to prune sources or have source specific groups, application-level key management is at joins in shared tree protocols, such as CBT or best a partially solved problem. To maintain scal- BGMP (although BGMP is compatible with Ex- ability in the presence of a large receiver set, re- press-style multicast groups). In addition, attacks keying must be done on portions of the tree may still be possible in the backbone with IGMPv3 [34][42][29]. For example, the Iolous protocol [29] when even one receiver does not prune all noisy or protects data from unauthorized receivers with malicious sources. To prevent such a scenario, re- data encryption. Unlike normal multicast delivery, ceivers would have to explicitly subscribe to a Iolus has the drawback that packets may cross known source list (as occurs in Express) rather than some links more than once. prune noisy sources after the fact. Note that IGMP Secure multicast services are network-level solu- version 3 is still under development. tions to ensure that multicast tree construction and Sprint and UUNet have deployed multicast as a delivery services are restricted to authenticated and commercial service. However, nothing prevents authorized hosts. Such protocols are therefore more receivers from joining any particular group other resistant to attacks, such as denial-of-service and than restricting access to the web page that lists the theft of service attacks. For example, Keyed-HIP multicast group address. (KHIP) [34] is a network-level security scheme that restricts sub-branch construction to unauthorized 5.2 Multicast Security domains and hosts. KHIP provides transmissions Providing security for multicast-based commu- and receiver access control, as well as data integ- nication is inherently more complicated than for rity. Each packet is encrypted to ensure data integ- unicast-based communication because multiple rity. entities participate, most of which will not have KHIP uses a bi-directional, core-based multicast trusted relationships with each other. Future multi- routing tree and lacks facilities for excluding spe- cast security should provide four distinct mecha- cific sources from the tree. In fact, all bi-directional nisms: authentication, authorization, encryption shared tree protocols break down into the same and data integrity. Authentication is the process of state as per-source trees when individual sources forcing hosts to prove their identities so that they must authenticate for each receiver. Cain has sug- may be authorized to create, send to or receive data gested placing authorization mechanisms at the from a group. Authorization is the process of al- edge of the network to maintain group state in the lowing authenticated hosts to perform specific presence of receiver-specific source prunes [7]. tasks. Encryption ensures eavesdroppers cannot However, such a scheme maintains security at the read data on the network. Data integrity mecha- edge routers. If the edge routers are by-passed, nisms ensure the datagram has not been altered in then unauthorized transmissions will enter into the transit. backbone. The advantage of such as scheme is that The current IP multicast service and architecture it keeps complexity on edge routers and out of the does not mandate any authentication. Source backbone. authentication and data integrity is possible One very serious unresolved issue with multi- through the services provided in IPsec, but not re- cast security is the location of access lists. One sim- ceiver authentication. Furthermore, IPsec does not ple model is to place control of authorized receivers prevent sources from sending; it just allows receiv- at the (primary) source of a session. Such a model ers to drop unauthenticated packets after they are does not resolve who authorizes sources within received. IPsec is not widely deployed and is cur- domains — presumably, it would be handled by

10 system administrators — or interdomain authori- zation. One alternative to source-based authenti- cation would be to use authentication servers. 100 Note that security mechanisms are often at 80 odds with application requirements of fast joins, pointing towards the use of multicast groups 60 within multicast groups [25][26], or authentication 40 of blocks of addresses. 20 Chance of collision (%) 5.3 Address allocation 0 As the current multicast address space is un- 0 20 40 60 80 regulated, nothing prevents applications from Max addresses in router memory (K) sending data to any multicast address. Members of two sessions will receive each other’s data if sepa- Figure 4. The chances of address collision in rate addresses are not chosen. A lack of address IPv4 with restricted available router memory, allocation mechanisms poses no threat to ISPs, when all memory is allocated. other than that of dealing with angry customers and carrying unwanted data. However, address of routers in the current deployed Internet limits collision poses a serious inefficiency risk for multi- the chances of address collision because new cast receivers and can create application inconsis- groups cannot be created after memory runs out. tencies. This is because packets from other sessions Deriving the chances of address collision is a sim- must be processed and dropped. ple application of the “birthday problem”, often This problem could be partially solved with applied to hash collisions. The chances of no colli- 28 28 28 proper access controls for group creation, which sions for X addresses for is simply (2 )(2 -1) (2 - 28 would limit collisions via sender access lists (see X+1)/(2 ). (Therefore, the chances of a collision is Section 5.1). one minus this value.) For the 268 million class D A proper allocation scheme would have a num- multicast addresses available, the chances of colli- ber of properties: sion are limited 0.78% for memory that can hold 2K • No single user could disrupt service to other addresses. However, if multicast were to become users, for example, by allocating all ad- more popular (and routers reserved more memory dresses. for multicast addresses), the problem of multicast • No, or negligible, delay in address alloca- allocation will become a serious issue. For routers tion so as not to delay applications. with memory that can store just 8K addresses, the • Low complexity of implementation. chances of a collision when all addresses are used increases to about 12%. Figure 4 shows the graph of • High scalability to interdomain environ- ments. the probability of a collision of addresses given a limited amount of router memory (in units of ad- • Efficient utilization of the address space. dresses). • Long-term scaling to millions of multicast Currently, there are four alternatives to the cur- groups. rent model for address allocation: The chance of an address collision is very lim- • The Multicast Address Allocation Archi- ited right now only because multicast is yet to be- tecture (MAAA) [21]. come a popular interdomain service. The average • multicast-capable router sold and deployed today Static allocation and assignment (see Section has memory available for only 1–2K (source ad- 2.1) [30]. (Referred to as GLOP.) dress, group address) entries2. The limited memory

2 As discussed in Section 4.2, deployed PIM-SM shared- automatic switchover to shortest-path (s,g) by receivers tree “(*,g)” entries do not save state because of the upon joining the tree.

11 • Per-source (or channel) allocation as pro- two sources to the same address E is only sent to posed by the Express [22] model (or in a receivers subscribing to both sources. Similarly, similar way by the Simple Multicast [33] Simple Multicast proposes designating addresses protocol). as a (core, class-D address) model for the purposes • IP version 6 (IPv6) addressing [10]. of core advertisement for shared trees. The scheme MAAA’s design emphasized the efficient use of in Simple Multicast is not meant to address source a dynamically allocated address space at the cost of authorization. Regardless of purpose, such a tuple complex design. GLOP uses autonomous system solves the allocation problem as address allocation (AS) numbers as the basis for restricting addresses is local to the core or source S listed. available to domains. GLOP is a short-term ex- One small problem with Express results from periment to be reviewed in May 2000. IPv6 drasti- each host using a different multicast address (un- cally increases the address space at the expense of like the current model where even per-source trees changing IP packet structures, although IPv6 was have the same class D address). The session can no designed to be incrementally deployed in the Inter- longer be identified by a common address among net. IPv6 is a major rework of IP but does provide sources. For example, in a distributed game, many sufficient unique addresses to make address allo- users are the source of data. This problem can be cation easy. IPv6 and Express solve all require- solved at the application level by using an alternate ments, requiring a change in current packet-header identifier. A more serious limitation of Express is formats for IPv6, and the deployment of IGMPv3 that receivers must explicitly learn of every source for Express. (Simple Multicast would also require in the session (whereas this is taken care of implic- changes to packet-header formats.) itly by routers in the case of PIM-SM or CBT using MAAA is the most complex of these choices. It the traditional IP architecture) 120 consists of three protocols connecting hosts, do- The IPv6 addressing scheme offers 2 multicast mains, and multicast address allocation servers. addresses for world use, driving the chances of Hosts request addresses from severs using the collision to near zero. IPv6 offers a number of other Multicast Address Dynamic Client Allocation Pro- advantages and is already supported by an API in tocol (MADCAP) [32]. The servers inform each UNIX and Microsoft WindowsNT operating sys- other of claimed address blocks using the Address tems. For an IPv6 router with space for 1024K ad- -24 Allocation Protocol (AAP) [20]. The allocation of dresses, the chance of a collision is less than 10 %. addresses between domains is handled by the Furthermore, an Express-like scheme can be Multicast Address Set Claim (MASC) [16] protocol. used in IPv6. If a domain of the source aggregator Even if MAAA scalability issues can be solved by (i.e., the first part of the IPv6 address) is placed in an appropriate implementation, MAAA does not the first part of the 120-bit multicast address, then address whether enough multicast addresses are domains can claim implicit ownership of address available in the current addressing scheme if multi- spaces. Ownership of multicast addresses within a cast becomes a popular interdomain service. domain can be managed with AAP or a similar MAAA and GLOP could also create the same kind protocol. of problems as class-based allocation of IP ad- Using IPv6 satisfies most, if not all, of the prop- dresses, i.e., fragment the address space and create erties for a good allocation scheme and is already starvation. supported by vendors and the IETF. Express [22] is an alternative to the IP-multicast model that uses a per-source, channel-based model. 5.4 Network Management Each channel is a service identified by a tuple (S,E) Network management refers to the debugging where S is the sender’s source address and E is the of problems that occur with the multicast tree dur- express destination address (i.e., a class-D address). ing transmission, and the monitoring of utilization Only S may send to (S,E) because receivers sub- and operation patterns for the purpose of network scribed to (S,E) are not subscribed to (S’,E), for planning. The current tools for debugging multicast some other host S’. Thus, data transmitted from are all freeware developed as needed by MBONE

12 users. Commercial toolkits for multicast network 10kbs at $4,300; 25kbs at $10,900; 35kbs at $15,200; management await widespread deployment of 64kbs at $27,000; and 128kbs at $54,000 [39]. UUnet multicast. However, such tools are a crucial part of should be deploying multicast data streams up to multicast deployment since deploying multicast 1.5Mbs shortly. The UUnet multicast service is without them is likely to generate less than satis- called UUcast and is not a native multicast imple- factory customer experiences. mentation. UUcast sources unicast data to a proxy, The current set of programs available for multi- which then multicasts the data over UUnet’s (or a cast management includes SNMP-based applica- partner’s) backbone on to receivers. By mixing uni- tions, Mrinfo, Mtrace, RTPmon, Mhealth, Multi- cast and per-source multicast, UUcast solves some mon, and Mlisten. Almeroth has an excellent sur- of the deficiencies of the service model. However, vey of these tools and of the issues involved in UUcast is not interoperable with native multicast multicast network management [1]. services, such as implemented by Sprint and other Also available is the RouteMonitor, a tool that carriers. measures the stability of routes on the MBone [28]. RouteMonitor counts the number of times distance 5.6 Additional Services metrics for each DVMRP router change in a given Additional services that might be offered by a period. A MBGP RouteMonitor is under develop- commercial multicast service and supporting ar- ment. chitecture, though not as vital as the above re- Finally, the Multicast Route Monitoring (MRM) quirements, includes the following. These services protocol [42] is under development by the IETF. are often analogous to existing unicast services. MRM is an SMNP-based tool that has special pro- • Service-level Agreement (SLA) and Virtual Pri- visions for collection of SMNP MIB data over a vate Network (VPN) management. SLAs in- multicast tree in a scalable fashion. Most of these clude guarantees on network availability and tools are academic prototypes. None of these tools latency, and notification of when SLAs are not are robust enough to support commercial deploy- met. VPNs use a public infrastructure such as ment. They only partially address the various is- the Internet to provide secure communication. sues in monitoring and debugging, and cannot • Network performance measurement. Providing identify all problems related to the current protocol measurements to senders allows applications architecture. to adjust properly to network conditions. For example measurements of the highest trans- 5.5 Billing Multicast Services mission delay among members of the group. Although the multicast service model does not • Subcasting. Many efficient reliability and con- define any support for multicast billing, it is not gestion control protocols rely on or make use of clear there is a need in the short term. Today, Sprint subcasting. Subcasting is useful for receiver- provides multicast to its customers at no charge. based scoping [25]. This makes sense to the extent that it provides • Congestion control. Without congestion con- savings on backbone costs as compared to multiple trol, multicast sessions threaten to unfairly unicast streams in one-to-many applications. As overwhelm well-behaved TCP connections. discussed in Section 3, multicast is a service that is Many proposed solutions address this problem useful mostly to content providers and not general at the , or directly at the appli- Internet receivers. Pricing schemes and business cation layer (e.g., layered multicast). It might be strategies reflect this. the case that network-level congestion control UUnet advertises its multicast pricing as a com- is the best solution; this issue requires more parison against flat rate unicast pricing [39]. UUnet study. multicast is priced as a flat rate service that is inde- • Low-latency interdomain routing. Routing pendent of the number of receivers. Customers of between domains should be as immediate as UUnet (i.e., sources) chose among six discrete intradomain routing from a data transmission bandwidths and monthly charges: 5kbs at $2,200; standpoint.

13 • Unidirectional links. Multicast should work 6.1 Single-sender service model efficiently on unidirectional links and with uni- Single-source Internet multicast is a much sim- cast topologies. Satellite links are unidirectional pler paradigm to support than multipeer services, and form asymmetric routing paths. They al- and can be deployed successfully right now. ready are an important element in the delivery Moreover, the driving applications to date are one- of audio and video content. to-many, including file transfers and streaming multimedia. Multicast services should initially be 6 Alternate Service Models deployed around these applications. Additionally, The current multicast service model is inher- single-source, source-rooted multicast is well sup- ently complex. Many of the features that invoke ported by ATM networks, whereas shared trees are problems are designed to support applications that not. are not widely popular today, such as multiplayer The single-source service model requires a sim- games and distributed simulations. On the other pler architecture. There is no third-party problem, hand, the service model does not support well the and scalability can be maintained by protocols that applications that we know to be of immediate in- build routing by means of explicit-join signaling to terest, like the distribution of . This the source, as suggested by Express. With only one is because the model is not restrictive enough. For source, routing can always be shortest path back to example, the service model allows multiple senders that source. Complex protocols like the automatic but does not provide authorization mechanisms. PIM-SM changeover, or MSDP peering, are unnec- One consequence of this is that we have seen non- essary for single source applications. RPs or cores standard deployments, which eventually may dis- are not necessary. Pricing should be easier to man- courage software developers from writing multi- age as it can be compared against unicast streams, cast applications. For example, UUnet has not de- which is not the case with the multipeer service ployed standard PIM; they have deployed a proxy- model. Authorization of the source can be provided based version in order to control sources. and checked by border routers in remote domains In order for multicast services to remain man- and edge-routers in the source’s domain. Receiver ageable by ISPs, and for multicast to remain a stan- authorization can be provided by group-key distri- dards-based service, we support breaking the de- bution protocols. ployment of the model into single source and mul- Single source multicast is well-supported by the tipeer parts. We view such a separation as tempo- source-rooted Express model. Express is compati- rary, and would ease issues ISPs have with de- ble with the current Internet, as its required func- ployment until multipeer services have matured to tions have been anticipated well by IGMPv3. Edge a point where their designs are scalable and man- routers can send a source-specific “(S,G)” joins us- ageable. Furthermore, some common functions that ing IGMPv3 for designated Express multicast do not exist in the current model must be added to groups. IGMPv3 is still under development, but both of their parts. These functions have been dis- Express has already been allocated a space of ex- cussed in the previous section: perimental addresses by IANA for which joins • Address allocation, from receivers are expected on a per-source basis • Access control, and [23]. The convention of forcing receivers to specifiy • Interdomain management. exact sources must be enforced by routers for Ex- The ability of the proposed model to easily imple- press to work properly. ment each is discussed in the following sections. Interdomain issues are also simple to implement Note that solutions to the problem of address allo- by this model, as the notion of a core or rendezvous cation is independent of the choice of single-source point does not apply to the single-source model. or multipeer models. 6.2 Multipeer service model Architectures for multi-sender applications that require multipeer multicast are not as well under-

14 stood, as compared to single-source models. Multi- An additional unknown is who controls sender peer sessions based on shared multicast trees are access to the group. If it is a centralized site, then either bi-directional or unidirectional from a known that site represents a single point of failure. It is core. Because such trees are not shortest-path to a likely that such functionality will be co-located main source, they must be centered at some adver- with the core, or distributed with a set of cores, tised core, or at a domain acting as a core. This pre- adding additional overhead and coordination sents a number of problems not present in the sin- among remote domains. gle-source tree scenario: The multipeer service model is consequently • The core must be advertised or discovered. more complex to realize and seems to offer less ro- • The core must be “well-located”. bustness and scalability to carriers and ISPs. • Secondary cores must exist so that one ISP is not responsible for the robustness of the 7 Conclusion entire session. After a long period of very useful experimenta- The current architecture addresses these prob- tion using the MBone, commercial deployment of lems with MSDP and GLOP, and in the future, with multicast services has begun. In this paper, we have BGMP and MAAA. examined the issues that are limiting deployment. An alternate idea is to use a core-multicast The initial design of multicast was motivated by (C,M) tuple, as proposed by the Simple Multicast the need to support one-to-many and many-to- [33] protocol. Simple Multicast decouples core al- many applications in a scalable fashion. Such appli- location from routing, and relies on application- cations cannot be serviced efficiently with unicast level mechanisms to chose and advertise core in- delivery. The commercial design of multicast must formation. The core-multicast tuple in packet head- now include the market requirements of ISPs and ers would also require some protocol to allocated their customers. ISPs require a service and a proto- addresses from a remote core. Presumably, this col architecture that is easy to deploy, control and would also occur out-of-band and at a higher level. manage, and that scales well with the growing It is not clear that multi-sender applications will Internet. ISP customers expect to be the sole owners require a shared-tree model; the trend in such ap- of multicast addresses, if only temporarily, to have plications is that all data is not usually wanted or protection from malicious network attacks and useful to all receivers [25]. Remember that shared thefts of service and content, and to be able to cor- trees carry all data to all receivers and therefore rect network problems quickly. A deployable ar- wastes bandwidth on unwanted data. chitecture should be driven by these concerns. Sender authorization and authentication is more The current architecture does not consider these difficult in the multipeer, shared-tree model and is concerns well. It lacks simple and scalable mecha- not addressed by any implementation. In the sim- nisms for supporting: plest case, once a sender is authorized to send, all • Access controls. Including group creation receivers in the group must accept the sender. If and membership. not, receiver-specific prunes cause the amount of • Security. For protection against attacks to state in the tree to increase towards per-source the routing and data integrity of multicast state. An alternate solution is to prune sources at datagrams. the end-routers using the IGMPv3 protocol [8]. • Address allocation. Including all the prop- Nevertheless, such mechanisms still allow data to erties listed in Section 5.3. travel through the network, and would not truly • Network management. Such tools are not prevent denial-of-service attacks or unauthorized well developed at this stage. senders. Placing gateways at border routers would Many of the mechanisms in the current archi- prevent traffic from entering domains, but would tecture that address these issues do so too broadly not prevent this traffic from congesting the back- because they consider both the multipeer and sin- bone. gle source models. Applications that are most popular today are one-to-many, such as file trans-

15 fer, streaming media, and in- IP-multicast Simple Multicast Express formation push. Many-to- Routing Tree Type Any Shared Per-source many applications at this point bi-directional Unidirectional only mainly consist of less popular only DIS and serverless multiplayer Address allocation Large address (core, class D) (Source, class D) space in IPv6, model model games. (Currently, serverless or proposed in architectures are not a credible MAAA commercial model). Sender authentication None None None, but multiple and authorization (IP- senders are not al- Conferencing over the Internet sec allowed in all) lowed in same group remains few-to-few but is cur- Receiver authentication None None (hooks provided) rently better supported by and authorization unicast, as Cain’s sweet spot Protocols required to PIM,MSDP, & None (Stored in Cores not used. manage Interdomain BGP + packets) predicts. By attempting to Core/RP (or support many-to-many appli- Allocation/Discovery BGMP/MASC) cations, the architecture has Group creation controls None Yes, at core Yes, at source become cumbersome and at (proposed times defeated itself. For ex- with MAAA) Requires modification No Yes No, but requires ample, MSDP supports PIM to packet formats (Yes for IPv6) IGMPv3 and router RPs, but prevents the creation cooperation. of bi-directional shared trees Table 1: A feature-based comparison of emerging protocols to IP- across domains. multicast. the current protocol architecture, and with PIM and We have shown that from a carrier standpoint, IGMP in particular, should be preserved. deployment that supports the per-source model Otherwise, the current deployment strategy makes more sense for robust, simple, and scalable threatens to compromise the success of multicast as multicast services to all customers. We are not sug- a service that adds value to the Internet, and sig- gesting efforts towards multi-peer multicast halt. nificantly delay the deployment of applications that We suggest only that commercial deployment be- would benefit from multicast, such as media gin with the well-understood source-rooted, one- streaming and interactive applications. to-many model and architecture, even if the impli- cation is an increase in multicast routing tables at routers. Acknowledgments Table 1 shows a comparison of the features of- fered by IP multicast and two recent proposals that We thank the following people for their insight- rely on a different service model. As stated, Express ful comments on the issues presented in this paper: supports the single-source model, and Simple Kevin Almeroth, Brad Cain, Jon Crowcroft, Preston Multicast supports the multipeer model, which we Grant, Mark Handley, Edward Kress, Manuel Oliv- discussed in the previous section. Both solve the era, Ramanan Shanmugan, and Clay Shields. address allocation problem by using an extended address space. Alternatively, a transition to IPv6 References multicast would also solves address allocation [1] K. Almeroth. “Managing IP Multicast Traffic: A First problems by reducing the chances of address colli- Look at the Issues, Tools, and Challenges. IP Multi- sion to near zero. cast Initiative white paper. February 1999. We propose that a service model for multicast [2] K. Almeroth. “The Evolution of Multicast: From the be defined that supports carrier, ISP, and market Mbone to Inter-domain Multicast to Internet2 De- requirements. A new protocol architecture, eventu- ployment”. IEEE Networks. January/February 2000. ally based on emerging solutions, could be de- [3] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, “Mul- signed and deployed, co-existing with the current tiprotocol extensions for BGP-4.'' IETF, Request for deployment of IP-multicast. Interoperability with Comments 2283, February 1998.

16 [4] T. Ballardie, P. Francis, and J. Crowcroft, “Core [17] D. Farinacci, Y. Rekhter, P. Lothberg, H. Kilmer, and based trees (CBT): An architecture for scalable mul- J. Hall, “Multicast source discovery protocol ticast routing,” in Proc. ACM Sigcomm. September (MSDP).” IETF Internet draft, 1995, pp. 85–95. draft-farinacci-msdp-*.txt, June 1998. [5] J. Borland. “Net video not yet ready for prime time,” [18] W. Fenner. “Internet group management protocol, CNET News.com. February 5, 1999. version 2,” IETF Request for Comments 2236, No- http://www.news.com/News/Item/0,4,32033,00.ht vember 1997. ml. [19] R. Finlayson. “IP Multicast and Firewalls,” IETF [6] B. Cain. Nortel Networks. Private Communication. Internet drafts. draft-ietf-mboned-mcast-firewall- June 1999. *.txt. November 1998 [7] B. Cain. “ Source Access Control for Bi-directional [20] M. Handley. “The Address Allocation Protocol,“ Trees”. 41st IETF meeting. March 30-April 3, 1998; IETF Internet draft. draft-ietf-malloc-aap-*.txt. Los Angeles, CA, USA August 1998.

[8] B. Cain, S. Deering, and A. Thyagarajan, ``Internet [21] M. Handley, D. Thaler, D. Estrin. “The Internet Mu l-

group management protocol, version 3. IETF Inter- ticast Address Allocation Architecture,” IETF Inter- net draft, draft-ietf-idmr-igmp-v3-*.txt, February net draft. draft-handley-malloc-arch-*.ps Dec 1997. 1999. [22] H. Holbrook and D. Cheriton, “IP Multicast Cha n- [9] C. Diot and L. Gautier. “A Distributed Architecture nels: EXPRESS Support for Large-scale Single-source for Multiplayer Interactive Applications on the Applications,” Proc. ACM SIGCOMM 99, September Internet,” IEEE Network Magazine. July/August 1999. 1999. [23] Internet Assigned Numbers Authority. [10] S. Deering, R. Hinden, “, Version 6 http://www.isi.edu/in-notes/iana/ assign- (IPv6) Specification ,” IETF Request for Comments ments/multicast-addresses. (See also 2460, December 1998. http://www.isi.edu/in-notes/iana/assignments/ [11] S. Deering and D. Cheriton. “Multicast routing in single-source-multicast.) datagram inter-networks and extended LANs,” [24] K. Kumar, P. Radoslavov, D. Thaler, C. Alaettinoglu, ACM Transactions on Computer Systems, 8(2):85-110, D. Estrin, and M. Handley. “The MASC/BGMP a r- May 1990. chitecture for interdomain multicast routing,” In [12] S. Deering et al. “An architecture for wide-area mu l- Proc. ACM SIGCOMM 98, September 1998. ticast routing,” In Proc. ACM SIGCOMM'94, pp. 126– [25] B. N. Levine, J. Crowcroft, C. Diot, J. J. Garcia-Luna- 135, 1994. Aceves, and J. F. Kurose. “Consideration of Receiver [13] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, G. Interest in Content for IP Delivery,” Proc. IEEE Info- Liu, and L. Wei, “PIM architecture for wide-area com. April 2000. multicast routing,” IEEE/ACM Transactions on [26] B.N. Levine and J.J. Garcia-Luna-Aceves. “Impro v- Networking, pp. 153–162, Apr 1996. ing Internet Multicast with Routing Labels,” Proc. [14] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. IEEE International Conference on Network Protocols, Helmy, D. Meyer, and L. Wei, “Protocol indepen d- October 1997, pp. 241–50. ent multicast version 2 dense mode specification.” [27] Maestro BOF meeting minutes. 45th IETF Meeting. IETF Internet draft, draft-ietf-pim-v2-dm-*.txt, Oslo, . IDMR Working group. November 1998. http://www.ietf.org/proceedings/99jul/45th-99jul- [15] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. ietf-101.html. July 1999. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, [28] D. Massey and W. Fenner. RouteMonitor. Available and L. Wei, “Protocol independent multicast from http://ganef.cs.ucla.edu/~masseyd/Route sparse-mode (PIM-SM): Protocol specification.” [29] S. Mittra. “Iolus: A Framework for Scalable Secure Internet Engineering Task Force (IETF), RFC 2362, Multicasting,” In Proc. ACM SIGCOMM '97, Sep- June 1998. tember 1997. ACM. [16] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. [30] D. Meyer and P. Lothberg. “Static Allocations in Radoslavov, D. Thaler. “The Multicast Address Set 233/8,” Internet draft. draft-ietf-mboned-static- Claim (MASC) Protocol,” Internet draft. draft-ietf- allocation-*.txt May, 1999 malloc-masc-*.txt. August 1998. [31] J. Moy, “Multicast extensions to OSPF,” IETF R e- quest for Comments 1584, March 1994.

17 [32] B. Patel, M. Shah, and S. Hanna. “Multicast Address Dynamic Client Allocation Protocol” IETF Internet draft raft-ietf-malloc-madcap-*.txt. May 1999. [33] R. Perlman, C.-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, J. Thoo, M. Green. "Sim- ple Multicast: A Design for Simple, Low-Overhead Multicast". Internet draft. February 1999. [34] C. Shields and J.J. Garcia-Luna-Aceves, "KHIP - A

Scalable, Efficient Protocol for Secure Multicast

Routing". In Proc. of ACM Sigcomm 99. September 1999. [35] C. Shields and J.J. Garcia-Luna-Aceves, "HIP - A Protocol for Hierarchical Multicast Routing. In Pro- ceedings of the Seventeenth Annual ACM Sympo- sium on Principles of Distributed Computing, Puerto Vallarta, Mexico, June 1998. [36] C. Shields and J.J. Garcia-Luna-Aceves, "The Or- dered Core Based Tree Protocol", In Proceedings of the IEEE INFOCOM97, Kobe, Japan, April 1997. [37] J.F. Shoch. “Inter-networking Naming, Addressing & Routing,” In Proc. of IEEE COMPCON, Fall 1978, pp. 72–79. [38] T. Speakman, D. Farinacci, S. Lin, and A. Tweedly, “Pragmatic General multicast,” Internet draft, Jan u- ary 1998. [39] UUnet multicast information. http://www.uu.net/ lang.en/products/access/uucast/ [40] D. Waitzman, C. Partridge, and S. Deering. “Di s- tance vector multicast routing protocol,” IETF R e- quest for Comments 1075, November 1988. [41] L. Wei, and D. Farinacci, "Multicast Reachability Monitor (MRM)", Internet Engineering Task Force Internet Draft, October 1999. [42] C. Wong, M. Gouda, and S. Lam. “Secure Group Communications Using Key Graphs”. In Proc. ACM SIGCOMM’98. pp. 68–79. September 1998.

18