Chapter 3

Multimedia Networks
Multicast
Chapter 3 outline
• 3.1 Introduction
• 3.2 Multicast over IP
• 3.3 Multicast Applications

2
 Multicast Routing

• Unicast: one source to one destination

• Multicast: one source to many destinations

• Main goal: efficient data distribution

– Avoid data duplication within network

3
 Multicast – Efficient Data
Unicast vs. Multicast
Distribution

Unicast
Server

Router
Number of streams!

Multicast
Server

Router 4
 Unicast vs. Multicast
Unicast vs. Multicast
• TCP Unicast but NOT Multicast
- TCP is connection orientated protocol
- Requires 3 way Handshake
- Reliable due to sequence numbers + Ack
- Flow control
• UDP Unicast and Multicast
- Connectionless
- Unreliable (application layer awareness)
• Unicast Protocols
- ARP not applicable
- HSRP etc are not applicable

5
 Multicast Disadvantages
Multicast Disadvantages

Multicast Is UDP Based!!!

• Best Effort Delivery: Drops are to be expected. Multicast applications
should not expect reliable delivery of data and should be designed accordingly.
Reliable Multicast is still an area for much research. Expect to see more
developments in this area. PGM offers reliability!

• No Congestion Avoidance: Lack of TCP windowing and “slow-start”

mechanisms can result in network congestion. If possible, Multicast
applications should attempt to detect and avoid congestion conditions.

• Duplicates: Some multicast protocol mechanisms (e.g. Asserts, Registers

and SPT Transitions) result in the occasional generation of duplicate packets.
Multicast applications should be designed to expect occasional duplicate
packets.

• Out of Order Delivery : Some protocol mechanisms may also result in out
of order delivery of packets.

6
 Multicast Advantages
Multicast Advantages
• Enhanced Efficiency: Controls network traffic and reduces server and CPU
loads

• Optimized Performance: Eliminates traffic redundancy

• Distributed Applications: Makes multipoint applications possible

Example: Audio Streaming

Multicast All clients listening to the same 8 Kbps audio

Unicast
0.8
0.6
Traffic
0.4
Mbps
0.2
0
1 20 40 60 80 100
# Clients 7
Multicast Components
Multicast Architecture
Cisco End-to-End Architecture

ISP A
ISP B
MSDP
RP
Multicast Source
Multicast Source DR Y
X RP
ISP B

IGMP Snooping PIM ISP A

MBGP
snooping

DR
IGMP PIM-SM DR

Bidir PIM
PIM-SSM
MVPN
Campus Multicast Interdomain Multicast
• End Stations (hosts-to-routers): • Multicast routing across domains
- IGMP - MBGP
• Switches (Layer 2 Optimization): • Multicast Source Discovery
- IGMP Snooping PIM snooping - MSDP with PIM-SM
• Routers (Multicast Forwarding Protocol): • Source Specific Multicast
- PIM Sparse Mode or Bidirectional PIM - PIM-SSM
8
Chapter 3 outline
• 3.1 Introduction
• 3.2 Multicast over IP
• 3.3 Multicast Applications

9
 IP Multicast Group Concept
IP Multicast Group Concept
Sender & Receiver
Group
Member 3

1. You must be a Sender

“member” of a group
to receive its data
A B D “Non” Group
2. If you send to a group Member
address, all members
receive it C E

3. You do not have to be

a member of a group
Group Group
to send to a group Member 1 Member 2
Receiver Receiver 10
 Multicast Addressing
Multicast Addressing
IPv4 Header
Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source
1.0.0.0 - 223.255.255.255 (Class A, B, C)

Destination
224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address Range

Options Padding

11
Multicast Group Address Range
Multicast Group Address range

224.0.0.0 - 239.255.255.255 (Class D)

• Reserved Link-Local Addresses

- 224.0.0.0 - 224.0.0.255
- Transmitted with TTL = 1
- Examples:
• 224.0.0.1 All systems on this subnet
• 224.0.0.2 All routers on this subnet
• 224.0.0.5 OSPF routers
• 224.0.0.13 PIMv2 Routers
• 224.0.0.22 IGMPv3
• Other Reserved Addresses
- 224.0.1.0 - 224.0.1.255
- Not local in scope (Transmitted with TTL > 1)
- Examples:
• 224.0.1.1 NTP Network Time Protocol
• 224.0.1.32 Mtrace routers
• 224.0.1.78 Tibco Multicast1 12
 Multicast Addressing
Multicast Addressing

• Administratively Scoped Addresses

