Internet Multicast Today - The Internet Protocol Journal ... · PDF fileThe Internet Protocol...

The Internet Protocol Journal - Volume 2, No. 4

Internet Multicast TodayInternet Multicast Todayby Mark Handley, ACIRI and Jon Crowcroft ,University College London

When you need to send data to many receivers simultaneously,you have two options: repeated transmission and broadcast.Repeated transmission may be acceptable if the cost is lowenough and delivery can be spread out over time, as with junk mailor electronic mailing lists. Otherwise, a broadcast solution isrequired. With real-time multimedia, repeated delivery is feasible,but only at great expense to the sender, who must invest in largeamounts of bandwidth. Similarly, traditional broadcast channelshave been very expensive if they cover significant numbers ofrecipients or large geographic areas. However, the Internet offersan alternative solution: IP multicast effectively turns the Internetinto a broadcast channel, but one that anyone can send to withouthaving to spend huge amounts of money on transmitters andgovernment licenses. It provides efficient, timely, and globalmany-to-many distribution of data, and as such may become thebroadcast medium of choice in the future.

The Internet is a datagram network, meaning that anyone cansend a packet to a destination without having to reestablish a path.Of course, the boxes along the way must have either precomputeda set of paths, or they must be relatively fast at calculating one asneeded, and typically, the former approach is used. However, thesending host need not be aware of or participate in the complexroute calculation; nor does it need to take part in a complexsignaling or call setup protocol. It simply addresses the packet tothe right place, and sends it. This procedure may be a morecomplex procedure if the sending or receiving systems need morethan the default performance that a path or network might offer, butit is the default model.

Adding multicast to the Internet does not alter the basic model. Asending host can still simply send, but now there is a new form ofaddress, the multicast or host group address. Unlike unicastaddresses, hosts can dynamically subscribe to multicastaddresses and by so doing cause multicast traffic to be deliveredto them. Thus the IP multicast service model can be summarized:

Senders send to a multicast addressReceivers express an interest in a multicast addressRouters conspire to deliver traffic from the senders to thereceivers

Sending multicast traffic is no different from sending unicast trafficexcept that the destination address is slightly special. However, toreceive multicast traffic, an interested host must tell its local routerthat it is interested in a particular multicast group address; the hostaccomplishes this task by using the Internet Group ManagementProtocol (IGMP).

Point-to-multipoint communication is nothing new. We are all usedto the idea of broadcast TV and radio, where a shared medium(the radio frequency [RF] spectrum) is partitioned among users(transmitter or TV/ radio station owners). It is a matter of regulationthat there is typically only one unique sender of particular contenton any given frequency, although other parts of the RF spectrumare given over to free use for multiparty communication (policeradio, citizen band radio, and so on).

The Internet multicast model [3] is very similar. The idea is toconvert the mesh wide-area network that is the Internet (whetherthe public Internet, a private enterprise net, or intranet makes nodifference to the model), into a shared resource for senders tosend to multiple participants, or groups.

To make this group communication work for large-scale systems inthe sense of a large number of recipients for a particular group, orin the sense of a large number of senders to a large number ofrecipients, or in the sense of a large number of different groups it isnecessary, both for senders and for the routing functions to supportdelivery, to have a system that can be largely independent of the

Home | Skip to Content | Skip to Navigation | Skip to Footer

Internet Multicast Today - The Internet Protocol Journal - Vo... http://www.cisco.com/web/about/ac123/ac147/ac174/ac198/a...

1 of 13 27/08/2009 15:40

particular recipients at any one time. In other words, just as a TV orradio station does not know who is listening when, an Internetmulticast sender does not know who might receive packets itsends. If this scenario sends out alarm bells about security, itshouldn't. A unicast sender has no assurance about who receivesits packets either. Assurances about disclosure (privacy) andauthenticity of sender/recipient are largely separate matters fromsimple packet delivery models. Security is a topic of muchresearch and the focus for the recently formed Internet ResearchTask Force (IRTF) research group, Secure Multicast Group(SMuG).

The Internet multicast model is an extension of the datagrammodel; it uses the fact that the datagram is a self-containedcommunications unit that not only conveys data from source todestination, but also conveys the source and destination addressinformation. In other words, in some senses, datagrams signaltheir own path, both with a source and a destination address inevery packet.

