Computer Networks :

Protocols and Practice

Part 7 : Multicast

Olivier Bonaventure
http://inl.info.ucl.ac.be/

CNPP/2008.1. © O. Bonaventure 2008

These slides are licensed under the creative commons attribution share-alike license 3.0. You can obtain detailed
information
about this license at http://creativecommons.org/licenses/by-sa/3.0/
 The motivation for non-unicast

Principles of unicast transmission

Source is identified by a unique address
Destination is identified by a unique address
Packets are sent from Source towards Destination

Motivation for a different mode than unicast

How to transmit same info to set of receivers ?
Source-based solution
sender sends N copies of this information, one for each receiver
easy to implement, but consumes a lot of bandwidth
Network-based solution
sender sends a single copy of the information
network (routers) takes care of distributing this information
efficiently towards all interested receivers
more efficient, but requires specific protocols and mechanisms

CNPP/2008.7. © O. Bonaventure 2008

General references on multicast include

B. Williamson, Developing IP Multicast Networks, Cisco Press, 2000

A presentation with the same information as in this book is available from ftp://ftpeng.cisco.com/ipmulticast/index.html

J. Crowcroft, M. Hanldey, Internetworking multimedia, UCL Press, 1998

http://www.cs.ucl.ac.uk/staff/jon/mmbook/book/book.html
A good list of references may be found in :
http://www.switch.ch/network/ipmcast/references.html
See also
M. Handley, J. Crowcroft, Internet multicast today, Internet Protocol Journal, Vol2, N4, Dec. 1999,
http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac198/about_cisco_ipj_archive_article09186a00800c851e.html
For tomorrow's multicast, see :
Ian Brown, Jon Crowcroft, Mark Handley, Brad Cain, Internet Multicast Tomorrow, Internet Protocol Journal,

http://www.cisco.com/en/US/about/ac123/ac147/ac175/about_cisco_ipj_archive09186a0080132b7c.html
A short discussion of IP multicast may be found in :
J. Kurose, K. Ross, Computer Networking : a top-down approach featuring the Internet, 2nd Edition, Addison Wesley, 2002
R. Perlman, Interconnections, 2nd Edition, Addison Wesley
 Dimensions to consider

Senders
Number of senders
How many endsystems will send packets
Localization of the senders
Where are these senders located ?
Volatility of the senders
How often does the set of senders change ?
Receivers
Number of receivers
How many endsystems will receive packets ?
Localization of the receivers
Where are all the receivers for a given transmission ?
Volatility of the senders
How often does the set of receivers change ?

CNPP/2008.7. © O. Bonaventure 2008

3
 Dimensions to consider (2)

Characteristics of the data traffic

Traffic volume
bits, kilobits, megabits per second
Traffic burstiness
one packet from time to time
a continuous flow of packet
Large bursts of packets separated by long idle times
Lifetime of a multicast transmission
one second, a few minutes, several hours
Num. of concurrent multicast transmissions
a few, a few tens, a few thousands, millions
Multicast level
LAN-level, network level, application level

CNPP/2008.7. © O. Bonaventure 2008

4
 Network-level multicast

Principle of the solution

Sender
Receiver4
R1 R2

Sender sends multicast packets R4

towards group of receivers identified
R3
by group address

Routers need to :
R7
know the existence of local receivers R5
for each defined group address
distribute this information to others
R6
decide on which links to retransmit
each received multicast packet Receiver3
packets should reach all receivers
packets should not be sent Receiver1
several times on the same links
Receiver2
Receivers must indicate their interest in receiving
packets destined to specific group addresses
CNPP/2008.7. © O. Bonaventure 2008

5
 Application-level multicast

Sender
Receiver4
R1 R2

Sender sends packets R4

towards a few receivers
R3
Routers only see normal unicast packets

R5 R7
Application copy and reproduce info
Application-level topology should
be tuned to avoid R6
sending the same information
several times over costly links Receiver3
Receiver1

Each receiver resends information

towards a few other receivers
Receiver2

Examples : Usenet news, IRC, some P2P apps, ...

CNPP/2008.7. © O. Bonaventure 2008

6
 Sample non-unicast applications

Localization applications
a server announces its availability
a client tries to locate the closest server

Distribution of real-time information

Multiparty conferences
Distributed games
Real-time Monitoring
Temperature
stock prices

Reliable distribution of information

software updates
news information

CNPP/2008.7. © O. Bonaventure 2008

7
 Localization of services

How to find the closest server for service Y ?

Network-based anycast service
Network-level solution
IP address A.B.C.D reserved for service Y
each server uses A.B.C.D as logical address
routers distribute route towards A.B.C.D/32

R2 Routing table
R1 West 1
R1 Routing table R1 R2 R4 East 1
R2 East 1 R3 West 2
R4 East 2 R4 A.B.C.D/32 W 2
R3 South-East 1
A.B.C.D/32 SE 1 R3
R4 Routing table
R2 NWest 1
R3 S-W 1
R1 Nwest 2
A.B.C.D/32 SW 2

CNPP/2008.7. © O. Bonaventure 2008

The anycast service is defined in :

Patridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
This type of service is used notably for some DNS servers. For example, several ISPs place several copies of their DNS servers at various
locations and each of those servers uses the same IP address. This allows the ISP customers to utilize the same IP addresses in their
configuration independently of their location.
Another example is the utilization of anycast for one of the root servers, see :
http://www.as112.net/

http://www.ripe.net/ripe/draft-documents/k-root-anycasting.html
 Distribution of realtime information

Example : N-way videoconference with RTP

Network-level solution
One multicast group for audio
One multicast group for video
One multicast group for shared whiteboard
All participants send data to everybody

Number of senders : a few R1 R2

Number of receivers : a few
Data traffic R4
continuous for video
may be bursty for audio R3
bursty for whiteboard User1 User3
Lifetime : long
Volaticity : stable
Concurrent sessions : can be User2
large
CNPP/2008.7. A distributed game would be different © O. Bonaventure 2008

