Download Multicasting and Multicast Routing Protocols

Chapter 12: Multicasting and Multicast
Routing Protocols
1
Objectives

12.1 Introduction


12.2 Multicast Addresses


To compare and contrast unicasting, multicasting, and
broadcasting communication
To define multicast addressing space in IPv4 and show the division
of the space into several blocks
12.3 IGMP

To discuss IGMP v3 which is responsible for collecting group
membership information in a network
2
Objectives

12.4 Multicast Routing

To discuss the general idea behind multicast routing protocols



12.5 Routing Protocols

To discuss multicast link state routing, distance vector routing and
core-based protocol (CBT) in general and their implementation in
the Internet


Source-Based Tree
Group-Based Tree
MOSPF / DVMRP / PIM-DM and PIM-SM
12.6 MBONE

To discuss multicast backbone (MBONE) that shows how to create
a tunnel when the multicast messages need to pass through an area
with no multicast routers
3
12.1 Introduction

There are three communication mechanisms
defined and classified as they related to the Internet



Unicasting
Multicasting
Broadcasting
4
Unicast


In unicast routing (Fig. 12.1), the router
forwards the received packet through only
one of its interfaces
In unicast routing, each router in the domain
has a table that defines a shortest path tree
to possible destinations
5
Unicast
Figure 12.1
Unicasting
6
Multicast

In multicasting (Fig. 12.2), there is one
source and a group of destinations


The relationship is one to many
The router may forward the received packet
through several of its interfaces
7
Multicast
Figure 12.2
Multicasting
8
Emulation of Multicasting with
Unicasting

As shown in Fig. 12.3 :

Multicasting is more efficient than multiple unicasting



Multicasting requires less bandwidth than multiple unicasting
In multiple unicasting, some of the links must handle several
copies
In multiple unicasting, the packets are created by the
source with a delay relative to each other


If there are 1000 destinations, the delay between the first and
the last packet may be unacceptable
In multicasting, there is little delay because of multiple packet
creation
9
Emulation of Multicasting with
Unicasting
Legend
S1
Di
Gi
G1
G1
G1
a. Multicasting
G1
Multicast router
Unicast router
Unicast destination
Group member
D1
S1
D2
D3
D4
b. Multiple unicasting
Figure 12.3 Multicasting versus multiple unicasting
10
Application for Multicasting





Access to Distributed Database
Information Dissemination
Dissemination of News
Teleconferencing
Distance Learning
11
Broadcasting


In broadcasting communication, the
relationship between the source and the
destination is one to all
The Internet does not explicitly support
broadcasting because of


Traffic
Bandwidth
12
12.2 Multicast Addresses


A multicast address is a destination address
for a group of hosts that have joined a
multicast group
A packet that uses a multicast address as a
destination can reach all members of the
group unless there are some filtering
restriction by the receiver
13
Multicast Addresses in IPv4


In classful addressing, multicast addresses
occupied the only single block in class D
In classless addressing, the same block has been
used for this purpose


In other words, the block assigned for multicasting is
224.0.0.0/4
This large block, or the multicast address space as
sometimes it is referred to, is divided into some smaller
ranges, as shown in Table 12.1, based on RFC 3171
14
15
Multicast Addresses Ranges

Local Network Control Block

The address in this block are
used for protocol control traffic



Not used for general multicast
communication
TTL = 1
Table 12.2 shows the assignment
of some of these addresses
16
Multicast Addresses Ranges

Internetwork Control Block

Also used for protocol control traffic


AD-HOC Block


But the IP packets with one of these addresses as destination
can be forwarded by router through the whole Internet
This block was traditionally assigned to some
applications that do not fit in the first or second block
discussed above
Stream Multicast Group Block

Allocated for stream multimedia
17
Multicast Addresses Ranges

SAP/SDP Block


SSM Block


Used for Session Announcement Protocol and Session
Directory Protocol
Used for Source Specific Multicasting
GLOP Block

This block defines a range of globally assigned
addresses that can be used inside an autonomous
system
18
Multicast Addresses Ranges

Administratively Scope Block

The addresses in this Administratively Scoped Block
are used in a particular area of the Internet


The packet whose address belongs to this range is not
supposed to leave the area
In other words, an address in this block is restricted to an
organization
19
Selecting Multicast Address

The selection of address depends on the
type of application

For Limited Group:

The administrator can use the AS number (x,y) and
choose an address between 239.x.y.0 and
239.x.y.255 that is not used by any other group as
the multicast address for that particular group
20
Selecting Multicast Address

For Larger Group:



If the group is spread beyond an AS territory, the
previous solution does not work
The group needs to choose an address from the SSM
block (232.0.0.0/8)
There is no need to get permission to use an address
in this block, because the packets in source-specific
multicasting are routed based on the group and the
source address; they are unique
21
Delivery of Multicast Packets at
Data Link Layer

Because the IP packet has a multicast IP
address, the ARP protocol cannot find the
corresponding MAC (physical) address to
forward the packet at the data link layer

What happens next depends on the following
two cases:


Network with Multicast Support
Network with no Multicast Support
22
Network with Multicast Support


Most LANs support physical multicast addressing
Ethernet is one of them


An MAC address is 48 bits long
If the first 25 bits starts with 00000001 00000000
01011100 0, it is a physical multicast address for
TCP/IP


The remaining 23 bits can be used to define a group
To convert an IP multicast address into an Ethernet
address, the router extracts the least significant 23 bits
of a multicast IP address and inserts them into a
multicast Ethernet physical address (see Fig. 12.4)
23
Network with Multicast Support
Figure 12.4
Mapping class D to Ethernet physical address
24
Network with no Multicast
Support


Most WANs do not support physical
multicast addressing
To send multicast packet through these
network, a process called tunneling is used

In tunneling, the multicast packet is
encapsulated in a unicast packet and sent
through the network (Fig. 12.5)
25
Network with no Multicast
Support
Figure 12.5
Tunneling
26
12.3 IGMP

In multicast, each multicast router needs to know
the list of groups to each interface


It means that they need to collect information about
members and share it with others
The Internet Group Management Protocol (IGMP)
is responsible for correcting and interpreting
information about group members in a network

It is one of the protocols designed at the IP layer for this
purpose (Fig. 12.6)
27
12.3 IGMP
Figure 12.6
Position of IGMP in the network layer
28
Group Management



IGMP is not a multicasting routing protocol
IGMP is a protocol that manages group membership
The IGMP protocol gives the multicast routers information
about the membership status of hosts (routers) connected to
the network

It helps a multicast router create and update a list of loyal members
related to each router interface
29
Group Management

IGMP has gone through three versions.



V1 and V2 provide any-source multicast (ASM), which means that
the group members receive a multicast message no matter where it
comes from
V3 provides what is called source-specific multicast (SSM), which
means that the recipient can choose to receive multicast messages
coming from a list of predefined sources
Only V3 is discussed in this section
30
IGMP Messages

Two types of message of IGMPv3



Member ship query message
Membership report message
The former can be used in three different formats
Figure 12.7
IGMP messages
31
Membership query message format

A membership query message is sent by a route to
find active group members in the network
Figure 12.8
Membership query message format
32
Membership query message format

Type


Maximum Response Code



The value is 0x11 for a membership query message
It is used to define the response time of a recipient of
the query
Checksum
Group Address

This field is set to 0 in a general query message; it is set
to IP multicast being queried when sending a groupspecific or group-and-source-specific query message
33
Membership query message format

Resv


S


Reserved for the future
Suppress flag: when this field is set to 1, it means that
the receivers of the query message should suppress the
normal timer updates
QRV

Querier’s robustness variable: it is used to monitor the
robustness in the network
34
Membership query message format

QQIC


Querier’s query interval code: it is used to calculate the
querier’s query interval (QQI), as we will show shortly
Number of sources (N)

This field defines the number of unicast source
addresses attached to the query


The value of this field is zero for the general query and the
group-specific query; and non-zero in the group-and-sourcespecific query
Source Addresses

These fields list the N source address, the origin of
multicast messages
35
Membership query message format

Three formats of query messages (Fig. 12.9)

General query message


Group specific message



The querier router probes each neighbor to report the whole list
of its group membership.
Probes each neighbor to report if it is still interested in a
specific multicast group.
The multicast group address is defined as x.y.z.t in the group
address field of the query.
Group-and-source-specific query message

Probes each neighbor to report if it is still in a specific
multicast group, x.y.z.t, coming from any of the N sources
whose unicast addresses are defined in this packet
36
Membership query message format
Figure 12.9
Three forms of query messages
37
Membership report message format


Version 3 Membership Reports are sent by IP
systems to report (to neighboring routers) the
current multicast reception state, or changes in the
multicast reception state, of their interfaces
Reports have the following format: (Fig. 12.10)
38
Membership report message format
Figure 12.10
Membership report message format
39
Membership report message format