By adding a range of addresses dedicated for sending to groups,and providing independence between the address allocation andthe rights to send to a group, the analogy between RF spectrumand the Internet multicast space is maintained. Some mechanism,as yet unspecified, is used to dynamically choose which address tosend to. Suffice it to say that for now, the idea is that somehow,elsewhere, the address used for a multicast session or groupcommunication activity is chosen so that it does not clash withother uses or users, and is advertised to potential senders andreceivers.

Unlike the RF spectrum, an IP packet to be multicast carries aunique source identifier, in that such packets are sent with thenormal unicast IP address of the interface of the sending host.

It is also worth noting that an address that is being used to signifya group of entities must surely be a logical address (or in somesenses a name) rather than a topological or topographicalidentifier. We shall see that this means there must be some servicethat maps such a logical identifier to a specific set of locations inthe same way that a local unicast address must be mapped (orbound) to a specific location. In the multicast case, this mapping isdistributed. Note also that multicast Internet addresses are in somesense "host group" addresses, in that they indicate a set of hoststo deliver to. In the Internet model, there is a further level ofmultiplexing, that of transport level ports, and there is room forsome overlap of functionality, since a host may receive packetssent to multiple multicast addresses on the same port, or multipleports on the same multicast address.

This model raises numerous questions about address and groupmanagement, such as how these addresses are allocated. Thearea requiring most change, though, is in the domain of therouting. Somehow the routers must be able to build a distributiontree from the senders to all the receivers for each multicast group.The senders don't know who the receivers are (they just send theirdata), and the receivers don't know who the senders are (they justask for traffic destined for the group address), so the routers haveto do something without help from the hosts. We will examine thisscenario in detail in the section "Multicast Routing."

RoadmapThe functions that provide the Standard Internet Multicast Servicecan be separated into host and network components. The interfacebetween these components is provided by IP multicast addressingand IGMP group membership functions, as well as standard IPpacket transmission and reception. The network functions areprincipally concerned with multicast routing, while host functionsalso include higher-layer tasks such as the addition of reliabilityfacilities in a transport-layer protocol. That's the order in which wecover each of these functions in the rest of this article. At the endof the article we list the current status of Internet Engineering TaskForce (IETF) specification for the various components.

Host FunctionsAs we stated above, host functionality is extended through the useof the IGMP protocol. Hosts and routers, which we will look at later,must be able to deal with new forms of addresses. When IPVersion 4 addressing was first designed, it was divided into classesas shown in Figure 1.

Figure 1: Internet Address Classes


2 of 13 27/08/2009 15:40

*Note:Click above for larger view

Originally Class A was intended for large networks, B for midsizenetworks, and C for small networks. Class D was later allocated formulticast addresses. Since then, classless addressing has beenintroduced to solve Internet scaling problems, and the rules forClasses A, B, and C no longer hold, but Class D is still reserved formulticast, so all IPv4 multicast addresses start with the high-order4-bit "nibble": 1110

In other words, from the 2 32 possible addresses, 2 28 aremulticast, meaning that there can be up to about 270 milliondifferent groups, each with as many senders as can get unicastaddresses! This number is many orders of magnitude more thanthe RF spectrum allows for typical analog frequency allocations.

For a host to support multicast, the host service interface to IPmust be extended in three ways:

A host must be able to join a group, meaning that it must beable to reprogram its network level, and possibly,consequentially, the lower levels, to be able to receivepackets addressed to multicast group addresses.An application that has joined a multicast group and thensends to that group must be able to select whether it wantsthe host to loop-back the packets it sent so that it receivesits own packets.A host should be able to limit the scope with which multicastmessages are sent. The Internet Protocol contains aTime-To-Live (TTL) field, used originally to limit the lifetimeof packets on the network, both for safety of upper layers,and for prevention of traffic overload during temporaryrouting loops. It is used in multicast to limit how "far" apacket can go from the source. We will see below howscoping can interact with routing.

When an application tells the host networking software to join agroup, the host software checks to see if the host is a member ofthe group. If not, it makes a note of the fact, and sends out anIGMP membership report message. It also maps the IP address toa lower-level address and reprograms its network interface toaccept packets sent to that address. There is a refinement here: ahost can join "on an interface;" that is, hosts that have more thanone network card can decide which one (or more than one) theywish to receive multicast packets via. The implication of themulticast model is that it is "pervasive," so it is usually necessary tojoin on only one interface.