For example realtime applications supporting multicast, see :

http://www-mice.cs.ucl.ac.uk/multimedia/software/
 Distribution of realtime information (2)

Live audio/video
one sender transmits streaming audio/video to
large number of receivers

Sender
R1 R2

R4 Receiver4

R3
Number of senders : one
Number of receivers : can be R5 R7
large
Data traffic
continuous R6
Lifetime : long
Volatility : volatile or stable Receiver3
Concurrent sessions : usually few
Receiver1

CNPP/2008.7.
Receiver2 © O. Bonaventure 2008

10
 Reliable distribution of information

Information is delivered reliably and efficiently

to all destinations
Application level solution
Usenet News, Mailing lists, software updates
Application relays placed at key network locations
is widely deployed today

Network-level solution
Information distributed by multicast packets
Issue
Multicast transport protocol are required for reliability
Those protocols are deployed in some enterprise networks, but
not widely available in the global Internet

CNPP/2008.7. © O. Bonaventure 2008

11

Concerning the application-level solutions, several researchers are currently working on the definition of generic multicast overlays that could
be used by applications.

Several reliable multicast protocols have been proposed during th e last years.
RFC 2887: The Reliable Multicast Design Space for Bulk Data Transfer
M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby, August 2000
RFC 3208: PGM Reliable Transport Protocol Specification
T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R.
Edmonstone, R. Sumanasekera, L. Vicisano, December 2001
See also :
http://www.ietf.org/html.charters/rmt-charter.html
 The benefits and costs
of network-level multicast
Benefits
Multicast allows a more efficient utilization of the
available bandwidth
no unnecessary packet duplication

But, to support IP multicast, routers must

implement special multicast routing protocols
implementation and configuration cost
maintain some state information for multicast
memory consumption
IP multicast packets require special treatment
CPU consumption

The bandwidth saved should be compared to the router costs!

CNPP/2008.7. © O. Bonaventure 2008

12
 The Any-Source IP Multicast (ASM)
service model
Principles
A fraction of the IP address space is reserved
exclusively for IP multicast
224.0.0.0 -> 239.255.255.255

A multicast address identifies

a group of receivers
receivers can join and leave a group at any time
members of a group can be located anywhere
Any source host can transmit IP packets towards
any IP multicast address
a sender does not need to be a member of a group
Routers take care of the efficient transmission of
multicast packets towards their destinations
Packet forwarding based on destination address

CNPP/2008.7. © O. Bonaventure 2008

13

The ASM model was defined in :

S. Deering, Host extensions for IP multicasting. RFC1112, 1-1989.

 IP Multicast addresses

Initial Allocation of IP addresses

Well-known addresses
224.0.0.1 : all hosts
224.0.0.2 : all multicast routers
224.0.0.5 : all OSPF routers
Other addresses like 224.0.1.11
Reserved addresses to broadcast IETF meetings

Dynamic multicast address assignment

sdr application listens to special multicast group
this group is used to broadcast announcements of the creation of
new IP multicast groups
When an application needs to create a multicast group, it
requests sdr to select one address at random
sdr checks that it did not heard anything about this IP address
Suitable for research experiments, ...
more difficult in a commercial Internet

CNPP/2008.7. © O. Bonaventure 2008

14

The list of well-known IP multicast addresses may be found in :

http://www.iana.org/assignments/multicast-addresses
 IP Multicast addresses (2)

Multicast Address allocation

Evolution is to allocate addresses hierarchically
Administratively scoped addresses
239.0.0.0 - 239.255.255.255
reserved for utilization inside private domains
Should not appear on the global Internet
Static group address assignment (GLOP)
233.0.0.0 - 233.255.255.255
each Autonomous System receives 256 addresses in this range
and can allocate those addresses to its users

MASC : Multicast Address Set-Claim

Dynamic Method to allocate blocks of IP multicast addresses to
ISPs under development
Multicast Addresses allocated for some time only
far from being deployed

CNPP/2008.7. © O. Bonaventure 2008

15

The assignment of 233.0.0.0/8 is defined in

RFC 3180: GLOP Addressing in 233/8 , D. Meyer, P. Lothberg, September 2001

Work on the allocation of IP multicast addresses is being performed in :

http://www.ietf.org/html.charters/malloc-charter.html
 Evaluation of the ASM model

Advantages
Any source can send packets to any group
Any receiver may join any group

Drawbacks
How do we allocate IP multicast addresses ?
Random allocation is not really a long term solution
Risk of collision is severe
Lack of access control
Any source can send packets to any group
Consider a videoconference between professors where students
could easily send packets to interrupt the conference...
Any receiver may join any group
Encryption can be used to protect packet contents, but ...
Inefficient handling of well-known sources
CNN uses 226.0.0.10 and IraqiTV selects same address...

CNPP/2008.7. © O. Bonaventure 2008

16
 The Source-Specific IP Multicast (SSM)
service model
Objective
Provide a deployable one-to-many service
Principles
SSM multicast address = channel from a sender
A single source can use as many channels as there are
SSM addresses
Several senders can use same channel id without problems
A fraction of the IP address space is reserved
exclusively for SSM multicast addresses
232.0.0.0 -> 232.255.255.255
Receivers subscribe to channels from senders
Receiver knows from which sender packets will arrive
Routers retransmit multicast packets from the
sender to all channel subscribers
Packet forwarding based on both packet source and
destination addresses (Channel)

CNPP/2008.7. © O. Bonaventure 2008

17

Source-Specific Multicast for IP , H. Holbrook, B. Cain, RFC4602, 2006

An Overview of Source-Specific Multicast(SSM) Deployment , S. Bhattacharyya et al., RFC3569, 2003

Source-Specific Protocol Independent Multicast in 232/8, D. Meyer, R. Rockell, G. Shepherd, RFC4608, 2006
 Issues for network-level multicast

1. How to localize all the members of each

multicast group ?
Internet Group Management Protocol