- 239.0.0.0 - 239.255.255.255
- Private address space
• Similar to RFC1918 unicast addresses
• Not used for global Internet traffic
• Used to limit “scope” of multicast traffic
• Same addresses may be in use at different locations for
different multicast sessions
- Examples
• Site-local scope: 239.255.0.0/16
• Organization-local scope: 239.192.0.0/14
• SSM (Source Specific Multicast) Range
- 232.0.0.0 - 232.255.255.255
- Primarily targeted for Internet style Broadcast
13
 Multicast Addressing
Multicast Addressing
IP Multicast MAC Address Mapping
(FDDI and Ethernet)
32 Bits
28 Bits
1110

239.255.0.1
5 Bits
Lost

01-00-5e-7f-00-01
25 Bits 23 Bits
48 Bits

14
 Multicast Addressing
Multicast Addressing
IP Multicast MAC Address Mapping
(FDDI & Ethernet)
Be Aware of the 32:1 Address Overlap
32 - IP Multicast Addresses
224.1.1.1
224.129.1.1
225.1.1.1 1 - Multicast MAC Address
225.129.1.1 (FDDI and Ethernet)
0x0100.5E01.0101
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
15
 How are Multicast Addresses
How are Multicast Addresses Assigned?
Assigned?
• Static Global Group Address Assignment
-Temporary method to meet immediate needs
-Group range: 233.0.0.0 - 233.255.255.255
•Your AS number is inserted in middle two octets
•Remaining low-order octet used for group
assignment
-Defined in RFC 2770
• “GLOP Addressing in 233/8”
• Manual Address Allocation by the Admin !!
-Is still the most common practice
16
 Host-Router signaling: IGMP
Host-Router Signaling: IGMP
• How hosts tell routers about group membership
• Routers solicit group membership from directly
connected hosts
• RFC 1112 specifies version 1 of IGMP
- Supported on Windows 95
• RFC 2236 specifies version 2 of IGMP
- Supported on latest service pack for Windows and most UNIX
systems
• RFC 3376 specifies version 3 of IGMP
- Supported in Window XP and various UNIX systems

17
 Host-Router signaling: IGMP
Host-Router Signaling: IGMP

Joining a Group

H1 H2 224.1.1.1 H3

Report

• Host sends IGMP Report to join group

18
 Host-Router signaling: IGMP
Host-Router Signaling: IGMP

Maintaining a Group
224.1.1.1 H1 224.1.1.1 H2 224.1.1.1 H3

X X
Suppressed Report Suppressed

Query

• Router sends periodic Queries to 224.0.0.1

• One member per group per subnet reports
• Other members suppress reports 19
 Host-Router signaling: IGMP
Host-Router Signaling: IGMP

Leaving a Group (IGMPv2)

224.1.1.1
H1 H2 H3

Leave to
#1 224.0.0.2

Group Specific
Query to 224.1.1.1
#2
1. Host sends Leave message to 224.0.0.2
2. Router sends Group specific query to 224.1.1.1
3. No IGMP Report is received within ~3 seconds
4. Group 224.1.1.1 times out 20
 Host-Router signaling: IGMP
Host-Router Signaling: IGMPv3

• RFC 3376
-Adds Include/Exclude Source Lists
-Enables hosts to listen only to a specified
subset of the hosts sending to the group
-Requires new ‘IPMulticastListen’ API
• New IGMPv3 stack required in the O/S.
-Apps must be rewritten to use IGMPv3
Include/Exclude features

21
Host-Router signaling: IGMP v3
Host-Router Signaling: IGMPv3
• New Membership Report address
-224.0.0.22 (IGMPv3 Routers)
• All IGMPv3 Hosts send reports to this address
» Instead of the target group address as in IGMPv1/v2
• All IGMPv3 Routers listen to this address
• Hosts do not listen or respond to this address
-No Report Suppression
• All Hosts on wire respond to Queries
» Host’s complete IGMP state sent in single response
• Response Interval may be tuned over broad range
» Useful when large numbers of hosts reside on subnet

22
 IGMP v3 Joining a Group
IGMPv3—Joining a Group

1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report Group: 224.1.1.1

(224.0.0.22) Exclude: <empty>

1.1.1.1

rtr-a

• Joining member sends IGMPv3 Report to 224.0.0.22

immediately upon joining
23
 IGMP v3 Joining specific
IGMPv3—Joining specific Source(s)
source(s)
1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report Group: 224.1.1.1

(224.0.0.22) Include: 10.0.0.1

1.1.1.1

rtr-a

• IGMPv3 Report contains desired source(s) in the

Include list.

• Only “Included” source(s) are joined. 24

 IGMP v3 Maintaining State
IGMPv3—Maintaining State

1.1.1.10 1.1.1.11 1.1.1.12