Taking a particular example to illustrate the IP-level to link-levelmapping process, if a host joins an IP multicast group using anEthernet interface, there is a mapping from the low 24 bits of themulticast address into the low 24 (out of 48) bits of the Ethernetaddress. Since this mapping is a many-to-one mapping, there maybe multiple IP multicast groups occupying the same Ethernetaddress on a given wire, though it may be made unlikely by theaddress allocation scheme. An Ethernet LAN is a shared-mediumnetwork, thus local addressing of packets to an Ethernet groupmeans that the packets are received by Ethernet hardware anddelivered to the host software of only those hosts with members ofthe relevant IP group. Therefore, host software is generally savedthe burden of filtering out irrelevant packets. Where there is anEthernet address clash, software can filter the packets efficiently.

Operation of the IGMP protocol can be summarized as follows:

When a host first joins a group, it programs its Ethernetinterface to accept the relevant traffic, and it sends an IGMPJoin message on its local network. This message informsany local routers that there is a receiver for this group nowon this subnet.


3 of 13 27/08/2009 15:40

The local routers remember this information, and arrangefor traffic destined for this address to be delivered to thesubnet.After a while, the routers wonder if there is still any memberon the subnet, and send an IGMP query message to themulticast group. If the host is still a member, it replies with anew message unless it hears someone else do so first.Multicast traffic continues to be delivered.Eventually the application finishes, and the host no longerwants the traffic. It reprograms its Ethernet interface toreject the traffic, but the packets are still sent until the routertimes the group out and sends a query to which no oneresponds. The router then stops delivering the traffic.

Thus joining a multicast group is quick, but leaving can be slowwith IGMP Version 1. IGMP Version 2 reduces the leave latency byintroducing a "Leave" message and a set of rules to prevent onereceiver from disconnecting others when it leaves. IGMP Version 3(not yet deployed) introduces the idea of source-specific joiningand leaving, whereby a host can subscribe (or reject) traffic fromindividual senders rather than the group as a whole, at theexpense of more complexity and extra state in routers.

Multicast RoutingGiven the multicast service model described above, and therestrictions that senders and receivers don't know each others'location or anything about the topology, how do routers conspire todeliver traffic from the senders to the receivers?

We shall assume that if a sender and a receiver did know abouteach other, they could each send unicast packets to the other. Inother words, there is a network with bi-directional paths and anunderlying unicast routing mechanism already running. Given thisnetwork, there is a spectrum of possible solutions. At one extreme,we can flood data from the sender to all possible receivers andhave the routers for networks where there are no receivers pruneoff their branches of the distribution tree. At the other extreme, wecan communicate information in a multicast routing protocolconveying the location of all the receivers to the routers on thepaths to all possible senders. Neither method is particularlydesirable on a global scale, so the most interesting solutions tendto be hybrid solutions that lie between these extremes.

In the real world, there are many different multicast routingprotocols, each with its own advantages and disadvantages. Weshall explain each of the common ones briefly, because a workingknowledge of their pros and cons helps us understand the practicallimits to the uses of multicast.

Flood and Prune ProtocolsFlood and Prune Protocols are more correctly known asreverse-path multicast algorithms. When a sender first startssending, traffic is flooded out through the network. A router mayreceive the traffic along multiple paths on different interfaces, inwhich case it rejects any packet that arrives on any interface otherthan the one it would use to send a unicast packet back to thesource. It then sends a copy of each packet out of each interfaceother than the one back to the source. In this way, each link in thewhole network is traversed at most once in each direction, and thedata is received by all routers in the network.

So far, this process describes reverse-path broadcast. Many partsof the network will be receiving traffic, even though there are noreceivers there. These routers know they have no receivers(otherwise IGMP would have told them) and they can then sendprune messages back toward the source to stop unnecessarytraffic from flowing. Thus the delivery tree is pruned back to theminimal tree that reaches all the receivers. The final distributiontree is what would be formed by the union of shortest paths fromeach receiver to the sender, so this type of distribution tree isknown as a shortest-path tree (strictly speaking, it's a reverseshortest path tree-typically the routers don't have enoughinformation to build a true forward shortest-path tree).

Two commonly used multicast routing protocols fall in the class:the Distance Vector Multicast Routing Protocol (DVMRP) [4] andProtocol Independent Multicast Dense-Mode (PIM-DM) [5]. Theprimary difference between these protocols is that DVMRPcomputes its own routing table to determine the best path back tothe source, whereas PIM DenseMode uses the routing table of theunderlying unicast routing system, hence the term "ProtocolIndependent."


4 of 13 27/08/2009 15:40