2. How to efficiently distribute multicast packets

from one or more sender(s) to a group of
receivers ?
A loop-free graph must be built to connect the
sender(s) to all the interested receivers
source tree
unidirectional shared tree
bi-directional shared tree

CNPP/2008.7. © O. Bonaventure 2008

18
 Localization of receivers

R1
Response Response query

PC2 Membership PC1 Membership PC3 Membership R2

Group4 Group1 Group3 query
Group2 Group2 Group2

Principle
Routers query their attached LANs to identify
active groups
Hosts respond to router queries
Routers redistribute the localization of the
receivers towards other routers

CNPP/2008.7. © O. Bonaventure 2008

19
 IGMPv1

IGMP : Internet Group Management Protocol

R1
Query

PC2 Membership PC1 Membership PC3 Membership IGMP Query message

Group4 Group1 Group3 sent in IP packet with
Group2 Group2 Group2 destination = 224.0.0.1
TTL=1
default period : 60 sec
Issues
Queries must be received by all IP multicast hosts
Responses should not overload router

CNPP/2008.7. © O. Bonaventure 2008

20

All IP Multicast enabled hosts should always listen to IP address 224.0.0.1

IGMPv1 is defined in :
RFC 1112 Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, August 1989.
 IGMPv1 (2)

R1
Response(G3)
Response

PC2 Membership PC1 Membership PC3 Membership

Group4 Group1 Group3 IGMP Response packet
Group2 Group2 Group2 sent in IP packet with
destination = G3
IGMP Responses TTL=1
Hosts do not reply immediately
Random delay (0 - 10 seconds)
One IGMP response per group
Response sent to multicast address of the group
other members of the group will suppress their response
Consequences
a single response packet for each group on each LAN
router must listen to all multicast groups to receive
IGMPv1 responses
CNPP/2008.7. © O. Bonaventure 2008

21

As an optimization, it is possible for a host to send an IGMP response message without receiving a Query when they join a
group. This allows the router to be immediately informed about new group members.
 IGMPv1 (3)

R1

Router state
Group1 present (timer=30sec)
PC2 Membership PC1 Membership PC3 Membership Group2 present (timer=45 sec)
Group4 Group1 Group3
Group2
Group3 present (timer=60sec)
Group2 Group2 Group4 present (timer=10sec)

How to leave a group ?

Soft-state solution
timer associated to router state for each group
if timer expires before the reception of a group
response, group is considered to be absent on the LAN
timer should be longer than interval between IGMP queries

CNPP/2008.7. © O. Bonaventure 2008

22
 IGMP v2

Main additions in IGMPv2

Explicit Leave Group message
a host may send an explicit leave message to indicate
that it is no more interested by a given group
leave message is sent to All-Multicast-Routers group (224.0.0.2)

Group specific Query

A router may send a specific query to a single group to
verify whether there are still members of the group
A group specific query is sent to the group address

CNPP/2008.7. © O. Bonaventure 2008

23

IGMPv2 is defined in :

RFC 2236: Internet Group Management Protocol, Version 2 , W. Fenner, November 1997
 IGMPv2 (2)

Example leave

Group specific response Leave message

Router state
IP destination : Group2 IP destination : 224.0.0.2 Group1 present (timer=30sec)
TTL:1 TTL:1 Group2 present (timer=45 sec)
Group3 present (timer=60sec)
Group4 present (timer=10sec)

R1
3: Response(Group2) 1: Leave(Group2)
2: Query(Group2)

PC2 Membership PC1 Membership PC3 Membership

Group4 Group1
Group specific Query
Group3 IP destination : Group2
Group2 Group2 Group2 TTL:1

CNPP/2008.7. © O. Bonaventure 2008

24
 LAN-level multicast

Principle
Two types of destination Ethernet addresses
Physical addresses
identifies one Ethernet adapter
Logical addresses
identifies a logical group of Ethernet destinations
48 bits
OUI
0 : physical address (unicast)
1 : logical address (multicast)

Transmission of multicast frame

sender transmits frame with multicast destination addr.
Reception of multicast frames
Ethernet adapters can be configured to capture frames
whose destination address is
Their unicast address
One of a set of multicast addresses
CNPP/2008.7. © O. Bonaventure 2008

25
 IP Multicast over Ethernet

IP Multicast over Ethernet

Algorithmic mapping of IP multicast addresses
special OUI reserved for IP multicast [0x00005e]
1 89 16 17 24 25 32
1110 ABCDE xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ignored by mapping process 23 bits

1 89 16 17 24 25 32 33 40 41 48
OUI IP Multicast 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The low order 23 bits of the IP multicast address are

copied in the low order 23 bits of the Ethernet address
32 IP multicast address are mapped on the same
Ethernet logical address

CNPP/2008.7. © O. Bonaventure 2008

26

Issue :
32 IP addresses are mapped on the same Ethernet address. For example, Ethernet address 01-00-5e-0a-00-0a is used to send IP packets
destined to the following IP multicast addresses :
224.10.0.1, 225.10.0.1, 226.10.0.1, 227.10.0.1,
228.10.0.1, 229.10.0.1, 230.10.0.1, 231.10.0.1,
232.10.0.1, 233.10.0.1, 234.10.0.1, 235.10.0.1,
236.10.0.1, 237.10.0.1, 238.10.0.1, 239.10.0.1,
224.138.0.1, 225.138.0.1, 226.138.0.1, 227.138.0.1,
228.138.0.1, 229.138.0.1, 230.138.0.1, 231.138.0.1,
232.138.0.1, 233.138.0.1, 234.138.0.1, 235.138.0.1,
236.138.0.1, 237.138.0.1, 238.138.0.1, 239.138.0.1,
 The hidden cost of LAN multicast

Multicast on a single Ethernet

group of receivers identified by special address
receivers join group by configuring their adapter

Sw

Ethernet does not inform switch