H1 H2 H3

v3 Report v3 Report v3 Report

(224.0.0.22) (224.0.0.22) (224.0.0.22)

1.1.1.1 Query

• Router sends periodic queries

• All IGMPv3 members respond

• Reports contain multiple Group state records 25

 Multicast L3 Forwarding
Multicast L3 Forwarding

•Multicast Routing is backwards from

Unicast Routing
-Unicast Routing is concerned about where
the packet is going.
-Multicast Routing is concerned about
where the packet came from.

26
 Unicast vs. Multicast
Unicast vs. Multicast Forwarding
Forwarding
• Unicast Forwarding
-Destination IP address directly indicates where to
forward packet.
-Forwarding is hop-by-hop.
•Unicast routing table determines interface and next-
hop router to forward packet.

27
 Unicast vs. Multicast
Unicast vs. Multicast Forwarding
Forwarding
•Multicast Forwarding
-Destination IP address (group) doesn’t directly
indicate where to forward packet.
-Forwarding is connection-oriented.
•Receivers must first be “connected” to the source
before traffic begins to flow.
» Connection messages (PIM Joins) follow unicast routing
table toward multicast source.
» Build Multicast Distribution Trees that determine where to
forward packets.
» Distribution Trees rebuilt dynamically in case of network
topology changes.
28
Reverse Path Forwarding (RPF)

• The RPF Calculation:

– The multicast source address is checked against
the unicast routing table.
– This determines the interface and upstream router
in the direction of the source to which PIM Joins
are sent.
– This interface becomes the “Incoming” or RPF
interface.
• A router forwards a multicast datagram only if
received on the RPF interface.
29
Reverse Path Forwarding (RPF)
Src
• RPF Calculation: 10.1.1.1
 Based on Source Address.
 Best path to source found A
in Unicast Route Table.
C
 Determines where to send Join
B
Join
Join
 Joins continue towards D
Source to build multicast E
E1

tree. E0
Unicast Route
 Multicast data flows down E2 Table
Net Itf
tree. 10.1.1.0/24 E0

H1
30
Reverse Path Forwarding (RPF)
Src
• RPF Calculation: 10.1.1.1
Unicast Route
 Repeat for other receivers. Table
Join Net Itf
A 10.1.1.0/24 E0

E0
C E2
B
E1
D

H2

H1
31
Reverse Path Forwarding (RPF)
Src
• RPF Calculation: 10.1.1.1
• What if we have equal-cost
paths?
• We can’t use both.
• Tie-Breaker:
• Use highest Next-Hop
IP address. 1.1.1.1 1.1.2.1

E0 E1

Unicast Route Table

Join
Net Itf Next Hop
10.1.1.0/24 E0 1.1.1.1
10.1.1.0/24 E1 1.1.2.1
H1
32
 Multicast Distribution Trees
• Shortest Path Distribution Tree
– The simplest form:
• Root is the source of the multicast traffic
• Branches form a spanning tree through the network to the receivers.
– Uses the shortest path through the network. Called shortest path
tree (SPT).
• Shared Trees:
– Single common root placed at some chosen point.
– Depending on the multicast routing protocol, this root is often
called a rendezvous point (RP) or core.
– Also called RP trees (RPT) or core-based trees (CBT).

33
 Multicast Distribution Trees
Shortest Path or Source Distribution Tree

Source 1 Source 2

Notation: (S, G)
S = Source
G= Group

Receiver 1 Receiver 2
34
 Multicast Distribution Trees
Shortest Path or Source Distribution Tree

Source 1 Source 2

Notation: (S, G)
S = Source
G= Group

Receiver 1 Receiver 2
35
 Multicast Distribution Trees
Shared Distribution Tree

Source 1 Source 2

RP

(RP) PIM
Notation: (*, G) Rendezvous Point
* = All sources
Shared Tree
G= Group
Source Tree

Receiver 1 Receiver 2
36
 Multicast Distribution Trees

• Characteristics of Distribution Trees:

– Source or Shortest Path trees:
• Uses more memory O(S x G)
• Optimal paths from source to all receivers 
minimizes delay
– Shared Trees:
• Uses less memory O(G)
• Suboptimal paths from source to all receivers may

introduce extra delay

37
 Data Distribution Choices

• Source rooted trees

– State in routers for each sender
– Forms shortest path tree from each sender to receivers
– Minimal delays from sources to destinations
• Shared trees
– All senders use the same distribution tree
– State in routers only for wanted groups
– No per sender state (until IGMPv3)
– Greater latency for data distribution

38
 Source Rooted vs Shared Trees

B A B A

Often does not use