It should be fairly obvious that sending traffic everywhere andgetting people to tell you what they don't want is not a particularlyscalable mechanism. Sites get traffic they don't want (albeit verybriefly), and routers not on the delivery tree need to store prunestate. For example, if a group has one member in the UK and twoin France, routers in Australia still get some of the packets, andthey need to hold prune state to prevent more packets fromarriving! However, for groups where most places actually do havereceivers (receivers are "densely" distributed), this sort of protocolworks well. So although these protocols are poor choices for aglobal scheme, they might be appropriate within someorganizations.

MOSPFMulticast Open Shortest Path first (MOSPF [12]) isn't really acategory, but a specific instance of a protocol. MOSPF is themulticast extension to Open Shortest Path First (OSPF [11]), whichis a unicast link-state routing protocol.

Link-state routing protocols work by having each router send arouting message periodically listing its neighbors and how far awaythey are. These routing messages are flooded throughout theentire network, so every router can build up a map of the network.This map is then used to build forwarding tables (using a Dijkstraalgorithm) so that the router can decide quickly which is the correctnext hop for a particular packet.

Extending this concept to multicast is achieved simply by havingeach router also list in a routing message the groups for which ithas local receivers. Thus given the map and the locations of thereceivers, a router can also build a multicast forwarding table foreach group.

MOSPF also suffers from poor scaling. With flood-and-pruneprotocols, data traffic is an implicit message about where there aresenders, so routers need to store unwanted state where there areno receivers. With MOSPF, there are explicit messages aboutwhere all the receivers are, so routers need to store unwantedstate where there are no senders. However, both types of protocolbuild very efficient distribution trees.

Center-Based TreesRather than flooding the data everywhere, or flooding themembership information everywhere, algorithms in thecenter-based trees category map the multicast group address to aparticular unicast address of a router, and they build explicitdistribution trees centered around this particular router. Three mainproblems need to be solved to get this approach to work:

How is the mapping from group address to center addressperformed?How is the center location chosen so that the distributiontrees are efficient?How is the tree actually constructed given the centeraddress?

Different protocols have come up with different solutions to theseproblems. Three center-based tree protocols are worth exploringbecause they illustrate different approaches: Core-Based Trees(CBT), PIM Sparse-Mode (PIM-SM), and the Border GatewayMulticast Protocol (BGMP). However, we will leave discussion ofBGMP until our second article because it is not currently deployed.

Core-Based TreesCore-Based Trees (CBT [1] ) was the earliest center-based treeprotocol, and it is the simplest.

When a receiver joins a multicast group, its local CBT router looksup the multicast address and obtains the address of the Corerouter for the group. It then sends a Join message for the grouptoward the Core. At each router on the way to the Core, forwardingstate is instantiated for the group, and an acknowledgment is sentback to the previous router. In this way, a multicast tree is built, asshown in Figure 2.

Figure 2:Formation of a CBT Bi-directional shared Tree


5 of 13 27/08/2009 15:40


If a sender (that is, a group member) sends data to the group, thepackets reach its local router, which forwards them to any of itsneighbors that are on the multicast tree. Each router that receivesa packet forwards it out of all its interfaces that are on the treeexcept the one the packet came from. The style of tree CBT buildsis called a "bi-directional shared tree," because the routing state is"bi-directional"-packets can flow both up the tree toward the Coreand down the tree away from the Core, depending on the locationof the source, and packets are "shared" by all sources to thegroup. This scenario is in contrast to "unidirectional shared trees"built by PIM-SM as we shall see later.

IP multicast does not require senders to a group to be members ofthe group, so it is possible that a sender's local router is not on thetree. In this case, the packet is forwarded to the next hop towardthe Core. Eventually the packet will either reach a router that is onthe tree, or it will reach the Core, and it is then distributed along themulticast tree.

CBT also allows multiple Core routers to be specified, adding alittle redundancy in case the Core becomes unreachable. CBTnever properly solved the problem of how to map a group addressto the address of a Core. In addition, good Core placement is adifficult problem. Without good Core placement, CBT trees can bequite inefficient, and so CBT is unlikely to be used as a globalmulticast routing protocol.

However, within a limited domain, CBT is very efficient in terms ofthe amount of state that routers need to keep. Only routers on thedistribution tree for a group keep forwarding state for that group,and no router needs to keep information about any source; thusCBT scales much better than flood-and-prune protocols, especiallyfor sparse groups where only a small proportion of subnetworkshave members.

PIM Sparse-ModeThe work on CBT encouraged others to try to improve on itslimitations while keeping the good properties of shared trees, andPIM Sparse- Mode [7] was one result. The equivalent of a CBTCore is called a Rendezvous Point (RP) in PIM, but it largelyserves the same purpose.

