Multicast Deployment Made Easy

8/12/2019 Multicast Deployment Made Easy

1/20

Public

Copyright 1999 Cisco Systems, Inc. All Rights Reserved.

Page 1 of 20

D E S I G N IMPLEMENTATION

G

U I D E

Multicast Deployment Made Easy

I P M ul t icast Planning and D eployment Gu ide

Introduction

Purpose

Multicast M ade Ea sy is a comprehensive w orkbook and step-by-step planning guide for deploying IP multicast. This

guide will ease your deployment of IP multicast and assist yo u w ith purchasing decisions. IP multicast will help you proa ctively

manage network growth and control costs. Upgrading your network infrastructure to support IP multicast will enable your

organization to more quickly take advantage of multicast applications and minimize their impact on your network capacity and

response times.

Audience

This guide is designed to assist Internet Service Providers, Enterprise and small-to-medium b usiness netw ork engineers

Scope

Multicast Ma de Easy provides an o verview o f the multicast deployment planning phase and multicast ba sics, and d etails

specific solutions fo r d eploying native multicast.

Planning

Traffic Characteristics

Applications may use unicast, b road cast, o r multicast t ransmission fa cilities. When implementing multicast netw ork a pplications,

you need to understand the transmission facilities the application uses.

Unicast

In unicast, a pplications can send o ne copy of each packet to each m ember of the multicast group. Unicast is simple toimplement but diffi cult to scale if the group is large. Unicast applications also require extra band w idth, because the same

information has to be carried multiple times, even on shared links.

Figure 1 Unicast Transmission

Source

Network

MultipleUnicastStreams

A

B

C

D

E

T=1T=2

T=3

T=4

T=5

Unicast Transmissiongeneratesseparate copy of data to each recipient

Requires extra bandwidth Scalability restrictions for

large numbers of recipients


2/20

Public

Copyright 1999 Cisco Systems, Inc. All Rights Reserved.Page 2 of 20

Broadcast

Broadcast a pplications can send one copy of each packet and a ddress it to a broa dcast ad dress. Broa dcast is simpler

to implement tha n unicast, but it is more diffi cult to route, especially over a w ide area. The netwo rk must either stop broad casts

at the LAN bo undary (often done to prevent broa dcast storms) or send the broa dcast everywherea significa nt burden on

netwo rk resources if only a few users w ant to receive the packets. It is nearly impossible to send broa dcast pa ckets to members of

a m ulticast group that are not w ithin your enterprise network, such a s across the Internet. Broa dcast pa ckets must be processed

by each host o n the netwo rk, even those not interested in the dat a, w hich places a burden on t hose hosts.

Figure 2 Broadcast Transmission

M ulticast

In IP multicast, applications send one copy of a pa cket a nd a ddress it to a g roup of receivers (at the multicast address)

that w ant to receive it rather than t o a single receiver (for exa mple, at a unicast a ddress). Multicast depends on the netw ork to

forw ard t he packets to only those networks and ho sts that need to receive them, therefore controlling network tra ffi c and reducing

the amount of processing that hosts have to do. M ulticast applications are not limited by doma in bounda ries but can be used

throughout the entire Internet.

Figure 3 Basic Multicast Service

Source

Network

BroadcastStreams

T=1

T=2

T=3

T=4

T=5

Broadcast Transmissionforwardsdata packet to all portions of network

Wastes bandwidth when there arefew intended recipients

M ulticast Transmissionsendssingle multicast packet addressedto all intended recipients

Efficient communication andtransmission

Performance optimizations Enables truly distributed

applications


3/20

Public


Features of IP Multicast

The primary diff erence betw een multicast and unicast a pplicatio ns lies in the relatio nships between sender and receiver. There are

three general categories of multicast applications:

O ne to many, as when a single host sends to tw o or more receivers.

M any-to-one refers to a ny number of receivers sending da ta b ack to a (source) sender via unicast or multicast. This

implementation of multicast deals w ith response implosion t ypically involving tw o-way request/response applications w here

either end may generate the request.

M any-to-many, also called N-wa y multicast, consists of any number of hosts sending to the same multicast group address, as well

as receiving from it.

Table 1 M ulticast application examples

One-to-many are the most commo n multicast applications. The demand for many-to-many N-wa y is increasing w ith the

introduction o f useful collabo ration and videoconferencing tools. Included in this category a re audio-visual distribution,

Webcasting, caching, employee and customer training, a nnouncements, sales and ma rketing, information technology services and

human resource information. Multicast ma kes possible effi cient tra nsfer of large dat a fi les, purchasing information, stock catalo gs

and fi nancial ma nagement information. It also helps monitor real-time information retrieval as, for exa mple, stock price

fluctuatio ns, sensor dat a, security systems and manufa cturing.

For current informat ion a bout some multicast-capable a pplications a nd cont ent providers, see the Cisco Web site at http://

www.cisco.com (ask Web Design G roup fo r URL).

Benefits of IP Multicast

Table 2 Benefits

One to Many Many to One Many to Many

Database Updates Resource Discovery Multimedia Conferencing

Live Concerts Data Collection Synchronized Resources

Broadcasts Auctions Concurrent Processing

Newsfeeds Polling Collaboration

Push media Moderated Applications Distance Learning

Caching Chat groups

Announcements DistributedInteractive Simulations

Monitoring Multi-player Games

Lectures Interactive Music Sessions

Optimizes Internet performance

Saves bandwidth by enhancing network efficiency in distribution of data.

Supports distributed applications

Enables next generation multimedia applications such as distance learning and videoconferencing on the network in a scalable,reliable and efficient manner.

Reduces the cost to deploy applications

Reduces the cost of network resources by conserving bandwidth and server and network processing.

Increases productivity

Opens new ways to work through collaboration and conferencing, saving valuable travel time and money. Multicasting alsoenables the simultaneous delivery of information to many receivers, especially beneficial for delivering news and financialinformation.

Increases competitiveness

Increases competitiveness by extending market reach and opening new business and revenue opportunities. It allows bothEnterprises and ISPs to offer new services that are not feasible using unicast transport.

Eases scalability

Scales well as the number of participants and collaborations expand and greatly reduces the load on the sending server.

