Multicast Routing and Addressing

Kaarle Ritvanen
Helsinki University of Technology
Department of Computer Science and Engineering
[email protected]

Abstract fines a few extension messages for the IPv6 version of the In-
ternet Control Message Protocol rather than defining a com-
Multicast routing is necessary when multicast datagrams are pletely new protocol to be run over IPv6 although the mech-
to be sent to groups spanning several networks. The most anisms used by IGMP and MLD are essentially the same. [5]
popular protocol is PIM-SM because it scales well also in Nevertheless, IGMP and MLD only define how hosts and
large networks. PIM-SM is based on shared distribution routers share membership information. It does not define
trees but also allows switching to source-rooted trees to im- how the routers arrange the appropriate datagrams to arrive
prove performance. Multicast address allocation and assign- to their network. There are separate protocols for achieving
ment require some mechanism too. It can be done manually that and they are discussed in more detail in Sections 2 and 3.
but there are also some protocols, such as MADCAP and
MASC, which can be used to automate those tasks. This pa-
per describes some of the techniques used in multicast rout-
ing and address allocation. 1.2 Multicast vs. Broadcast
KEYWORDS: multicast, routing, address allocation, PIM Many link-layer protocols, such as the one used with Eth-
ernet, support broadcasting. Broadcasting means that the
packet is sent to every node within the link or subnet. Eth-
1 Introduction ernet address FF:FF:FF:FF:FF:FF is reserved for this
purpose. Broadcasting is typically used when the address of
Usually datagrams sent over the Internet have a single des- the target host is not known, for example, when submitting
tination address which it will be delivered to. However, in Dynamic Host Configuration Protocol (DHCP) or Address
certain cases it would be convenient if the datagrams could Resolution Protocol queries. Broadcasting can be viewed as
be sent to multiple receivers. a special case of multicasting since it involves sending data-
For instance, consider videoconferencing software that al- grams to a certain set of nodes.1 [4]
lows conferences among more than two participants. The
same video stream is sent to every other participant by the However, hardware broadcast differs significantly from IP
currently speaking participant in the conference. Of course, multicasting. It is a simple mechanism that does not require
that host could send multiple datagrams having the same using any routing protocols. Unlike unicast and broadcast
content but different destination addresses, but this approach addresses, IP multicast addresses determine sets of nodes,
leads to inefficient use of bandwidth. It would be more effi- the members of which can belong to arbitrarily many sub-
cient to duplicate the datagrams as late as possible on their nets, which makes multicasting an essentially more difficult
path to the receivers. This technique is called multicasting. issue than broadcasting. [4]
The Internet Protocol (IP) incorporates a multicasting
mechanism. In IPv4, a set of addresses, namely block
224.0.0.0/4, is reserved to be used to identify multicas-
ting groups [1]. In a similar fashion, also IPv6 address block 2 Multicast Routing Protocols
FF00::/8 is reserved for this purpose [2].
Many multicast routing protocols have been developed but
there is no single all-purpose approach to this subject [4].
1.1 Host Perspective Common multicast routing protocols include Protocol In-
Since the multicast groups are dynamic, hosts must some- dependent Multicast and Distance Vector Multicast Routing
how be able to inform the routers about their memberships in Protocol [6].
such groups. Therefore there is the Internet Group Manage-
ment Protocol (IGMP) which is used for this purpose with 1 Broadcasting is considered a special case of multicasting in the Ethernet
IPv4 [3]. In addition to allowing hosts to update their group addressing scheme. A half of the Ethernet addresses are reserved for mul-
membership information, it provides the routers a way of ticasting. Actually, IP multicasting utilizes a small fraction of them when
it takes place in Ethernet or other multicast-capable network. If the least
verifying the validity of the memberships. [4]
significant bit of the first octet of an Ethernet address is set, it is a multicast
For IPv6, there is also an IGMP equivalent, which is called address. In this sense, the Ethernet broadcast address is only a certain, fixed
the Multicast Listener Discovery (MLD) protocol. MLD de- multicast address.

1
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