When a sender starts sending, whether it is a member or not, itslocal router receives the packets and maps the group address tothe address of the RP. It then encapsulates each packet in anotherIP packet (imagine putting one letter inside another, differentlyaddressed, envelope) and sends it unicast directly to the RP.

When a receiver joins the group, its local router initiates a Joinmessage that travels hop-by-hop to the RP instantiating forwardingstate for the group. However, this state is unidirectional state-it canbe used only by packets flowing from the RP toward the receiver,and not for packets flowing back up the tree toward the RP. Datafrom senders is de-encapsulated at the RP and flows down theshared tree to all the receivers.

PIM-SM is an improvement on CBT in that discovery of sendersand and tree building from senders to receivers are separatefunctions. Thus PIM-SM unidirectional trees are not particularlygood distribution trees, but they do start data flowing to the


6 of 13 27/08/2009 15:40

receivers. Once this data is flowing, the local router of a receivercan then initiate a transfer from the shared tree to a shortest-pathtree by sending a source-specific Join message toward the source,as shown in Figure 3. When data starts to arrive along theshortest-path tree, a prune message can be sent back up theshared tree toward the source to avoid getting the traffic twice.

Figure3: Formation of a PIM Sparse-Mode Tree


Unlike other shortest-path tree protocols such as DVMRP andPIM-DM, where prune state exists everywhere there are noreceivers, with PIM-SM, source-specific state exists only on theshortest-path tree. Also, low-bandwidth sources such as thosesending Real-Time Control Protocol (RTCP) receiver reports donot trigger the transfer to a shortest-path tree, a scenario thatfurther helps scaling by eliminating unnecessary source-specificstate.

Because PIM-SM can optimize its distribution trees after formation,it is less critically dependent on the RP location than CBT is on theCore location. Hence the primary requirement for choosing an RPis load balancing. To perform multicast-group-to-RP mapping,PIM-SM redistributes a list of candidates to be RPs to all routers.When a router needs to perform this mapping, it uses a specialhash function to hash the group address into the list of candidateRPs to decide the actual RP to join.

Except in rare failure circumstances, all the routers within thedomain will perform the same hash, and come up with the samechoice of RP. The RP may or may not be in an optimal location, butthis situation is offset by the ability to switch to a shortest-path tree.

The dependence on this hash function and the requirement toachieve convergence on a list of candidate RPs does, however,limit the scaling of PIM-SM. As a result, it is also best deployedwithin a domain, although the size of such a domain may be quitelarge.

Interdomain Multicast RoutingAll the multicast routing schemes described so far suffer fromscaling problems of one form or another:

DVMRP and PIM-DM initially send data everywhere, andrequire routers to hold prune state to prevent this floodingfrom persisting.MOSPF requires all routers to know where all receivers are.PIM-SM needs redistribution of information about the set ofRPs. Because traffic needs to flow to the RP, an RP cannothandle too many groups simultaneously, so many RPs areneeded globally.

Thus each of these schemes is likely to be best deployed within adomain. How then does interdomain multicast routing take place?Long-term solutions to this problem will be discussed in the secondof these articles. In the meantime, the interim solution currentlybeing deployed consists of multiprotocol extensions to the unicastBorder Gateway Protocol (BGP) interdomain routing protocol, anda protocol called MSDP to glue PIM-SM domains together.


7 of 13 27/08/2009 15:40

Multiprotocol BGPFor either technical or policy reasons, not all routers or peeringsbetween Internet Service Providers (ISPs) are multicast capable.This situation complicates the use of PIM-SM for operationbetween domains because PIM assumes that the route obtainedby unicast routing is good for multicast routing (strictly speaking,PIM assumes the reverse unicast path is good for forward-pathmulticast routing). If, in fact, the reverse unicast path is not goodfor forward-path multicast, then Join messages will often reachrouters that do not support multicast, resulting in a lack of multicastconnectivity. How then do we solve this problem?

BGP is the unicast interdomain routing protocol that is very widelyused to connect unicast routing domains together. Themultiprotocol extensions to BGP allow multiple routing tables to bemaintained for different protocols. Thus with the MultiprotocolExtensions for BGP-4 (MBGP) [2], you can build one routing tablefor unicast-capable routes and one for multicast-capable routesusing the same protocol. PIM can then use the multicast-capableroutes to forward Join messages and can, therefore, detour aroundparts of the network that don't support multicast.