Increased application availability

Alleviates network congestion caused by existing applications that are inefficiently transmitting to groups of recipients, thusallowing more recipients simultaneous access to the application.


4/20

Public


Phasing

Cisco recommends a phased implementation a pproach, as w ith any new technology introduction. Begin with low -risk,

low -band w idth a pplications a nd establish a testbed on a selected subnet with mana gement visibility. Subsequently expand

deployment to the campus intranet, private WAN links, and fi nally to the Internet. Unicast islands can be upgraded to native IP

multicast as implementation progresses. It is not recommended to try to connect these islands w ith a ny kind of a tunnel. There is

little or no cost in confi guring IP multicast on a router if there is no application t raffi c to forw ard. Therefore, once you understand

how multicast works, it is best if you deploy it throughout your network.

Costs

In unicast, as yo u increase the number of clients, you linearly increase the netw ork ba ndw idth used and cost since you generate a

separat e copy of d ata to each recipient. The extra ba ndw idth required may be in excess of some of your communication links. This

means unicast do es not easily scale to large numbers of recipients. Broad cast transmissions forw ard dat a pa ckets to a ll portions of

the network w asting band w idth w hen there are few intended recipients.

Multicast t ransmission sends a single multicast packet ad dressed t o a ll recipients. It provides efficient communication and

transmission, o ptimizes performance, a nd enables truly distributed applications.

Example: Audio Streaming

All clients listening to the same 8 Kbps audio

Figure 4 Multicast Traffic Compared to Unicast Traffic

The cost of d eploying IP multicast as a Cisco customer is minimal. Since Cisco routers and t he Cisco IO S (Internetw orkO perating System) are already running, you only need to t urn on the multicast features in your softw are. IP multicast has been

supported in IO S by the PIM protocol since 10.2. Interdomain multicast is effi ciently supported in 11.1CC and 12.0 images. It is

recommended that you use 12.0 and later images if you are deploying PIM f or the fi rst time. To do w nload the most current image,

go t o the C isco C CO (Customer Connection O nline) Web page (ww w.C isco.com/cco).

Number of Clients

Traffic M bps

1 20 40 60 80 100

0

0. 2

0. 4

0. 6

0. 8 Multicast

Unicast


5/20

Public


Multicast is currently ava ilable across all Cisco IOS-based routing platfo rms including the follow ing:

Cisco 1003

Cisco 1004

Cisco 1005

Cisco 1600 series

Cisco 2500 series

Cisco 2600 series

Cisco 2800 series

Cisco 2900 series

Cisco 3600 series

Cisco 3800 series

Cisco 4000 series (Cisco 4000, 4000-M , 4500, 4500-M , 4700, 4700-M)

Cisco 7200 series

Cisco 7500 series

Cisco 12000

Time to Deploy

Once you have completed y our planning a nd read this guide, the time to t urn on t he commands a nd provide the service should beminimal (about 10 minutes per router). There is one global comma nd a nd o ne interface command that must be configured on each

router. In ad dition, one router should be identified a s the rendezvous point (RP) for your netw ork, w hich requires two confi guration

commands.


6/20

Public


IP Multicast Fundamentals

Deploying IP Multicast

Figure 5 Multicast-Enabled Network

To support IP multicast, the sending a nd receiving nod es, intermediate routers and the netwo rk infrastructure between them must

be multicast-enabled. In deploying IP multicast as a n end-to-end solution, yo u w ill need to consider the follow ing four a reas:

Addressing

You must have an IP multicast ad dress to communicate w ith a group of receivers rather than a single receiver, a nd yo u must have

a mechanism for ma pping this address onto MAC layer multicast addresses where they exist. End no de hosts must ha ve netw ork

interface cards (NICs) that effi ciently fi lter for LAN data link layer addresses w hich are mapped ba ck to the network lay er IP

multicast addresses.

IP a ddress space is divided into four sections-Cla sses A, B, C and D . The first three classes are used f or unicast tra ffi c. C lass D

add resses are reserved fo r multicast traf fi c and are alloca ted dyna mically. (See IP G roup Addressing below.)

Dynamic Host Registration

The end nod e host must have softw are supporting Internet G roup Ma nagement Protocol (IGM P-defined in RFC 2236) to

communicate requests to join a multicast group and receive multicast tra ffi c. IG M P specifies how the host should inform the

netwo rk that it is a member of a particular multicast group.

Internetwork

Multicast Routing

Network Network

Multicast Application(for example, videoconference, multicast file transfer)

Dynamic Host Registration

Addressing:source port and destination port, sender address(unicast)

and multicast receiver address

Source

MulticastApplication

UDPIP, IGMPTCP/IP

Protocol Stack

Network Driver

Network Interface

Receiver

Receiver MulticastApplication

UDPIP, IGMPTCP/IP

Protocol Stack

Network Driver

Network Interface


7/20

Public


Multicast Routing

The netw ork must be a ble to build packet distrib ution t rees tha t a llow sources to send packets to a ll receivers. These trees ensure

that only one copy o f a packet exists on any given netwo rk. There are several standard s for routing IP m ulticast traffi c. The

Cisco-recommended solution is Protocol Independent M ulticast (PIM), a multicast protocol tha t can be used w ith all unicast IP

routing protocols.

Multicast Applications

End node hosts must have IP multicast application softw are such as video conferencing and must be able to support IP multicast

tra nsmission a nd reception in the TC P/IP prot oco l stack.

IP Multicast Group Addressing

Unlike Class A, B, and C IP a ddresses, the last 28 b its of a Cla ss D a ddress have no structure. The multicast group add ress is the

combination of the high-order 4 bits of 1110 and t he multicast gro up ID. These are typically w ritten as dot ted-decimal numbers

and are in the range 224.0.0.0 through 239.255.255.255. Note that the high-order bits are 1110. If the bits in the first octet a re 0,

this yields the 224 portion of the add ress.

The set of hosts that responds to a particular IP multicast a ddress is called a host group. A host gro up can span m ultiple

netwo rks. Membership in a ho st group is dynamic-hosts can join and leave host groups. For a discussion of IP multicast registration,

see the section called Internet G roup Ma nagement Protocol.

