Unit 4: Multicast and Multicast routing · Unit 4: Multicast and Multicast routing Multicast is a...

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.

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



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)



• 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:



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



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.



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.



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:



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.



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).



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



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:



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.



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.



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.



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.



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.



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



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



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.


Unit 4: Multicast and Multicast routing · Unit 4: Multicast and Multicast routing Multicast is a...

Documents

Transcript of Unit 4: Multicast and Multicast routing · Unit 4: Multicast and Multicast routing Multicast is a...