Compiled by: Krishna Bhandari www.genuinenotes.com
Unit 4: Multicast and Multicast routing
Multicast is a communication method and data delivery scheme in which a single source sends the same
data to multiple receivers simultaneously. Sending a message to such a group of multiple receivers is
called multicasting, and the routing algorithm used is called multicast routing. It is similar to broadcasting
but more secure because it has an added bonus of receiver discretion, where the data is received by
specific users or hosts.
The multicast process involves a single sender and multiple receivers. User datagram protocol (UDP) is the
most common protocol used with multicasting where other network layer protocols like TCP, ARP doesn’t
support multicasting. Email is the best example of multicast, where a user can choose to send mail to
many different addresses, rather than a complete contact list. Another example is the one-to-many
multicasting of a streaming video toward many users from a single server. Another good example is
Internet protocol (IP) multicasting, where network nodes, like switches and routers, handle data packet
replication through multicast groups.
Compiled by: Krishna Bhandari www.genuinenotes.com
Fig: Multicasting Scenario
IP Multicast Applications:
IP multicast is a technique for one-to-many communication over an IP network. The destination nodes
send Internet Group Management Protocol join and leave messages, for example in the case of IPTV when
the user changes from one TV channel to another. IP multicast scales to a larger receiver population by
not requiring prior knowledge of who or how many receivers there are. Multicast uses network
infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be
delivered to a large number of receivers. The nodes in the network take care of replicating the packet to
reach multiple receivers only when necessary.
There are three general categories of multicast applications:
One-to-Many (1toM): A single host sending to two or more (n) receivers.
• Scheduled audio/video (a/v) distribution: Lectures, presentations, meetings, or any other type of
scheduled events
• Push media: News headlines, weather updates, sports scores
• File Distribution and Caching: Web site content, executable binaries, and other file-based updates
sent to distributed end-user or replication/caching sites
• Announcements: Network time, multicast session schedules, random numbers, keys,
configuration updates
• Monitoring: Stock prices, Sensor equipment (seismic activity, telemetry, meteorological or
oceanic readings), security systems, manufacturing or other types of real-time information
Compiled by: Krishna Bhandari www.genuinenotes.com
Many-to-Many (MtoM): Any number of hosts sending to the same multicast group address, as well as
receiving from it.
• Multimedia Conferencing
• Synchronized Resources: Shared distributed databases of any type
• Concurrent Processing: Distributed parallel processing.
• Collaboration: Shared document editing.
• Distance Learning
• Chat Groups
• Multi-player Games
• Jam Sessions: Shared encoded audio (e.g., music).
Many-to-One (Mto1): Any number of receivers sending data back to a (source) sender via unicast or
multicast.
Unlike the one-to-many and many-to-many application categories, the many-to-one (Mto1) category does
not represent a communications mechanism at the IP layer.
• Resource Discovery
• Data Collection
IP multicast: abstraction of hardware multicast
The internet abstraction of hardware multicasting includes following characteristics:
– Group address: class D address, some permanent, some temporary
– Number of groups: limited by practical constraints on routing table size, actual is 228
– Dynamic group membership: hosts can join or leave anytime
– Use of hardware: if the underlying hardware permits multicast, IP uses hardware to send,
else it uses broadcast or unicast to send!
– Inter-network forwarding: multicast routers are required to forward IP multicast
(capability is usually added to conventional routers)
– Delivery semantics: uses the same best-effort IP delivery - multicast datagrams may be
lost, delayed, duplicated, delivered out of order
– Membership and transmission: any may send to the multicast group; only the group may
receive
IP multicast service model:
IP Multicast Service Models are of three types: Any-Source Multicast (ASM), Source-Filtered Multicast
(SFM) and Source-Specific Multicast (SSM).
Any-Source Multicast (ASM)
Compiled by: Krishna Bhandari www.genuinenotes.com
• A recipient, by joining a group identified by the multicast address, can receive data sent to the
group.
• A recipient can join or leave a group at any time, and the recipient location or quantity is not
limited.
• In addition, any sender can serve as the multicast source to send data to the group.
• Destination ‘multicast’ address only defines ‘Group’ membership
Source-Filtered Multicast (SFM)
• As an extension of ASM, source-filtered multicast (SFM) extends the source filtering function of
the upper-layer protocol module. That is, in the SFM model, whether the multicast data of
specified multicast source(s) is allowed to pass can be controlled.
• Destination ‘multicast’ address only defines ‘Group’ membership
• Excluded List (mode), implies include everything else
• Include List (mode), implies exclude everything else
Source-Specific Multicast (SSM)
• Source-specific multicast (SSM) is a method of delivering multicast packets in which the only
packets that are delivered to a receiver are those originating from a specific source address
requested by the receiver.
• Adds new concept of ‘Channel’ rather than Group
• Source (unicast) and destination multicast Group address together define a single ‘Channel’ for
membership
• Like SFM Include List (mode) but with single source which is now significant for membership
• (S,G) Channel is not the same as (S,G) Group
• ASM and SFM receivers joining a Group receives from ALL sources unless filtered
• (S,G) Group represents filtered source (include or exclude)
• ASM and SFM good for many-to-many interactions
• SSM is good for one-to-many interactions
• Application may include two one-to-many, primary & Backup
IP multicast addresses:
The IP multicast addresses are in the range 224.0.0.0 through 239.255.255.255 i.e. class D. The distribution
of multicast addresses is as follows:
Compiled by: Krishna Bhandari www.genuinenotes.com
Local subnetwork (Protocols)
Addresses in the range of 224.0.0.0 to 224.0.0.255 are individually assigned and designated for
multicasting on the local subnetwork only. These addresses are reserved for protocols. For example, the
Routing Information Protocol (RIPv2) uses 224.0.0.9, Open Shortest Path First (OSPF) uses 224.0.0.5 and
224.0.0.6, and Multicast DNS uses 224.0.0.251. Routers must not forward these messages outside the
subnet from which they originate.
Internetwork control block (Public communication)
Addresses in the range 224.0.1.0 to 224.0.1.255 are individually assigned and designated as the
internetwork control block. This block of addresses is used for traffic that must be routed through the
public Internet, such as for applications of the Network Time Protocol using 224.0.1.1.
AD-HOC block (Unassigned)
Addresses in three separate blocks are not individually assigned. These addresses are globally routed and
are used for applications that don't fit either of the previously described purposes.
Source-specific multicast (SSM)
The 232.0.0.0/8 (IPv4) and ff3x::/32 (IPv6) blocks are reserved for use by source-specific multicast.
GLOP (Reserved for ISPs)
The 233.0.0.0/8 range was originally assigned by RFC 2770 as an experimental, public statically assigned
multicast address space for publishers and Internet service providers that wished to source content on
the Internet. The allocation method is termed GLOP addressing and provides implementers a block of 255
addresses that is determined by their 16-bit autonomous system number (ASN) allocation.
Unicast-prefix-based (/8 multicast provided for /24 unicast network)
The 234.0.0.0/8 range is assigned by RFC 6034 as a range of global IPv4 multicast address space provided
to each organization that has /24 or larger globally routed unicast address space allocated; one multicast
Compiled by: Krishna Bhandari www.genuinenotes.com
address is reserved per /24 of unicast space. A resulting advantage over GLOP is that the mechanisms in
IPv4 and IPv6 become more similar.
Administratively scoped (Private use within organization)
The 239.0.0.0/8 range is assigned by RFC 2365 for private use within an organization. From the RFC,
packets destined to administratively scoped IPv4 multicast addresses do not cross administratively
defined organizational boundaries, and administratively scoped IPv4 multicast addresses are locally
assigned and do not have to be globally unique. The RFC also discusses structuring the 239.0.0.0/8 range
to be loosely similar to the scoped IPv6 multicast address range described in RFC 1884.
Link-level/hardware multicast:
When a computer joins a multicast group, it needs to be able to distinguish between normal unicasts
(which are packets directed to one computer or one MAC address) and multicasts. With hardware
multicasting, the network card is configured, via its drivers, to watch out for particular MAC addresses (in
this case, multicast MAC addresses) apart from its own. When the network card picks up a packet which
has a destination MAC that matches any of the multicast MAC addresses, it will pass it to the upper layers
for further processing.
Ethernet is a good example of hardware multicast. Most Ethernets support multicast.
Ethernet multicast addresses: (FF-FF-FF-FF-FF-FF)
The low order bit of the high order byte is 1:
*1:**:**:**:**:**
Ethernet uses the low-order bit of the high-order octet to distinguish conventional unicast addresses from
multicast addresses. A unicast would have this bit set to ZERO (0), whereas a multicast would be set to
ONE (1).
Many NICs on the same network may listen to the same Ethernet multicast address. Other Link-level layers
may not support multicast, being NBMA (Non-Broadcast Multiple Access).
Mapping IP multicast to Ethernet:
For mapping IP Multicast addresses to Ethernet Addresses, the lower 23 bits of a Class D IP Address are
copied to one of the IANA (Internet Assigned Numbers Authority) Designated Ethernet Addresses.
Note: A key IANA function is the global coordination of the Internet Protocol addressing systems,
commonly known as IP Addresses.
Ethernet addresses reserved for this purpose are in the range of 01:00:53:00:00:00 through
01:00:5e:7f:ff:ff. Ethernet Addresses have a 48 bit address field (Source and Destination 48 bits each one).
Expressed in hexadecimal numbering, the first 24 bits of an Ethernet multicast address are 01:00:5e, this
indicates the frame as multicast, the next bit in the Ethernet address is always 0, leaving 23 bit for the
multicast address.
Compiled by: Krishna Bhandari www.genuinenotes.com
Because IP Multicast groups are 28 bits (1110XXXX XXXXXXXX XXXXXXXX XXXXXXXX) long and there are
only 23 bits available the mapping cannot be one to one, so only 23 low order bits of the multicast group
ID are mapped onto the Ethernet address. The 5 higher order bit remain in the multicast group are
ignored.
This means that we have to map multiple Multicast IP addresses to the same Multicast MAC address. We
don’t have enough MAC addresses to give each multicast IP address its own MAC address. We miss 5 bits
of mapping information: 2^5 = 32. This means we will map 32 multicast IP addresses to 1 multicast MAC
address.
An example:
Having the following IP Multicast Address 224.192.16.1 convert it to the appropriate Ethernet MAC
Representation.
Compiled by: Krishna Bhandari www.genuinenotes.com
224. 192. 16. 1
11100000.11000000.00010000.00000001
Multicast Ethernet
01:00:5e
00000001.00000000.01011110.0XXXXXXX.XXXXXXXX.XXXXXXXX
11100000.11000000.00010000.00000001
Final=
00000001.00000000.0101 1110.0100 0000.0001 0000.0000 0001
01 00 5 E 4 0 1 0 0 1
01:00:5E:40:10:01
Internet Group Message Protocol (IGMP):
The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and
adjacent routers on IPv4 networks to establish multicast group memberships. IGMP is an integral part of
IP multicast. In other words, IGMP is an Internet protocol that provides a way for an Internet computer to
report its multicast group membership to adjacent routers. Multicasting allows one computer on the
Internet to send content to multiple other computers that have identified themselves as interested in
receiving the originating computer's content. IGMP can be used for one-to-many networking applications
such as online streaming video and gaming, and allows more efficient use of resources when supporting
these types of applications.
Position of IGMP in TCP\IP:
Compiled by: Krishna Bhandari www.genuinenotes.com
IGMP Messages:
IGMP V2 Message:
These versions are backwards compatible. A router supporting IGMPv3 can support clients running
IGMPv1, IGMPv2 and IGMPv3. IGMPv1 uses a query-response model. Queries are sent to 224.0.0.1.
Membership reports are sent to the group's multicast address. IGMPv2 accelerates the process of leaving
a group and adjusts other timeouts. Leave-group messages are sent to 224.0.0.2. A group-specific query
is introduced. Group-specific queries are sent to the group's multicast address. A means for routers to
select an IGMP querier for the network is introduced.
Compiled by: Krishna Bhandari www.genuinenotes.com
Type
Indicates the message type as follows: Membership Query (0x11), Membership Report (IGMPv1: 0x12,
IGMPv2: 0x16, IGMPv3: 0x22), Leave Group (0x17)
Max Resp Time
Specifies the time limit for the corresponding report. The field has a resolution of 100 milliseconds, the
value is taken directly. This field is meaningful only in Membership Query (0x11); in other messages it is
set to 0 and ignored by the receiver.
Group Address
This is the multicast address being queried when sending a Group-Specific or Group-and-Source-Specific
Query. The field is zeroed when sending a General Query.
Overview of IGMP V3:
IGMP Version 3 (IGMPv3) adds support for “source filtering,” which enables a multicast receiver host to
signal to a router which groups it wants to receive multicast traffic from, and from which source(s) this
traffic is expected. IGMP version 1 and version 2 allow hosts to join multicast groups but they don’t
check the source of the traffic. Any source is able to receive traffic to the multicast group(s) that they
joined. IGMPv3 supports applications that explicitly signal sources from which they want to receive
traffic.
With IGMPv3, receivers signal membership to a multicast host group in the following two modes:
• INCLUDE mode—In this mode, the receiver announces membership to a host group and provides a list
of IP addresses (the INCLUDE list) from which it wants to receive traffic.
• EXCLUDE mode—In this mode, the receiver announces membership to a host group and provides a list
of IP addresses (the EXCLUDE list) from which it does not want to receive traffic. This indicates that the
host wants to receive traffic only from other sources whose IP addresses are not listed in the EXCLUDE
list.
Dynamics of IGMP message:
IGMP operates locally, i.e., within a network. The Internet Group Management Protocol offers functions
that a station can use to inform the router assigned to it that it is to be included in a multicast group. On
the other hand, it enables the routers to remember outgoing interfaces of those receiver devices that are
to receive certain IP multicast data streams to be able to send specific reports as soon as corresponding
data is received.
Joining a Group – Router: A router also maintains a list of groupids that show membership for the
networks connected to each interface. If a multicasting router receives a membership report from a device
attached to an interface for a network where there was not already interest, the router will issue a
membership report message to a device on the network that supplies the multicast packets for this group.
Router acts like host but group list is much broader (accumulation of all loyal members that are connected
to its interfaces).
Compiled by: Krishna Bhandari www.genuinenotes.com
Leaving a Group: There must be a mechanism for a device to report that it no longer wishes to have
membership in a group. When a host sees that no process is interested in a specific group, it sends a leave
report. When a router determines that none of the networks connected to its interfaces is interested in a
specific group, it sends a leave report about that group.
Monitoring membership: A host or router can join a group by sending a membership report message and
leave by sending a leave report message. However, sending these two types is not enough. The multicast
router is responsible for monitoring all the hosts or routers in a LAN to see if they want to continue their
membership in a group. The router periodically sends a general query message in which group address
field is set to 0.0.0.0. It expects a response for each group in its group list. The query message has a
maximum response time of 10s. When a host or router receives the general query message, it responds
with a membership report if it is interested in a group.
IGMP snooping: IGMP is an L3 protocol. Switches are L2. When a multicast L2 message comes in to a
switch, it does not know where the members are -> must flood on all ports. For large bridged networks,
this may waste a lot of bandwidth, especially for high bandwidth applications (eg IPTV). Bridges may
therefore listen to IGMP messages, and prune/graft traffic based on this. This is called IGMP snooping.
Multicast router:
An mrouter, or multicast router, is a router program that distinguishes between multicast and unicast
packets and determines how they should be distributed along the Multicast Internet (sometimes known
as the Multicast Backbone or MBone). Using an appropriate algorithm, an mrouter tells a switching device
what to do with the multicast packet.
Multicast router listens to all multicast traffic and forwards if necessary. Multicast router listens to all
multicast addresses. Ethernet: 223 link layer multicast addresses. Listens promiscuously to all LAN
Compiled by: Krishna Bhandari www.genuinenotes.com
multicast traffic. Communicates with directly connected hosts via IGMP. Communicates with other
multicast routers with multicast routing protocols.
There are two approaches for multicasting in a multicast router: dense-mode routing and sparse-mode
routing. These protocols are used in distributing multicast packets. The protocol to be used depends on
the available bandwidth and the different distributions of end-users across the network. Dense-mode
routing is used when there is a large number of end-users and the bandwidth is enough to cater them.
Meanwhile, sparse-mode routing is used when there is limited bandwidth and end-users are thinly
distributed.
Multicast Routing Overview:
A packet received on a router is forwarded on many interfaces. The network replicates the packets – not
the hosts. All routing protocols aim at building delivery trees through a network. Mostly multicast routing
is more concerned where packets come from instead of where they are going.
Multicast VS Multiple unicast:
Compiled by: Krishna Bhandari www.genuinenotes.com
Delivery Tree:
A tree structure, described multicast packets route from the sender to receivers. The sender is a root of
the tree, and receivers are leaves. Multicast routing is about building forwarding trees from the sender S
to the group G of receivers or listeners.
Group Shared Trees: (*, G)
• Same delivery tree for all senders
• Router state: O(G)
• But suboptimal paths and delays
• Unidirectional or Bidirectional
Source Based Trees: (S, G)
• Different delivery tree for each sender
• Router state: O(S*G),
• Optimal paths and delay.
Data-driven / Push
• Trees built when data packets are sent
Demand-driven / Pull
• Build when members join
Multicast Routing Protocol:
A multicast routing protocol manages group membership and controls the path that multicast data takes
over the network.
Compiled by: Krishna Bhandari www.genuinenotes.com
Source Based Tree:
In the source based-tree approach, there is one tree built per active sender in the group. Each tree can
therefore be defined by the sender id and the group id, or (S,G). All the trees are shortest path trees with
the root in the multicast router closest to the sender. All other multicast routers have to keep track of all
the (S, G) trees it is involved in.
In Figure, we see a group’s source-based tree. There are two trees because there are two active senders
in the group. If the group’s id is Q, the two trees will be denoted (S1, Q) and (S2, Q). As can be seen, both
trees are shortest path trees, but also that they partly overlap.
DVMRP (Distance Vector Multicast Routing Protocol):
The Distance Vector Multicast Routing Protocol (DVMRP) is a routing protocol used to share information
between routers to facilitate the transportation of IP multicast packets among networks. Multicast
distance vector routing uses source-based trees, but the router never actually makes a routing table.
When a router receives a multicast packet, it forwards the packet as though it is consulting a routing table.
The shortest path tree is temporary i.e. after the packet is forwarded, the table is destroyed. To
accomplish this, the multicast distance vector algorithm uses a process based on four decision making
strategies. Each strategy is based on its predecessor by improving the shortcomings of the previous one.
Flooding:
A router receives a packet and without even looking at the destination group address, sends it out from
every interface except the one from which it was received. Flooding accomplishes the first goal of
multicasting: every network with active members receives the packet. However, so will networks without
active members. This is a broadcast, not a multicast. There is another problem: it creates loops. A packet
that has left the router may come back again from another interface or the same interface and be
forwarded again. Some flooding protocols keep a copy of the packet for a while and discard any duplicates
to avoid loops.
Spanning Tree:
Effective solution of flooding is spanning tree. Defines a tree structure where only one active path
connects any two routers.
Compiled by: Krishna Bhandari www.genuinenotes.com
Figure: Internetwork and a spanning tree
A multicast router simply forwards each multicast packet to all interfaces that are part of the spanning
tree except the one on which the packet originally arrived. Forwarding along the branches of a spanning
tree guarantees that the multicast packet will not loop since there is only one path to reach each node
through a spanning tree.
Reverse Path Forwarding (RPF):
RPF is modified flooding strategy. To prevent loops, only one copy is forwarded, the other copies are
dropped. In RPF, a router forwards only the copy that has travelled the shortest path from the source to
the router. To find this copy, RPF uses the unicast routing table. The router receives a packet and extracts
the source address (a unicast address). It consults its unicast routing table as though it wants to send a
packet to the source address. The routing table tells the router the next hop. If the multicast packet has
just come from come from the hop defined in the table, the packet has travelled the shortest path from
the source to the router because the shortest path is reciprocal in unicast distance vector routing tables.
If the path from A to B is the shortest, then it is also the shortest from B to A. The router forwards the
packet if it has travelled from the shortest path, it discards it otherwise. This strategy prevents loops
because there is always one shortest path from the source to the router.
The shortest path tree as calculated by routers R1, R2 and R3 is shown by the thick line. When router R1
receives a packet from the source through the interface m1, it consults its routing table and finds that the
shortest path from R1 to the source is through the interface m1. The packet is forwarded. However, if a
copy of the packet has arrived through the interface m2, it is discarded because m2 does not define the
shortest path from R1 to the source. This process is continued for all the remaining routers.
Compiled by: Krishna Bhandari www.genuinenotes.com
Reverse Path Broadcasting (RPB):
RPF guarantees that each network receives a copy of the multicast packet without formation of loops.
However, RPF does not guarantee that each network receives only one copy, a network may receive two
or more copies. The reason is that RPF is not based on the destination address ( a group address),
forwarding is based on the source address.
Fig: Problem with RPF
To eliminate duplication, we must define only one parent router for each network. We must have
restriction: a network can receive a multicast packet from a particular source only through a designated
parent router. For each source, the router sends the packet only out of those interfaces for which it is a
designated parent. This policy is called reverse path broadcasting (RPB). RPB guarantees that the packet
reaches every network and that every network receives only one copy. The figure below shows the
difference between RPF and RPB.
The designated parent router can be the router with the shortest path to the source. Because routers
periodically send updating packets to each other (in RIP), they can easily determine which router in the
neighborhood has the shortest path to the source. To summarize, RPB creates a shortest path broadcast
tree from the source to each destination. It guarantees that each destination receives one and only one
copy of the packet.
Reverse Path Multicasting (RPM):
RPB does not multicast the packet, it broadcasts it. This is not efficient. To increase efficiency, the
multicast packet must reach only those networks that have active members for that particular group.
This is called reverse path multicasting (RPM). To convert broadcasting to multicasting, the protocol uses
two procedures: pruning and grafting.
Compiled by: Krishna Bhandari www.genuinenotes.com
Figure: Reverse Path Multicasting (RPM)
The designated parent router of each network is responsible for holding the membership information.
This is done through the IGMP protocol. The process starts when a router connected to a network finds
that there is no interest in a multicast packet. The router sends a prune message to the upstream router
so that it can exclude the corresponding interface. That is, the upstream router can stop sending
multicast messages for this group through that interface. Now if this router receives prune messages
from all downstream routers, it in turn sends a prune message to its upstream router.
If a leaf router has sent a prune message but suddenly realizes, through IGMP, that one of its networks
is again interested in receiving the multicast packet, it can send a graft message. The graft message
forces the upstream router to resume sending the multicast messages.
RPM adds pruning and grafting to RPB to create a multicast shortest path tree that supports dynamic
membership changes.
The distance vector multicast routing protocol (DVMRP) is an implementation of distance vector routing.
It is a source-based routing protocol, based on RIP.
Multicast Open Shortest Path First (MOSPF):
MOSPF is an extension of the OSPF protocol that uses multicast link state routing to create source-based
trees. The protocol requires a new link state update packet to associate the unicast address of a host with
the group address or addresses the host is sponsoring. This packet is called the group membership LSA. In
this way, we can include in the tree only the hosts (using their unicast address) that belong to a particular
group. In other words, we make a tree that contains all the hosts belonging to a group, but we use the
unicast address of the host in the calculation. For efficiency, the router calculates the shortest path trees
on demand (when it receives the first multicast packet). In addition, the tree can be saved in cache
memory for future use by the same source/group pair. MOSPF is a data-driven protocol, the first time an
MOSPF router sees a datagram with a given source and group address, the router constructs the Dijkstra
shortest path tree.
Protocol Independent Multicast (PIM):
PIM is the name given to two independent multicast routing protocols: Protocol Independent Multicast-
Dense Mode (PIM-DM) and Protocol Independent Multicast-Sparse Mode (PIM-SM). Both protocols are
unicast-protocol-dependent, but the similarity ends here.
Compiled by: Krishna Bhandari www.genuinenotes.com
Protocol Independent Multicast- Dense Mode (PIM-DM):
It is used when there is a possibility that each router is involved in multicasting (dense mode). In this
environment, the use of a protocol that broadcasts the packet is justified because almost all routers are
involved in the process. E.g. LAN. PIM-DM is a source-based tree routing protocol that uses RPF and
pruning and grafting strategies for multicasting. Its operation is like that of DVMRP however unlike
DVMRP, it does not depend on a specific unicasting protocol. It assumes that the autonomous system is
using a unicast protocol and each router has a table that can find the outgoing interface that has an
optimal path to a destination. This unicast protocol can be a distance vector protocol (RIP) or link state
protocol (OSPF).
Group-Shared Tree:
The more common way to distribute multicast traffic is by setting up shared distribution trees. Recall that
with Source based tree, the root of the tree is at the source and each source creates its own S, G entry.
With group-shared tree, there is a shared (configured) root for multicast distribution. Often times this
shared root is called the Rendezvous Point (RP) and is essential for the proper configuration of various
multicast routing protocols. Each source must send their traffic to the RP for correct distribution to all
receivers. Instead of a S, G entry, this creates a *, G entry within the multicast routing table. The *
represents "all sources." The diagram below illustrates a shared tree.
Fig: Group-Shared tree for multicasting
In the group-shared tree approach, instead of each router having m shortest path trees, only one
designated router, called the center core, or the rendezvous router, takes the responsibility of
distributing multicast traffic. The core has m shortest path trees in its routing table. The rest of the
routers in the domain have none. If a router receives a multicast packet, it encapsulates the packet in a
Compiled by: Krishna Bhandari www.genuinenotes.com
unicast packet and sends it to the core router. The core router removes the multicast packet from its
capsule, and consults its routing table to route the packet.
Core Based Tree (CBT):
The core-based tree protocol is a group-shared protocol that uses a core as the root of the tree. The
autonomous system is divided into regions, and a core (center router or rendezvous router) is chosen
for each region.
Formation of the tree: After the rendezvous point is selected, every router is informed of the unicast
address of the selected router. Each router then sends a unicast join message (similar to a grafting
message) to show that it wants to join the group. This message passes through all the routers that are
located between the sender and rendezvous router. When the rendezvous router has received all join
messages from every member of the group, the tree is formed.
Sending multicast packets: After formation of the tree, any source (belonging to the group or not) can
send a multicast packet to all members of the group. It simply sends the packet to the rendezvous
router, using the unicast address of the rendezvous router. The rendezvous router then distributes the
packet to all members of the group.
Selecting the rendezvous router: One of the routers in the tree is called the core.
A packet is sent from the source to members of the group following this procedure:
• The source, which may or may not be the part of the tree, encapsulates the multicast packet
inside a unicast packet with the unicast destination address of the core and sends it to the core.
This part of delivery is done using a unicast address; the only recipient is the core router.
• The core decapsulates the unicast packet and forwards it to all interested interfaces.
• Each router that receives the multicast packet, in turn, forwards it to all interested interfaces.
Protocol Independent Multicast- Sparse Mode (PIM-SM):
PIM-SM is used when there is a slight possibility that each router is involved in multicasting (sparse
mode). In this environment, the use of a protocol that broadcasts the packet is not justified, a protocol
Compiled by: Krishna Bhandari www.genuinenotes.com
such as CBT that uses a group-shared tree is more appropriate. PIM-SM is used in a sparse multicast
environment such as a WAN.
It is a group-shared tree routing protocol that has a rendezvous point (RP) as the source of the tree. Its
operation is like CBT; however, it is simpler because it does not require acknowledgement from a join
message. In addition, it creates a backup set of RPs for each region to cover RP failures. One of the
characteristics of PIM-SM is that it can switch from a group-shared tree strategy to a source-based tree
strategy when necessary. This can happen if there is a dense area of activity far from the RP. That area
can be more efficiently handled with a source-based tree strategy instead of a group-shared tree
strategy.