2.1 Distance Vector Multicast Routing Proto- DVMRP. As its name suggests, MOSPF must be used in con-
col junction with the Open Shortest Path First (OSPF) routing
protocol. MOSPF takes advantage of the link-state infor-
Distance Vector Multicast Routing Protocol (DVMRP) was mation maintained by OSPF. MOSPF defines an additional
one of the first multicast routing protocols. However, it was message type that is used to advertise the locations of mul-
still used in the global Internet to a large extent until the end ticast group members, similarly as link-states are advertised
of the 1990s. It was the protocol used in MBONE, a virtual in OSPF. Using the link-state and group membership infor-
multicasting backbone network. mation, MOSPF routers are able to calculate pruned source-
DVMRP defines some extension message types to IGMP. rooted shortest-path trees for multicast datagrams by using
Those messages are exchanged between DVMRP-capable the Dijkstra’s algorithm. MOSPF also defines a mechanism
routers in order to find out where the members of a certain for inter-AS multicast forwarding. [9]
group are located. DVMRP also defines a way to tunnel mul- The biggest disadvantage of MOSPF is that every router
ticast traffic through unicast-only networks. must maintain membership information of every group.
Originally, DVMRP was derived from another distance Therefore MOSPF also scales poorly if there are many multi-
vector routing protocol, namely the Routing Information cast groups. When compared to DVMRP, MOSPF causes no
Protocol (RIP), which is used in conventional routing. The useless data traffic. In contrast, it causes more routing infor-
DVMRP constructs source-rooted forwarding trees for ev- mation traffic because the membership databases have to be
ery pair formed of source address and group address. Each synchronized whenever someone joins or leaves a group. [4]
router determines its place in the tree so that its distance to
the source is as small as possible. On receiving a multicast
datagram, the router forwards it to every (virtual) interface 2.3 Protocol Independent Multicast
except the one leading to the source along the tree.
Protocol Independent Multicast (PIM) consists of two sep-
Version 3 of DVMRP employs an algorithm called Re-
arate protocols, namely PIM Dense Mode (PIM-DM) and
verse Path Multicasting (RPM). A router indeed knows
PIM Sparse Mode (PIM-SM) [10]. PIM-DM is intended
whether there are local group members beyond a certain in-
to be used when the multicast group members are densely
terface. In contrast, it does not know whether there are any
distributed across the network, whereas PIM-SM should be
distant members, considering a multihomed network. RPM
used when the distribution is wide and spans several net-
suggests that if a router does not know whether there are any
works. The operation of PIM-SM is described in detail in
members beyond a certain interface, the datagram should be
Section 3.
forwarded there. If a router on a leaf network receives a data-
gram with a destination group that has no members in that PIM-DM basically uses the same broadcast-and-prune
strategy as DVMRP. The main difference between these two
network, it sends a prune request to the router from which
the datagram originated. Then that router learns that for- is that PIM-DM does not incorporate any topology discovery
warding packets with that address to that leaf network is not mechanism as DVMRP does, hence it is said to be protocol
necessary. Similarly, networks adjacent to the leaf networks independent. Whereas DVMRP uses a distance vector proto-
can send prune requests if they learn that neither they nor col to build source-rooted trees, PIM-DM relies on the rout-
ing information the router has gathered by using a unicast
their leaf networks have any group members. Hence the in-
formation about group memberships (or actually the absence routing protocol, such as RIP or OSPF. [11]
of them) flows up in the tree toward the source. A mecha- Often a protocol called Multiprotocol Extensions for BGP
nism for canceling prunes is also provided. [7] (MBGP) is used to gather the routing topology information
As the group memberships vary dynamically and as the for PIM. MBGP is an extension to the Border Gateway Pro-
routers do not have infinite amount of memory, it is neces- tocol (BGP), and among other things it allows defining dif-
sary that the pruning information eventually expires. There- ferent topologies and policies for multicasting and unicast-
fore using DVMRP causes periodic flooding to networks ing. [12]
without memberships [8]. DVMRP also suffers from the
same scalability problems as other distance vector protocols. 2.4 Deployment of Routing Protocols
When the number of routers grows, propagation of the rout-
ing and membership information becomes slower. In addi- It seems that DVMRP and PIM are the most used multi-
tion, DVMRP has to keep track of a large amount of infor- cast routing protocols. The leading routing hardware vendor
mation which means that routers must have a lot of memory. Cisco Systems supports both of them. For instance, Cisco
Therefore it is not a suitable multicast routing protocol to be Catalyst 3750 series devices support DVMRP and PIM [13].
used in the global Internet. [4] The E-series routers of another large vendor, Juniper Net-
Moreover, the tunneling capability of DVMRP has caused works, also support them [14].
problems. It is too easy to create virtual topologies that are DVMRP used to be the most popular protocol since it
inconsistent with the physical topology, which leads to inef- was used in MBONE but PIM has taken its place. In fact,
ficient routing. nowadays MBONE is almost dead. DVMRP tunnels were
effectively replaced by inter-domain MBGP by the end of
2000 [15]. Most WWW pages concerning MBONE have
2.2 Multicast Extensions to OSPF
been last updated in the late 1990s.
Multicast Extensions to OSPF (MOSPF) is an attempt to Most router vendors support PIM, and some Internet Ser-
create multicast routing protocol that scales better than vice Providers have begun using PIM in their backbones

2
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

and providing multicast services based on it. The problem B (RP)

with MOSPF is that it can be used only in OSPF networks.
Typically, OSPF is not used on small or medium-sized net-
works. [16] A
2 R2
Perhaps even bigger problem in using MOSPF is that it
runs Dijkstra’s algorithm for each distribution tree and keeps C
track of a huge amount of state information. Therefore it is
not suitable if there are many multicast groups to be handled. R1 3
Cisco Systems has stated that they do not support MOSPF
for this reason and encourage using PIM [17]. 1
E
Neither PIM nor MOSPF specify how to gain information
about multicast sources in other domains. This is one of the D
most difficult issues in multicast routing and one possible
solution is discussed in Section 3.4. Anyway, since MOSPF
scales poorly and is not superior to PIM in inter-domain rout- Figure 1: Joining to a group
ing, there is no good reason to use it.

Of course, Join/Prune messages must be sent immediately