Type



0x22 defines this type of the message
Checksum
Number of Group Records (M)


This field defines the number of group records carried
by the packet
There can be zero or more group records of variable
length
40
Membership report message format


Each group record includes the following
information related to the responder’s membership
in a single multicast group
Record Type

Six record types
41
Membership report message format

Aux Data Len



This field defines the length of the auxiliary data
included in each group record
It may contain zero, to indicate the absence of any
auxiliary data
Number of Sources (N)

The Number of Sources (N) field specifies how many
source addresses are present in this Group Record
42
Membership report message format

Source Addresses


These fields list the source addresses
Aux Data


This field contains any auxiliary data that may be
included in the report message
The IGMP has not yet defined any auxiliary data, but it
may be added to the protocol in the future
43
IGMP Protocol Applied to Host


How a host implements IGMP is discussed
in this section
Hosts need to do the management of groups

Each process (running application programs) associated
with each socket


How to maintain the socket states?
Several interfaces are used


How to maintain interface states?
Can interface states be simplified?
44
Socket state


Each process has a record for each multicast
group
The record shows one of the two modes:

Include mode


It lists the unicast source addresses from which the
socket accepts the group messages
Exclude mode

It lists the unicast source addresses that the socket
will not accept the group messages
45
Example 12.4
Figure 12.11 shows a host with three processes: S1, S2, and S3. The
first process has only one record; the second and the third processes
each have two records. We have used lowercase alphabet to show the
source address.
Figure 12.11
Socket state
46
Interface State

If a record with the same multicast group
has many lists of resources, the following
two rules need to be followed to combine
the list of resources

Each time there is a change in any socket
record, the interface state will change
47
Interface State

Rule 1:

If any of the records to be combined has the exclusive
filter mode, then the resulting interface record will have
the exclusive filter mode and the list of the source
addresses is made as shown below:


Apply the set intersection operation on all the address lists with exclusive
filters
Apply the set difference operation on the result of part a and all the
address lists with inclusive filters
48
Interface State

Rule 2:

If all the records to be combined have the inclusive filter
mode,


Then the resulting interface record will have the inclusive filter
mode
And the list of the source addresses is found by applying the set
union operations on all the address lists
49
Example 12.5
We use the two rules described above to create the interface state for
the host in Example 12.4. First we found the list of source address for
each multicast group.
a. Multicast group 226.14.5.2 has two exclude lists and one
include list. The result is an exclude list as calculated below.
b.
Multicast group: 228.24.21.4 has two include lists. The
result is an include list as calculated below. We use the plus sign
for the union operation.
Figure 12.12 shows the interface state.
50
Example 12.5
Figure 12.12
Interface state
51
Sending Change-State Reports


If there is any change in the interface state,
the host needs to immediately send a
membership report message for that group,
using the appropriate group record(s)
As Figure 12.13 shows, four different cases
may occur in the change, based on the oldstate filter and the new state filter

Only the group records are shown, not the
whole report
52
Figure 12.13 Sending change state reports
53
Receiving Query Reports

When a host receives a query, it does not
respond immediately


It delays the response by a random amount of
time calculated from the value of the Max Resp
Code field
The action of the host depends on the type
of the query received as shown below:
54
Receiving Query Reports
1. If the received query is a general query, the host reset the
interface timer (see Fig. 12.12) to the calculated delay
value

This means if there is any previous delayed response, it is
cancelled
2. If the received query is a group-specific query, then the
corresponding group time (see Fig. 12.12) is reset to the
shorter value of the remaining time for the timer or the
calculated delay

If a timer is not running, its remaining time is considered to be
infinity
55
Receiving Query Reports
3. If the received query is a group-and-source-specific query,
then the action is the same as the previous case

In addition, the list of source is recorded for the delayed response
56
Timer Expiration


Membership report messages are sent by a
host when a timer expires
However, the types and number of group
records contained in the message depends
on the timer
57
Timer Expiration
1. General query received  timer expires:


Host sends a membership report contains one CurrentState-Record for each group in the interface state
If all records to be sent do not fit in one report

They can be split into several reports
2. Group-specific query received  timer expires:

Host sends a membership report contains only one
Current-State-Record for that particular group if it is
still active
58
Timer Expiration
3. Group-and-source-specific query received 
timer expires:


Same as 2.
The type of the single record contained in the report
and source list depends on the filter mode of the group

Include




The record type is Mode_Is_Include (type 1) and the source list is (A . B)
A: group source list / B: received source list
.(dot sign) means the intersection operation
Exclude


The record type is Mode_Is_Exclude(type 2) and the source list is (B - A)
-(minus sign) means the difference operation
59
Report Suppression

In IGMPv2,


If a host receives a report sent by another host,
it cancelled the corresponding timer in its
interface state, which means suppressing the
pending report
In IGMPv3,

This mechanism has been removed from the
protocol for some practical reasons described in
RFC 3376
60
IGMP Protocol Applied to Router


How a router implements IGMP is
discussed in this section
A querier (multicast router) in IGMPv3
needs to handle 6 types of group records
contained in a membership report

Multiple interfaces are used

How to maintain their states?
61
Querier’s State


The multicast router needs to maintain the
state information for each multicast group
associated with each network interface
Figure 12.14 shows an example of a
multicast router and its two state tables
62
Querier’s State
Figure 12.14
Router States
63
Action Taken on Membership
Report Reception

A multicast router sends out queries and receives
reports

When a multicast router receives the reports, it needs to
take some actions to change its state


Reception of Report in Response to General Query
Reception of Reports in Response to Other Queries
64
Reception of Report in Response to
General Query

When a router sends a general query, it expects to
receive a report or reports


This types of a report normally contains Current-StateRecord(types 1 and 2)
When such a report arrives, the router changes its state,
as shown in Figure 12.15
65
Reception of Report in Response to
General Query
Figure 12.15
Change of state related to general query report
66
Reception of Reports in Response to
Other Queries

When a router sends a group-specific or groupand-source-specific query, it expects to receive a
report or reports


This types of a report normally contains FilterState_Mode_Change_Record (types 3 and 4) or
Source_List_Change_Record (types 5 and 6)
When such a report arrives, the router changes its state,
as shown in Figure 12.16
67
Figure 12.16
Change of state related to other report types
68
Role of IGMP in Forwarding


In previous versions of IGMP, the forwarding
recommendation was based only on the
destination multicast address of a packet
In IGMPv3, the recommendation is based on both
destination address and the source address.

RFC 3376 mentions 6 different recommendations that
IGMPv3 software can give to the IP multicast router to
forward or not to forward a packet with respect to an
interface
69
Role of IGMP in Forwarding

If the multicast destination address does not exist in the router state,
the recommendation is definitely not to forward the packet
70
Variables and Timers

Maximum Response Time



The maximum response time is the maximum time
allowed before sending a report in response to a query
It is calculated from the value of the 8-bit Max Resp
Code field in the query
The calculation of the maximum response time is
shown in Fig. 12.17
71
Variables and Timers
RFC 3376:
The Max Response Time in Query messages has an exponential range,
changing the maximum from 25.5 seconds to about 53 minutes, for use on
links with huge numbers of systems
Figure 12.17
Calculation of maximum response time
72
Variables and Timers

Querier’s Robustness Variable (QRV)


It dictates how many times a response message
to a query should be sent
The number of times a host should send a
response to a query is QRV -1

Default value is 2
73
Variables and Timers

Qurier’s Query Interval




This is the interval between the general queries
Default value is 125
This value can be changed by an administrator
to control the traffic on the network
Other Variables and Timers

See RFC 3376
74
IGMP Encapsulation


The IGMP message is encapsulated in an IP datagram with
the value of protocol field set to 2 and the TTL field set to
1
The destination IP address of datagram, however, depends
on the type of the message, as shown in Table 12.5
75
IGMP Compatibility with Older
Versions


To be compatible with V1 and V2, IGMPv3 software is
designed to accept messages defined in V1 and V2.
Table 12.6 shows the value of type fields and the type of
messages in V1 and V2
76
12.4 Multicast Routing

Objectives

To discuss the idea of optimal routing, common in all
multicast protocols


Optimal Routing: Shortest Path Trees
To discuss the general idea behind multicast routing
protocols


Source-Based Tree
Group-Based Tree
77
Optimal Routing: Shortest Path
Trees


The process of optimal inter-domain routing
eventually results in the finding of the shortest
path tree
However, the number of trees and the formation of
the trees in unicast and multicast routing are
different
78
Unicast routing


