to the Frequently Asked Questions (FAQ) File for Multicasting
FAQ file attempts to answer some of the common questions about multicasting
today, both for providers and users. For discussion about multicast, join the
IPMulticast mailing list.
FAQ file deals with the current status of multicasting, not with
of multicasting or the history of the MBone.
A good introduction to the history and current status of multicasting
is provided by Kevin Almeroth's paper, The evolution of multicast:
From the MBone to inter-domain multicast to Internet2 deployment
published in the IEEE Networks Magazine and available on
the web as a
downloadable gzipped postscript file. This FAQ file tries to
address, in a vendor neutral fashion, some of the questions that
seem to arise again and again in discussions on multicasting. Many
of the questions and answers came from the IP Multicast Initiative
multicast IPMulticast mailing list,
which can provide more about the basics of multicasting. Another recommended
multicast FAQ file with a somewhat different viewpoint is available
This file only provides a guide for interested users or implementors
of multicasting; if you want authoritative answers, read the protocols
referenced within! It is maintained by
Marshall Eubanks, who is solely responsible for any errors or
omissions, and welcomes any and all questions, comments, corrections
Can't find it here ? Search the web :
is Multicasting ?
Multicasting is a technique developed to send packets from one
location in the Internet to many other locations, without any
unnecessary packet duplication. In multicasting, one packet
is sent from a source and is replicated as needed in the network
to reach as many end-users as necessary.
The concept of a group is crucial to multicasting. Every multicast
requires a multicast group; the sender (or source) transmits
to the group address, and only members of the group can receive
the multicast data. A group is defined by a Class
Multicasting is not the same as broadcasting on the Internet
or on a LAN. In networking jargon, broadcast data are sent to
every possible receiver, while multicast packets are
sent only to receivers that want them.
Should Anyone be Interested in Multicasting ?
Multicasting is useful because it conserves bandwidth, in many
cases the most expensive part of network operations. It does
this by replicating packets as needed within the network, thereby
not transmitting unnecessary packets. Multicasting is the most
economical technique for sending a packet stream (which could
be audio, video, or data) from one location to many other locations
on the Internet simultaneously. Its commercial applications
include webcasting over the Internet (one to many multicasts),
multiparty computer games and conference calls (many to many
multicasts) and communication between devices behind the scenes
(the focus of recent work on small group multicast, also called
explicit multicast or Xcast).
What is the penetration of Multicast into the Internet ?
Unfortunately, not every Internet Service Provider (ISP) offers
multicasting at present. Information about the current status
and pentation of Multicast into the Internet is provided on
Multicast Status Page. At present (mid-April, 2001), the
penetration of multicast into the commodity Internet seems to
be between 3 and 5 per cent. This page also provides a dynamically
of Autonomous Systems with multicast routing as seen from
A list of ISPs and other service providers supporting multicast
is available at http://www.multicast-isp-list.com/.
If your ISP supports multicasting and is not on the list, suggest
that they join (inclusion is free if you answer the questions).
What Multicast Content is available ?
Multicast content (primarily streaming audio and video) is available
from a number of sources, including On-the-I.com,
our streaming audio broadcast service. In addition, we (Multicast Tech) maintain listings
of all permanent multicast broadcasts at
Multicast Video.com and
Lucy Lynch of the University
of Oregon provides a list
of regular multicast content providers, together with a
calendar of special multicast events. This web page also
includes instructions on how to submit your events, if you are
What if I want more information ?
The following books may be useful :
General Information on Multicast :
"Multicast Networking & Applications" by C. Kenneth Miller,
1999, ISBN 0-201-30979-3.
"Multicast Communication: Protocols, Programming, and Applications"
by Ralph Wittmann and Martina Zitterbart, 2001, ISBN 1-55860-645-9.
"Multicast and Group Security"
by Thomas Hardjono, Lakshminath R. Dondeti, 2003, ISBN: 1580533426
Planning, Developing and Debugging Multicast Networks :
"Cisco Multicast Routing and Switching", by William Parkhurst,
1999, ISBN 0-07-134647-3.
"Developing IP Multicast Networks: The Definitive Guide to
Designing and Deploying CISCO IP Multicast Networks" by
Beau Williamson, 2000, ISBN 1.57870-077-9.
"Interdomain Multicast Routing" by Edwards, Giuilano
and Wright, 2002, ISBN 0-201-74612-3.
Programming Multicast Applications :
by David Makofske, Kevin Almeroth, 2002, ISBN: 155860846X.
IETF working groups deal with multicast ?
There are quite a number :
Audio Video Transport or AVT, deals with streaming audio,
video and multimedia using the Real Time Protocol (RTP).
Reliable Multicast Transport or RMT, deals with reliable
deals with the Protocol Independent Multicast specification.
deals with issues of MBone deployment, and tends to have the
most discussion about operational multicast issues.
is responsible for IGMP v3 and MLD v2 (and
IDMR was phased out).
There is a
also an IETF Working Group on Multicast
Finally, the SSM
working group deals with Source Specific Multicasting
is unicasting ?
Unicasting is the traditional method of data transport on the
Internet, between one specific source and one specific receiver.
The vast majority of all data transmissions on the Internet
today, including all TCP, FTP and HTTP traffic, are unicast.
multicasting use TCP ?
No. Multicasting uses UDP (User Datagram Protocol) as its underlying
TCP (transmission control protocol) uses frequent transmission
of acknowledgement (ACK) packets between the receiver and the
transmitter for flow control, and also to determine if packets
have arrived safely, in order that dropped packets can be retransmitted.
This form of feedback and retransmission does not scale well
into the one to many case, although some forms of reliable multicast
do use negative acknowledgements (NACKs) to signal the need
UDP is a simpler protocol where there is no acknowledgement
of the success or failure of the transmission of any packet,
and no retransmission, at the transport layer. (In the jargon,
UDP is called "best effort.") Strictly speaking, therefore,
multicast data transport is unreliable, and any reliability
must be engineered-in at a higher level.
does (*,G) and (S,G) mean ?
Any multicast transmission has a Class
D multicast group address, G. A multicast group can have
more than one source, and each such source will also have
a "regular" (Class A, B or C, or CIDR) Internet address, S.
The notation (*,G) means every possible source for a given
group G, while (S,G) means a particular source, at a particular
Internet address S, in the group G. With IGMP
v1 and v2, you join all sources of a group, (*,G), while IGMP
v3 will make it possible to join a specific source-group pair,
is a Class D address ? And what does jargon such as 233/8 mean
The current Internet (IPv4) has a 32 bit address space. This
space was originally divided into five classes (or address
blocks), Class A, B, C, D and E, with Classes A, B and C being
assigned to normal unicast routing. Later, the Classless InterDomain
Routing (CIDR) protocol was established, so that blocks of
Internet addresses in the Class A, B and C address space could
be routed more efficiently. Upon the development of multicasting,
Class D was assigned to multicast addresses (Class E is still
reserved for experiments). Class D addresses all have 1110
as the first four bits. Since 11100000 is decimal 224, and
11101111 is decimal 239, this means that all Internet addresses
from 220.127.116.11 to 18.104.22.168 are assigned to multicasting.
It is cumbersome to refer to address blocks in the above fashion,
so CIDR developed (and multicasting has adopted) a shorthand,
where the start of a block, and the number of bits THAT ARE
FIXED, are specified. In that shorthand, the multicast address
space can be described as 22.214.171.124/4 or, even more simply,
as 224/4. The fixed part of the address is referred to as
the prefix, and this block would be pronounced "two twenty
four slash four."
So, in the above question, 233/8 means all
addresses between 126.96.36.199 to 188.8.131.52, which is the
GLOP address space.
Note that the LARGER the number after the slash,
the LONGER the prefix and the SMALLER the actual address block.
Note, too, that despite the use of this notation, multicast
group addresses are not subject to CIDR.
I use any multicast address I want ? How do I apply for a multicast
You cannot use any multicast address that you
want, but (except for very special cases involving control
traffic) you cannot apply for multicast addresses either.
What you can do is use a multicast address from a certain
range for certain purposes. The use of the multicast address
space is governed by
RFC3171, which describes the following blocks that have
been assigned by the Internet Assigned Names and Numbers Authority,
Multicast Address BLocks Assigned
by IANA (from RFC 3171).
||Local Network Control Block
||Internetwork Control Block
||ST Multicast Groups
||DIS Transient Block
||Source Specific Multicast (SSM) Block
||Administratively Scoped Block
Of these blocks, most users will use an address from the SDP/SAP
Block (given out by SDR or a similar program), the GLOP Block,
the SSM block, and the Administratively Scoped Block. The
uses of these blocks is described below.
is scoping ?
Scoping is the restriction of multicast data
transport to certain limited regions of the Internet. It comes
in two flavors, TTL scoping and administrative scoping.
is TTL scoping ?
Every Internet Protocol Packet has a Time To
Live (TTL) field, which despite the name is really a count
of the number of hops (transmission from one router to the
next) the packet is allowed. The TTL field is decremented
by one each time a packet leaves a router, and a packet with
a TTL of zero is discarded. Although the TTL field was implemented
to prevent packets from looping forever in the network, the
TTL field can be set low to prevent packets from leaving a
particular domain. The problem with TTL scoping is that the
hop-distance to the edge of a network or domain from a given
source may not uniform, and so it may not be possible to both
service the entire domain with multicast traffic and prevent
that traffic from leaking to other domains, no matter what
TTL value is chosen.
is Administrative Scoping ?
Administrative scoping is the restriction of multicast transport
based on the address range of the multicast group. It is defined
RFC 2365. Administrative scoping is restricted to the
address range 239/8, with the 239.255/16 address space being
reserved for the "local network" (i.e., those packets should
not be forwarded) and 239.192/14 is reserved for "organizational
scoping." Such large scale administrative scoping must be
announced, so that others know what the scope is, which is
supposed to be done by MZAP, the Multicast-Scope Zone Announcement
Protocol, described in
The most widespread current use of administratively scoped
multicast is UU.net and their UUCAST multicast service.
Many domains will filter out all 239/8 traffic at their borders,
so that any address in this range could be used for internal
is the GLOP address space ?
"GLOP" address space (this is not an acronym!) is a means of
assigning addresses in 233/8 based on an autonomous system number,
as described in
RFC 2770. Basically, a /24 is assigned to each Autonomous
System based on the 16 bit Autonomous System Number (ASN), in
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
|------233------|----------16 bits AS-----------|--local
For a given ASN number, converted
into two octets (say X and Y) in the usual fashion of Internet
addresses, the GLOP space is therefore 233.X.Y/24. This address
range is assumed to be assigned by default and does not have
to be explicitly requested. Note, however, that a GLOP allocation
only provides 256 separate addresses, which is widely viewed
as not enough for large scale broadcasters.
If you know your Autonomous System Number, you can find your GLOP range using Greg Shepherd's
there restrictions on the usage of GLOP address space ?
There are no restrictions of use of your GLOP space.
a Multicast Group with IGMP
Do I Join a Multicast Group? What is IGMP ?
A computer joins a multicast group by sending an Internet Group
Management Protocol (IGMP) membership report message. IGMP is
common to all multicast router protocols - it isolates end users
from the routing protocol in use. IGMP packets are always sent
with a TTL of 1, and are not supposed to be
Join latencies are typically very short, a few seconds at most.
are the differences between IGMP version 1 and 2 (v1 and v2) ?
The biggest operational difference is a that IGMP v2 has an explicit
Leave Group message, while in IGMP v1 it is necessary to time
out to leave a group. IGMP v2 leave latencies are a few seconds
or less, while v1 latencies can be 5 minutes, which can be a real
problem if an unwanted multicast transmission is a substantial
portion of the total available bandwidth.
IGMP v2 and v1 interoperate on the same network. ?
No. In case that IGMP v1 messages are present, all routers are
supposed to be configured manually to use version 1.
improvements will IGMP v3 bring ?
version 3, or IGMP v3, allows for specific (S,G) joins and
leaves, through the addition of source specific INCLUDE reports,
so that it will be possible to join a specific source of a specific
group directly. This capability will make SSM
if my router is not IGMP enabled ?
CISCO and other vendors support the concept of a stub router,
where IGMP packets are passed untouched to a router that does
support IGMP, which effectively becomes the first hop router for
IGMP traffic from the stub domain. For this to work the stub router
must recognize IGMP packets and forward them without decrementing
Of course it is always possible to tunnel.
Multicast Routing Protocols are in Use Today ?
The protocols for multicast data transport have evolved over
the years. The original
multicast proposal was for dense mode, where all possible receivers
are assumed to want multicast traffic initially and so multicast
traffic is flooded throughout the network until receivers specifically
request to leave the multicast group and stop receiving the
traffic (i.e., are "pruned"). This "flood and prune" technique
is relatively straightforward to implement, but is not very
efficient as the size of the network increases (it "does not
scale," in the jargon). The first multicast routing protocol
in common use, DVMRP
(for Distance Vector Multicast Routing Protocol), used this
technique, and was the protocol of the MBONE for years.
More recently, a sparse mode protocol has come into common use.
In sparse mode, no receiver is assumed to want multicast traffic
until it explicitly asks for it. There is thus no unwanted flooding
of traffic throughout the network, and so the protocol scales
much better and is more usable with large networks. The new
standard for multicast traffic is Protocol Independent Multicast
- Sparse Mode - or PIM-SM.
This protocol is called "Protocol Independent" as it uses the
unicast routing information to route multicast traffic, regardless
of how the unicast routing tables are constructed. There is
also a PIM Dense Mode (PIM-DM),
which combines the simplicity of the old DVMRP with the protocol
independence and other improvements in PIM-SM for those situations
where a Dense Mode protocol might be appropriate. Another protocol,
which mixes the properties of Dense and Sparse Mode, but is
only appropriate for domains using the Open Shortest Path First
(OSPF) unicast routing protocol, is Multicast - OSPF, or MOSPF.
I use multicast if my computer is not connected to a enabled
multicast router ?
Most office LANs are now Ethernets, and you do not need
a router to multicast on an Ethernet. However, if your LAN
is a set of Ethernets connected by bridges, hubs or switches,
your multicast performance will depend on the details of
the network, what sort of equipment is in use, and how it
is configured. You will not be able to send or receive multicasts
to or from places off of your LAN in any case, though.
If you want to multicast to or from the wider world, and
your network is not connected to the multicast enabled Internet,
all is not lost. You can still use tunneling, where multicast
packets are encapsulated in unicast packets over links that
are not multicast enabled. Tunneling was used extensively
in the old MBONE. It is much better to use native multicasting
and avoid tunneling if possible.
However, we here at Multicast Technologies do provide multicast
transit and connectivity via tunnels. If you are interested,
please send e-mail to firstname.lastname@example.org.
is the Protocol called "Protocol Independent" ?
The early DVMRP routing protocol actually constructs its own
routing tables, independently of the unicast routing tables.
Although this offers certain advantages, it is wasteful of router
resources. Protocol Independent Multicast (PIM) is so-called
because it uses the unicast routing information to route multicast
data, regardless of the routing protocol used to derive the
unicast routing data.
is a PIM-SM Rendezvous Point (RP)?
PIM-SM requires at least one Rendezvous Point, or RP, per
domain to function. Initially, receivers do not need to
know the location of a source to function, as the address
of the RP is distributed throughout the domain. When a receiver
wants to join a group, G, it sends a IGMP member report
to its first hop router, which sends a (*,G) join to the
RP. (In case there is more than one first
hop router, one is elected to be the Designated Router,
or DR, and it carries out this task.) Similarly, when a
source wants to begin transmitting to a group, its DR encapsulates
and unicasts the multicast data to the RP, which strips
off the encapsulation and multicasts it to the group members
Note that the RP is always a router, while a source is a
computer attached to a router, so that in general an RP
is not a source directly.
is a Shared Tree (ST), and a Shortest Path Tree (SPT) ?
The Shared Tree (also known as the Core Based Tree, or CBT,
from the different routing protocol described in RFC
2189) is the set of paths from the RP to the complete
set of group members.
The Shortest Path Tree is the similar set of paths from
a group source to the complete set of group members. It
is called "shortest path" as the unicast routing table is
used to determine the best route between the receiver and
the source, which is assumed to be the best route between
the source and the receiver. It may not be the "shortest"
route in a geographical sense.
Note also that the Shared Tree really is the Shortest Path
Tree to the RP; but it will be generally suboptimal
for transmissions from an arbitrarily located source.
Having a long lasting Shared Tree could be very useful for
some multicast applications, such as video-conferencing,
where sources might join the group for brief intervals,
and then leave the group. In this case, it might not be
worth setting up a separate SPT for each transient source.
In the case of long lasting sources doing one to many webcasting,
though, there is plenty of time to set up a SPT from the
source, and the increased latency and extra work imposed
on the network by a suboptimal Shared Tree is to avoided.
does the source send to the group ?
The source simply sends packets to the appropriate Class
D group address. Behind the scenes, though, it is much more
complex than that. Initially, the source packets are captured
by the first hop router, or the DR if
there is more than one first hop router, encapsulated, and
unicast to the RP.
After the initial transmission is established, the RP sends
a (S,G) join message to source. When that is received by
the DR, the encapsulation is stopped, and native multicasts
of the source's output are sent to the RP.
Still later, PIM-SM will switch from the Shared Tree to
the SPT. A receiver's first hop router, or DR, will issue
an (S,G) join towards the source. This join travels up the
Shared Tree until it finds the source, or a router with
(S,G) state that is already receiving from the source. At
this point, multicast traffic starts flowing down the SPT
to the receiver. At the router where the Shared Tree and
the SPT diverge, traffic will be received from both trees.
That router will then issue a prune towards the RP, stopping
the traffic flowing down that branch of the Shared Tree.
Eventually, a steady state may be reached, where all traffic
is flowing down the SPT, and when the RP can cease transmissions.
If you think this is complicated, you are not alone in that
feeling. Everything in the above answer is short circuited
by the SSM modifications to PIM-SM.
does PIM-SM switch between a Shared Tree and a Shorest Path
In practice, either immediately or never.
After the initial transmission is established, the switch-over
to the Shortest Path Tree occurs once a certain number of
bits (the SPT-Threshold) have been sent down the Shared
Tree. This threshold seems to be almost always set to zero,
so that the transition starts immediately.
If the only sources for a given group are on a LAN attached
to the RP, the switch-over to a SPT never occurs, as the
Shared Tree is the SPT for that group.
PIM-SM, how does a router actually becomes a rendezvous point
Routers must be configured manually to be a candidate RP.
One router in each PIM domain is elected by the other RPs
to be the Bootstrap Router (BSR). The BSR floods messages
announcing all of the suitable RPs (the RP-set) throughout
the domain, so that all routers know the addresses of the
The RP can also be specified manually, which makes sense
for a small domain with only a few routers.
Note that a router can be set up to be a RP for only a subset
of Class D group addresses. You could, for example, configure
one of your routers to be a RP only for the groups that
you were going to participate in.
is Source Specific Multicast ?
Source Specific Multicasting (SSM)
uses the capabilities
of IGMP v3 to tune PIM-SM to the needs of large scale, one-to-many,
webcasting. IGMP v3 allows a source to explicitly request
traffic from a particular (S,G) pair, through an INCLUDE
report. In SSM edge routers must be modified to generate
a PIM-SM SPT (S,G) join directly from a IGMP v3 INCLUDE
report, joining directly to the source without using a Rendezvous
Point at all. In SSM, routers in the interior of the network
do not have to be modified at all, and could run standard
PIM-SM. Knowledge of the source and group pair is assumed
to come from "out-of-band", such as from a web-page. Since
the Internet address of the source is given explicitly,
there is no need to run MSDP.
SSM is now included as part of the PIM-SM v. 2 draft.
More SSM implementation details can be obtained from my
at NANOG 21.
The address range 232/8 has been reserved for SSM.
is MSDP ? How does multicast traffic pass between autonomous systems
The Internet is divided into Autonomous Systems (AS's, or "domains"),
which are networks under a common routing policy. Routing within
an AS is done by whatever routing protocol is chosen by the
AS administrator; routing between autonomous systems is done
by an Exterior Gateway Protocol, currently BGP4, which maintains
tables which describe the AS paths required to reach a given
address block in some other AS. This presents a problem for
multicasting - how can a router determine which AS contains
the source for a given multicast group address ?
The Multicast Source Discovery Protocol (
MSDP) allows for a RP in a given AS to share information
about active sources with RPs in other AS's. This allows multicast
data to be forwarded between different AS's. It works with BGP4+,
which actually gives the interdomain multicast routes.
In SSM, the source and group address are
assumed to be known by other means, such as a web page, and
a (S,G) join can go directly across AS boundaries without using
NOTE : BGP4+ is also known as
MBGP (MultiProtocol BGP). It is NOT the same as BGMP,
the Border Gateway Multicast Protocol.
I work for an ISP. How do I connect to the multicast enabled Internet
This can be a complicated problem, but here are a few suggestions.
First, at least one of your upstream providers will need to
support multicast, and you will need some assistence from them.
If none of your upstream providers support multicast, you will
need to tunnel, and you probably should
The Internet2 had a multicast workshop recently that addressed
how to become enabled - you should take a look at the presentation
material. Good references are the books, Interdomain
Multicast Routing by Edwards, Giuilano and Wright, and Developing
IP Multicast Networks: The Definitive Guide by Beau Williamson.
If you are running an autonomous system, you will need to run
MBGP and set up PIM and MSDP Peers with your upstream peer -
you should contact your technical reference there and request
the necessary info. If you have trouble, you can ask questions
on the IP Multicast Initiative multicast mailing
The accessgrid multicast beacon at http://dast.nlanr.net/Projects/Beacon/
(and its beacon view web page at http://beaconserver.accessgrid.org:9999/)
is an excellent debugging tool. You may not want to devote the
bandwidth to become a permanent beacon group member, but sourcing
a beacon is a good way to test multicast transit both in and
You might want to consider, once you get multicast enabled,
to being listed on our multicast ISP list at http://www.multicast-isp-list.com
(inclusion is free if you answer the questions).
is the Real Time Protocol (RTP) ?
RTP (and the closely related Real Time Control Protocol, or
RTCP) provides a framework for sending real-time data over the
Internet. It is designed to be independent of the underlying
transport protocol, such as PIM-SM, and can be used with either
multicasting or unicasting. RTP allows for sequence numbering
and timing, which are crucial for the playback of an audio or
video data stream. RTCP is used to communicate control information
to receivers, and for quality control feedback from receivers
to the source. RTP is defined by
RFC 1889; a new draft
is also in the works.
is reliable multicast ?
in the context of multicasting generally means some form of
re-transmission of missing packets, using NACKs or Tree based
ACKs, but it also could mean "layered" techniques using Forward
Error Correction (FEC). Development of reliable multicast is
very much a work in progress; see the
RMT working group, the drafts referenced by the RMT charter,
and the IRTF RMRG
There are a number of reliable multicast products in use. Cisco
offers Practical General Multicast (PGM), which is now an Internet
reliable multicast based on their version of PGM, called
and the Reliable Multicast Transport Protocol, version 2 (RMTP-II).
multicast addresses collide at the MAC (Ethernet) layer ?
Yes. Normally, an Ethernet device will only accept packets addressed
to its unique MAC identity (or to the broadcast address). However,
Ethernet devices are also engineered to accept packets from the
multicast MAC address range. MAC addresses are 48 bits; of that,
25 bits are used in the multicast prefix : multicast MAC addresses
must start with 01:00:5E in hexadecimal, and the next bit must
be zero. This leaves only 23 bits to store the multicast Class
D address. Since multicast group addresses must start with
1110, there are really only 28 independent bits in a Class D address,
and so 5 bits are "lost" in the translation to a MAC address,
and collisions can occur.
For a GLOP address in 233/8, a total of 8
bits of the Class D address are redundant, and so only one bit
is lost (the highest order bit of the AS number, see below). Since
no autonomous system has yet been assigned a ASN with that bit
set to one, GLOP addresses will not yet be subject to MAC collisions
(at least with other GLOP addresses).
How a GLOP Address Maps Into a MAC address
Note : You may need to enlarge your browser window to see
a MAC collision may not be fatal, as applications can filter on
the Internet address of the source, but it may mean that too much
traffic is put on the local LAN. It may also put too much load on device CPUs, as the interface
NIC card may not be able to filter out the unwanted, and may send it up the kernel stack to
bits AS-----------|--local bits---|
lowest bits AS------|--local bits---|
Although SSM addresses cannot collide at the
IP level, due to the unique IP source address associated with
each SSM Class D address, MAC collisions can occur for SSM addresses,
and it is my personal opinion that a GLOP-like structuring of
the SSM address space may be needed to prevent this.
Last Updated Mon Feb 26 18:18:05 EST 2007