optimal path from
source to
destination.

D C D C

Source
Rooted Shared Tree
Trees
Routers maintain Traffic is heavily concentrated on
state for each some links while others get little
sender in a group. utilization. 39
 Multicast Routing Protocols

• Current multicast protocols can be subdivided into

three basic categories:
– Dense mode protocols (DVMRP and PIM-DM)
– Sparse mode protocols (PIM-SM and CBT)
– Link-state protocols (MOSPF)
• PIM operates in either dense or sparse mode
depending on how the router is configured.
• Cisco PIM routers allow making the sparse/dense
decision dynamically on a multicast group basis.

40
 Dense Mode Protocols

• Dense mode protocols such as DVMRP and

PIM DM employ only SPTs to deliver (S, G)
multicast traffic using a push principle.
• Push principle assumes:
– Every subnet in the network has at least one
receiver of the (S, G) multicast traffic.
– The traffic is pushed or flooded to all points in
the network.

41
 Dense Mode Protocols
• Prune
– To avoid the unnecessary consumption of valuable
network resources, routers send Prune messages back
up the source distribution tree to shut off unwanted
multicast traffic.
– Branches without receivers are pruned off the
distribution tree, leaving only branches that contain
receivers.
– Prunes have a timeout value associated
– When they time out, they cause the router to put the interface
back into forward state and to start flooding multicast traffic out
this interface again.
.
42
 Dense Mode Protocols
• Grafting
– Most dense mode protocols rapidly can graft a
previously pruned branch back onto the distribution tree.
– When a new receiver on a previously pruned branch of
the tree joins the multicast group
• Router detects the new receiver and immediately sends a Graft
message up the distribution tree toward the source
– When the upstream router receives the Graft message,
the router immediately puts the interface on which the
Graft was received into forward state so that the
multicast traffic begins flowing down to the receiver.

43
 Sparse Mode Protocols
• Sparse mode protocols make distribution of
multicast traffic to receivers using:
– Shared trees
– Occasionally (as in PIM-SM), SPTs
• Instead of using a push model sparse mode
protocols use a pull model where multicast traffic is
pulled down to the receivers in the network.
• The pull model assumes:
– Multicast traffic is not wanted unless it is requested
specifically using an explicit Join mechanism

44
 Sparse Mode Protocols
• Shared Tree Join Messages
– To pull the multicast traffic down to a receiver in a
sparse mode network a shared tree branch must be
constructed from the root node (the RP in PIM-SM or the
core in CBT) to the receiver.
– To construct the shared tree branch, a router sends a
shared tree Join message toward the root of the shared
tree.
– The Join message travels router by router toward the
root, constructing a branch of the shared tree as it goes

45
 Sparse Mode Protocols
• Prune Messages
– In sparse mode, Prune messages are sent up the distribution tree
when multicast group traffic is no long desired.
– Branches of the shared tree or SPT that were created via explicit
Joins messages can be torn down when they are no longer
needed.
– E.g., if a leaf router detects that it no longer has any directly
connected hosts (or downstream multicast routers) for a particular
multicast group, the router sends a Prune message up the
distribution tree to shut off the flow of unwanted multicast group
traffic.
– Sending Prune messages, instead of waiting for the branch of the
sparse mode distribution tree to time out, greatly improves leave
latency in the network.

46
 Link State Protocols
• Link-state protocols such as MOSPF function much like
dense mode protocols:
– Both use SPTs to distribute multicast traffic to the receivers in the
network.
• Link-state protocols don't use the flood and Prune
mechanism that is used in DVMRP or PIM-DM.
• Instead, they flood special multicast, link-state information
that identifies the whereabouts of group members (that is,
receivers) in the network.
• All routers in the network use this group membership
information to build shortest path trees from each source to
all receivers in the group..

47
 Distance Vector Multicast Routing
(DVMRP)
• Steve Deering, 1988
• Source rooted spanning trees
– Shortest path tree (SPT)
– Minimal hops (latency) from source to receivers
• Extends basic distance vector routing
• Flood and prune algorithm
– Initial data sent to all nodes in network(!) using Reverse Path
Forwarding
– Prunes remove unwanted branches
– State in routers for all unwanted groups
– Periodic flooding since prune state times out (soft state)

48
 DVMRP Algorithm
• Truncated Reverse Path Multicast
– Optimized version of Reverse Path Forwarding
– Truncating
• No packets sent onto leaf networks with no receivers
– Still how “truncated” is this?
• Pruning
– Prune messages sent if no downstream receivers
– State maintained for each unwanted group
• Grafting
– On join or graft, remove prune state and
propagate graft message
49
 Truncated Reverse Path
