multicast.ppt 912KB Jun 23 2011 12:10:54 PM

CS640
Introduction to Computer Networks
Multicast
Nov 29th, 1999
Prof. Lawrence H. Landweber
Prof. Jun Murai

One to many communication
• Application level one to many communication
• multiple unicasts

• IP multicast

R
S

R
S

R

R

R

R

Why Multicast
• When sending same data to multiple receivers
– better bandwidth utilization
– less host/router processing
– quicker participation

• Application
– Video/Audio broadcast (TV, radio type)
– Video conferencing
– Real time news distribution

IP multicast service model
•
•

•
•
•
•

RFC1112 : Host Extensions for IP Multicasting
Transmission of an IP datagram to a "host group",
host group identified by a class D IP address
Members of the group could be present anywhere in the Internet
Members join and leave the group and indicate this to the routers
Senders and receivers are distinct: i.e., a sender need not be a me
mber
• Routers listen to all multicast addresses and use multicast routing
protocols to manage groups (IGMP, Internet Group Management
Protocol, RFC2236)

IP multicast group address
• Class D address space
– high-order three 3bits are set
– 224.0.0.0 ~ 239.255.255.255

• Well-known address designated by IANA
– RFC1700
– 224.0.0.0 ~ 224.0.0.25
– 224.0.0.1 (ALL-SYSTEMS.MCAST.NET)
• all multicast hosts on the subnet

– 224.0.0.2 (ALL-ROUTERS.MCAST.NET)
• all multicast routers on the subnet

IGMP – Joining a group
IGMP
MembershipReport
R

Example : R joins to Group 224.2.0.1
•

R sends IGMP Membership-Report
to 224.2.0.1

•

DR receives it. DR will start
forwarding packets for 224.2.0.1 to
Network A

•

DR periodically sends IGMP
Membership-Query to 224.0.0.1
(ALL-SYSTEMS.MCAST.NET)

•

R answers IGMP MembershipReport to 224.2.0.1

Network A
DR
Network B

Data to
224.2.0.1

R: Receiver
DR: Designated

IGMP – Leaving a group
Example : R leaves from a Group 224.2.0.1

IGMP
Leave-Group
R

•

R sends IGMP Leave-Group to 224.0.
0.2
(ALL-ROUTERS.MCAST.NET)

Network• A DR receives it.
•
DR
Network B

Data to
224.2.0.1

R: Receiver
DR: Designated

DR stops forwarding packets for 224.2.
0.1 to Network A if no more 224.2.0.1 gr
oup members on Network A.

Challenges in this model
• How to select receivers by a sender ?
–
–
–

–

need authentication, authorization
encryption of data
key distribution
still under research phase

IP multicast routing
• Purpose: share a Group information among
routers, to implement a better routing for da
ta distribution
• Distribution tree structure
– Source tree vs shared tree

• Data distribution policy
– ACK type vs NACK type

Source distribution tree
Source

S

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

A

B

D

C

F

E

R

R

Receiver 1

Receiver 2

Shared distribution tree
Source

S1
Notation: (*, G)
* = all sources
G = Group

Shared Root
A

B

D

C

F

E

R

R

Receiver 1

Receiver 2

S2

Source tree characteristics
• Source tree
– More memory O (G x S ) in routers

– optimal path from source to receiver, minimizes
delay

• good for
– small number of senders, many receivers such
as Radio broadcasting application

Shared tree characteristics
• Shared tree
– less memory O (G) in routers
– Sub-optimal path from source to receiver, may introduce e
xtra delay (source to root)
– May have duplicate data transfer (possible duplication of a
path from source to root and a path from root to receivers)

• good for
– Many senders with low bandwidth
– environment such as most part of the shared tree is identic
al to the source tree

Data distribution policy
• NACK type
– Start with “broadcasting” then prune brunches with no
receivers, to create a distribution tree
– a lot of un-used traffic when small receivers in wide
area

• ACK type
– forward only to the hosts which explicitly joined to the
group
– latency by join propagation and high costs when many
receivers

Protocol types
• Dense mode protocols
–
–
–
–

assumes dense group membership
Source distribution tree and NACK type
DVMRP (Distance Vector Multicast Routing Protocol)
PIM-DM (Protocol Independent Multicast, Dense Mode)

• Sparse mode protocol
–
–
–
–

assumes sparse group membership
Shared distribution tree and ACK type
PIM-SM (Protocol Independent Multicast, Sparse Mode)
CBT