Multicast Source Discovery ProtocolIn addition to the problem of designing a scalable mechanism formapping multicast groups to RPs, attempts to use PIM-SM as aninterdomain protocol are hindered by ISPs' desire not to bedependent on other ISPs' facilities. For example, consider amulticast group consisting of senders and receivers in twodomains, A and B, run by two different ISPs. If the RP is in domainA, and there is some problem in domain A, then senders andreceivers in domain B might still be unable to communicate witheach other using multicast, even though they are in the samedomain, because initial PIM register messages must go via the RP.ISPs do not want to be dependent on other ISPs for connectivitywithin their own domain, so it appears that using PIM-SM as aninterdomain protocol would be unacceptable, even if there were noscalability problems.

The Multicast Source Discovery Protocol (MSDP) [8] is an attemptto work around this problem. It does not provide a long-termscalable solution, but does provide a solution that solves the ISPinterdependence problem.

With MSDP, ISPs run PIM-SM within their own domain, and theyhave their own set of RPs for all groups within that domain.Additionally, the RPs within the domain are interconnected witheach other and with RPs in neighboring domains using MSDPcontrol connections to form a loose mesh.

The process is shown in Figure 4. Within domain 1, R1 and R2send Join messages from group G to RP-1. Similarly, R3 and R4send Join messages to RP-2. When S starts sending, its packetsare encapsulated to RP-2 by its local router in the normal PIM-SMmanner. RP-2 decapsulates the packets and forwards them downthe group-shared tree within domain 2 to reach R3 and R4. Inaddition, it sends a Source Active message over the MSDP meshto all other RPs. RPs like RP-1 that have active joiners for thisgroup then send a source-specific Join back across theinterdomain boundary toward S. Traffic is then deliveredinterdomain following the source-specific state laid down by theJoin messages, and it is eventually delivered to R1 and R2.

Figure 4: MSDP in Operation


8 of 13 27/08/2009 15:40


MSDP uses the normal PIM-SM source-specific join mechanisminterdomain following the MBGP multicast routes back to thesource, but it sets up only a group-shared tree within each domain,avoiding the need to depend on remote RPs in different domainsfor the delivery of traffic between local members in a domain.

As an interdomain routing protocol, however, MSDP has manyshortcomings. In particular, every RP in every domain must be toldabout every source that starts sending, and a significant subset ofthe RPs must cache all this information so that receivers that joinlate can cause source-specific Joins to be sent by their local RP.Thus MSDP does not scale well if there are a large number ofsenders worldwide.

In addition, to ensure that the first few packets sent by a source donot get lost, they must be encapsulated and sent alongside theSource Active message to all the RPs that might possibly havereceivers. If they are not encapsulated, then sources that sendonly a few packets every few minutes might never get any datathrough to receivers because the source-specific state has timedout after each time they send.

In summary, MSDP is not a scalable long-term solution tointerdomain multicast routing. However, it does solve a realshort-term problem faced by ISPs, and so it is currently seeingsignificant deployment.

Multicast Address AllocationA local protocol for requesting multicast addresses from multicastaddress allocation servers has recently been standardized. Thisprotocol is called Multicast Address Dynamic Client AllocationProtocol , or MAD-CAP [10]. It is a relatively simple request-response protocol loosely modeled after the Dynamic HostConfiguration Protocol (DHCP) [6].

MADCAP is intended to be used with interdomain protocols thatperform dynamic allocation of parts of the multicast address spacebetween domains, but because these protocols are not yetdeployed, they will be discussed in the second of these articles.

As an interim solution for interdomain address allocation, a simplestatic mechanism has been defined. This mechanism involves


9 of 13 27/08/2009 15:40

embedding the Autonomous System (AS) number of the domainas the middle 16 bits of a multicast address. Thus the domain withAS number 16007 would get multicast addresses in the range233.64.7.0 to 233.64.7.255 (64 and 7 being the upper and lowerbytes, respectively, of 16007). Known as glop addressing , thismechanism is experimental. It may be superseded by a dynamicmechanism in the longer term.

Multicast ScopingWhen applications operate in the global Multicast backbone(MBone), it is clear that not all groups should have global scope.Not only is this constraint especially important for performancereasons with flood and prune multicast routing protocols, but it alsois true with other routing protocols for application security reasonsand because multicast addresses are a scarce resource. Beingable to constrain the scope of a session allows the same multicastaddress to be in use at more than one place as long as the scopesof the sessions do not overlap. This is analogous to the same radiofrequency being used by two radio stations operating far apart fromone another-each will only be heard locally.