Multicast Example
Router R2 accepts packets sent
from Router R1 because that is Sender
the shortest path to the Sender.

Unlike RPF, which simply

forwards out all but the incoming
interface, DVMRP’s Reverse Path
Multicast maintains a list of child
R1
links for each sender.

Packets are sent out using only siblings

child links not parent or sibling R2 R3
links. Router R2 will not forward
data from the Sender to Router
R3.
R5

R6 R7 R8

Receiver
Truncation: no packets
forwarded onto leaf
networks with no
receivers
50
 DVMRP Pruning Example

Sender

R1

R2 R3

Prune Messages R5

R6 R7 R8

Receiver

51
 DVMRP Grafting Example

Sender

Join from
Receiver 2
causes router
R1 to remove its
prune state and
send a Join
R2 R3 message up
toward the
Pruned Links Sender.

R5 R8
Graft Messages
R6 R7
Membership Report
Receiver 2
Receiver 2 joins multicast
Receiver
group

52
 DVMRP Problems

• State maintained for unwanted groups

• Bandwidth intensive
– Periodic data flooding per group
• No explicit joins, and prune state times out
– Not suitable for heterogeneous networks
• Poorly handles large number of senders
– Scaling = O(Senders, Groups)
• Problems of distance vector routing
– Slow convergence
– Cycles due to lack of global knowledge
53
 Core Based Trees (CBT)

• Attributes
– Single shared tree per group => sparse trees
– Large number of senders
– Routing tables scale well, size = O(Groups)
– Bi-directional tree

54
 Group Management in CBT
2. Receiver 2 also
Join Messages Core joins the multicast
group, causing
Router R3 to join the
ACK Messages shared tree by
sending a Join
message toward the
R R Core. Router R4 is
already part of the
shared tree, so it
adds R3 to the
shared tree and
R R R4 sends back an ACK.

R2 R3
R1 R
1. Receiver 1 joins the multicast
group, causing Router R2 to join the
shared tree by sending a Join Receiver 1 Receiver 2
message toward the Core. The Core
sends an explicit ACK back to
Router R2. 55
 Group Sending Data in CBT
(1)in CBT Packets from the
Case 1: Sender is a Sender are
Core propagated by
member of the multicast
routers on the
group, and the first hop shared tree by
router is on the shared sending out all
interfaces that are
tree.
R R branches of the
tree except the
interface the
packet arrived on.

R R R4

R2 R3
R1 R

Sender
Receiver 1

Receiver 2
56
 Group Sending Data in CBT (2)
Case 2: Sender is not a member
Core 2. The Core unencapsulates
the encapsulated packets,
of the multicast group, and the and it distributes them out
first hop router is not on the the shared tree.
shared tree.

R R

R R R4

Receiver 3

R
R1
R2 R3
R
1. R1 is not on the shared
tree, so it does an IP-in-IP
Sender encapsulation of packets Receiver 1
from the Sender, and it
unicasts the encapsulated
packets to the Core. Receiver 2
57
 Multicast Tree Creation

• PIM Join/Prune Control Messages

– Used to create/remove Distribution Trees
• Shortest Path trees
– PIM control messages are sent toward the Source
• Shared Trees:
– PIM control messages are sent toward RP

58
 Multicast Distribution Tree
Creation
Shared Tree Example

A B D (RP) F

C E

(RP) PIM Rendezvous Point

PIM Messages

Receiver 1 Receiver 2
59
 Major Deployed PIM Variants

• PIM ASM:
– Sparse mode / RP / SPT / Shared Tree
• PIM SSM:
– Source Specific Multicast, no RP, SPT only
• PIM BiDir:
– BiDirectional PIM, no SPT, Shared tree only

60
PIM-SIM Shared Tree Join

RP

(*, G) State created only

along the Shared Tree.
(*,G) Join

Shared
Tree

Receiver 1
61
PIM-SIM Sender Registration

RP

Sender

(S, G) State created only

along the Source Tree.
(S,G) Join (S,G) Register
(unicast)
Shared
Tree Traffic Flow
Source Receiver 1
Tree
62
 PIM-SIM Sender Registration
(II)
(S, G) traffic begins
arriving at the RP via the
Source tree.
RP sends a Register-
Stop
back to the first-hop
RP
router

Sender

(S,G) Join (S,G) Register

(unicast)
Shared
Tree (S,G) Register-Stop
(unicast)
Source Receiver 1
Tree Traffic Flow
63
PIM-SIM Sender Registration
(III)

RP

Sender
Source traffic flows natively
along SPT to RP.
From RP, traffic flows down
the Shared Tree to
Receivers.
Shared
Tree
Source Receiver 1
Tree Traffic Flow
64
 PIM-SIM SPT Switchover