3 Operation of PIM-SM when some host joins or leaves a group so that it causes mod-
ifications to the distribution tree. Figure 1 shows an example
PIM-SM is a multicast routing protocol for situations where of hosts R1 and R2 joining to a group. The following actions
the group member distribution is sparse. Like PIM-DM, it take place:
is independent of unicast routing protocols. The major dif-
ference between PIM-SM and PIM-DM is that PIM-SM is 1. Host R1 informs router D that it wants to join group G.
a demand-driven protocol like MOSPF. Instead of broad- Router D adds group G to its routing table, outgoing
casting to all interfaces until a prune request is received, interface set to the local area network interface and in-
group memberships must explicitly be announced before coming interface set to the one leading to router C. A
datagrams are forwarded. Therefore, PIM-SM scales better Join/Prune message for group G is sent to router C.
to large networks than MOSPF because PIM-SM routers do
not have to be aware of every group membership. 2. On receiving the message from router D, router C up-
dates its routing table in similar fashion and sends a
This section illustrates how PIM-SM works. The descrip-
Join/Prune message to router B which is the RP for
tion of the protocol operation in Sections 3.1 and 3.2 is
group G. As router B itself is the RP, it only updates
loosely based on [18].
its routing table without sending a further Join/Prune
message.
3.1 Rendezvous Points and Shared Trees
3. Host R2 joins to group G. This makes router E send a
PIM-SM uses the same shared distribution tree approach as Join/Prune to router C which in turn appends the inter-
the Core Based Trees (CBT) protocol [19]. Each PIM-SM face leading to router E to the outgoing interface list for
domain has at least one router called Rendezvous Point (RP). group G. However, no Join/Prune is sent to router B be-
If there are more RPs than just one, they are responsible for cause router C already belongs to the shared forwarding
different multicast groups. So within a domain, exactly one tree of group G.
RP is associated with each multicast address.
RPs correspond the core routers of CBT since they act as
roots for shared distribution trees. Shared tree means that the 3.1.2 Sending Datagrams
same distribution tree is used for all source addresses. This
implies that less state information needs to be maintained Now suppose that host S connected to router A to sends a
than with dense mode protocols which use separate trees for datagram to group G, as depicted in Figure 2. This triggers
each source node. the following actions:

1. Router A receives the datagram from host S, encapsu-

3.1.1 Establishing Shared Trees lates it to a PIM-SM Register message and unicasts it to
Each subnet of a PIM-SM domain has one Designated router B.
Router (DR) that connects the local hosts to multicast dis-
2. Router B decapsulates the datagram. It forwards the
tribution trees. DRs obtain information about local member-
datagram to the interface leading to router C because
ships by IGMP or MLD as usual. DRs with local members
it is the only interface in the outgoing interface list for
in a multicast group periodically send PIM-SM Join/Prune
group G.
messages toward2 the RP of the group in question. Also the
intermediate routers between those DRs and the RP periodi- 3. Router C receives the datagram and looks up the outgo-
cally send messages of this type toward the RP. ing interface list which contains the interfaces leading
2 In this context,
sending toward node N means that the packet is received to routers D and E. The datagram is forwarded to them
and processed by the next router along the shortest route to N. and they deliver it to hosts R1 and R2.

3
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

S S

B (RP) B (RP)

1 3
A A
2 R2 R2
4
C 2,3 C

R1 3 R1

3 1
E E

D D

Figure 2: Sending to a group Figure 3: Switching to the shortest-path tree

After having received the Register message from the 4. As router C received a datagram originating from host S
source, the RP (router B in this case) can send a source- via router A, it knows that the shortest-path request has
specific Join/Prune message for group G and source S to- propagated all the way to the DR of S. (In this case,
ward S so that the intermediate routers set up their routing there was no intermediate routers between them, but
tables with respect to group G and source S. The advantage this is not always the case.) Now router C can enable the
is that multicast datagrams do not have to be encapsulated new routing table entry and prune itself from the shared
and unicast to the RP. tree with respect to source address S and therefore it
sends a Join/Prune message to router B with S inserted
3.2 Shortest Path Trees to the prune list. The original datagram is forwarded to
routers D and E as usual.
As it can be seen in Figure 2, the shared tree approach
leads to a less efficient forwarding of datagrams than using After these steps multicast datagrams sent to group G by
shortest-path source-rooted trees. It would be more efficient host S are delivered to router D using the shortest route. In
if router A sent the datagrams directly to router C. This does fact, the route to router E was also shortened because the
not matter if the data rates are low. However, if some hosts shortest route between host S and router D happened to cross
are sending to a group very frequently, it may cause con- with the shared-tree route to router E.
gestion near the RP. In addition, the transmission delay is In this case, router B is the RP, so it does not send fur-
increased because the datagrams are circulated via the RP. ther prune requests although router C is its only child in the
To overcome this disadvantage, PIM-SM allows DRs to shared tree for group G. The RP cannot prune itself from the
switch between shared trees and shortest path trees (SPT). forwarding tree with respect to any source since it must know
Suppose that router D in Figure 3 notices that host S is send- all the sources for the groups it manages. The reason for this
ing to group G by a significant rate and decides to switch to becomes apparent in Section 3.4.
SPT. This causes the following events to happen:

1. Router D sends a source-specific Join/Prune message to

router C with the source address set to the address of S. 3.3 RP Selection