Some multicast gro up addresses are assigned as well-know n ad dresses by the Internet Assigned Numbers Authority (IANA).

These multicast group ad dresses are called permanent host groups and are similar in concept to t he w ell-know n TCP a nd U DP port

numbers. Address 224.0.0.1 means all systems on this subnet, and 224.0.0.2 means all routers on this subnet. G roups in the

range of 224.0.0.xxx are alw ays sent with a TTL of 1. G roups in the range of 224.0.1.xxx are reserved for protocol operations and

sent wit h normal TTLs.

Table 3 Wel l-Know n Class D Addresses

The IANA ow ns a block o f Ethernet ad dresses that in h exad ecimal is 00:00:5e. This is the high-order 24 bits of th e Ethernet address,

meaning that this block includes addresses in the range 00:00:5e:00:00:00 to 00:00:5e:ff:ff:ff. The IANA allocates half of this block

for multicast a ddresses. G iven tha t the fi rst byte of any Ethernet a ddress must be 01 to specify a multicast add ress, the Ethernet

add resses corresponding to IP multicasting a re in the ra nge 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff.

Class D Address Purpose

224.0.0.1 All hosts on a subnet

224.0.0.2 All routers on a subnet

224.0.0.4 All DVMRP routers

224.0.0.5 All MOSPF routers

224.0.0.9 Routing Information Protocol (RIP)-Version 2

224.0.1.1 Network Time Protocol (NTP)

224.0.1.2 SGI Dogfight

224.0.1.7 Audio news

224.0.1.11 IETF audio

224.0.1.12 IETF video

224.0.0.13 Protocol Independent Multicasting


8/20

Public


This allocation a llows fo r 23 bits in the Ethernet a ddress to correspond to the IP multicast group ID . The mapping places the

low -order 23 bits of the multicast group ID into these 23 bits of the Ethernet a ddress, a s shown in Figure 6. Because the upper fi ve

bits of the multicast ad dress are ignored in this mapping, t he resulting add ress is not uniq ue. Thirty-tw o d ifferent multicast gro up

IDs ma p to each Ethernet address.

Figure 6 Multicast address mapping

Because the mapping is not unique a nd because the interface card might receive multicast f rames in w hich the host is really not

interested, t he device driver or IP mo dules must perform fi ltering. You should a lso consider this w hen choosing wha t multicast group

to ha ve your application send to. For instance, 225.0.0.1 is a valid IP multicast ad dress, but its M AC layer a ddress will be the same

as 224.0.0.1. This is also true for 224.128.0.1. If you use these addresses for your multicast application, you may have problems in

your network.

M ulticasting o n a single physical netw ork is simple. The sending process specifies a destinat ion IP a ddress tha t is a multicast

address, and the device driver converts this to the corresponding Ethernet address and sends it. The receiving processes must notify

their IP layers that they w ant to receive data grams destined fo r a given multicast add ress, and t he device driver must somehow

enable reception of these multicast frames. This process is handled by joining a multicast group.

When a host receives a multicast d ata gram, it must deliver a copy to all the processes that belong to that group. This is different

from UD P w here a single process receives an incoming unicast UD P da tagra m. With multicast, multiple processes on a given host

can belong to the same multicast group.

Co mplications a rise w hen multicasting is extended b eyond a single physical netw ork a nd multicast packets pass through

routers. A protocol is needed for routers to know if any hosts on a given physical netw ork belong to a given multicast group. The

Internet Group Management Protocol handles this function.

Internet Group Management Protocol

The Internet G roup M ana gement Pro tocol (IGM P) is an integral part of IP. It must be implemented by all hosts w ishing to receive

IP multicasts. IGM P is part of the IP layer and uses IP data grams (consisting of a 20-byte IP header and a n 8-byte IG RP m essage)

to tra nsmit information a bout multicast groups. IGM P messages are specified in the IP dat agra m w ith a proto col value of 2. Figure

7 shows the forma t of t he 8-byte IG M P message.

Figure 7 IGMP V2 Message Format

8-bit typeMaximumResponse

TimeChecksum Group Address

0 7 8 15 16 31 63


9/20

Public


The value of the type field is OX11 for a membership query sent by a router. The type value is 0X16 for a membership report sent

by the host and 0X17 for a leave request sent by the host. For ba ckwa rds compatibility to IG M PV1, 0X12 is reserved.

The value of the checksum field is calculated in the same way as the ICMP checksum. The group address is a class D IP address.

In a q uery, the group ad dress is set to 0, a nd in a report, it contains the group ad dress being reported.

The concept of a pro cess joining a multicast group on a given host interface is fundamental t o multicasting. M embership in a

multicast group on a given interface is dynamic (that is, it changes over time as processes join and leave the group). This means that

end users can dy namically join multicast groups based on the applications that they execute.

M ulticast routers use IG MP messages to keep track of group membership on each of t he netw orks that a re physically atta ched

to th e router. The follow ing rules apply :

A host sends an IG MP report w hen the first process joins a group. The report is sent out the same interface on which the process

joined t he group. No te that if other processes on the same host join the same group, the host do es not send a nother report.

In IG M P v2

1

a ho st w ill send an IG M P leave to the router if the host believes it w as the last one to send an IG MP host report. The

router then sends a gro up specific q uery to the group multicast add ress so that a ny hosts that still want to receive data for t he

group can prevent the router fro m pruning its interface.

A multicast router sends an IGM P q uery at regular intervals to see whether any hosts still have processes belonging to any groups.

The router sends a query out each interface. The group address in the query is 0 because the router expects one response from a

host for every group tha t conta ins one or more members on a host.

A host responds to an IG MP query by sending one IG MP report fo r each group that still contains at least one process. Since all

hosts on the netwo rk listen to t he IGM P reports being sent, if one host responds for a specific group, t he others on the LAN w ill

suppress sending the report .

Using queries and reports, a multicast router keeps a ta ble of its interfaces that ha ve at least one ho st in a multicast group. When

the router receives a multicast da tagra m to fo rw ard, it f orw ards the dat agra m (using the corresponding multicast O SI Layer 2

add ress) on only those interfaces that still have hosts w ith processes belonging to tha t group. The multicast da tagra m is forw arded

