1

IP Multicasting

By

Behzad Akbari

These slides are based on the slides of J. Kurose (UMASS) and Shivkumar (RPI)

2

R1

R2

R3 R4

sourceduplication

R1

R2

R3 R4

in-networkduplication

duplicatecreation/transmissionduplicate

duplicate

Broadcast Routing deliver packets from source to all other nodes source duplication is inefficient:

source duplication: how does source determine recipient addresses?

3

In-network duplication

flooding: when node receives broadcast packet, sends copy to all neighbors Problems: cycles & broadcast storm

controlled flooding: node only broadcast packet if it hasn’t broadcast same packet before Node keeps track of packet ids already broadcasted Or reverse path forwarding (RPF): only forward packet if it

arrived on shortest path between node and source spanning tree

No redundant packets received by any node

4

A

B

G

DE

c

F

A

B

G

DE

c

F

(a) Broadcast initiated at A (b) Broadcast initiated at D

Spanning Tree

First construct a spanning tree Nodes forward copies only along spanning

tree

5

A

B

G

DE

c

F1

2

3

4

5

(a) Stepwise construction of spanning tree

A

B

G

DE

c

F

(b) Constructed spanning tree

Spanning Tree: Creation Center node Each node sends unicast join message to center

node Message forwarded until it arrives at a node already

belonging to spanning tree

6

Multicast Routing: Problem Statement Goal: find a tree (or trees) connecting routers

having local mcast group members tree: not all paths between routers used source-based: different tree from each sender to rcvrs shared-tree: same tree used by all group members

Shared tree Source-based trees

7

Approaches for building mcast trees

Approaches: source-based tree: one tree per source

shortest path trees reverse path forwarding

group-shared tree: group uses one tree minimal spanning (Steiner) center-based trees

…we first look at basic approaches, then specific protocols adopting these approaches

8

Shortest Path Tree

mcast forwarding tree: tree of shortest path routes from source to all receivers Dijkstra’s algorithm

R1

R2

R3

R4

R5

R6 R7

21

6

3 4

5

i

router with attachedgroup member

router with no attachedgroup member

link used for forwarding,i indicates order linkadded by algorithm

LEGENDS: source

9

Reverse Path Forwarding

if (mcast datagram received on incoming link on shortest path back to center)

then flood datagram onto all outgoing links

else ignore datagram

rely on router’s knowledge of unicast shortest path from it to sender

each router has simple forwarding behavior:

10

Reverse Path Forwarding: example

• result is a source-specific reverse SPT– may be a bad choice with asymmetric links

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

datagram will be forwarded

LEGENDS: source

datagram will not be forwarded

11

Reverse Path Forwarding: pruning forwarding tree contains subtrees with no mcast

group members no need to forward datagrams down subtree “prune” msgs sent upstream by router with no

downstream group members

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

prune message

LEGENDS: source

links with multicastforwarding

P

P

P

12

Shared-Tree: Steiner Tree

Steiner Tree: minimum cost tree connecting all routers with attached group members

problem is NP-complete excellent heuristics exists not used in practice:

computational complexity information about entire network needed monolithic: rerun whenever a router needs to

join/leave

13

Center-based trees

single delivery tree shared by all one router identified as “center” of tree to join:

edge router sends unicast join-msg addressed to center router

join-msg “processed” by intermediate routers and forwarded towards center

join-msg either hits existing tree branch for this center, or arrives at center

path taken by join-msg becomes new branch of tree for this router

14

Center-based trees: an example

Suppose R6 chosen as center:

R1

R2

R3

R4

R5

R6 R7

router with attachedgroup member

router with no attachedgroup member

path order in which join messages generated

LEGEND

21

3

1

15

IP Multicast Architecture

Hosts

Routers

Service model

Host-to-router protocolHost-to-router protocol(IGMP)(IGMP)

Multicast routing protocols(various)

16

Internet Group Management Protocol IGMP: “signaling” protocol to establish,

maintain, remove groups on a subnet. Objective: keep router up-to-date with group