2. Router C sees from its unicast routing table that the If there are several RPs within the domain, DRs must know
shortest path to host S passes through router A. There- which RP is associated with each multicast group address.
fore router C creates a new entry to its multicast rout- One router in a domain acts as the Bootstrap Router (BSR)
ing table for group G and source address S and sets of the domain. That router is determined by an election pro-
the incoming interface to the one leading to router A. cedure. All routers configured to act as RPs advertise them-
However, this entry is not yet used. Router C sends selves to the BSR. The advertisement messages include the
router A a similar source-specific Join/Prune message multicast address blocks for which the router is willing to
it received from router D. Router A updates its routing act as the RP. The BSR collects this information to a PIM-
table similarly. The outgoing interface of the new entry SM Bootstrap message which is then propagated hop-by-hop
for source S is set so that the datagrams are sent also to within the domain.
router C. But what if several routers offer to act as the RP for some
address blocks? The load is then balanced between them all.
3. Host S sends a datagram to group G. Router A now for- DRs use a certain hash algorithm to determine the correct RP
wards it to both routers B and C. for each group address.

4
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

3.4 Connecting PIM-SM Domains 3.5 Source-Specific Multicast

PIM-SM builds forwarding trees within a single domain. A Source-Specific Multicast (SSM) defines new semantics for
PIM-SM domain means a contiguous set of PIM-capable multicasting. It suggests that instead of using only the multi-
routers that are configured to operate within certain bound- cast group addresses, the channels3 are identified by the pair
aries [10]. This implies that hosts can only receive multicast formed of the source and group address [21]. This change
datagrams from the domain they belong to. imposes the restriction that only one host can send to the
However, there are protocols that enable receiving data- channel. But in some cases, this makes perfect sense. Con-
grams also from other domains. Multicast Source Discovery sider a multicast-based video-on-demand server that starts
Protocol (MSDP) is one such protocol. MSDP routers are streaming periodically, for example every 15 minutes. Dur-
connected to each other by TCP connections, thus forming ing that period it collects a group of viewers and then uses
a virtual topology. When an MSDP-capable RP receives a multicast to deliver the datagrams. Another example could
Register message from the DR of some new sender, it gen- be a multicast-based TV or radio channel. The clients need
erates a Source-Active (SA) message containing the address to receive datagrams only from the streaming server. In fact,
of the source host, the group address and its own IP address. the clients do not even want to receive datagrams from any-
Then it sends the SA message to its MSDP peers (neigh- one else. SSM actually provides very strict access control on
bors in the virtual topology) which in turn flood it to their who is allowed to send to a group [21].
other peers, in somewhat similar fashion DVMRP handles As only one host is allowed to send to an SSM group, the
datagrams with non-pruned group addresses. The outcome complexity of routing is lower than in conventional multi-
is that every RP is aware of the sender unless the group is casting. Only one source-rooted tree is needed for datagram
private, in which case no SA messages are sent. [20] delivery. There is no need for shared trees nor using source
On the other hand, individual RPs know each active inter- discovery protocol. [21]
domain multicast source (for non-private groups). Upon re- Indeed, SSM requires that hosts are able to pass the source
ceiving an SA message for such group that has members address to the router when joining to groups. IGMPv3 pro-
in its domain, an RP sends a Join/Prune message for that vides a mechanism for this [3]. For IPv6, MLDv2 adds sup-
group and that source address toward the source host like port for SSM [22]. Of course, using SSM has implications on
it does for intra-domain sources. After this the RP receives the application level too. Considering an SSM-based video-
the datagrams sent by the source in the other domain and for- conferencing application, the participants must use some ad-
wards them according to the normal PIM-SM convention. Of ditional protocol to find out which hosts are sending to the
course, this means that every intermediate router must also group so they can join the appropriate channels.
support PIM-SM. [20] The combination of SSM and PIM-SM is called PIM-
SA messages are also cached for a while, just in case SSM. SSM is used only with certain group addresses. There-
that a group gets members in that domain although it has fore PIM-SM routers know when to use PIM-SSM. In prac-
not yet any. Active sources are also advertised periodically tice that means that the DRs send Join/Prune messages di-
to ensure that datagrams are received from all inter-domain rectly to the source instead of the RP. The result is that only
sources. [20] source-rooted trees are built. Therefore it is not necessary to
Nevertheless, the SA flooding approach of MSDP is not it- use MSDP with these addresses, either. [23]
self very scalable. It works when the total number of RPs is
low or there are not so many groups nor source hosts. There-
fore someone might argue that why should we have different 4 Multicast Address Allocation and
PIM-SM domains at all. Would it not be better to have only
one domain within which the forwarding trees were built? Assignment
There are a few reasons for having separate domains.
Multicast routing protocols deal with the issue of getting the
Firstly, domain boundaries impose a maximum for the dis-
datagrams to each member of the group having a certain ad-
tance between source hosts and RP. Since the RP of a certain
dress. But how are these group addresses allocated to sites
group is determined by a hash function, it can happen that
and assigned4 to nodes and applications? It is clear that a
it is located on the opposite side of the domain. When the
mechanism is needed for allocating and assigning these ad-
diameter of the domain is kept reasonably small, this is not a
dresses to prevent collisions.
problem.
According to a document produced by the Multicast Ad-
Another reason is security. The bootstrap protocol of PIM-
dress Allocation (MALLOC) Working Group of the Inter-
SM described in Section 3.3 is prone to certain types of at-
net Engineering Task Force (IETF), there are three possi-
tacks. And messing up the system does not have to be inten-
ble ways to allocate and assign multicast addresses: static,
tional. Also misconfiguration of routers may make the entire
scope-relative and dynamic [24]. Although no difference be-
domain unworkable. Moreover, if an ISP charges its cus-
tween allocation and assignment is made in that document,
tomers per traffic basis, the customer would prefer having
a separate PIM-SM domain in order to reduce the amount 3 In SSM terminology, groups (together with the source address) are