Multicast scoping can currently be performed in two ways, knownas TTL Scoping and Administrative Scoping . Currently TTLscoping is most widely used, with only a very few sites making useof administrative scoping.

TTL ScopingWhen an IP packet is sent, an IP header field called Time To Live(TTL) is set to a value between zero and 255. Every time a routerforwards the packet, it decrements the TTL field in the packetheader, and if the value reaches zero, the packet is dropped. TheIP specification also states that the TTL should be decremented ifa packet is queued for more than a certain amount of time, but thisdecrement is rarely implemented these days. With unicast, the TTLis normally set to a fixed value by the sending host (64 and 255 arecommonly used) and is intended to prevent packets from loopingforever.

With IP multicast, the TTL field can be used to constrain how far amulticast packet can travel across the MBone by carefullychoosing the value put into packets as they are sent. However,because the relationship between hop count and suitable scoperegions is poor at best, the basic TTL mechanism is supplementedby configured thresholds on multicast tunnels and multicast-capable links. Where such a threshold is configured, the router willdecrement the TTL, as with unicast packets, but then will drop thepacket if the TTL is less than the configured threshold. When thesethresholds are chosen consistently at all of the borders to a region,they allow a host within that region to send traffic with a TTL lessthan the threshold, and to know that the traffic will not escape thatregion.

An example is the multicast tunnels and links to and from Europe,which are all configured with a TTL threshold of 64. Any site withinEurope that wishes to send traffic that does not escape Europecan send with a TTL of less than 64 and be sure that its traffic doesnot escape. However, there are also likely to be thresholdsconfigured within a particular scope zone-for example, mostEuropean countries use a threshold of 48 on international linkswithin Europe, and because TTL is still decremented each time thepacket is forwarded, it is good practice to send European trafficwith a TTL of 63, a scenario that allows the packet to travel 15hops before it would fail to cross a European international link.

Administrative ScopingIn some circumstances it is difficult to consistently choose TTLthresholds to perform the desired scoping. In particular, it isimpossible to configure overlapping scope regions as shown inFigure 5, and TTL scoping has numerous other problems, so morerecently, administrative scoping has been added to the multicastforwarding code in mrouted and in most router implementations.

Figure 5: Overlapping Scope Zones possible with AdministrativeScoping



10 of 13 27/08/2009 15:40

Administrative scoping allows the configuration of a boundary byspecifying a range of multicast addresses that will not beforwarded across that boundary in either direction.

Scoping DeploymentAdministrative scoping is much more flexible than TTL scoping, butit has many disadvantages. In particular, it is not possible to tellfrom the address of a packet where it will go unless all the scopezones that the sender is within are known. Also, becauseadministrative boundaries are bi-directional, one scope zonenested within or overlapping another must have totally separateaddress ranges. This makes address allocation difficult from anadministrative point of view, because the ranges ought to beallocated on a top-down basis (largest zone first) in a networkwhere there is no appropriate top-level allocation authority. Finally,it is easy to misconfigure a boundary by omitting or incorrectlyconfiguring one of the routers. With TTL scoping it is likely that inmany cases a more distant threshold will perform a similar task,lessening the consequences, but with administrative scoping, thereis less likelihood that this scenario will occur.

For these reasons, administrative scoping has been viewed bymany network administrators as a specialty solution to difficultconfiguration problems, rather than as a replacement for TTLscoping, and the Mbone still very much relies on TTL scoping.However, this situation is set to change as a protocol forautomatically discovering scope zones (and scope zonemisconfigurations) starts to be deployed. This protocol is called theMulticast Zone Announcement Protocol (MZAP) [9], and it willshortly become an IETF Proposed Standard. Eventually the use ofconfigured TTL scopes to restrict traffic will cease to be used as aprimary scoping mechanism.

SummaryIn this article we have looked at the various routing systems thatare used to devise delivery trees over which multimedia data canbe sent for the purposes of group communication, and at addressallocation and scoping mechanisms for this traffic.

After ten years of experimentation, IP multicast is not currently aubiquitous service on the public Internet, but significantdeployment has taken place on private intranets. The existingmulticast routing and address allocation mechanisms work well atthe scale of domains. However, as we have seen, there are stillsignificant technical problems concerning scaling to be overcomebefore multicast can be a ubiquitous interdomain service. Inaddition to the routing problems, we also still lack deployedcongestion control mechanisms for multicast traffic, which areessential if multicast applications are to be safely deployed.