RP

Sender
Last-hop router joins the
Source Tree.
Additional (S, G) State is
created along new part of
the Source Tree.

Shared (S,G) Join

Tree
Source Traffic Flow
Receiver 1
Tree
65
 PIM-SIM SPT Switchover (II)
Traffic begins flowing down
the new branch of the
Source Tree. Additional (S,
G) State is created along the
Shared Tree to prune off (S, RP
G) traffic.

Sender

Shared
Tree
(S,G) RP-bit Prune
Source Receiver 1
Tree Traffic Flow
66
 PIM-SIM SPT Switchover (III)
(S, G) Traffic flow is now
pruned off of the Shared Tree

and is flowing to the

Receiver via the Source Tree.

(S, G) traffic flow is no RP

longer needed by the RP so
it Prunes the flow of (S, G)
traffic.

Sender

Shared
Tree
(S,G) Prune
Source Receiver 1
Tree Traffic Flow
67
 PIM-SIM SPT Switchover (IV)

(S, G) Traffic flow is now

only
flowing to the Receiver via a
single branch of the Source RP
Tree.

Sender

Shared
Tree
Source Receiver 1
Tree Traffic Flow
68
 PIM-SIM
• Default behavior of PIM-SM :
– Routers with directly connected members will join the Shortest
Path Tree as soon as they detect a new multicast source.
• Effective for Sparse or Dense distribution
of multicast receivers
• Advantages:
– Traffic only sent down “joined” branches
– Can switch to optimal source-trees for high traffic
sources dynamically
– Unicast routing protocol-independent
– Basis for inter-domain multicast routing
• When used with MBGP, MSDP and/or SSM

69
 Source Specific Multicast
• One-to-Many Multicast Model:
– E.g., Video/Audio broadcasts, Stock Market data
• Why does PIM-SM need a Shared Tree?
– So that hosts and 1st hop routers can learn who the active source
is for the group.
• What if this was already known?
– Hosts could use IGMPv3 to signal exactly which (S,G) SPT to join.
– The Shared Tree & RP wouldn’t be necessary.
– Different sources could share the same Group address and not
interfere with each other.
– Result: Source Specific Multicast (SSM)
– RFC 3569 An Overview of Source-Specific Multicast (SSM)

70
 PIM Source Specific Mode
Receiver learns of source, group/port
Receiver sends IGMPv3 (S,G) Join
First-hop send PIM (S,G) join directly toward
Source

Out-of-band
Source Directory
(S, G) Join E.g.,Web Server

IGMPv3 (S, G)
Join

71
PIM Source Specific Mode
Result: Shortest Path Tree rooted at the
Source, with NO Shared Tree.

72
 PIM SSM - Evaluation

• Ideal for applications with one source

sending to many receivers
• Solves multicast address allocation
problems.
– Flows differentiated by both source and group.
• Not just by group.
– Content providers can use same group ranges.
• Since each (S,G) flow is unique.
– Helps prevent certain DoS attacks
• “Bogus” source traffic:
– Can’t consume network bandwidth.
– Not received by host application.
73
 Many–to-Any State Problem

• Creates huge amounts of (S,G) state

– State maintenance workloads skyrocket
• High OIL fanouts make the problem worse
– Router performance begins to suffer
• Using Shared-Trees only.
– Provides some (S,G) state reduction
• Results in (S,G) state only along SPT to RP
• Frequently still too much (S,G) state
• Need a solution that only uses (*,G) state

74
 Bidirectional PIM Overview

RP

Receiver

Shared Tree
Sender
Receiver

Receiver
75
 Bidirectional PIM Overview

RP

Receiver

Shared Tree
Sender
Receiver

Receiver
76
 Bidirectional PIM Evaluation

• Ideal for Many to Many applications

• Drastically reduces network mroute state.
– Eliminates ALL (S,G) state in the network.
• SPT’s between sources to RP eliminated.
• Source traffic flows both up and down Shared Tree.
– Allows Many-to-Any applications to scale.
• Permits virtually an unlimited number of sources.

77
Automating Distribution of RP
• PIM-SM and PIM sparse-dense modes use various methods to
automate the distribution of the RP.
• Benefits:
– Eliminates the need to manually configure RP information in every
router and switch in the network.
– Easy to use multiple RPs within a network to serve different group
ranges.
– Allows load-splitting among different RPs and allows the
arrangement of RPs according to the location of group participants.
– Avoids inconsistency; manual RP configurations may cause
connectivity problems, if not configured properly.
• PIM uses the following mechanisms to automate the distribution of the
RP:
– Auto-RP
– Bootstrap router (BSR)
78
 Distribution of RP (Cisco)