according to the Multicast routing protocol running on the router. IGMP does not determine how packets are forwarded.

The Time to Live (TTL) field in the IP hea der of r eports and queries is set to 1. A multica st da ta gra m w ith a TTL of 0 is

restricted to t he same host. By d efault, a multicast data gram w ith a TTL of 1 is restricted to t he same subnet. H igher TTL fi eld

values can b e forw arded b y the router. By increasing the TTL, an application can perform an expa nding ring search for a particular

server. The first multicast d at agr am is sent w ith a TTL of 1. If no response is received, a TTL of 2 is tried, a nd th en 3, and so on.

In this w ay, the a pplication locates the server that is closest in terms of hops.

The special range of addresses 224.0.0.0 through 224.0.0.255 is intended for applications that never need to multicast further

than o ne hop. A multicast router should never forwa rd a dat agra m w ith one of these addresses as the destination, regardless of the

TTL.

Multicast in the Layer 2 Switching Environment

It is clear t hat there is a w ell-defined mechanism for d istributing IP multicast tra ffi c in C isco routed environments thanks to the C lass

D add ressing scheme, IG M P, and PIM, but this mechanism is predicated on a d istributed layer 3 framew ork. With distributed layer

3 devices, there is a va riety o f lay er 3 mechanisms to cont rol IP multicast tra nsmissions. Simply disabling multicasting on a particular

router interface, for example, helps to cont ain a multicast transmission. Similarly, confi guring a pa rticular router interface to only

forw ard packets with a TTL abo ve a certain number can also help to conta in multicast transmission.

At some point, how ever, it is inevitable that t he IP multicast traf fi c w ill traverse a la yer 2 switch, especially in campus

environments. (See Figure 8.) And, as w e learned earlier, IP multicast tra ffi c maps to a correspond ing layer 2 multicast ad dress,

causing the traffi c to be delivered to all ports of a layer 2 switch.

1. In contrast, in IG MP version 1 the host do es not send a report w hen processes leave a group, even when the last process leaves a group. The host knows tha t thereare no members in a given group, so w hen it receives the next q uery, it do esnt report t o the gro up.


10/20

Public


Consider video server A and video client B in Figure 8. The video client wants to watch a 1.5-Mbps IP multicast-based video

feed coming fro m a corpo rat e video server. The process start s when the client sends an IG M P join message on the LAN w hich is

received by all routers on the LAN, w hich in turn uses PIM to add this LAN t o the PIM distribution tree. IP multicast traf fic is then

forw arded to the video client. The sw itch detects the incoming multicast traf fi c and examines the destination M AC ad dress to

determine w hich ports to forw ard the traffi c to. Since the destination M AC ad dress is a multicast add ress and there are no entries

in the switching tab le for w here the traffi c should go, the 1.5-M bit video feed is simply sent to all ports, clearly an inefficient strategy.

Figure 8 IP Multicast Traffic in Layer 2 Environments

Cisco Group Management Protocol (CGMP)

Cisco G roup Ma nagement Protocol (CG M P) is a C isco-developed protocol that allow s Cata lyst sw itches to leverage IGM P

informat ion on C isco routers to ma ke layer 2 forw arding d ecisions. The net result is that w ith CG MP, IP multicast traffi c is delivered

only to those Cat alyst switch ports tha t are interested in the traffi c. All other ports that ha ve not explicitly requested the traffi c will

not receive it.

It is important to note here that the CGMP operation will not adversely affect layer 2 forwarding performance. Unlike other

solutions that instruct the sw itch to snoop layer 3 information a t the port level, C G M P preserves layer 2 sw itch operation. As a

result, the C ata lyst 5000, for example, can deliver multicast tra ffi c at one million packets per second.

Figures 9 through 11 depict the CG M P process between a C isco 7505 router and a Ca talyst 5000 switch. This time, w hen the

last hop router receives the IG M P join message, it records the source MAC add ress of t he sender and issues a C G MP join message

to the C ata lyst 5000 switch. The Ca talyst 5000 switch uses the CG MP message to dyna mically build an entry in the sw itching table

that maps the multicast tra ffi c to the switch port of the client. No w the 1.5-Mb ps video feed will be delivered only t o tho se switch

ports that a re in the switching tab le, sparing other ports that d ont need the dat a.

Figure 9 IP Multicast Traffic in CGMP Environments: IGMP J oin Message


11/20

Public


Figure 10 IP Multicast Traffic in CGMP Environments: CGMP J oin Message

Figure 11 IP Multicast Traffic in CGMP Environments: Traffic Flow after CGMP J oin

Although the example wa s based on a single sw itch design, CG M P also w orks in cascaded-sw itched design. Co nsider the design in

Figure 12, w hich comprises a set o f C ata lyst 5000s, a ll behind a single router interface.

Figure 12 Cascaded Switch Architecture

Without C G MP, multicast traffi c is flood ed to the entire layer 2-switch fa bric. The upstream router prevents the multicast tra ffi c

from hitting the campus backbone, but do es nothing to co ntrol the traffi c in the sw itch fabric. With C G MP, how ever, the multicast

traffi c can be controlled, not only in the Ca talyst 5000 sw itch directly connected to the router, but also in the downstream C ata lyst

switches. Figure 13 depicts CG M P operation in a cascaded layer 2-switch fa bric.


12/20

Public


Figure 13 CGMP in a Cascaded Switch Architecture

It is clear t hat IP multicasting and la yer 2 switching are valua ble technologies for providing a scalab le fabric for client and server

connectivity. How ever, w ithout any mechanism to effi ciently hand le multicast traffi c, the layer 2 sw itch has to deliver the traffi c to

all port s. Cisco has eliminated such ineffi ciencies w ith CG M P, an industry-leading solutio n that ensures the successful deployment

of high performance layer 2 switching a nd IP multicasting together in the enterprise.

IGMP Snooping

H igh performa nce switches can use anot her method to constra in the floo ding of multicast traffi c, IGM P Snooping. IGM P Snooping

requires the LAN sw itch to examine, or snoop, some layer 3 informat ion in the IGM P packet sent from t he host to the router.