Despite these issues, IP multicast still shows great promise formany applications. Solutions have been devised to many of theremaining problems, although they have not yet been deployed. Inthe second of these articles, we will look at the proposed solutionsfor scalable interdomain routing and address allocation. We willalso touch on multicast congestion control and the solutions thatare currently emerging from the research community.

Document StatusA list of IETF specifications for the protocols discussed in thisarticle is given below. We include the status for each document asof this writing (November 1999). For more information, check theIETF Web pages at www.ietf.org

References


11 of 13 27/08/2009 15:40

Ballardie, A., "Core Based Trees (CBT version 2) MulticastRouting," RFC 2189, September 1997.

1.

Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,"Multiprotocol Extensions for BGP-4," RFC 2283, February1998.

2.

Deering, S., "Host Extensions for IP Multicasting," RFC1112, August 1989.

3.

Deering, S., Partridge, C., and Waitzman, D., "DistanceVector Multicast Routing Protocol," RFC 1075, November1988.

4.

Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy,A., Meyer, D., and Wei, L., "Protocol Independent MulticastVersion 2 Dense Mode Specification," Internet Draft, work inprogress.

5.

Droms, R., "Dynamic Host Configuration Protocol," RFC1531, October 1993.

6.

Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,Handley, M., Jacobson, V., Liu, C., Sharma, P., and Wei, L.,"Protocol Independent Multicast-Sparse Mode (PIM-SM):Protocol Specification," RFC 2362, June 1998.

7.

Farinacci D. et al. "Multicast Source Discovery Protocol(MSDP)," Internet Draft, work in progress, June 1998.

8.

Handley, M., Thaler, D., and Kermode, R., "Multicast-ScopeZone Announcement Protocol (MZAP)," Internet Draft, workin progress.

9.

Hanna, S., Patel, M., and Shah, M., "Multicast AddressDynamic Client Allocation Protocol (MADCAP)," RFC 2730,December 1999.

10.

Moy, J., "OSPF Version 2," RFC 2328, April 1998.11.Moy, J., "Multicast Extensions to OSPF," RFC 1584, March1994.

12.

Miller, C. K., "Reliable Multicast Protocols and Applications,"The Internet Protocol Journal , Volume 1, No. 2, September1998.

13.

JON CROWCROFT is a professor of networked systems in theDepartment of Computer Science, University College London,where he is responsible for a number of European and U.S.funded research projects in Multimedia Communications. Hehas been working in these areas for over 18 years. Hegraduated in Physics from Trinity College, CambridgeUniversity, in 1979, and gained his MSc in Computing in 1981,and PhD in 1993. He is a member of the ACM, the BritishComputer Society, and is a Fellow of the IEE and a seniormember of the IEEE. He is a member of the InternetArchitecture Board (IAB) and was general chair for the ACMSIGCOMM from 1995 to 1999. He is also on the editorial teamfor the ACM/IEEE Transactions on Networks. With MarkHandley, he is the co-author of WWW: Beneath the Surf (UCLPress); he also authored Open Distributed Systems (UCLPress/Artech House), and with Mark Handley and IanWakeman, a third book, Internetworking Multimedia (MorganKaufmann Publishers), published in October 1999.E-mail: [email protected]

MARK HANDLEY received his BSc in Computer Science withElectrical Engineering from University College London in 1988and his PhD from UCL in 1997. For his PhD he studiedmulticast-based multimedia conferencing systems, and wastechnical director of the European Union funded MICE andMERCI multimedia conferencing projects. After two yearsworking for the University of Southern California's InformationSciences Institute,he moved to Berkeley to join the new AT&TCenter for Internet Research at ICSI (ACIRI). Most of his workis in the areas of scalable multimedia conferencing systems,reliable multicast protocols, multicast routing and addressallocation, and network simulation and visualization. He isco-chair of the IETF Multiparty Multimedia Session Controlworking group and the IRTF Reliable Multicast ResearchGroup. E-mail: [email protected][This article is based in part on material in InternetworkingMultimedia by Jon Crowcroft, Mark Handley, and Ian Wakeman,ISBN 1-55860-584-3, published by Morgan Kaufmann in 1999.Used with permission].


12 of 13 27/08/2009 15:40

Internet Multicast Today - The Internet Protocol Journal ... · PDF fileThe Internet Protocol...

Documents

Transcript of Internet Multicast Today - The Internet Protocol Journal ... · PDF fileThe Internet Protocol...