of traffic. If the RP of a group the customer uses resided called channels. Joining to a group is called subscribing a channel.
4 Although used interchangeably by many multicast-related documents,
outside the customer’s network, the traffic would circulate
address allocation and assignment have a slightly different meaning. Allo-
via the ISP’s network, thus imposing additional traffic costs. cation refers to granting an administrative domain the right to use and assign
The location of the RP can be selected if the ISP refrains certain addresses, whereas assignment means dividing the addresses among
from advertising its own RPs for that group, however. the nodes or applications.

5
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

this paper presents how this categorization applies to both its length are embedded to the address and the 32 least
allocation and assignment. significant bits are reserved for the group ID. Including
the prefix length information allows not only ASs to as-
4.1 Address Allocation sign static addresses but also every other organization
having control over any unicast prefix. [29]
This section describes different ways to allocate multicast
addresses to organizational domains.
4.2 Address Assignment
Static Statically allocated address blocks may be obtained In addition to allocating multicast addresses, they also have
from the Internet Assigned Numbers Authority (IANA). to be assigned to nodes and applications within a domain.
Although some organizations have managed to acquire This section describes how that can be done.
their own multicast address blocks, IANA more will-
ingly assigns static multicast addresses for applications
Static Static addresses are needed by certain public proto-
rather than allocating them for organizations. cols and they are assigned by IANA. For example, hosts
However, the IPv4 multicast address space is pretty running a Network Time Protocol (NTP) server can pe-
small and IANA is constantly receiving address allo- riodically send datagrams to group 224.0.1.1. Thus,
cation requests. This problem was discussed in the NTP clients are able to receive NTP clock synchroniza-
meeting of IETF MBONE Deployment Working Group tion messages even without knowing the unicast ad-
held on March 1, 2004. Previously made bad allocation dress of the server. They just have to join this well-
choices were considered a problem because they make known multicast group.
it more difficult to refuse requests by others. [25] Assigning multicast addresses manually to private ap-
plications or nodes can also be viewed as static assign-
Scope-relative Address block 239.0.0.0/8 has been de-
ment. These addresses may be administratively scoped
fined to be the administratively scoped IPv4 multicast
addresses, GLOP addresses or even addresses allocated
space. Addresses belonging to this block may be used
by IANA for the organization. Anyway, they have to be
as group addresses locally or within a single organiza-
in some way further assigned to nodes or applications.
tion. Multicast datagrams sent to these addresses will
not be sent across administrative boundaries, so these Scope-relative IANA assigns scope-relative multicast ad-
addresses do not need to be globally unique. Similarly, dresses for certain types of services. These addresses
scoped multicast addresses have also been defined for are valid relative to the administratively scoped address
IPv6 [2]. [26] blocks. For instance, 239.255.255.249 refers
to site-local DHCP servers and 239.251.255.249
Dynamic In theory, it is possible that some protocol is used
refers to organization-local DHCP servers. [26]
between administrative domains in order to prevent
them from using the same multicast addresses. One Dynamic When a normal application program needs a mul-
such protocol is described in Section 5.2. However, us- ticast group address, it could be allocated dynamically
ing dynamic inter-domain allocation is rare. from a Multicast Address Allocation Server (MAAS)
Derived This allocation method is not listed in [24], but like unicast addresses are allocated from DHCP servers.
it is still important. Instead of directly allocating a This is convenient when the address is needed for only
static address block, Autonomous Systems (AS) can a limited time. The allocation can then be renewed if
use so called GLOP addressing when it needs multi- it turns out that the original lease time was too short.
cast group addresses. For each AS there are 256 ad- There are a few protocols for dynamically allocating
dresses derived from its AS number that it is allowed to multicast addresses. One of them is discussed in Sec-
use for any purposes. These addresses belong to block tion 5.1.
233.0.0.0/8. The second octet of the address is the It is important to note that dynamic assignment can
high-order octet of the 16-bit AS number and the third be used regardless of the way the addresses were al-
octet of the address is the low-order octet of the num- located. They may be statically allocated or administra-
ber. [27] tively scoped addresses, or even dynamically allocated
GLOP addressing is possible with IPv4, but there is addresses.
quite a similar way to use IPv6 multicast addresses
without explicit reservation. This mechanism is per- 4.3 SSM Addresses
haps even better than GLOP addressing scheme because
rather than being based on AS numbers, the addresses IANA has reserved IPv4 address block 232.0.0.0/8 for
are derived from network prefixes. IPv6 addresses be- SSM [21]. Similarly, some IPv6 addresses are intended to be
longing to block FF30::/12 are reserved for this pur- used solely with SSM [29].
pose. IPv6 unicast addresses contain a prefix, the length As described in Section 3.5, SSM channels are identified
of which is usually at most 64 bits [28].5 The prefix and by the combination of the group address and the source ad-
dress. This means that the group addresses do not have to
5 Actually, this is true only for such unicast addresses that do not belong