membership of entire LAN Routers need not know who all the members are,

only that members exist Each host keeps track of which mcast groups

are subscribed to Socket API informs IGMP process of all joins

17

How IGMP Works

On each link, one router is elected the “querier” Querier periodically sends a Membership Query message

to the all-systems group (224.0.0.1), with TTL = 1 On receipt, hosts start random timers (between 0 and 10

seconds) for each multicast group to which they belong

QRouters:

Hosts:

18

How IGMP Works (cont.)

When a host’s timer for group G expires, it sends a Membership Report to group G, with TTL = 1

Other members of G hear the report and stop (suppress) their timers

Routers hear all reports, and time out non-responding groups

Q

G G G G

Routers:

Hosts:

19

How IGMP Works (cont.) Normal case: only one report message per group

present is sent in response to a query Query interval is typically 60-90 seconds

When a host first joins a group, it sends immediate reports, instead of waiting for a query

IGMPv2: Hosts may send a “Leave group” message to “all routers” (224.0.0.2) address

Querier responds with a Group-specific Query message: see if any group members are present Lower leave latency

20

IP Multicast Architecture

Hosts

Routers

Service model

Host-to-router protocol(IGMP)

Multicast routing protocols

21

Multicast Routing

Basic objective – build distribution tree for multicast packets The “leaves” of the distribution tree are the

subnets containing at least one group member (detected by IGMP)

Multicast service model makes it hard Anonymity Dynamic join/leave

22

Routing Techniques Flood and prune

Begin by flooding traffic to entire network Prune branches with no receivers Examples: DVMRP, PIM-DM

Link-state multicast protocols Routers advertise groups for which they have

receivers to entire network Compute trees on demand Example: MOSPF

23

Routing Techniques(…) Core-based protocols

Specify “meeting place” aka “core” or “rendezvous point (RP)”

Sources send initial packets to core Receivers join group at core Requires mapping between multicast group

address and “meeting place” Examples: CBT, PIM-SM

24

Routing Techniques (…) Tree building methods:

Data-driven: calculate the tree only when the first packet is seen. Eg: DVMRP, MOSPF

Control-driven: Build tree in background before any data is transmitted. Eg: CBT

Join-styles: Explicit-join: The leaves explicitly join the tree. Eg: CBT,

PIM-SM Implicit-join: All subnets are assumed to be receivers

unless they say otherwise (eg via tree pruning). Eg: DVMRP, MOSPF

25

Shared vs. Source-based Trees Source-based trees

Separate shortest path tree for each sender (S,G) state at intermediate routers Eg: DVMRP, MOSPF, PIM-DM, PIM-SM

Shared trees Single tree shared by all members Data flows on same tree regardless of sender (*,G) state at intermediate routers Eg: CBT, PIM-SM

26

Source-based Trees

Router

Source

Receiver

S

R

R

R

R

R

S

S

27

A Shared Tree

RPRP

Router

Source

Receiver

S

S

S

R

R

R

R

R

28

Shared vs. Source-Based Trees Source-based trees

Shortest path trees – low delay, better load distribution More state at routers (per-source state) Efficient in dense-area multicast

Shared trees Higher delay (bounded by factor of 2), traffic

concentration Choice of core affects efficiency Per-group state at routers Efficient for sparse-area multicast

29

Distance-Vector Multicast Routing DVMRP consists of two major components:

A conventional distance-vector routing protocol (like RIP)

A protocol for determining how to forward multicast packets, based on the unicast routing table

DVMRP router forwards a packet if The packet arrived from the link used to reach the

source of the packet Reverse path forwarding check – RPF

If downstream links have not pruned the tree

30

Example TopologyG G

S

G

31

Flood with Truncated Broadcast

G G

S

G

32

PruneG G

S

Prune (s,g)

Prune (s,g)

G

33

Graft (s,g)

Graft (s,g)

GraftG G

S

G

G

Report (g)

34

Steady StateG G

S

G

G

35

DVMRP limitations