about locations of receivers
Sender Receiver1 default : multicast=broadcast
optimizations are possible Receiver2
Ethernet multicast frames are
easily created and transmitted
Receiver1 must configure its Ethernet adapter
to capture the interesting multicast frames.
Most adapters are optimized to capture a few addresses (e.g. 32)
If a receiver needs a larger number of multicast addresses,
filtering must be done in software by the Ethernet driver
CNPP/2008.7. © O. Bonaventure 2008

27

Some switches are able to look at the contents of IP packets to determine whether they can provide some information about the location of
receivers, but this is outside the scope of this presentation.
 IGMPv3

Complete rewrite of IGMP

Drawbacks of IGMPv1/2
Difficult to efficiently support IP multicast in
switched LANs

S3 S1 R

S4 S2 S5

Routers must listen to all IP multicast addresses to

receive IGMP messages
No support for SSM service model
CNPP/2008.7. © O. Bonaventure 2008

28

Some switches are able to snoop IGMP messages and to determine automatically the location of IP multicast receivers. However, this implies
that those switches need to inspect the content of the receivers multicast frames carrying IP packets.
 IGMPv3 (2)

IGMPv3 Query
R1

PC2 Membership PC1 Membership PC3 Membership

Group4 Group1 Group3
Group2 Group2 Group2
Three types of IGM Queries
General Query
similar to IGMPv1/2, Query sent to IP address 224.0.0.1
Group Specific Query
similar to Group Specific queries in IGMPv2, sent to group addr.
Group-Source Specific Query
router asks responses from specific sources and groups
query sent to group address includes list of sources

CNPP/2008.7. © O. Bonaventure 2008

29

IGMPv3 is defined in :

RFC 3376: Internet Group Management Protocol, Version 3 , B. Cain, S. Deering, I. Kouvelas, B. Fenner, A . Thyagarajan, October 2002
 IGMPv3 (3)

IGMPv3 Responses
R1
Resp(G4,G2) Resp(G1,G2) Resp(G3,G2) Query

PC2 Membership PC1 Membership PC3 Membership

Group4 Group1 Group3
Group2 Group2 Group2

each host sends an IGMPv3 Response

response contains the entire list of groups for the host
for each group, the host may optionally indicate that its
interest is only for some specified senders (for SSM)
response is sent in packets with destination=224.0.0.22
a random timer is used before sending response to avoid
overloading the network or the routers

CNPP/2008.7. © O. Bonaventure 2008

30
 Issues for network-level multicast

1. How to localize all the members of each

multicast group ?
Internet Group Management Protocol

2. How to efficiently distribute multicast packets

from one or more sender(s) to a group of
receivers ?
A loop-free graph must be built to connect the
sender(s) to all the interested receivers
source tree
unidirectional shared tree
bi-directional shared tree

CNPP/2008.7. © O. Bonaventure 2008

31
 Multicast source distribution tree
Sender2

Sender1
Receiver4
R1 R2

Router state : (S,G) R4

For each (Source, Group) pair each R3
router maintains the list of interfaces State for Router R4
used to reach the group members (S1,G) : ->Rec4
(S2,G) : ->Rec4
R5 R7 ->R3

State for Router R3

(Sender1,G) : ->R4, ->R7 R6
(Sender2,G) : ->R5, ->R7
Receiver3
Receiver1
Tradeoff Receiver2
optimum distribution tree versus amount of state maintained by routers
CNPP/2008.7. © O. Bonaventure 2008

32

This type of source distribution tree is well suited to support the SSM service model, but can also be used to support the ASM service model.
 Building the source tree
How to build the distribution tree ?
Link-state solution
link-state routing protocol used to distribute membership
Each router knows the exact location of group members
Each router can easily compute source trees

Broadcast solution
Assume initially that group members are everywhere
The first packet towards a group is sent everywhere
If a router receives unwanted traffic, it will ask its
upstream routers to stop transmitting this traffic
Distribution tree is built progressively

CNPP/2008.7. © O. Bonaventure 2008

33
 Building the source tree
Link-state solution
Principle
Routers collect membership information with IGMP

Group membership is distributed by special type of

LSPs flooded by link-state routing protocol

By processing those LSPs, each router knows

The entire network topology
The localization of the receivers from each multicast group

Based on the link state database, each router

computes (S,G) spanning trees for each Source,
Group pair by using the Dijkstra algorithm

CNPP/2008.7. © O. Bonaventure 2008

34
 Multicast with OSPF
Router B state
Router A state ... Router C state
... (C,G1) : ->A,LAN (C,G1) : ->B, ->E
(C,G1) : LAN ... (C,G2) : ->B, ->E
... (C,G3) : ->E
G2 G1

G1 A B CC

D E

G1 Router E state
G2 G3 ...
Router E state (C,G1) : LAN
... (C,G2) : ->D
(C,G2) : LAN (C,G3) : ->D
(C,G3) : LAN ...
...
CNPP/2008.7. © O. Bonaventure 2008

35

The multicast extensions to OSPF are defined in

RFC1584 Multicast Extensions to OSPF. J. Moy. March 1994

RFC1585 MOSPF: Analysis and Experience. J. Moy. March 1994
 Multicast with OSPF (2)

Advantages of OSPF for IP Multicast

routers have complete information on
network topology
localization of group members

Drawbacks of OSPF for IP Multicast

Large number of LSPs if there are many groups or
many group members in the network
these LSPs may consume a lot of memory inside all
routers whether or not there is multicast traffic
group membership LSPs compete with normal LSPs
Amount of router state depends on number of
(S,G) pairs
Computation of (S,G) spanning trees can be costly

CNPP/2008.7. © O. Bonaventure 2008

36
 Building the source tree
How to build the distribution tree ?
Link-state solution
link-state routing protocol used to distribute membership
Each router knows the exact location of group members
Each router can easily compute source trees

Broadcast solution
Assume initially that group members are everywhere
The first packet towards a group is sent everywhere
If a router receives unwanted traffic, it will ask its
upstream routers to stop transmitting this traffic
Distribution tree is built progressively