When the switch hears an IG MP Report from a host for a particular multicast group, the sw itch adds the hosts port number to the

associated multicast table entry. When it hears an IG MP Leave Gro up message from a host, it removes the hosts port from the table

entry.

On the surface, this seems like a simple solution to put into practice. However, depending on the architecture of the switch,

implementing IGM P Snooping may be diffi cult to a ccomplish witho ut seriously degrading the performance of the switch. The CP U

must examine every multicast frame passing through the switch just to fi nd a n occasional IG MP packet. This results in performance

degrada tion to the switch and in extreme cases switch fa ilure. Unfo rtunately, many low -cost, Layer-2 switches that ha ve

implemented IG M P snooping rather than C G MP suffer from this problem. The sw itch may perform IG MP Snooping just fine in a

limited d emo environment, but w hen the buyer puts it into production netw orks with high-band w idth multicast streams, it melts

dow n under load.

The only viable solution to this problem is a high-performa nce sw itch designed wit h special ASICs that ca n examine the layer-3

portion o f all multicast packets at line-rate to determine whether or not they are IG M P packets.

Distribution Trees

IP multicast traffi c flow s from the source to the multicast group over a distribution tree that connects all of the sources to all of the

receivers in the group. This tree may be shared by all sources (a shared-tree), or a separate distribution tree can be built for each

source (a source-tree). The shared-tree may b e one-w ay or b idirectiona l.

Applications send one copy of each packet using a multicast a ddress, and the network f orw ards the packets to only tho se

networks, LANs, that have receivers.


13/20

Public


Source trees are construct ed w ith a single path betw een the source and every LAN tha t ha s receivers. Shared-trees are

constructed so that all sources use a common distribution tree. Shared-trees use a single location in t he network to w hich all packets

from a ll sources are sent a nd fro m w hich all packets are sent to all receivers.

These trees are loop-free. Messages are replicated only when the tree branches.

M embers of multicast groups can join or leave at a ny time, so the distribution tree must be dynamically updat ed. Branches with

no listeners are discard ed (pruned). The type of distribut ion tree used an d the w ay multicast ro uters interact depend on t he objectives

of the routing prot ocol, including receiver distribution, number o f sources, reliability of dat a delivery, speed of netwo rk

convergence, shared-path o r source path, a nd if shared path, d irection of dat a fl ow.

Tree Structure

Distribution trees may be formed as either source-based trees or shared trees. Source-based distribution trees build an optimal

shortest-path tree rooted at the source. Each source/group pair req uires its ow n state informa tion, so f or gro ups with a very la rge

number of sources, or netw orks that ha ve a very large number of groups w ith a la rge number of sources in each group, the use of

source-based trees can stress the storage capability of routers.

Shared distribution trees are formed aro und a central router, called a rendezvous point or core, from w hich all traffi c is

distributed regardless of t he location of the traffi c sources. The adva ntage of shared distribution trees is that they do not create lots

of source/group sta te in the routers. The disadva nta ge is tha t the pat h from a part icular source to th e receivers may b e much longer,

w hich may be important for d elay-sensitive applications. The rendezvous router may also be a traffi c bott leneck if there are manyhigh dat a ra te sources.

Figure 14 Source Trees and Shared Trees

Distribution of Receivers

One criterion to determine w hat type of tree to use relates to w hether receivers are sparsely o r densely d istributed througho ut the

netwo rk (for example, whether almost all of the routers in the netwo rk have group members on their directly a tta ched

subnetw orks). If the netw ork ha s receivers or members on every subnet or t he receivers are closely spaced, t hey have a d ense

distribution. If the receivers are on o nly a few subnets and are w idely spaced, they ha ve a sparse distribution. The number of

receivers does not matter; the determining factor is how close the receivers are to each other and the source.

Source

Receiver

Source Tree(shortestpath tree)

Shared Treefrom RP

Router A Router B

Router C RP


14/20

Public


Sparse-mode protocols use explicit join messages to set up distribution trees so that tree state is set up only on routers on the

distribution tree and d ata packets are forw arded to only those LANs that have hosts who join the group. Sparse-mode protocols

are thus also appropriate for large internetworks where dense-mode protocols would waste bandwidth by flooding packets to all

parts the internetwork and then pruning back unw anted co nnections. Sparse-mode proto cols may build either shared trees or source

trees or both types of distribution trees. Sparse-mode protocols may be best compared to a magazine subscription since the

distribut ion t ree is never built unless a receiver joins (subscribes) to the gro up.

Dense mode protocols build only source-distribution trees. Dense mode protocols determine the location of receivers by

flo oding da ta t hroughout your netw ork and then explicitly pruning off bra nches that do no t have receivers therefore creating

distribution state on every router in your netw ork. D ense mode protocols may use fewer control messages to set up state than

sparse-mode proto cols, and they ma y be able to better guarantee delivery of dat a t o a t least some group members in the event of

some netw ork fa ilures. Dense mode protoco ls may be compared to junk mail in that every netw ork w ill receive a copy of the data

w hether they w ant it or not.

IP Multicast Routing Protocols

In addition, there are several multicast routing protocols including Protocol Independent Multicast (PIM), Core Based Trees (CBT),

and Multicast O pen Shortest Path First (M OSPF).

Protocol Independent Multicast (PIM)

PIM can support bot h dense mode and sparse mode groups. Prot ocol Independent M ulticast (PIM ) can service both shared trees

and shortest pa th trees. PIM can a lso support b i-directional trees. PIM is being enhanced to support explicit joining to w ard sources

so that once an a lternative method of d iscovering sources is defined, PIM w ill be able to take ad vanta ge of it. PIM -SM (Sparse

M ode) Version 2 is an IETF standa rd: R FC # 2362. PIM-DM (Dense Mo de) is an IETF draf t.

PIM uses any unicast routing proto col to build the da ta d istribution trees. PIM is the only multicast routing proto col deployed

on the Internet to d istribute multicast da ta na tively and not over a b andw idth-limited, tunneled topology.

Protocol Independent Multicast-Sparse Mode (PIM-SM)

PIM Sparse Mode can be used fo r any combination of sources and receivers, w hether densely or sparsely populated, including