Like distance-vector protocols, affected by count-to-infinity and transient looping

Shares the scaling limitations of RIP. New scaling limitations: (S,G) state in routers: even in pruned parts! Broadcast-and-prune has an initial broadcast.

No hierarchy: flat routing domain

36

Multicast Backbone (MBone) An overlay network of IP multicast-capable

routers using DVMRP Tools: sdr (session directory), vic, vat, wb

Host/router

MBone router

Physical linkTunnelPart of MBone

R R

R

H R

H

R

RH

37

A method for sending multicast packets through multicast-ignorant routers

IP multicast packet is encapsulated in a unicast IP packet (IP-in-IP) addressed to far end of tunnel:

Tunnel acts like a virtual point-to-point link Intermediate routers see only outer header Tunnel endpoint recognizes IP-in-IP (protocol type = 4)

and de-capsulates datagram for processing Each end of tunnel is manually configured with unicast address

of the other end

MBone Tunnels

IP header,dest = unicast

IP header,dest = multicast

Transport headerand data…

38

Protocol Independent Multicast (PIM) Support for both shared and per-source trees Dense mode (per-source tree)

Similar to DVMRP Sparse mode (shared tree)

Core = rendezvous point (RP) Independent of unicast routing protocol

Just uses unicast forwarding table

39

PIM Protocol Overview Basic protocol steps

in RegisterRouters with local members Join toward Rendezvous Point (RP) to join shared tree

Routers with local sources encapsulate data messages to RP

Routers with local members may initiate data-driven switch to source-specific shortest path trees

PIM v.2 Specification (RFC2362)

40

Source 1

Receiver 1

Receiver 2

PIM Example: Build Shared Tree

(*,G)

Receiver 3

(*,G)

(*,G)

(*,G)

(*,G)

(*,G)

Join messagetoward RP

Shared tree after R1,R2 join

RP

41

Source 1

Receiver 1

Receiver 2

Data Encapsulated in Register

(*,G)

Receiver 3

(*,G)

(*,G)

(*,G)

(*,G)

(*,G)

Unicast encapsulated data packet to RP in Register

RP

RP de-capsulates, forwards down shared tree

42

Source 1

Receiver 1

Receiver 2

RP Send Join to High Rate Source

Receiver 3

(S1,G)

RP

Join messagetoward S1

Shared tree

43

Source 1

Receiver 1

Receiver 2

Build Source-Specific Distribution Tree

Receiver 3

Join messages

Shared Tree

RP

Build source-specific tree for high data rate source

(S1,G),(*,G)

(S1, G)

(S1,G),(*,G)(S1,G),(*,G)

44

Source 1

Receiver 1

Receiver 2

Forward On “Longest-match” Entry

Receiver 3

Source 1 Distribution Tree

Shared Tree

RP

(S1,G),(*,G)

(S1, G)

(S1,G),(*,G)(S1,G),(*,G)

Source-specific entry is “longer match” for source S1 than is Shared tree entry that can be used by any source

(*, G)

45

Prune S1 off Shared Tree

Prune S1 off shared tree where if S1 and RP entries differ

Source 1

Receiver 1

Receiver 2 Receiver 3

Source 1 Distribution Tree

Shared Tree

RP

Prune S1

46

Reliable Multicast Transport Problems:

Retransmission can make reliable multicast as inefficient as replicated unicast

Ack-implosion if all destinations ack at once Source does not know # of destinations “Crying baby”: a bad link affects entire group Heterogeneity: receivers, links, group sizes Not all multicast applications need strong reliability

of the type provided by TCP. Some can tolerate reordering, delay, etc

47

Reliability Models

Reliability => requires redundancy to recover from uncertain loss or other failure modes.

Two types of redundancy: Spatial redundancy: independent backup copies

Forward error correction (FEC) codes Problem: requires huge overhead, since the FEC is also

part of the packet(s) it cannot recover from erasure of all packets

Temporal redundancy: retransmit if packets lost/error Lazy: trades off response time for reliability Design of status reports and retransmission optimization