CNPP/2008.7. © O. Bonaventure 2008

37
 Broadcasting IP packets

How to broadcast packets in a large network ?

Routing table
Routing table A : West [via B]
A : West B : West
B : Local C : Local
Routing table C : East D : West [via B]
A : Local D : South [via E] E : South-West
D : South E : South
B : East
C : East [via B]
E: East [via B] A B CC

Routing table Routing table

A : North A : North [via B]
B : North [via A] B : North
C : North [via A] C : North-Est
D E D : West
D : Local
E : East E : Local

The graph containing the links from all shortest paths

originating at router C creates a spanning tree rooted at C

CNPP/2008.7. © O. Bonaventure 2008

38
 Reverse Path Forwarding

Principle of the solution

Forwarding of broadcast packets depends on
Multicast Destination IP address
Unicast Source IP address
Simple router forwarding algorithm
Broadcast packet from Source S received on interface in:
// consult routing table
// to find shortest route towards S
if (interface in == shortest_route(to S))
for(i=0; i++; i<N)
{
if (i!=in) Send_packet(interface i);
}
else
Discard(packet);
}

CNPP/2008.7. © O. Bonaventure 2008

39
 RPF example

Packet received by B on non-shortest path

Packet is discarded
Packet received by A on shortest path Packet received by B on shortest path
Packet is transmitted on all other links Packet is retransmitted on all other links
Src:C Dst:Broad

A B Src:C Dst:Broad CC

Src:C Dst:Broad Src:C Dst:Broad Src:C Dst:Broad

Src:C Dst:Broad
D E
Src:C Dst:Broad

Packet received by D on non shortest path

Packet is discarded
Packet received by E on non shortest path
Packet is discarded
Packet received by D on shortest path Packet received by E on shortest path
Packet is transmitted on all other links Packet is retransmitted on all other links

Propagation of the broadcast packet sent by router C

CNPP/2008.7. © O. Bonaventure 2008

40
 Improving RPF

How to avoid unnecessary transmissions ?

Sender-based solution
for each source, router computes list of outgoing interfaces
broadcast packets are only forwarded on these interfaces
list of outgoing interfaces is computed by including
interfaces towards neighbors on shortest path from source
router must know shortest path chosen by neighbor router
possible with OSPF, requires specific messages with RIP
CPU intensive

Receiver-driven solution

CNPP/2008.7. © O. Bonaventure 2008

41
 Improving RPF
Sender-based solution
C outing table
B Routing table Router B's state A : West [via B]
Router A's state A : West (A,Broad ) : ->E, ->C B : West
(A,Broad ) : ->B, ->D B : Local
C : East (C,Broad ) : ->A C : Local
(C,Broad ) : ->D (D,Broad ) : ->C D : West [via B]
D : South [via E] E : South-West
(D,Broad ) : - E : South (E,Broad ) : ->A
(E,Broad ) : ->A

A B CC
A Routing table
A : Local
D : South
B : East Routing table
C : East [via B] D Routing table
A : North A : North [via B]
E: East [via B] B : North
B : North [via A]
C : North-Est
C : North [via A] D E D : West
D : Local
E : East E : Local

Router E's state

Computation of router state (A,Broad ) : -
topology based with link-state routing (B,Broad ) : -
special messages with DV routing (C,Broad ) : -
(D,Broad ) :->B

CNPP/2008.7. © O. Bonaventure 2008

42

Spanning tree rooted at router C

Spanning tree rooted at router A
Spanning tree rooted at router B
Spanning tree rooted at router D
 Improving RPF

How to avoid unnecessary transmissions ?

Sender-based solution

Receiver-driven solution
for each source, router maintains list of outgoing interfaces
broadcast packets are only forwarded on these interfaces
Computation of list of outgoing interfaces
Initially list of outgoing interfaces contains all interfaces
when a router receives a packet over a non-shortest path, it sends a
special message to the upstream router
the upstream router will then update its list of interfaces
Less CPU intensive than sender-based solution

CNPP/2008.7. © O. Bonaventure 2008

43
 Improving RPF
Receiver-based solution
Packet received by B on shortest path
Create state for router B:
(C,Broad) : ->A, ->E
Packet is retransmitted on all links in outgoing list

Src:C Dst:Broad

A B CC

Src:C Dst:Broad

D E

Packet received by E on shortest path

Create state for router E:
(C,Broad) : ->B, ->D
Packet is retransmitted on all links in outgoing list

CNPP/2008.7. © O. Bonaventure 2008

44
 Improving RPF
Receiver-based solution (2)

Packet received by A on shortest path Packet received by B from non shortest path
Create state for router A Packet is discarded
(C,Broad) : ->D Send Prune message (C,Broad) to router E
Packet is transmitted on all other links
Src:C Dst:Broad

A B CC

Src:C Dst:Broad Src:C Dst:Broad

D E
Src:C Dst:Broad

Packet received by D on non shortest path

No state created
Packet is discarded Packet received by E on non shortest path
Send Prune message (C,Broad) to router E State for router E unchanged:
(C,Broad) : ->B, ->D
Packet is discarded
Send Prune message (C,Broad) to router B
CNPP/2008.7. © O. Bonaventure 2008

45
 Improving RPF
Receiver-based solution (3)
Prune message indicates that
broadcast packets from C should not
be retransmitted towards E
New state for router :
(C,Broad) : ->A

A B CC

Src:C Dst:Broad
Prune(C) Prune(C)
Prune(C)
D E

Packet received by D on shortest path Prune messages indicate that

Create state for router D : broadcast packets from C should not
(C,Broad) : ->E be retransmitted towards B and D
Packet is transmitted on all other links New state for router E :
(C,Broad) : -

CNPP/2008.7. © O. Bonaventure 2008

46
 Improving RPF
Receiver-based solution (4)
Final router states
State for router A : State for router B :
(C,Broad) : ->D (C,Broad) : ->A

A B CC

D E

State for router D : State for router E :

(C,Broad) : - (C,Broad) : -