DVMRP
exchange distance vector
• Maintain ‘multicast routing table’ by exchanging distance
vector information among routers
– consistent view of a tree among all routers
– convenient to have separate paths for unicast versus multicast data
grams;( ie tunnelings)

• ‘Dependent routers’ information
– information about responsible downstream routers for a source
– A downstream router send “poison Reverse” to a selected upstrea
m router to indicate the dependency.
– Poison Reverse : metric + 32 (inf)
– entry will be removed from the list by prune message

• Designated Forwarder
– multiple routers on the same LAN
– lower metric or lower IP address becomes the designated forwarde
r (discover when exchanging metric info.)

DVMRP
broadcast & prune
• Forward multicast packets based on RPF (Reverse path for
warding) rule
• leaf routers check and sends prune message to upstream ro
uter when no group member on the network
• upstream router prune the interface with no dependent dow
nstream router.
• Graft message to create a new branch for late participants
• Restart forwarding after prune lifetime (standard : 720 min
utes)
• draft-ietf-idmr-dvmrp-v3-09.txt (September 1999)

RPF(reverse path forwarding)
• RPF check
– A packet received through interface I, from S (source) to G (multica
st group) – packet (S,G)
– A router looks into the routing table to find an interface used to send
packet to S, I(parent).
– If I != I (parent), I is a wrong interface to receive (S,G).
– if I = I(parent), I is a correct interface to receive (S, G).

• If the RPF check succeeds, the datagram is forwarded to all inter
faces except I.
• If the RPF check fails, the datagram is typically silently discarded
• Packet is never forwarded back out the RPF interface!

DVMRP (1)
form a source tree by exchanging metric
source tree
S

DF

R1
Receiver 1

Source

DVMRP (2)
broadcast
S

DF

R1
Receiver 1

Source

source tree
datagram

DVMRP (3)
prune
S

DF

R1
Receiver 1

Source

source tree
datagram
IGMP DVMRP-Prune

DVMRP (4)
X and Y pruned
S

DF

source tree
datagram

Source

X
Y

R1
Receiver 1

DVMRP (4)
New member
S

DF

source tree
datagram
IGMP DVMRP-Graft

Source

X
Y

R1
Receiver 1

R2
Receiver 2

DVMRP (4)
New branch
S

DF

source tree
datagram
IGMP DVMRP-Graft

Source

X
Y

R1
Receiver 1

R2
Receiver 2

PIM
• PIM : Protocol Independent Multicast
– independent of particular unicast routing protocol
– Pros: simple, less overhead
– Cons: may cause more broadcast-and-prunes

• All routers in a domain support PIM
• No multicast tunnel
• PIM v2 is assigned new protocol 103

PIM DM overview(1)
• Broadcast and prune ideal for dense group
• Source tree created on demand based on RP
F rule
• If the source goes inactive, the tree is torn d
own
• Easy plug-and-play
• Branches that don’t want data are pruned

PIM DM overview(2)
• Grafts used to join existing source tree
• Uses Asserts to determine the forwarder for
multi-access LAN
• Prunes on non-RPF P2P links
• Rate-limited prunes on RPF P2P links

PIM DM Forwarding
• PIM DM interfaces are placed on the “oilist” for a
multicast group if;
– PIM neighbor heard on interface
– Host on this interface has just joined the group
– Interface has been manually configured to join group

• Packets are “flooded” out all interfaces in “oilist”
– If a PIM neighbor is present, DM assumes EVERYON
E wants to receive the group so it gets flooded to that li
nk by definition

PIM Assert Mechanism
• Routers receive packet on an interface in their “oil
ist”
– Only one router should continue sending to avid duplic
ate packets.

• Routers sends “PIM assert” messages
–
–
–
–

Compare distance and metric values
Router with best route to source wins
If metric & distance equal, highest IP addr wins
Losing router stops sending (prunes interface)

PIM DM State Maintenace
• State is maintained by the “flood and prune”
behavior of Dense mode.
– Received Multicast packets reset(S,G) entry “ex
piration” timers.
– When (S,G) entry “expiration” timers count dow
n to zero, the entry is deleted.

• Interface prune state timers out every 210 se
conds causing periodic reflooding and pruni
ng

PIM-DM(1)
Initial flood of data

S

Source

A

B

C

D

G
F
H

R1
Receiver 1

E

I
R2
Receiver 2

PIM-DM(2)
prune non-RPF p2p link