topo logies where senders and receivers are separa ted by WAN links, and/or w hen the stream o f multica st traf fi c is intermittent .

I ndependent of unicast rou ting pr otocols

PIM can be deployed in conjunction w ith any unicast routing protoco l.

Explicit-join

PIM-SM a ssumes that no hosts w ant the multicast tra ffi c unless they specifica lly ask for it. It creates a shared

distribution tree centered on a defined rendezvous point (RP) from w hich source traffi c is relayed to the receivers. Senders first

send the data to the RP, and the receivers last-hop router sends a join message toward the RP (explicit join).

Scalable

PIM-SM scales well to a netw ork of any size including those with WAN links. PIM -SM do mains can be efficiently and

easily connected together using M BG P a nd M SDP to pro vide native multicast service over the Internet.

Flexible

A receivers last-hop router can sw itch fro m a PIM -SM sha red tree to a source-tree or shortest-pat h distributio n tree

whenever conditions warrant it, thus combining the best features of explicit-join, shared-tree and source-tree protocols.

Protocol Independent Multicast-Dense Mode (PIM-DM)

PIM dense mode (PIM-DM ) initially floo ds all branches of the netw ork w ith dat a, then prunes branches with no multicast

group members. PIM-DM is most effective in environments where it is likely that there will be a group member on each subnet.

PIM -DM assumes that the multicast group members are densely distributed throughout the netwo rk and t hat ba ndw idth is

plentiful.

PIM-DM creates source-based shortest-path distribution trees; it ca nnot be used t o b uild a shared distribution tree.


15/20

Public


Figure 15 PIM-Dense Mode

Protocol Dependent Multicast Choices

Protoco l D ependent M ulticast, in contrast to PIM, requires building routing tab les that support either distance vector (e.g., Distance

Vector Multicast Ro uting Protoco l, DVM RP) or link-state (e.g., M ulticast Open Shortest Pa th First, M OSPF) routing algorithms.

D istance Vector M ulticast Routing Protocol (DVM RP)

DVMRP was the first multicast routing protocol developed. DVMRP

must calculate and exchange its ow n RIP-like routing metrics so it canno t ta ke advant age of the enhancements and capa bilities of

adva nced routing pro tocols such as O SPF, IS-IS and EIG RP. It is dense-mode and so must floo d da ta throughout t he netw ork and

then prune of branches so that state for every source is created on every router in y our netw ork.

M ulti cast O pen Short est Path Fir st (M O SPF)

MO SPF is an extension to the O SPF unicast routing protocol. O SPF works by

having each router in a netw ork understand a ll of the ava ilable links in the netw ork. Each O SPF router calculates routes from

itself to all possible destinations. M OSPF w orks by including multicast informat ion in O SPF link-state ad vertisements so tha t a n

M OSPF router learns w hich multicast groups are active on w hich LANs. M OSPF builds a distribution tree for each source/group

pair a nd computes a tree for a ctive sources sending t o the group. The tree stat e must be recomputed w henever link state change

occurs. If there are many sources and/or ma ny gro ups, this calculation, called the D ijkstra a lgorithm, must be recomputed fo r

every source/group co mbina tion w hich can be very CP U intensive.

MO SPF incorporat es the scalability benefi ts of O SPF but can only run o ver OSPF routing doma ins. It is best used w hen relatively

few source/group pairs a re active at any given time, since all routers must build each distribution tree. It do es not w ork w ell w here

unstable links exist. It can b e deployed gra dually since MOSPF routers can be combined in the same routing do main w ith

non-multicast OSPF routers. It is not w idely implemented a nd d oes not support tunneling.

O ther Protocols

Oth er proto cols exist tha t ar e designed fo r research purpo ses, such as C ore Ba sed Trees (CBT), Simple

M ulticast, Express Multicast, etc. CBT and Simple Multicast, a variation of C BT, support only shared trees.

EXPR ESS supports source trees only a nd must be implemented on every ho st to initiat e construction of the dat a path. EX PRESS

assumes that receivers will learn about receivers via some mechanism outside of the EXPRESS protocol. EXPRESS does not use

IGMP.

Reverse Path Forwarding (RPF)

Reverse Path Forwarding (RPF) is an algorithm used for forwarding multicast datagrams. The algorithm works as follows:

The packet ha s arrived on the RPF interface if a ro uter receives it on a n interface that it uses to send unicast packets to the source.


16/20

Public


If the packet arrives on the RPF interface, the router forwa rds it out the interfaces that a re present in the outgoing interface list

of a multicast routing table entry.

If the packet does not a rrive on the RPF interface, the packet is silently discarded to avoid loo p-backs.

If a PIM router has source tree state, it does the RPF check using the source IP add ress of the multicast packet. If a PIM router has

shared t ree sta te, it uses the RPF check on th e rendezvous points (RP ) address (which is know n w hen members join the gro up).

Sparse-mod e PIM uses the RPF loo kup function t o determine w here it needs to send Jo ins and Prun es. Shared-tree sta te joinsare sent towards the RP. Source-tree state joins are sent towards the source.

D ense-mode D VMR P and PIM groups use only source-rooted trees and ma ke use of RP F forw arding a s described a bove.

M OSPF do es not necessarily use RPF since it can compute bo th fo rw ard and reverse shortest path source-rooted trees by using the

Dijkstra computation.

Interdomain Multicast Routing

Multicast Border Gateway Protocol

M ulticast Border Ga tewa y Proto col (M BG P) offers a method fo r providers to distinguish w hich prefi xes they w ill use for performing

multicast reverse path fo rw arding (RPF) checks. The RPF check is fundamental in establishing multicast forw arding trees and

moving multicast content successfully from source to receiver(s).

MB G P is based on R FC 2283, Multiprotocol Extensions for BG P-4. This brings along all of t he administrative machinery tha t

providers and customers like in their inter-domain routing environment. Examples include all of the AS machinery and the tools to

operate on it (e.g., route ma ps). Therefore, by using MBG P, a ny netw ork utilizing internal o r external BG P can apply the multiple

policy control knobs familiar in BG P to specify routing (and therefore forw arding) policy for multicast.

