Multicast Routing Protocols

The Need for Multicast Routing

Routing based on member information– Whenever a multicast router receives a multicast packet it

checks the group ID of the message and forwards the packet only if there is a member of that group in networks connected to it

Member information exchange– For delivering a multicast packet from the source to the

destination nodes on other networks, multicast routers need to exchange the information they have gathered from the group membership of the hosts directly connected to them

Basic Router Model

Since hosts can send any time to any group, routers must be prepared to receive on all link-layer group addresses– And know when to forward or drop packets

What does a router keep track of?– interfaces leading to receivers– sources when utilizing source distribution trees– prune state depending on the multicast routing protocol (e.g. Dense Mode)

Data Distribution Concepts

Routers maintain state to deliver data down a distribution tree Source trees

– Router keeps (S,G) state so packets can flow from the source to all receivers

– Trades off low delay from source against router state

Data Distribution Concepts

Shared trees– Router keeps (*,G) state so packets flow from the root of the

tree to all receivers– Trades off higher delay from source against less router state

Data Distribution Concepts

How is the tree built?– On demand, in response to data arrival

» Dense-mode protocols (PIM-DM and DVMRP)» MOSPF

– Explicit control– Sparse-mode protocols (PIM-SM and CBT)

Data Distribution Concepts

Building distribution trees requires knowledge of where members are– flood data to find out where members are not (Dense-mode protocols)– flood group membership information (MOSPF), and build tree as data

arrives– send explicit joins and keep join state (Sparse-mode protocols)

Data Distribution Concepts

Construction of source trees requires knowledge of source locations

–In dense-mode protocols you learn them when data arrives (at each depth of the tree)–Same with MOSPF–In sparse-mode protocols you learn them when data arrives on the shared tree (in leaf routers only)

»Ignore since routing based on direction from RP»Pay attention if moving to source tree

Data Distribution Concepts

To build a shared tree you need to know where the core (RP) is– Can be learned dynamically in the routing protocol (Auto-RP,

PIMv2)– Can be configured in the routers

Data Distribution Concepts

Shared trees make sense for– Many low-rate sources– Applications that don’t require low delay– Consistent policy and access control across most participants in a group– When most of the source trees overlap topologically with the shared tree

Multicast Routing Protocols—Characteristics

Types of multicast protocols– Dense-mode

» Flood and prune behavior– Sparse-mode

» Explicit join behavior

Multicast Routing Protocols—Characteristics

Dense-mode protocols–Assumes dense group membership

»Branches that are pruned don’t get data»Pruned branches can later be grafted to reduce join latency

–DVMRP—Distance Vector Multicast Routing Protocol–Dense-mode PIM—Protocol Independent Multicast

Multicast Routing Protocols—Characteristics

Sparse-mode protocols»Assumes group membership is sparsely populated across a large region »Uses either source or shared distribution trees»Explicit join behavior—assumes no one wants the packet unless asked »Joins propagate from receiver to source or Rendezvous Point (Sparse mode PIM) or Core (Core Based Tree)

Intra-Domain Multicast Routing Protocols

Similar to unicast routing protocols - such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) protocol -, there should be multicast routing protocols such that multicast routers can determine where to forward multicast messages

Existing multicast protocols:– Distance Vector Multicast Routing Protocol (DVMRP) based on

the RIP unicast routing protocol– Multicast Extensions to OSPF (MOSPF) protocol based on the

OSPF unicast routing protcol– Protocol Independent Multicast Sparse Mode (PIM-SM)

protocol:» performs better when group members are sparsely distributed

Protocol Independent Multicast (PIM) The major proposed (and used) multicast protocols perform well if

group members are densely packed and bandwidth is not a problem However, the fact that DVMRP periodically floods the network and

the fact that MOSPF sends group membership information over the links, make these protocols not efficient in cases where group members are sparsely distributed among regions and the bandwidth is not plentiful

To address these issues, PIM contains two protocols: PIM-DM and PIM-SM

Although these two algorithms belong to PIM and they share similar control messages, they are essentially two different protocols

PIM-Sparse Mode (PIM-SM)

PIM-SM has a key difference with existing dense-mode protocols (DVMRP, MOSPF)

In PIM-SM protocol routers need to explicitly announce their will for receiving multicast messages of multicast groups, while dense-mode protocols assumes that all routers need to receive multicast messages unless they explicitly send a prune message

Sparse Mode Protocol Independent Multicast (PIM-SM) I. Phase

Sender

Receiver

Legend

router

IP connection

group member host

non member host

rendezvous point (RP)

data flow

Sparse Mode Protocol Independent Multicast (PIM-SM) II. Phase

Sender

Receiver

Legend

router

IP connection

SPT branch

group member

non member

rendezvous point (RP)

data flow

Explicit join model– Receivers join to the Rendezvous Point (RP)– Senders register with the RP– Data flows down the shared tree and goes only

to places that need the data from the sources– Last hop routers can join source tree if the data rate warrants by sending

joins to the source RPF check for the shared tree uses the RP RPF check for the source tree

uses the source

Sparse Mode PIM

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) Draft: draft-ietf-idmr-pim-sm-specv2-00.txt Draft: draft-ietf-idmr-pim-arch-04.txt

Sparse Mode PIM

Sparse Mode PIM Example

Receiver 1

B

E

A D

Source

C

Receiver 2

RP

Link

Data

Control

Sparse Mode PIM Example

Receiver 1

B

E

A D

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

C

Receiver 2

RP

Join

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source RP Creates (*, G) State

C

Receiver 2

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source Source Sends DataA Sends Registers to the RP

C

Receiver 2

Register

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source RP de-encapsulates RegistersForwards Data Down the Shared TreeSends (S,G) Join Towards the Source

C

Receiver 2

Join Join

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source RP Sends Register-Stop OnceData Arrives Natively

C

Receiver 2

Register-Stop

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source C Sends (S, G) Joins to Join theShortest Path (SPT) Tree

C

Receiver 2

(S, G) Join

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source When C Receives Data Natively,It Sends Prunes Up the RP tree forthe Source. RP Deletes (S, G) OIF andSends Prune Towards the Source

C

Receiver 2

(S, G) RP Bit Prune

(S, G) Prune

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source New Receiver 2 JoinsE Creates State and Sends (*, G) Join

C

Receiver 2

(*, G) PIM Join

(*, G) IGMP Join

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

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

C

Receiver 2

Sparse Mode PIM Example

Receiver 1

B

E

A RP D

Source

New Source Starts SendingD Sends Registers, RP Sends JoinsRP Forwards Data to Receiversthrough Shared Tree

C

Receiver 2

Source 2(*, G) PIM Register

Multicast Routing Protocols Comparison

Multicast Routing Protocol Unicast Protocol Dependence

DVMRP RIP

MOSPF OSPF

PIM-SM -

Source Specific Protocol Independent Multicast (PIM-SS)

Only one S source can send data to an (S,G) channel, where G is a multicast address

In such a way the problem of global assignment of the multicast address is eliminated, since the used addresses are local considering to the actual sender

Each hosts are responsible to use different multicast addresses The distribution tree according to an (S,G) SSM channel is

always rooted in the S source, in such a way RP-based shared trees are not necessary

ASM and SSM routing

Broadcast MembershipMOSPF

Problem of learning group membership

Flood and PruneDVMRP

Rendezvous MechanismPIM-SM

Intra-domain Multicast

MSDP Peering

Inter-domain Multicast

BBC, 2005

Multicast, state-of-the-art