RP Mapping Agent sends group-to-RP
mappings (every 60 secs) RP mapping agent
224.0.1.40 224.0.1.40

R2 and R3 learn R2 R3
group-to-RP mappings as
they are members of the
224.0.1.40 224.0.1.40
224.0.1.40 multicast group,
Cisco-RP discovery.
R4 R5

• Auto-RP automates the distribution of group-to-RP mappings.

– Defines which multicast groups use which RP.
• All routers in the PIM network learn about the active group-to-RP mapping from the RP
mapping agent by automatically joining the Cisco-RP-discovery (224.0.1.40) multicast
group.
• The RP mapping agent is the router that sends the authoritative discovery packets
that notify other routers which group-to-RP mapping to use (every 60 seconds).
• Such a role is necessary in the event of conflicts (such as overlapping group-to-RP
ranges).
79
 RP-Announce (Cisco)
RP mapping agent

Cisco RP-Announce Cisco RP-Announce

224.0.1.39 224.0.1.39

Candidate Candidate
for RP R2 R3 for RP

Candidate RPs send RP-

Announce every 60 secs to
224.0.1.39. R4 R5

• Mapping agents use multicast to discover which routers in the network are possible
candidate RPs by joining the Cisco-RP-announce (224.0.1.39) group to receive
candidate RP announcements.
• Candidate RPs send RP-announce multicast messages for the particular groups every
60 seconds.
• The RP mapping agent uses the information contained in the announcement to create
entries in group-to-RP cache.
– RP mapping agents create only one entry per group.
– If more than one RP candidate announces the same range, then the RP mapping
agent uses the IP address of the RP to break the tie. 80
 IPv4 vs. IPv6 Multicast
IP Service IPv4 Solution IPv6 Solution
Address Range 32-bits,class D 128-bits (112 bits
group)
Routing Protocol Independent Protocol Independent
All IGPs,and BGP4+ All IGPs,and BGP4+
with v6 mcast SAFI

Forwarding PIM-DM, PIM-SM, PIM-SM, PIM-SSM,

PIM-SSM, PIM-bidir PIM-bidir

Group Management IGMP v1,v2,v3 MLD v1,v2

Domain Control Boundary/Border Scope Identifier
Inter-Domain MSDP accross Single RP within
Solutions Independent PIM Globally Shared
Domains Domains
81
 IPv6 Multicast Addresses
(RFC3513)
128 bits
8 bits 4 bits 4 bits

FF Flags Scope Group-ID

Flags:
1111 00PT Scope • P  proposed for unicast-based assignments
1111
• T (Lifetime) 0=permanent, 1=temporary

Scope (where the address is valid and unique?):

• 1  Interface-Local (Loopback)
• 2  Link-local
• 4  Admin
• 5  Site (single site)
• 8  Organization (multiple sites/1 organization)
• E  Global
82
 IPv6 Layer 2 Multicast
Addressing Mapping
112 bits
8 bits 4 bits 4 bits 80 bits 32 bits

FF Flags Scope High-Order WW XX YY ZZ

80 bits lost

33:33:WW:XX:YY:ZZ

48 bits
Ethernet MAC Address

83
 Unicast Based Multicast
Addresses
8 bits 4 bits 4 bits 8 bits 8 bits 64 bits 32 bits

FF Flags Scope Rsvd Plen Network Prefix Group-ID

• RFC 3306 - Unicast-based Multicast Addresses

• Includes Unicast-Prefix information in multicast address
• Similar to IPv4 “GLOP” Addressing
• Solves IPv6 global address allocation problem
• Flags = 00PT
• P=1, T=1  Unicast-based Multicast Address
• Plen  indicates number of bits in network prefix field
• Example:
• Content Provider´s Unicast Prefix:
• 1234:5678:9abc::/64
• Multicast Address:
• FF36:0030:1234:5678:9abc::0001 84
 IPv6 Multicast Forwarding

• PIM-Sparse Mode (PIM-SM)

• PIM-Source Specific Mode (PIM-SSM)
– RFC3569 SSM overview (v6 SSM needs MLDv2)
– Unicast prefix based multicast addresses
ff30::/12
– SSM range is ff3X::/32
• Current allocation is from ff3X::/96
• PIM-bidirectional (PIM-bidir)

85
 Embedded RP Addressing
RFC 3956
8 bits 4 bits 4 bits 4 bits 4 bits 8 bits 64 bits 32 bits

FF Flags Scope Rsvd RPAd Plen Network Prefix Group-ID