S

IGMP PIM-Prune

Source

A

B

C

D

G
F
H

R1
Receiver 1

E

I
R2
Receiver 2

PIM-DM(3)
C and D Assert to Determine
Forwarder for the LAN, C Wins

S

IGMP PIM-Assert
with its own IP address

Source

A

B

C

D

G
F
H

R1
Receiver 1

E

I
R2
Receiver 2

PIM-DM(4)
I, E, G send Prune
H send Join to override G’s Prune

S

IGMP PIM-Prune
IGMP PIM-Join

Source

A

B

C

D

G
F
H

R1
Receiver 1

E

I
R2
Receiver 2

PIM-DM(5)
I Gets Pruned
E’s Prune is Ignored
G’s Prune is Overridden

S

Source

A

B

C

D

G
F
H

R1
Receiver 1

E

I
R2
Receiver 2

PIM-DM(6)
New Receiver, I send Graft

S

IGMP PIM-Graft

Source

A

B

C

D

G
F
H

R1
Receiver 1

I

E

R2
R3
Receiver 3

Receiver 2

PIM-DM(6)
new branch

S

IGMP PIM-Graft

Source

A

B

C

D

G
F
H

R1
Receiver 1

I

E

R2
R3
Receiver 3

Receiver 2

PIM-SM overview (1)
• Shared Tree for a group with RP (Rendez-Vous Point) a
s a root
• Explicit Join Model
– Receivers send Join towards the RP
– Sender Register with RP
– Last hop routers can join source tree if the data rate warrants
by sending joins to the source

• RPF check depends on tree type
– For shared trees, uses RP address
– For source tress, uses Source address

PIM-SM overview(2)
• Only one RP is chosen for a particular group
• RP statically configured or dynamically learned
(Auto-RP, PIM v2 candidate RP advertisements)
• Data forwarded based on the source state (S, G)
if it exists, otherwise use the shared state (*, G)
• RFC2362 – “PIM Sparse Mode Protocol Spec”
(experimental)
• Internet Draft: draft-ietf-pim-v2-sm-00.txt
(October 1999)

PIM-SM Basics
•
•
•
•
•
•
•
•

PIM Neighbor Discovery
PIM SM Forwarding
PIM SM Joining
PIM SM REgistering
PIM SM SPT-Swichover
PIM SM Pruning
PIM SM Bootstrap
PIM SM State Maintenance

PIM Neighbor Discovery
• PIM Hellos are multicast to the “All-PIMRouters” (224.0.0.13, ff02::d) multicast
group address periodically
• Highest IP address elected as “DR”
(Designated Router)
• If “DR” times-out, a new “DR” is elected

PIM SM Bootstrap
• A set of routers are configured as candidate Bootstra
p Router(BSR)s
– single BSR is selectd for the domain

• Candidate RPs periodically unicast Candidate-RP-A
dvertisement messages (C-RP-Advs) to BSR
• The BSR periodically sends Bootstrap messages cont
aining the set of Candidate-RPs
– Bootstrap message are flooded in the domain

• Routers receive and store Bootstrap messages origina
ted by the BSR.

PIM SM State Maintenance
• Periodic Join/Prunes are sent to all PIM nei
ghbors
• Periodic Joins refresh interfaces in a PIM ne
ighbor’s oilists
• Periodic Prunes refresh prune state in a PIM
neighbor
• Received Multicast packets reset(S,G) entry
expiration timers.

PIM-SM(1)
S

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(2)
S

Receiver 1 Joins Group G
C Creates (*, G) State, Sends
(*, G) Join to the RP

Source

A

B

RP

D

Join

C

R1

E

Receiver 1

R2

Receiver 2

PIM-SM(3)
S

RP Creates (*, G) State

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(4)
S

Source Sends Data
A Sends Registers to the RP

Source
Register
Data

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(5)
S

RP de-encapsulates Registers
Forwards Data Down the Shared Tree
Sends Joins Towards the Source

Source

join

A

join

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(6)
S

RP Sends Register-Stop Once
Data Arrives Natively

Source
Register-Stop

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(7)
SPT Switchover
S

C Sends (S, G) Joins to Join the
Shortest Path (SPT) Tree

Source

A

B

RP

D

join

C

R1

E

Receiver 1

R2

Receiver 2

PIM-SM(8)
S

C starts receiving Data natively

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(9)
S

