1. IP Multicasting By Behzad Akbari Fall 2008
These slides are based on the slides of J. Kurose (UMASS) and Shivkumar (RPI)

2. creation/transmission
Broadcast Routing
deliver packets from source to all other nodes
source duplication is inefficient: R1 R2 R3 R4
source duplication
in-network
duplication
duplicate
creation/transmission
source duplication: how does source determine recipient addresses?

3. In-network duplication
flooding: when node receives brdcst pckt, sends copy to all neighbors
Problems: cycles & broadcast storm
controlled flooding: node only brdcsts pkt if it hasn’t brdcst same packet before
Node keeps track of pckt ids already brdcsted
Or reverse path forwarding (RPF): only forward pckt if it arrived on shortest path between node and source
spanning tree
No redundant packets received by any node

4. Spanning Tree First construct a spanning tree
Nodes forward copies only along spanning tree A B G D E c F
(a) Broadcast initiated at A
(b) Broadcast initiated at D

5. 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 A A 3 B B c c 4 2 D D F E F E 1 5 G G
Stepwise construction of spanning tree
(b) Constructed 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
Source-based trees
Notes:
3.3 Network Layer: Multicast Routing Algorithms
Shared tree

7. Approaches for building mcast trees
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
Notes:
3.3 Network Layer: Multicast Routing Algorithms

8. Shortest Path Tree
mcast forwarding tree: tree of shortest path routes from source to all receivers
Dijkstra’s algorithm
S: source
LEGEND R1 2 R4
router with attached
group member 1 R2 5
router with no attached
group member 3 4 R5
Notes:
3.3 Network Layer: Multicast Routing Algorithms 6
link used for forwarding,
i indicates order link
added by algorithm R3 i R6 R7

9. Reverse Path Forwarding
rely on router’s knowledge of unicast shortest path from it to sender
each router has simple forwarding behavior:
if (mcast datagram received on incoming link on shortest path back to center)
then flood datagram onto all outgoing links
else ignore datagram
Notes:
3.3 Network Layer: Multicast Routing Algorithms

10. Reverse Path Forwarding: example
S: source
LEGEND R1 R4
router with attached
group member R2
router with no attached
group member R5 R3
datagram will be forwarded R6 R7
datagram will not be
forwarded
result is a source-specific reverse SPT
may be a bad choice with asymmetric links
Notes:
3.3 Network Layer: Multicast Routing Algorithms

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
LEGEND
S: source R1
router with attached
group member R4
router with no attached
group member R2 P P
Notes:
3.3 Network Layer: Multicast Routing Algorithms R5
prune message P
links with multicast
forwarding R3 R6 R7

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
Notes:
1. See L. Wei and D. Estrin, “A Comparison of multicast trees and algorithms,” TR USC-CD , Dept. Computer Science, University of California, Sept 1993 for a comparison of heuristic approaches.
3.3 Network Layer: Multicast Routing Algorithms

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
Notes:
1. It’s always nice to see a PhD dissertation with impact. The earliest discussion of center-based trees for multicast appears to be D. Wall, “Mechanisms for Broadcast and Selective Broadcast,” PhD dissertation, Stanford U., June 1980.
3.3 Network Layer: Multicast Routing Algorithms

14. Center-based trees: an example
Suppose R6 chosen as center:
LEGEND R1
router with attached
group member R4 3
router with no attached
group member R2 2 1 R5
path order in which join messages generated R3 1
Notes:
3.3 Network Layer: Multicast Routing Algorithms R6 R7

15. IP Multicast Architecture
Service model
Hosts
Host-to-router protocol (IGMP)
Routers
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”
Routers: Q
Hosts:
On each link, one router is elected the “querier”
Querier periodically sends a Membership Query message to the all-systems group ( ), with TTL = 1
On receipt, hosts start random timers (between 0 and 10 seconds) for each multicast group to which they belong

18. How IGMP Works (cont.)
Routers: Q
Hosts: G G G G
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

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 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” ( ) address
Querier responds with a Group-specific Query message: see if any group members are present
Lower leave latency

20. IP Multicast Architecture
Service model
Hosts
Host-to-router protocol (IGMP)
Routers
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 Link-state multicast protocols
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
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 S
Source R
Receiver R R R S S R

27. A Shared Tree
Router S
Source R
Receiver R R RP R S S R

28. Shared vs. 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 Topology G G S G

31. Flood with Truncated BroadcastG G S G

32. Prune G G
Prune (s,g)
Prune (s,g) S G

33. Graft G G G
Report (g)
Graft (s,g) S
Graft (s,g) G

34. Steady State G G G S 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 R R R H R
Host/router R H R
MBone router H
Physical link
Tunnel
Part of MBone

37. Transport header and data…
MBone Tunnels
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
IP header,
dest = unicast
IP header,
dest = multicast
Transport header and 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
Routers with local members Join toward Rendezvous Point (RP) to join shared tree
Routers with local sources encapsulate data in Register messages to RP
Routers with local members may initiate data-driven switch to source-specific shortest path trees
PIM v.2 Specification (RFC2362)

40. PIM Example: Build Shared Tree
Shared tree after
R1,R2 join
Source 1
Join message toward RP
(*,G)
(*,G) RP
(*,G)
(*,G)
(*,G)
(*,G)
Receiver 1
Receiver 2
Receiver 3

41. Data Encapsulated in Register
Unicast encapsulated data packet to RP in Register
Source 1
(*,G)
(*,G) RP
(*,G)
(*,G)
(*,G)
(*,G)
Receiver 1
Receiver 2
Receiver 3
RP de-capsulates, forwards down shared tree

42. RP Send Join to High Rate Source
Shared tree
Source 1
Join message toward S1
(S1,G) RP
Receiver 1
Receiver 2
Receiver 3

43. Build Source-Specific Distribution Tree
Shared Tree
Source 1
Join messages
(S1, G)
(S1,G),(*,G)
(S1,G),(*,G) RP
(S1,G),(*,G)
Receiver 1
Receiver 2
Receiver 3
Build source-specific tree for high data rate source

44. Forward On “Longest-match” Entry
Shared Tree
Source 1
Source 1 Distribution Tree
(S1, G)
(*, G)
(S1,G),(*,G)
(S1,G),(*,G) RP
(S1,G),(*,G)
Receiver 1
Receiver 2
Receiver 3
Source-specific entry is “longer match” for source S1 than is Shared tree entry that can be used by any source

45. Prune S1 off Shared Tree Source 1 Receiver 1 Receiver 2 Receiver 3
Source 1 Distribution Tree
Source 1
Prune S1 RP
Receiver 1
Receiver 2
Receiver 3
Prune S1 off shared tree where if S1 and RP entries differ

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 (see next slide) important