next broadcast packets from C will only flow on shortest

path tree
state is created dynamically when multicast packets are
received on shortest path from source
a timer is associated with each state
state is removed when timer expires
CNPP/2008.7. © O. Bonaventure 2008

47
 Using RPF for Multicast

Principles
Multicast packets are initially transmitted by routers
as if they were broadcast packets

Routers create (S,G) state upon reception of first

multicast packets from S to G

Two types of Prune messages are sent

Source specific Prune (S,G) message if packet is received
on non-shortest path
Group Prune message if there is no group member
downstream of this router

(S,G) state is updated by reception of Prune msgs

CNPP/2008.7. © O. Bonaventure 2008

48
 RPF for Multicast : Example
Packet received by B on shortest path
(C,G2) state is set to all router interfaces except incoming interface
New state for router B:
(C,G2) : ->A, ->E
Packet is retransmitted on all branches of source tree

Src:C Dst:G2
G2 A B CC

Src:C Dst:G2

G1
D E
G2

Packet received by E on shortest path

(C,G2) state is set to all router interfaces except incoming interface
New state for router B:
(C,G2) : ->B, ->D, LAN
Packet is retransmitted on all branches of source tree

CNPP/2008.7. © O. Bonaventure 2008

49
 RPF for Multicast : Example (2)
Packet received by A on shortest path
(C,G2) is set to all interfaces except incoming interface
New state for router A:
(C,G2) : ->D, LAN
Packet is retransmitted on all branches Packet received by B on non shortest path
of source tree Packet is discarded
No update to state
Send Prune (C,G2) msg to E
Src:C Dst:G2
G2 A B CC

Src:C Dst:G2 Src:C Dst:G2

Src:C Dst:G2
G1
D E
G2

Packet received by D on non shortest path

Packet is discarded
No state is created in router D Packet received by E on non shortest path
Send Prune (C,G2) msg to E Packet is discarded
No update to state
Send Prune (C,G2) to B
CNPP/2008.7. © O. Bonaventure 2008

50
 RPF for Multicast : Example (3)

State for router A:

(C,G2) : ->D, ->LAN Prune received from router E
Updated state for router B :
(C,G2) : -> A

G2 A B CC

Prune(C,G2)
Src:C Dst:G2 Prune(C,G2)

G1
D E
Prune(C,G2) G2

Packet received by D on shortest path

No member of group G2, packet is discarded
Prune message will be sent to router A Prune received from router B
New state for router D Updated state for router B :
(C,G2) : - (C,G2) : ->LAN

CNPP/2008.7. © O. Bonaventure 2008

51
 RPF for Multicast : Example (4)
Prune received from router B
New state for router A :
(C,G2) : ->LAN State for router B :
(C,G2) : -> A

G2 A B CC

Prune(C,G2)

G1
D E
G2

State for router D

(C,G2) : -
State for router E :
State lifetime (C,G2) : LAN
periodically state info is removed and flooding restarts
flood and prune operation
Graft msg can be used by D to join the tree later
CNPP/2008.7. © O. Bonaventure 2008

52
 Example protocols

DVMRP
first multicast routing protocol deployed
special unicast distance vector routing protocol
sender-based optimization for RPF
special poison reverse message to inform upstream router
that it is the best path for a given source
timer associated with router state
periodic flood and prune

PIM-Dense Mode
periodic flood and prune
does not rely on a special unicast routing protocol
RPF is based on existing unicast routing table
receiver-based optimization for RPF

CNPP/2008.7. © O. Bonaventure 2008

53

DVMRP is defined in :

RFC1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C.

Partridge, S.E. Deering. Nov-01-1988.
DVMRP was used to build the MBONE. The MBONE was an overlay network built by establishing tunnels between routers to distribute
multicast packets through networks that do not support multicast.
See e.g.
Michael R. Macedonia and Donald P. Brutzman, MBone Provides Audio and Video Across the Internet , http://www-itg.lbl.gov/mbone/
Macedonia.html

PIM Dense mode is defined in :

A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), Internet draft,
draft-ietf-pim-dm-new-v2-01.txt, work in progress, Feb. 2002
 Issues for network-level multicast

1. How to localise all the members of each

multicast group ?
Internet Group Management Protocol

2. How to efficiently distribute multicast packets

from one or more sender(s) to a group of
receivers ?
A loop-free graph must be built to connect the
sender(s) to all the interested receivers
source tree
unidirectional shared tree
bi-directional shared tree

CNPP/2008.7. © O. Bonaventure 2008

54
 Multicast shared distribution tree
Sender2

Sender1
Receiver4
R1 R2

Router state : (*,G) R4

For each group, each router R3
maintains the list of interfaces State for Router R4
used to reach the group members (*,G) : ->Rec4
R5 R7
State for Router R3
(*,G) : ->R4, ->R5
R6

Receiver3

Receiver1
Tradeoff Shared tree
optimum distribution tree versus router state Receiver2

CNPP/2008.7. © O. Bonaventure 2008

55

In this example, R3 is a special router acting as the root for the multicast shared distribution tree
 Using unidirectional shared trees

Principles
One router is configured as Rendez-vous Point

All other routers know the address of the RP

RP is the root of the shared (*,G) tree

Multicast packets sent by hosts are intercepted by

multicast routers and sent to the RP
RP redistributes these packets over the (*,G) tree

Receivers join dynamically the shared (*,G) tree

CNPP/2008.7. © O. Bonaventure 2008

56
 Construction of the shared tree
A has a member of group G2
Initial state for router A :
(*,G2) : ->LAN, incoming:RP
RP
Join(*,G2)
G2 B CC
A

Join(*,G2)

D E
G2
E has a member of group G2
Initial state for router E :
(*,G2) : ->LAN, incoming:B

Routers attached to group members send

Join (*,G) msgs towards RP to build shared tree
CNPP/2008.7. © O. Bonaventure 2008

57
 Construction of the shared tree (2)

RP received Join from A for (*,G2)