Tw o path a ttributes, MP _REACH _NLR I and M P_UNR EACH _NLR I, are introduced to yield BG P4+ as described in Internet

D raft draf t-ietf-idr-bgp4-multiprotocol-01.txt. M BG P is a simple w ay to ca rry tw o sets of routes-one set for unicast routing and

one set fo r multicast routing. The routes associated w ith multicast routing are used by the multicast routing prot ocols to b uild dat a

distribution trees.

The advant ages are that an internet can support non-congruent unicast and multicast topologies and, w hen the unicast and

multicast topologies are congruent, can support d iffering policies. M BG P provides for scalable policy-based inter-doma in routing

that can be used to support non-congruent unicast and multicast forw arding pat hs.

Multicast Source Discovery Protocol

M ulticast Source Discovery Proto col (M SDP) is a mechanism to connect PIM-SM doma ins to enable forw arding of multicast traffi c

between doma ins while allow ing each doma in to use its own independent rendezvous points (RPs) and not rely on RPs in ot her

domains.

The RP in each do main establishes an M SDP peering session using a TCP connection w ith the RPs in other do mains or w ith

border routers leading to the other doma ins. When the RP learns about a new multicast source within its ow n doma in (through the

normal PIM register mechanism), the RP encapsulates the first data packet in a Session Advertisement (SA) and sends the SA to all

MSDP peers. The SA is forwarded by each receiving peer using a modified RPF check, until it reaches every MSDP router in the

internet. If the MSD P peer is an R P, a nd the R P ha s a (*,G ) entry fo r the group in the SA, the RP w ill create (S,G) state for the source

and join to the shortest path for the source. The encapsulated packet is decapsulated a nd fo rw arded d ow n tha t RP s shared-tree.

When the packet is received by a receivers last hop router, the last-hop may also join the shortest path to the source. The sources

RP periodically sends SAs w hich include all sources within tha t R Ps ow n doma in.

MSD P peers may be confi gured to cache SAs to reduce join latency w hen a new receiver joins a group w ithin the cache.


17/20

Public


Reliable Multicast-Pragmatic General Multicast

Reliable multicast protoco ls overcome the limitations of unreliable multicast da tagra m delivery a nd expand the use of IP multicast.

IP multicast is based on UD P in w hich no a cknow ledgments are returned to t he sender. The sender therefore do es not know if the

dat a it sends are being received, a nd t he receiver cannot request tha t lost o r corrupted packets be retransmitted. M ultimedia audio

and video applications generally d o no t require reliable multicast, since these transmissions are tolerant o f a low level of loss.

H ow ever, some multicast applicat ions require reliable delivery.

Some elements that a re relevant to d eciding w hether reliab le multicast is applica ble include the degree of reliab ility required,

requirements for ba ndw idth a nd fo r ord ered pa cket delivery, the burstiness of d ata , delay tolerance, timing (real-time vs.

non-real-time), the network infrastructure (LAN, WAN, Internet, satellite, dial-up), heterogeneity of links in the distribution tree,

router capab ilities, number of senders and size of multicast group, scalab ility, a nd gro up setup protocol.

Cisco currently delivers Pragma tic G eneral M ulticast (PG M) as the reliable multicast solution. Implementation of PG M uses

negative-acknow ledgments to provide a reliable multicast tra nsport for applications that require ordered, duplicate-free, multicast

da ta d elivery fro m multiple sources to multiple receivers. PG M gua ran tees tha t a receiver in the group either receives all da ta pa ckets

from t ransmissions and retransmissions, or is able to d etect unrecoverable da ta packet loss. PG M is specifica lly intended a s a

w orkable solution for multicast applications w ith ba sic reliability requirements. Its central design goa l is simplicity of operation

with due regard for scalability and network efficiency.

Reliable multicast w ill be useful in areas w here loss is not tolerated o r w here a high-degree of fi delity is required, a s for exa mple,

in such areas as bulk da ta transfer, inventory updates, fi nancial stock q uotes, data conferencing, hybrid broa dcasting (Whiteboard),

softw are d istribution, push (Webserver content), da ta replication, caching, a nd distributed simulation. Reliable multicast

applications are also freq uently deployed over satellite networks w ith terrestrial (e.g., Internet) back channels.

Appendix A: References

IETF Documents http://www.ietf.org

Internet G roup Ma nagement Protocol, Version 2 (RFC 2236); W Fenner; November 1997.