to block ::/3. Addresses outside this block are required to contain a 64- allocates unicast addresses only from block 2000::/3, so this is not a
bit interface ID, thus leaving only 64 bits for the prefix. IANA currently problem.

6
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

be globally unique. They only have to be unique among the ernet. The authors of the protocol argue that this makes the
applications used on the sending host. Therefore they can protocol more resilient to network failures. [33]
be used freely without further allocation by IANA. For the MASC nodes form a hierarchical virtual topology where
same reason, no MAAS is needed to coordinate address as- the nodes are connected to each other by TCP connections.
signment between nodes. Each non-leaf node advertises free address prefixes it has re-
served to its children. When a child node wants to allocate
some addresses, it chooses a suitable portion from one of its
5 Address Allocation Protocols parent’s blocks7 and sends the parent a claim for that block.
The claim is then sent to all the siblings of the originator. If
The MALLOC Working Group has suggested a three-layer none of them claims an overlapping set of addresses within
allocation6 architecture. According to its suggestion, alloca- a certain period (48 hours by default), the claimer is enti-
tion of addresses takes place hierarchically, at three different tled to use the block. However, each prefix reservation has
layers. The motivation behind this modular architecture is a finite validity period, after which it should be renewed if
that each layer can be replaced or updated independently. necessary. [34]
The layers are: [24] As the waiting period after the claim usually is relatively
1. Multicast clients requesting for single addresses from long, MASC servers must allocate a sufficient amount of
MAASs. blocks in advance. Unfortunately, predicting the future is
a difficult task and therefore good algorithms are required.
2. Intra-domain mechanism to ensure that MAASs do not Robust algorithms are also useful when deciding the prefix
allocate duplicate addresses. The MAASs could be to be claimed. It is better to pick a prefix that can be ex-
manually configured or there might be a protocol for panded as much as possible (by decrementing its length) be-
doing this. The Multicast Address Allocation Protocol cause aggregatable address blocks require less space to store
is one such protocol [30]. than completely random prefixes. [34]
3. Inter-domain allocation mechanism. If it is desirable
to have fully dynamic allocation and assignment, there 5.2.1 Border Gateway Multicast Protocol
must be a protocol for making sure that the group ad-
MASC can be used in connection with the Border Gateway
dresses are unique across domain boundaries.
Multicast Protocol (BGMP) [35]. BGMP is an inter-domain
multicast routing protocol that builds shared trees between
5.1 Multicast Address Dynamic Client Alloca- the domains, like CBT and PIM-SM do within a domain.
tion Protocol The root of the tree for a certain group is located in the do-
main that has allocated the group address by MASC. [36]
Multicast Address Dynamic Client Allocation Protocol BGMP was thought to be more scalable than MSDP on
(MADCAP) is a protocol that is used by applications to allo- the same basis as PIM-SM scales better than DVMRP. Al-
cate multicast addresses from MAASs. MADCAP was orig- though IETF expected that it would replace MSDP in the
inally based on DHCP and that is why there are many simi- long run, BGMP nowadays suffers from lack of interest of
larities between these two protocols. [31] vendors and operators, and thereby it did not enter the stan-
MADCAP has a server discovery mechanism which itself dards track [37].
uses a statically allocated scope-relative multicast address.
Clients can lease multicast addresses from the servers, renew
their leases and release them. When allocating addresses, the 5.3 Deployment of Allocation Protocols
clients pass the server the desired address family, scope and
It seems that there are very few if any implementations
possibly some other options. [31]
of multicast address allocation protocols in addition to the
It is important to note that MADCAP does not solve the
reference implementations. These allocation protocols are
problem how applications on different hosts can agree on a
hardly used by anyone. Anyway, Microsoft has added MAD-
common group address. One of the hosts has to reserve the
CAP support to its DHCP server although this does not imply
address which then must be communicated to the other hosts
that someone is really using it [38]. It seems that there are
by an application level protocol, such as the Service Location
no MASC implementations besides the reference implemen-
Protocol (SLP) [32].
tation written by Pavlin Radoslavov.
The IETF MBONE Working Group is aware of the fact
5.2 Multicast Address-Set Claim Protocol that there currently is no workable solution for global dy-
Multicast Address-Set Claim (MASC) is an inter-domain al- namic allocation. Moreover, application developers and de-
location protocol. MAASs of different domains may use it ployers lack knowledge of MADCAP and SLP, which could
to make sure that they are not assigning addresses from over- be used to allocate temporary addresses and propagate them
lapping address blocks. In contrast to the traditional request– to other hosts. [25]
response protocols, MASC employs a claim–collide mecha- The reason for the lack of public interest towards dynamic
nism similar to the collision detection technique used in Eth- multicast address allocation is that the use of multicast is
altogether relatively rare. If there were masses of software
6 Again, term allocation is used to mean both address allocation and as-