State for RP:
(*,G2) : ->A Router B received Join from E for (*,G2)
Join sent towards RP
State for router A : State for Router B:
(*,G2) : ->LAN, incoming:RP RP (*,G2) : ->E, incoming:RP
Join(*,G2)
G2 B CC
A

D E
G2

State for router E :

(*,G2) : ->LAN, incoming:B

CNPP/2008.7. © O. Bonaventure 2008

58
 Construction of the shared tree (3)

RP received Join from B for (*,G2)

State for RP:
(*,G2) : ->A, ->B
State for router A : State for Router B:
(*,G2) : ->LAN, incoming:RP RP (*,G2) : ->E, incoming:RP

G2 B CC
A

D E
G2

If D wants to join the shared tree State for router E :

D will send a join(*,G2) to A (*,G2) : ->LAN, incoming:B
A will update its state and D will immediately be on shared tree

CNPP/2008.7. © O. Bonaventure 2008

59
 Transmission of multicast packets

State for Router B:

State for RP: (*,G2) : ->E, incoming:RP
(*,G2) : ->A, ->B
State for router A : Router C has no state for group G2
(*,G2) : ->LAN, incoming:RP Packet is intercepted and sent to RP
RP inside a REGISTER packet

G2 B CC
A

Src:S Dst:G2

D E
G2
Sender : S
Multicast packet sent
State for router E : by Sender towards G2
(*,G2) : ->LAN, incoming:B

CNPP/2008.7. © O. Bonaventure 2008

60

The Register packet used by router C is a kind of tunnel. Router C places the packet received from the sender inside an IP packet whose
source is C and whose destination is the RP.
 Transmission of multicast packets (2)

RP checks that there is state for G2

Packet is de-encapsulated and
forwarded on (*,G2) shared tree
RP will create a source tree to receive
State for RP: G2 packets natively from router C
(*,G2) : ->A, ->B
State for router A :
(*,G2) : ->LAN, incoming:RP S:C D:RP Src:S Dst:G2
RP

G2 B CC
A

D E
G2
Sender : S

State for router E :