Proto col Independent Multicast Sparse Mo de (PIM-SM) Version 2 (IETF stand ard: RFC # 2362). D . Estrin, D. Farinacci, A.

Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, June 1998.

Pro toco l Independent M ulticast Dense M ode (PIM-DM ) Version 2 (IETF dra ft. htt p://w w w.ietf. org/internet-draft s/

dra ft-ietf-pim-v2-dm-02.txt ). PIM Working G roup of th e IETF; S. Deering, D. Estrin, D . Farina cci, V. Jaco bson, A. Helmy, D.

Meyer, L. Wei; May 1999.

IG MP Multicast R outer D iscovery (draft-ietf-idmr-igmp-mrdisc-01.txt); S. Biswa s, B. C ain (Nortel N etwo rks); Feb. 1999 (expires

Aug. 1999).

MO SPF: Analysis and Experience, Informational RFC 1585, J. M oy, March 1994.

M ulticast Source D iscovery Proto col (MSDP) (draft-farinacci-msdp-00.txt); D. Farinacci, Y. R ekhter (Cisco); P. Lothberg (Sprint);

H . Kilmer (D igex); J. H all (UUnet); June 1998.

PG M Reliable Transport Pro tocol Specifications (draft -speakman-pgm-spec-02.txt); T. Speakman, D. Farinacci, S. Lin, A.

Tw eedly; Aug. 1998.

IP M ulticast Applications: C hallenges and Solutions (draft-quinn-multicast-apps.00.txt); B. Quinn; N ov. 1998

Cisco sites

Product information, job opportunities, softw are images: cco.Cisco.com, or http://www.cisco.com

Understanding IP Multicast:

http://www.cisco.com/warp/public/732/multicast

Customer Support Mailing List: [email protected]

EFT/Beta Site Web Page: ftp://ftpeng.cisco.com/ipmulticast.html

EFT/Beta Ma iling List: [email protected]

IP Multicast Confi guration Examples:

ftp://ftpeng.cisco.com/ipmulticast/config_examples.html

Auto-RP guide: ftp://ftpeng.cisco.com/ftp/ipmulticast/autorp.html


18/20

Public


More Information

IP Multicast Initiative: http://www.ipmulticast.com

Annual IP Multicast Summit: http://www.ipmulticast.com/events/summit99

Ma naging IP M ulticast Traffi c: A First Look at the Issues, Tools, and C hallenges; White Paper from the IP Multicast Initiative

(IPM I) and Sta rdust Forums for the 3rd Annual IP Multicast Summit; Feb. 1999. http://www.ipmulticast.com/events/

summit99.whitepaper.htm

Implementing IP Multicast in Different Netwo rk Infrastructures, An IP M ulticast Initiative White Paper; Stard ust Forums, Inc.;

V. Johnson, M . Johnson, K . M iller; 1997. http://www.ipmulticast.com/community/whitepapers/netinfra.html

H ow IP Multicast Works, An IP Multicast Initiative White Paper; Stardust Forums, Inc.; 1996. http://

www.ipmulticast.com/community/whitepapers/howipmcworks.html

Introduction to IP M ulticast Routing, An IP Multicast Initiative White Paper; Stardust Forums, Inc.; 1997. http://

www.ipmulticast.com/community/whitepapers/backgrounder.html

IP Multicast Deployment Guide, IP Multicast Initiative, V. Johnson, M. Johnson; N ovember 1998. http://

www.ipmulticast.com/deployment_guide.htm

Appendix B: Acronyms

Acronym Meaning

ATM

Asynchronous Transfer Mode

Auto-RP

Auto-Rendezvous Point

BGP

Border Gateway Protocol

BSR

Bootstrap Router

CBT

Core Based Tree

CCO

Cisco Connection Online (www.cisco.com)

CGMP

Cisco Group Management Protocol

DM

Dense Mode

DVMRP

Distance Vector Multicast Routing Protocol

EFT

Early Feature Testing

GRE Generic Routing Encapsulation

IANA

Internet Assigned Numbers Authority

ICMP

Internet Control Message Protocol

ID

Identification

IETF

Internet Engineering Task Force

IGMP

Internet Group Management Protocol

IGRP Interior Gateway Routing Protocol

IP Internet Protocol

IP/TV Internet Protocol Television

ISP Internet Service Provider

LAN Local Area Network

MBGP Multicast Border Gateway Protocol


19/20

Public


MBONE Multicast Backbone

MOSPF Multicast Open Shortest Path First

MRM Multicast Route Monitor

MSDP Multicast Source Discovery Protocol

NIC Network Interface Card

OSI Open System Interconnection

OSPF Open Shortest Path First

PGM Pragmatic General Multicast

PIM Protocol Independent Multicast

PIMv2 PIM version 2

Pkt Packet

RFC Request For Comments

RP Rendezvous Point

RPF Reverse Path Forwarding

RTP Routing Table Protocol

SA (message) Session Announcement

SM Sparse Mode

SMS Systems Integrator and Reseller

SVC Switched Virtual Circuit

TCP Transport Control Protocol

TTL Time To Live

UDLR Unidirectional Link Routing

UDP User Datagram Protocol

WAN Wide Area Network

Acronym Meaning


20/20

Copy right 1999 Cisco Systems, Inc. All rights reserved. Printed in the USA. Access Registrar, AccessPath, Any to Any, AtmDirector, CCDA, C CD E, CCD P, CC IE, CC NA, CC NP, CCSI, CD -PAC, the Cisco logo,

Cisco Certified Internetwork Expert logo, CiscoLink, the C isco M anagement C onnection logo, the Cisco NetWorkslogo, t he Cisco Powered Netw ork logo, C isco Systems Capital, the Cisco Systems Capital logo,

Cisco Systems Networking Academy, the Cisco Technologies logo, C onnectWay, Cont rolStream, Fast Step, FireRunner, Giga Stack, IG X, JumpStart , Kernel Proxy, MGX , Nat ural Netw ork Viewer, NetSonar,Network Registrar, New World, Packet, PIX , Point and C lick Internetwor king, Policy Builder, Precept, Rout eStream, Secure Script, ServiceWay, SlideCast, SM ARTnet, StreamView, The Cell, Traffi cDirector,

T P th Vi R Vi t lSt Vi i W Vl D i t W k D i t d W k St k t d k Ch i th W W W k Li Pl d L E i th I t t

Cisco Systems has more than 200 offices in the following countries. Addresses, phone numbers, and fax numbers are listed on the

Cisco Connection Onli ne Web site at http://www.ci sco.com/offices.

Argentina Australia Austria Belgium Brazil Canada Chile China Colombia Costa Rica Croatia Czech Republic Denmark Dubai, UAE

Finland France Germany Greece Hong Kong Hungary India Indonesia Ireland Israel I taly Ja pan Korea Luxembourg Malaysia

Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania Russia Saudi Arabia Singapore

Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela

Corporate HeadquartersCisco Systems, Inc.170 West Tasma n D riveSan Jose, CA 95134-1706USAhtt p://w w w.cisco. com

Tel: 408 526-4000800 553-NETS (6387)Fax: 408 526-4100

European HeadquartersCisco Systems Europe s.a. r.l.Pa rc Evolic, Ba timent L1/L216 Avenue du QuebecVillebon, BP 70691961 Courtaboeuf Cedex

Francehtt p://w w w -europ e.cisco.co mTel: 33 1 69 18 61 00Fax: 33 1 69 28 83 26

AmericasHeadquartersCisco Systems, Inc.170 West Tasma n D riveSan Jose, CA 95134-1706USA

htt p://w w w.cisco. comTel: 408 526-7660Fax: 408 527-0883

Asia HeadquartersNihon Cisco Systems K.K.Fuji Building, 9t h Floor3-2-3 M aruno uchiCh iyoda -ku, Tokyo 100Japan

htt p://w w w.cisco. comTel: 81 3 5219 6250Fax: 81 3 5219 6001