In unicast routing, each router in the domain
has a table that defines a shortest path tree
to possible destinations
Fig. 12.18 shows the situation
79
Figure 12.18
Shortest path tree in multicast routing
80
Multicast routing


A multicast packet may have destinations in more
than one network
Forwarding of a single packet to members of a
group requires a shortest path tree


N group  N trees (complexity is high)
Two approaches have been used to solve the problem:


Source-based trees
Group-shared trees
81
Source-based trees


In a source-based tree approach, the combination of source
and group determines the tree
If there are N groups and M sources in the system, there
can be a maximum of N*M different trees


In the source-based tree approach, each router needs to have one
shortest path tree for each group
See Fig. 12.19
82
Source-based trees
Figure 12.19
Source-based tree approach
83
Group-shared trees




In the group-shared tree approach, the group determines
the tree
If there are N groups in the system, there is a maximum of
N trees
In the group-shared tree approach, only the core router,
which has a shortest path tree for each group, is involved
in multicasting
See Fig. 12.20
84
Group-shared trees
Figure 12.20
Group-shared tree approach
85
12.5 Routing Protocols


During the last few decades, several multicast
routing protocols have emerged
Some of these protocols are extensions of unicast
routing protocols; some are totally new

Figure 12.21 shows the taxonomy of these protocols
86
Multicast routing protocols
Figure 12.21
Taxonomy of common multicast protocols
87
DVMRP

The Distance Vector Multicast Routing Protocol
(DVMRP) must achieve the following



It must prevent the formation of loops
It must prevent duplications
It must provide for dynamic membership
88
DVMRP

Reverse Path Forwarding (RPF):


In reverse path forwarding (RPF), the router forwards
only the packets that have traveled the shortest path from
the source to the router; all other copies are discarded
RPF prevents the formation of loops in the flooding
process
89
DVMRP
Figure 12.22 RPF
90
DVMRP

Reverse Path Broadcasting (RPB)



Net3 has two parents: routers R2 and R4
For each source, the router sends the packet only out of those
interfaces for which it is the designated parent. This policy is called
reverse path broadcasting
To eliminate duplication, the most common policy is to select the
router with the shortest path to the source as the designed parent router
91
DVMRP

RPF versus RPB

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
92
DVMRP

Reverse Path Multicasting (RPM)



Pruning: The router sends a prune message to
the upstream can stop sending multicast
messages for this group through that interface
Grafting: 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
93
DVMRP
RPF, RPB, and RPM
94
MOSPF



The Multicast Open Shortest Path First (MOSPF) is an
extension of the OSPF protocol that uses multicast link state
routing to create source-based trees
The tree is a least-cost tree (using a metric)
The tree is made all at once
95
CBT
Shared-group tree with rendezvous router
 The Core-Based Tree (CBT) 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) is chosen for each region
96
CBT

Procedure of Transmission in CBT




The source, which may or may not be 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
97
CBT
Sending a multicast packet to the rendezvous router
98
CBT


In CBT, the source sends the multicast
packet (encapsulated in a unicast packet) to
the core router
The core router decapsulates the packet and
forwards it to all interested interfaces
.
99
PIM

Protocol Independent Multicast (PIM) is the
name given to two independent multicast
routing protocols:


Protocol Independent Multicast, Dense Mode
(PIM-DM)
Protocol Independent Multicast, Sparse Mode
(PIM-SM)
100
PIM

PIM-DM



PIM-DM is used in a dense multicast environment,
such as a LAN environment.
PIM-DM uses RPF and prunning/grafting strategies to
handle multicasting. However, it is independent from
the underlying unicast protocol.
PIM-SM



PIM-SM is used in a sparse multicast environment such
as a WAN.
PIM-SM is a group shared routing should notify
protocol that has a rendezvous point (RP) as the source
of the tree.
PIM-SM is similar to CBT but uses a simpler procedure.
101
12.6 MBONE

MBONE



The multicast routers may not be connected directly, but
they are connected logically
Only the routers enclosed in the shaded circles are
capable of multicasting
With tunneling, these multicast routers are not isolated
102
islands
MBONE

Procedure of Transmission in MBONE





A logical tunnel is established by encapsulating the
multicast packet inside a unicast packet.
The multicast packet becomes the data of the unicast
packet
The intermediate (non-multicast) routers route the
packet as unicast routers and deliver the packet from
one island to another
It’s as if the unicast routers do not exist and the two
multicast routers are neighbors.
DVMRP supports MBNOE
103
MBONE
MBONE
104