(*,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

61
 Construction of the source tree

Router B receives Join and

creates state for source tree
Router B will forward join to source
New state for Router B:
State for RP: (*,G2) : ->E, incoming:RP
(*,G2) : ->A, ->B (S,G2): ->RP
State for router A :
(*,G2) : ->LAN, incoming:RP Join(S,G2)
RP

G2 B CC
A

D E
G2
Sender : S

State for router E :

(*,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

62
 Construction of the source tree (2)

State for Router B:

(*,G2) : ->E, incoming:RP
(S,G2): ->RP, incoming : C
State for RP:
(*,G2) : ->A, ->B Router C stops sending register
(S,G2) : -, incoming : B messages when (S,G2) state exists
State for router A : State for Router C:
(*,G2) : ->LAN, incoming:RP (S,G2): ->B, incoming: LAN
RP

G2 B CC
A

D E
G2
Sender

State for router E :

(*,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

63
 Forwarding of multicast packets

RP will forward packets Packet is sent on source tree

down the shared tree State for Router C:
(S,G2): ->B, incoming LAN

State for RP: Packet received from C

(*,G2) : ->A, ->B resent towards RP and E !
(S,G2) : -, incoming : B State for Router B:
(*,G2) : ->E, incoming:RP
State for router A : (S,G2): ->RP, incoming : C
(*,G2) : ->LAN, incoming:RP
RP

G2 B CC
A

D E
G2
Sender
State for router E :
(*,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

64
 Forwarding of multicast packets (2)

Packet is sent on source tree

State for Router C:
(S,G2): ->B, incoming LAN

State for RP: Send special prune to RP

(* except from S,G2) : ->A, ->B State for Router B:
(S,G2) : -, incoming : B (*,G2) : ->E, incoming:RP
(S,G2): ->RP, incoming : C
State for router A :
(*,G2) : ->LAN, incoming:RP
RP

G2 B CC
A RPPrune(S,G2)

D E
G2
Sender S
State for router E :
(*,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

65
 Switching to the source tree
When receiving Join(S,G2), B will
State for RP: add E to the (S,G2) source tree
(* except S,G2) : ->A, ->B New state for router B
(S,G2) : -, incoming : B (*,G2) : ->E, incoming:RP
(S,G2): ->RP, ->E, incoming : C
Asks to join source tree
State for router A :
RP
(*,G2) : ->LAN, incoming:RP

G2 B CC
A

Join(S,G2)

D E
G2
Sender S
Asks to join the source tree
State for router E :
(*,G2) : ->LAN, incoming:B
(S,G2) : ->LAN, incoming:B

CNPP/2008.7. © O. Bonaventure 2008

66
 Switching to the source tree (2)

RPLeave will force B to discard

packets from source S on (S,G2) tree
State for RP: B will send RPLeave(S,G2) to RP
(* except S,G2) : ->A, ->B State for router B :
(S,G2) : -, incoming : B (* except S,G2) : ->E, incoming:RP
(S,G2): ->RP, ->E, incoming : C

RP

G2 B CC
A
State for router A :
(*,G2) : ->LAN, incoming:RP
RPLeave(*,G2)

D E
G2
Sender
When packets arrive on source tree, router E will ask
its upstream to stop sending (S,G2) on shared tree
State for router E :
(*,G2) : ->LAN, incoming:B
(S,G2) : ->LAN, incoming:B
CNPP/2008.7. © O. Bonaventure 2008

67
 Switching to the source tree (3)
State for RP: State for router B :
(* except S, G2) ->A, ->B (* except S,G2) : ->E, incoming:RP
(S,G2) : ->A, incoming : B (S,G2): ->RP, ->E, incoming : C
RP

G2 B CC
A

State for router A :

(*,G2) : ->LAN, incoming:RP

D E
G2
State for router E : Sender
(*,G2) : ->LAN, incoming:B
(S,G2) : ->LAN, incoming:B

Examples
Multicast packet from Sender S towards G2
Multicast packets from sender attached to D towards G2
CNPP/2008.7. © O. Bonaventure 2008

68
 PIM Sparse Mode

Widely deployed multicast routing protocol

Possible configurations of Rendez-vous Points
RP addresses manually configured
using anycast to discover Rendez-vous Point
RP broadcast announces in dense-mode

Possible utilization of unidirectional shared tree

For all multicast packets
But RP could become overloaded with multicast
For first multicast packets sent to each group
Those packets are first sent to RP to let receivers hear from
sources
first-hop routers can join the source-tree if there is a lot of traffic
from a given source
popular PIM-SM implementation switches to source-tree as
soon as traffic is >0

CNPP/2008.7. © O. Bonaventure 2008

69

PIM Sparse-Mode is defined in :

RFC2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.
Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998.
 Issues for network-level multicast

1. How to localize all the members of each

multicast group ?
Internet Group Management Protocol

2. How to efficiently distribute multicast packets

from one or more sender(s) to a group of
receivers ?
A loop-free graph must be built to connect the
sender(s) to all the interested receivers
source tree
unidirectional shared tree
bi-directional shared tree

CNPP/2008.7. © O. Bonaventure 2008

70
 Using bi-directional shared trees

Principles
One router is configured as core for each group

All other routers know the address of the core

Core is root of bi-directional shared tree

Bi-directional shared tree is used to forward

multicast packets sent by any source

Routers join dynamically the shared tree

CNPP/2008.7. © O. Bonaventure 2008

71
 Multicast shared distribution tree
Sender2

Sender1

Receiver4
R1 R2

Router state : (*,G) Core R4

For each group, each router R3
maintains the list of interfaces State for Router R4
used to reach the group members (*,G) : ->Rec4
R5 R7
State for Router R3
(*,G) : ->R4, ->R5
R6

Receiver3

Receiver1
Tradeoff
optimum distribution tree versus router state Receiver2

CNPP/2008.7. © O. Bonaventure 2008

72
 Construction of the shared tree

A has a member of G2
Initial state for router A :
(G2) : ->LAN, incoming ?
CORE
Join(G2)
G2 B CC
A

Join(G2)

D E
G2
E has a member of G2
Initial state for router E :
(G2) : ->LAN, incoming ?

CNPP/2008.7. © O. Bonaventure 2008

73

This example is based on the utilization of CBT. Other protocols may behave differently
 Construction of the shared tree (2)

State for core

(G2) : ->A, ->B B joins shared tree
A has a member of G2 New state for router B :
Initial state for router A : (G2) : ->E, incoming: ?
(G2) : ->LAN, incoming:Core
CORE
Join(G2)
JoinACK(G2)
G2 B CC
A

D E
G2
E has a member of G2
Initial state for router E :
(G2) : ->LAN, incoming:?

CNPP/2008.7. © O. Bonaventure 2008

74
 Construction of the shared tree (3)

State for core B joins shared tree

A has a member of G2 (G2) : ->A, ->B
Initial state for router A : New state for router B :
(G2) : ->LAN, incoming:Core (G2) : ->E, incoming: Core
CORE
JoinACK(G2)

G2 B CC
A

JoinACK(G2)

D E
G2
E has a member of G2
Initial state for router E :
(G2) : ->LAN, incoming:B

CNPP/2008.7. © O. Bonaventure 2008

75
 Transmission of multicast packets

Member transmission
State for core
(G2) : ->A, ->B
State for router A :
(G2) : ->LAN, incoming:Core State for router B :
CORE (G2) : ->E, incoming: Core

G2 B CC
A
S G2

S G2 S G2
Sender S
D E
G2

State for router E :

(G2) : ->LAN, incoming:B

CNPP/2008.7. © O. Bonaventure 2008

76
 Transmission of multicast packets (2)

Non-member transmission
State for core
(G2) : ->A, ->B
State for router A : State for router B :
(G2) : ->LAN, incoming:Core (G2) : ->E, incoming: Core
CORE
S G2 S G2
G2 B CC
A

DCore S G2 S G2

D E
G2

S G2 State for router E :

(G2) : ->LAN, incoming:B
Router D will send the non-member
transmission to the Core inside a tunnel

CNPP/2008.7. © O. Bonaventure 2008

77
 CBT : Core Based Tree

A proposed multicast routing protocol

still only a proposal
based on bi-directional shared trees
requires less state than PIM-SM
does not switch to source trees to reduce delay
Core placement and reliability are key issues
Core is more involved in the forwarding of packets than
the RP in PIM-SM
all multicast packets for a given group are retransmitted by core
Core should correctly be placed for large groups
otherwise packets main the send unnecessary on expensive
links
Core locations can be configured on a per group basis
Core candidates send regular broadcast messages and
the best core for each group is selected

CNPP/2008.7. © O. Bonaventure 2008

78

CBT is defined in :
RFC2189 Core Based Trees (CBT version 2) Multicast Routing. A. Ballardie.
September 1997

Besides CBT, an extension to PIM that supports bidirectionnal shared trees is being developed, see :

Mark Handley, Isidor Kouvelas, Tony Speakman, Lorenzo Vicisano, Bi-directional Protocol Independent Multicast (BIDIR-PIM), Internet draft,
draft-ietf-pim-bidir-04.txt , work in progress
 Multicast without trees

Existing multicast solutions force each router on

the tree to maintain per-group state
acceptable with a small number of large groups
not acceptable with many small groups

Alternative solution
Connectionless/explicit multicast for small groups
Principle
Modify the IP header to encode the IP addresses of all the
members of the group inside the IP header
Routers will forward and duplicate packets on this basis
routers do not need to maintain per-group state
routers must instead perform per-packet processing
solution could be useful in specific cases (e.g. ADSL)

CNPP/2008.7. © O. Bonaventure 2008

79

See e.g. R. Boivie et al. Explicit Multicast (Xcast) Concepts and Options, RFC5058, Nov. 2007