C Sends Prunes Up the RP tree for
the Source. RP Deletes (S, G) OIF and
Sends Prune Towards the Source

Source

Prune

A

Prune

B

RP

D

Prune

C

R1

E

Receiver 1

R2

Receiver 2

PIM-SM(10)
S

B, RP pruned

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(11)
S

New receiver2 joins
E Creates State and Sends (*, G) Join

Source

A

B

RP

C

D

E
join

R1

Receiver 1

R2

Receiver 2

PIM-SM(12)
S

C Adds Link Towards E to the OIF
List of Both (*, G) and (S, G)
Data from Source Arrives at E

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

PIM-SM(13)
S

C Adds Link Towards E to the OIF
List of Both (*, G) and (S, G)
Data from Source Arrives at E

Source

A

B
C

R1

RP

D

E

Receiver 1

R2

Receiver 2

Inter-Domain Multicast Routing
• BGP4+ (Multicast BGP) for short-term
solution
• MASC : Multicast Address Set and Claim
• BGMP : Border Gateway Multicast
Protocol

MASC
• Hierarchical multicast address allocation
• dynamic allocation (lease) by “set and claim
with collision”
domain A
domain B
domain
D

domain C

domain E

MASC
• Assume Addr(A) is allocated to domain A, A notify to B C and E.
• B selects Addr(B) , subset of Addr(A) and send Claim (addr(B))
message to A and C
• A forward it to all children except B.
• If A’s children is already using Addr(B), report collision to A.
• A notify the collision to B to select other address space.
• B wait for a certain period before using it.
• Address space information is used to create distribution tree using
BGMP.
• Stored in M-RIB (Multicast Routing Information Base)

BGMP
• Use a PIM-like protocol between domains (“BGP for multicas
t”)
• BGMP builds shared tree of domains for a group
– So we can use a rendezvous mechanism at the domain level
– Shared tree is bidirectional
– Root of shared tree of domains is at root domain

•
•
•
•
•

Runs in routers that border a multicast routing domain
Runs over TCP like BGP
Joins and prunes travel across domains
Can build unidirectional source trees
M-IGP(multicast Intra-Gateway Protocol) tells the borders about group m
embership

BGMP
A host in C joins to Group G

E1 DomainE

DomainD D1
A4

A1
DomainA

Root domain

A3

join
M-IGP

join

B2 DomainB B1
F2
DomainF F1

A2
join

C1

M-IGP

DomainC

BGMP
Tree constructed, data goes to C

E1 DomainE

DomainD D1
A4

A1
DomainA

Root domain

B2 DomainB B1
F2
DomainF F1

A3

A2
C1
DomainC

BGMP
Domain E joins to G

E1 DomainE

join

DomainD D1
A4

join

A1

DomainA
A3
B2 DomainB B1
F2
DomainF F1

A2
C1
DomainC

BGMP
tree constructed. Data goes to E

E1 DomainE

DomainD D1
A4

A1
DomainA

A3
B2 DomainB B1
F2
DomainF F1

A2
C1
DomainC

Multicast Routers
• mrouted (Xerox PARC) : DVMRP
• GateD (Merit) : DVMRP, PIM-DM, PIM-S
M
• Cisco IOS : DVMRP, PIM-DM, PIM-SM

M-Bone
• Wide area IP multicast test bed using IP-in-IP tunneling technol
ogy
• Routing protocol
– DVMRP is used
– Transition to PIM (DM, SM) is ongoing

• Started in March 1992 for audio broadcasting of IETF meeting
(San Diego)
• Latest tolopology
– ftp://ftp.parcftp.xerox.com/pub/net-research/mbone/maps/mbone-map-big.ps

– About 6000 (S,G) entries

• Discussion in by mbone@isi.edu

M-BONE in 1994

M-BONE in 1996

M-BONE in 1998

Future Mulicast Service
• Current multicast service - latency and
packet drop
• Research for “Reliable multicast” is
actively going on for;
– large scale interactive game on the Internet
– Distributed database
– large scale news distribution etc.

Reliable multicast technology
• SRM ( scalable Reliable Multicast)
– multicast with re-transmit (with random back-off)
– All nodes can re-transmit datagram (Multicast/Unica
st)

• MTP (Multicast Transport Protocol: RFC1301)
• FEC (Forward Error Correction)
– error packet recovery by redundant packets

IPv6 Multicast Test
10sites in Japan
PIM-SM over IPv6 (KAME)
Digital Video streaming

Nov 27th, 1999