1 IP Multicasting

2 IP Multicasting: Motivation Problem: Want to deliver a packet from a source to multiple receivers Applications: –Streaming of Continuous Media: Video/audio broadcasting, Live Lectures over the Internet –Teleconferencing: Live audio/video exchange between multiple users in a conference –Distributed Interactive Gaming: Quake… –All require the sending of a packet from one sender to multiple receivers within a single “send” operation

3 Multicast via Unicast Waste of Resources –Same packet crosses the same link multiple times Receiver Maintenance –How do you keep track of all receivers? multicast receiver (red) not a multicast receiver routers forward unicast datagrams Source (sender) keeps track of all receivers And sends N unicast datagrams, one addressed to each of N receivers

4 Multicast as a network layer service Multicast routers (red) duplicate and forward multicast datagrams Routers actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers r Exactly one data copy is transmitted on each network link. r Routers must be aware of every multicast group r Most efficient use of network resources, but requires router support!

5 Internet Multicast Service Model Issue: How does a sender identify all receivers? Solution: Address indirection: A single IP address identifies all receivers in a multicast group –Sender addresses IP datagram to multicast group –routers forward multicast datagrams to hosts that have “joined” that multicast group multicast group

6 Multicast groups class D Internet addresses reserved for multicast: Open group semantics: oanyone can “join” (receive) multicast group oOnly receivers join a group! oanyone can send to multicast group even non- members needed: infrastructure to deliver mcast-addressed datagrams to all hosts that have joined that multicast group – multicast routing protocols

7 Mapping Multicast Addresses to Ethernet MAC addresses

8 Joining a mcast group: two-step process local: host informs local mcast router of desire to join group: IGMP (Internet Group Management Protocol) wide area: local router interacts with other routers to receive mcast datagram flow –many protocols (e.g., DVMRP, MOSPF, PIM) IGMP wide-area multicast routing

9 IGMP: Internet Group Management Protocol host: sends IGMP report when application joins mcast group –host need not explicitly “unjoin” group when leaving router: sends IGMP query at regular intervals –host belonging to a mcast group must reply to query query report

Multicast Routing: Problem Statement Goal: find a tree (or trees) connecting routers having local mcast group members –tree: not all paths between routers used –2 aproaches shared-tree: same tree used by all group members source-based: different tree from each sender to receivers Shared tree Source-based trees

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

Shared-Tree: Steiner Tree problem is NP-complete –Very hard to solve! excellent heuristics exists not used in practice: –computational complexity –information about entire network needed –monolithic: rerun whenever a router needs to join/leave

13 Steiner vs. Minimum Spanning Tree Minimum Spanning Tree (MST) is a minimum cost tree that connects all nodes in the graph –Polynomial time algorithms exist Steiner tree is a minimum cost tree that connects a subset of nodes in the graph (may involve nodes not in the subset) –NP-Complete

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

Center-based trees: an example Suppose R6 chosen as center: R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member path order in which join messages generated LEGEND

Source Based Approaches: Reverse Path Forwarding if (mcast datagram received on incoming link on shortest path back to sender) 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:

Source Based Approaches: Reverse Path Forwarding: example result is a source-specific reverse SPT R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member datagram will be forwarded LEGEND S: source datagram will not be forwarded

Source Based Approaches: 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 attached group member router with no attached group member prune message LEGEND S: source links with multicast forwarding P P P

Internet Multicasting Routing: DVMRP DVMRP: distance vector multicast routing protocol, RFC1075 flood and prune: reverse path forwarding, source-based tree –RPF tree based on DVMRP’s own routing tables constructed by communicating DVMRP routers –no assumptions about underlying unicast –initial datagram to mcast group flooded everywhere via RPF –routers not wanting group: send upstream prune msgs

PIM: Protocol Independent Multicast not dependent on any specific underlying unicast routing algorithm (works with all) two different multicast distribution scenarios : Dense:  group members densely packed, in “close” proximity.  bandwidth more plentiful  Uses RPF Sparse:  # networks with group members small wrt # interconnected networks  group members “widely dispersed”  bandwidth not plentiful  Uses CBT