signment. In this model, layer 3 corresponds to allocation, whereas assign- 7A MASC node can have several parents, which improves the availabil-
ment is performed at layers 1 and 2. ity of address blocks to be claimed.

7
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

employing multicast, it would be very convenient to allocate protocols but they are not used in practice. The use of mul-
and assign group addresses dynamically. But as multicast ticast is relatively rare, so there is no real need for dynamic
has been and still is mainly a subject of academic research address allocation and assignment, at least yet.
whereas commercial applications are few, dynamic alloca-
tion is not worth the additional complexity it causes.
References
6 Conclusions [1] S. Deering. Host Extensions for IP Multicasting.
RFC 1112, IETF Network Working Group, 1989.
Multicast routing means delivering datagrams across net- [2] R. Hinden, S. Deering. Internet Protocol Version 6
work boundaries to an arbitrary, dynamic set of receivers in (IPv6) Addressing Architecture. RFC 3513, IETF Net-
a reasonable and efficient way. Three multicast routing pro- work Working Group, 2003.
tocols were discussed, namely DVMRP, MOSPF and PIM.
[3] B. Cain et al. Internet Group Management Protocol,
Version 3. RFC 3376, IETF Network Working Group,
6.1 Comparison of Routing Protocols 2002.
DVMRP is a distance vector protocol originally based on [4] D. E. Comer. Internetworking with TCP/IP, Volume 1:
RIP. DVMRP uses a flood-and-prune strategy to build distri- Principles, Protocols and Architectures. 4th ed. Pren-
bution trees. Nowadays DVMRP is seldom used. Even those tice Hall, Upper Saddle River, New Jersey, USA, 2000.
multicast regions still hanging MBONE usually run PIM in-
ternally while DVMRP is used between them. DVMRP it- [5] S. Deering et al. Multicast Listener Discovery (MLD)
self does not address any interoperability issues but the other for IPv6. RFC 2710, IETF Network Working Group,
protocols can provide it the necessary information. DVMRP 1999.
also provides a way to tunnel multicast traffic over non-
[6] D. Waitzman et al. Distance Vector Multicast Routing
multicast networks. [39]
Protocol. RFC 1075, IETF Network Working Group,
MOSPF defines some new message types for OSPF in or-
1988.
der to enable multicasting. MOSPF builds one distribution
tree for each pair of source and group addresses which makes [7] T. Pusateri. DVMRP Version 3. IETF Inter-Domain
its scalability poor. The tree construction is based on Di- Multicast Routing Working Group, Internet Draft
jkstra’s algorithm and the OSPF link-state advertisements. (draft-ietf-idmr-dvmrp-v3-11), 2003.
In addition, every MOSPF router of a certain area must be
aware of all group memberships inside that area. That is a [8] T. Ferrari. Introduction to Multicast. INFN National
serious drawback since it causes much signaling overhead. Center for Telematics and Informatics, 2000. [refer-
However, this information is used to completely eliminate enced on February 3, 2004]
unnecessary data traffic and to calculate shortest-path distri- http://www.cnaf.infn.it/~ferrari/
bution trees. papers/myslides/mcast-intro/
PIM actually defines two protocols for two different node [9] J. Moy. Multicast Extensions to OSPF. RFC 1584,
distribution schemes. Both of them are independent of the IETF Network Working Group, 1994.
unicast routing protocol used. Except for that, PIM-DM
is quite similar to DVMRP. PIM-SM tries to minimize the [10] D. Estrin et al. Protocol Independent Multicast
overhead caused by flooding. The branches are explicitly — Sparse Mode (PIM-SM): Protocol Specification.
joined to and pruned from the distribution trees. Neverthe- RFC 2362, IETF Network Working Group, 1998.
less, this increases signaling overhead because the forward-
[11] A. Adams et al. Protocol Independent Multicast —
ing tree has to be updated even when no datagrams are sent
Dense Mode (PIM-DM): Protocol Specification (Re-
to the group. Another objective of PIM-SM is to keep the
vised). IETF PIM Working Group, Internet Draft
amount of state information small. PIM-SM supports both
(draft-ietf-pim-dm-new-v2-04), 2003.
shared and shortest-path distribution trees.
PIM-SM is currently the best alternative for delivering [12] T. Bates et al. Multiprotocol Extensions for BGP-4.
datagrams to sparsely distributed set of receivers. PIM-DM, RFC 2858, IETF Network Working Group, 2000.
DVMRP and MOSPF consume too much resources and their
use is limited to relatively small environments [39]. Table 1 [13] Anon. Configuring IP Multicast Routing. Cisco Sys-
summarizes the main properties of these protocols. tems, Inc. [referenced on February 6, 2004]
http://www.cisco.com/univercd/cc/td/
doc/product/lan/cat3750/12119ea1/
6.2 Address Allocation 3750scg/swmcast.pdf
Perhaps the currently most reasonable way to do multicas- [14] Anon. IP Services — Multicast. Juniper Networks, Inc.
ting is to use the administratively scoped addresses, GLOP [referenced on February 6, 2004]
addresses or SSM unless you manage to persuade IANA that http://www.juniper.net/products/
you really should have your own multicast address or address ip_infrastructure/e-series/
block. There are some address allocation and assignment ip_services_multicast.html