• New multicast address type

• Uses Unicast-Based Multicast addresses (RFC 3306)
• RP Address is embedded in multicast address.
• Flags = 0RPT
• R=1, P=1, T=1  embedded RP Address
• Network-Prefix::RPAd  RP Address
• For each Unicast prefix you control, you now also control:
• 16 RPs for each of the 16 Multicast Scopes (256 total)
with 2^32 multicast groups assigned to each RP (2^40
total)
86
 Embedded RP Addressing
Example
8 bits 4 bits 4 bits 4 bits 4 bits 8 bits 64 bits 32 bits

FF Flags Scope Rsvd RPAd Plen Network Prefix Group-ID

FF76:0130:1234:5678:9ABC::4321

1234:5678:9ABC::1

Resulting RP address
87
 Multicast Listener Discover
MLD
• MLD is equivalent to IGMP in IPv4
• MLD Messages are transported over ICMPv6
• Version number mapping:
– MLDv1 corresponds to IGMPv2
• RFC 2710
– MLDv2 corresponds to IGMPv3 (needed for SSM)
• RFC 3810
• MLD snooping
– Multicast traffic is forwarded to only those interfaces
associated with IP multicast address

88
Chapter 3 outline
• 3.1 Introduction
• 3.2 Multicast over IP
• 3.3 Multicast Applications

89
 Supporting Multicast on the
Internet

Application
? At which layer should
multicast be implemented?
IP ?

Network

Internet architecture
90
 End-System Multicast
MIT1
MIT
Berkeley
MIT2
UCSD

CMU1
CMU
CMU2

91
 Potential Benefits Over IP
Multicast
• Quick deployment
• All multicast state in end systems
• Simplifies support for higher level functionality
– Reliability, congestion control, etc.

92
 Concerns with End-System
Multicast
• Self-organize recipients into multicast delivery overlay tree
– Must be closely matched to real network topology to be efficient
• Performance concerns compared to IP Multicast
– Increase in delay
– Bandwidth waste (packet duplication)
– Not usually substantial problems

Berkeley MIT1 Berkeley MIT1

UCSD MIT2 MIT2

UCSD
CMU1
CMU1

IP Multicast CMU2 End System Multicast

CMU2
93
 Concerns with End-System
Multicast
• Reality: Many users behind asymmetric
DSL/Cable modems
– Not enough upload bandwidth to forward!
– => Must be leafs in the multicast tree
• Key Metric: Resource Index
– forwarding capacity/total bandwidth demand
– Measured ESM video groups have RI of 1-2…
– => Building feasible tree is challenging (+ dealing with
group dynamics, etc.)

94
 IPTV Transmission
IPTV supports two kinds of services:
• Multicast IPTV:
– An emitter sends the same content to multiple receivers
the same time.
• Unicast IPTV:
– An emitter sends TV content to multiple receivers.
– In contrast to multicast IPTV every receiver receives
different content.
– Personalized TV content, e.g. video on demand.
 IPTV Multicast
• Multicast IPTV enables a TV content provider to send TV
content to many subscribers at the same time.
• IP multicast saves considerable bandwidth, since only
one stream is transmitted over the network
• When a server multicasts data to several clients, it
sends this data to the corresponding router only once.
• Similarly to regular TV, multicast IPTV supports
multiple channels and sends them at the same time.
• IPTV does not broadcast to a user all channels at the
same time.
– IPTV divides channels into groups and sends to each user the
group that contains the requested channel.
– The user can switch between channels at any time.
• IGMP snooping to save bandwidth
IPTV Multicast Service
 IPTV Unicast
• Unicast IPTV sends a given TV content to a given
user.
• Video on Demand is a typical service of IPTV,
which enables a user to request a specific movie
and to receive it on his TV set.
• Contrary to multicast IPTV, unicast IPTV does not
save bandwidth, since the server must send the
content once for each user.
• Unicasting can be extremely demanding on the
server if multiple streams must be generated by
the media server and transmitted over the
network.
IPTV Unicast Service
 Other approaches: P2P TV

• Content is not only broadcasted from a

single central server but also from peers
• Different architectures:
– Tree-based (similar to multicast)
– Multi-tree based
• Several concurrent trees
– Unstructured

100
 Important Concepts
• Multicast provides support for efficient data delivery to multiple
recipients
• Requirements for IP Multicast routing
– Keeping track of interested parties
– Building distribution tree
– Broadcast/suppression technique
• Build reliability, congestion control, in-order delivery on top
– Just like with TCP/IP, but harder…
• Difficult to deploy new IP-layer functionality
• End system-based techniques can provide alternative
– Easier to deploy

101