8
HUT T-110.551 Seminar on Internetworking Sjökulla, 2004-04-26/27

MOSPF DVMRP PIM-DM PIM-SM

Root of tree Source Source Source RP or source
Tree is built Before sending After sending datagram and receiving prune On joining
Traffic overhead Signaling Excess data traffic due to flooding Signaling
Neighbor discovery OSPF link-state Own mechanism Unicast routing information
Traffic tunneling No Yes No No

Table 1: Routing protocol properties

[15] P. Rajvaidya, K. C. Almeroth. Analysis of Routing [28] R. Hinden et al. IPv6 Global Unicast Address Format.
Characteristics in the Multicast Infrastructure. Pro- RFC 3587, IETF Network Working Group, 2003.
ceedings of IEEE INFOCOM 2003, San Francisco,
California, USA, March 30 – April 3, 2003. [29] B. Haberman, D. Thaler. Unicast-Prefix-based IPv6
Multicast Addresses. RFC 3306, IETF Network Work-
[16] R. B. Bellman. The Push for IP Multicasting. Business ing Group, 2002.
Communications Review, Vol. 27, No. 6, pp. 28–32.
1997. [30] M. Handley, S. R. Hanna. Multicast Address Alloca-
tion Protocol (AAP). IETF MALLOC Working Group,
[17] Anon. Cisco IOS Multicast Q&A. Cisco Systems, Inc. Internet Draft (draft-ietf-malloc-aap-04),
2003. [referenced on February 25, 2004] 2000.
http://www.cisco.com/warp/public/cc/
pd/iosw/prodlit/mcast_qp.pdf [31] S. R. Hanna et al. Multicast Address Dynamic Client
Allocation Protocol (MADCAP). RFC 2730, IETF Net-
[18] S. Deering et al. The PIM Architecture for Wide-Area work Working Group, 1999.
Multicast Routing. IEEE/ACM Transactions on Net-
working, Vol. 4, No. 2, pp. 153–162. 1996. [32] E. Guttman et al. Service Location Protocol, Version 2.
RFC 2608, IETF Network Working Group, 1999.
[19] A. Ballardie. Core Based Trees (CBT) Multicast Rout-
ing Architecture. RFC 2201, IETF Network Working [33] P. I. Radoslavov et al. The Multicast Address-Set Claim
Group, 1997. (MASC) Protocol. RFC 2909, IETF Network Working
Group, 2000.
[20] B. Fenner (ed), D. Meyer (ed). Multicast Source Dis-
covery Protocol (MSDP). RFC 3618, IETF Network [34] P. I. Radoslavov et al. A Claim–Collide Mechanism for
Working Group, 2003. Robust Distributed Resource Allocation. USC Depart-
ment of CS Technical Report 99-711. 1999.
[21] S. Bhattacharyya (ed). An Overview of Source-Specific
Multicast (SSM). RFC 3569, IETF Network Working [35] D. Thaler. Border Gateway Multicast Protocol
Group, 2003. (BGMP): Protocol Specification. IETF BGMP
Working Group, Internet Draft (draft-ietf-
[22] R. Vida (ed), L. Costa (ed). Multicast Listener Dis- bgmp-spec-06), 2004.
covery Version 2 (MLDv2) for IPv6. Internet Draft
(draft-vida-mld-v2-08), 2003. [36] S. Kumar et al. The MASC/BGMP Architecture for
Inter-Domain Multicast Routing. Proceedings of ACM
[23] D. Meyer et al. Source-Specific Protocol Independent
SIGCOMM ’98, pp. 93–104. Vancouver, British
Multicast in 232/8. IETF MBONE Deployment Work-
Columbia, Canada, September 2–4, 1998.
ing Group, Internet Draft (draft-ietf-mboned-
ssm232-07), 2004. [37] B. Fenner. Note for draft-ietf-bgmp-spec. IETF BGMP
Mailing List, 2004. [referenced on April 7, 2004]
[24] D. Thaler et al. The Internet Multicast Address Alloca-
http://www1.ietf.org/mail-archive/
tion Architecture. RFC 2908, IETF Network Working
working-groups/bgmp/current/
Group, 2000.
msg00001.html
[25] S. Leinen (ed). MBONE Deployment Working Group
[38] Anon. Multicast Address Allocation. Microsoft Corpo-
Minutes. 59th IETF Meeting, Seoul, South Korea,
ration. [referenced on February 10, 2004]
February 29 – March 4, 2004. [referenced on April 5,
http://www.microsoft.com/technet/
2004]
prodtechnol/windowsserver2003/
http://www.ietf.org/proceedings/
proddocs/standard/sag_DHCP_und_
04mar/minutes/mboned.htm
MulticastAllocation.asp
[26] D. Meyer. Administratively Scoped IP Multicast.
RFC 2365, IETF Network Working Group, 1998. [39] J. Lin, R-S. Chang. A Comparison of the Internet Mul-
ticast Routing Protocols. Computer Communications,
[27] D. Meyer, P. Lothberg. GLOP Addressing in 233/8. Vol. 22, No. 2, pp. 144–155. 1999.
RFC 3180, IETF Network Working Group, 2001.