1. Internet and Intranet Protocols and Applications IP Multicast March, 2004 Prof. Arthur Goldberg Computer Science Department New York University

2. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 2 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Reliable multicast

3. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 3 P2P file sharing r Example r Alice runs P2P client application on her notebook computer r Intermittently connects to Internet; gets new IP address for each connection r Asks for “Hey Jude” r Application displays other peers that have copy of Hey Jude. r Alice chooses one of the peers, Bob. r File is copied from Bob’s PC to Alice’s notebook: HTTP r While Alice downloads, other users uploading from Alice. r Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable!

4. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 4 P2P: centralized directory Original Napster design 1) when peer connects, it informs central server: –IP address –content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob centralized directory server peers Alice Bob 1 1 1 1 2 3

5. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 5 P2P: problems with centralized directory r Single point of failure r Performance bottleneck r Copyright infringement file transfer is decentralized, but locating content is highly centralized

6. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 6 P2P: decentralized directory r Each peer is either a group leader or assigned to a group leader. r Group leader tracks the content in all its children. r Peer queries group leader; group leader may query other group leaders.

7. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 7 More about decentralized directory r overlay network r peers are nodes r edges between peers and their group leaders r edges between some pairs of group leaders r virtual neighbors r bootstrap node r connecting peer is either assigned to a group leader or designated as leader r advantages of approach r no centralized directory server r location service distributed over peers r more difficult to shut down r disadvantages of approach r bootstrap node needed r group leaders can get overloaded

8. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 8 P2P: Query flooding r Gnutella r no hierarchy r use bootstrap node to learn about others r join message r Send query to neighbors r Neighbors forward query r If queried peer has object, it sends message back to querying peer join

9. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 9 P2P: more on query flooding Pros r peers have similar responsibilities: no group leaders r highly decentralized r no peer maintains directory info Cons r excessive query traffic r query radius: may not have content when present r bootstrap node r maintenance of overlay network

10. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 10 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Reliable multicast

11. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 11 Multicast: one sender to many receivers Multicast: act of sending datagram to multiple receivers with single “transmit” operation –analogy: one teacher to many students Question: how to achieve multicast Unicast implementation source sends N unicast datagrams, one addressed to each of N receivers multicast receiver (red) not a multicast receiver (red) routers forward unicast datagrams

12. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 12 Multicast: with network support Routers actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers Multicast routers (red) duplicate and forward multicast datagrams

13. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 13 Multicast: Application-layer end systems involved in multicast copy and forward unicast datagrams among themselves

14. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 14 Internet Multicast Service Model multicast group concept: use of indirection –hosts addresses IP datagram to multicast group –routers forward multicast datagrams to hosts that have “joined” that multicast group 128.119.40.186 128.59.16.12 128.34.108.63 128.34.108.60 multicast group 226.17.30.197

15. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 15 IP Multicast - Concepts Message sent to multicast “group” of receivers –Senders need not be group members –Each group has a “group address” –Groups can have any size –End-stations (receivers) can join/leave at will –Data Packets are UDP (uh oh!)

16. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 16 IP Multicast Benefits Distribution tree for delivery/distribution of packets (i.e., scope extends beyond LAN) –Tree is built by multicast routing protocols. Current multicast tree over the internet is called MBONE No more than one copy of packet appears on any sub- net. Packets delivered only to “interested” receivers => multicast delivery tree changes dynamically Non-member nodes even on a single sub-net do not receive packets (unlike sub-net-specific broadcast)

17. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 17 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Using and example Java program –Message distribution –Reliable multicast

18. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 18 *cast Definitions Unicast - send to one destination General Broadcast - send to EVERY local node (255.255.255.255) Directed Broadcast - send to subset of nodes on LAN (198.122.15.255) Multicast - send to every member of a Group of “interested” nodes (perhaps a Class D address). RFCs 1700, 1112

19. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 19 Multicast addresses Class D addresses: 224.0.0.0 - 239.255.255.255 Each multicast address represents a set of hosts group of arbitrary size, called a “host group” Addresses 224.0.0.x and 224.0.1.x are reserved. See assigned numbers RFC 1700 –Eg: 224.0.0.2 = all routers on this sub-net Addresses 239.0.0.0 thru 239.255.255.255 are reserved for private network (or intranet) use

20. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 20 Link-Layer Multicast Addresses Ethernet and other LANs using 802 addresses: LAN multicast address Lower 23 bits of Class D address are inserted into the lower 23 bits of MAC address (see RFC 1112) 0x01005e

21. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 21 Multicast groups class D Internet addresses reserved for multicast: host group semantics: oanyone can “join” (receive from) a multicast group oanyone can send to a multicast group ono network-layer identification to hosts of members needed: infrastructure to deliver multicast-addressed datagrams to all hosts that have joined that multicast group

22. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 22 NIC, IP Stack, and Apps Cooperate! Idea - NIC does not accept packets unless some app on this node wants it (avoid non-productive work). How does it know which packets to accept? –App “joins” group with Class D address –IP stack gives class D info to NIC –NIC builds “filter” to match MAC addresses –Latch on to: Own address, MAC broadcast, or “Group” address

23. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 23 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Using and example Java program –Group management –Message distribution –Reliable multicast

24. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 24 IP Multicast - Sending Use normal IP-Send operation, with multicast address specified as destination Must provide sending application a way to: –Specify outgoing network interface, if more than 1 is available –Specify IP time-to-live (TTL) on outgoing packet –Enable/disable loop-back if the sending host is/isn’t a member of the destination group on the outgoing interface

25. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 25 IP Multicast - Receiving Two new operations –Join-IP-Multicast-Group( group-address, interface ) –Leave-IP-Multicast-Group( group-address, interface ) Receive multicast packets for joined groups via normal Receive operation

26. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 26 IP Multicast in Java Java has a Multicast Socket Class Use it to “join” a multicast group. MulticastSocket s; InetAddress group; try { group = InetAddress.getByName(“227.1.2.3”); s = new MulticastSocket(5555); s.joinGroup(group); } catch (UnknownHostException e) { } catch (IOException e) { }

27. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 27 IP Multicast in Java Receive DatagramPackets on a MulticastSocket DatagramPacket recv = new DatagramPacket(buf, buf.length); try { s.receive(recv); } catch (IOException e) { System.out.println("mcastReceive: " + e.toString()); return; } // get message String msg = new String(recv.getData(), recv.getOffset(), recv.getLength());

28. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 28 IP Multicast in Java To send, just send a DatagramPacket to the multicast address, port (no need to use a MulticastSocket, although you could) group = InetAddress.getByName(“227.1.2.3”); s = new DatagramSocket(); DatagramPacket snd = new DatagramPacket(buf, buf.length, group, 5555); try { s.send(snd); } catch (IOException e) { System.out.println("mcastSend: " + e.toString()); return; }

29. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 29 Multicast Scope Scope: How far do transmissions propagate? Implicit scope: –Reserved Mcast addresses => don’t leave subnet. TTL-based scope: –Each multicast router has a configured TTL threshold –It does not forward multicast datagram if TTL <= TTL- threshold –Useful at edges of a large intranet as a blanket parameter

30. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 30 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Using and example Java program –Group management –Message distribution –Reliable multicast

31. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 31 Joining a multicast 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

32. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 32 IGMP: Internet Group Management Protocol host: sends IGMP report when application joins mcast group –IP_ADD_MEMBERSHIP socket option –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

33. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 33 IGMP IGMP version 1 router: Host Membership Query msg broadcast on LAN to all hosts host: Host Membership Report msg to indicate group membership –randomized delay before responding –implicit leave via no reply to Query RFC 1112 IGMP v2: additions include group-specific Query Leave Group msg –last host replying to Query can send explicit Leave Group msg –router performs group-specific query to see if any hosts left in group –RFC 2236 IGMP v3: under development as Internet draft

34. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 34 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Using and example Java program –Group management –Message distribution –Reliable multicast

35. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 35 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 receivers –shared-tree: same tree used by all group members Shared tree Source-based trees

36. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 36 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

37. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 37 Shortest Path Tree mcast forwarding tree: tree of shortest path routes from source to all receivers Can be computed with Dijkstra’s algorithm R1 R2 R3 R4 R5 R6 R7 2 1 6 3 4 5 i router with attached group member router with no attached group member link used for forwarding, i indicates order link added by algorithm LEGEND S: source

38. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 38 An Aside: A Link-State Routing Algorithm Dijkstra’s algorithm net topology, link costs known to all nodes –accomplished via “link state broadcast” –all nodes have same info computes least cost paths from one node (‘source”) to all other nodes –gives routing table for that node iterative: after k iterations, know least cost path to k dest.’s Notation: c(i,j): link cost from node i to j. cost infinite if not direct neighbors D(v): current value of cost of path from source to dest. V p(v): predecessor node along path from source to v, that is next v N: set of nodes whose least cost path definitively known

39. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 39 Dijsktra’s Algorithm 1 Initialization: 2 N = {A} 3 for all nodes v 4 if v adjacent to A 5 then D(v) = c(A,v) 6 else D(v) = infinity 7 8 Loop 9 find w not in N such that D(w) is a minimum 10 add w to N 11 update D(v) for all v adjacent to w and not in N: 12 D(v) = min( D(v), D(w) + c(w,v) ) 13 /* new cost to v is either old cost to v or known 14 shortest path cost to w plus cost from w to v */ 15 until all nodes in N

40. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 40 Dijkstra’s algorithm: example Step 0 1 2 3 4 5 start N A AD ADE ADEB ADEBC ADEBCF D(B),p(B) 2,A D(C),p(C) 5,A 4,D 3,E D(D),p(D) 1,A D(E),p(E) infinity 2,D D(F),p(F) infinity 4,E A E D CB F 2 2 1 3 1 1 2 5 3 5

41. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 41 Dijkstra’s algorithm, discussion— end aside Algorithm complexity: n nodes each iteration: need to check all nodes, w, not in N n*(n+1)/2 comparisons: O(n**2) more efficient implementations possible: O(nlogn)

42. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 42 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:

43. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 43 Reverse Path Forwarding: example result is a source-specific reverse SPT Problems –A bad choice with asymmetric links –Substantial extra traffic 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

44. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 44 Reverse Path Forwarding: pruning forwarding tree contains subtrees with no mcast group members –“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

45. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 45 Shared-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

46. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 46 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

47. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 47 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 2 1 3 1

48. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 48 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

49. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 49 DVMRP: continued… soft state: DVMRP router periodically (1 min.) “forgets” branches are pruned: –mcast data again flows down unpruned branch –downstream router: reprune or else continue to receive data routers can quickly regraft to tree –following IGMP join at leaf odds and ends –commonly implemented in commercial routers –Mbone routing done using DVMRP

50. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 50 Tunneling Q: How to connect “islands” of multicast routers in a “sea” of unicast routers?  mcast datagram encapsulated inside “normal” (non-multicast- addressed) datagram  normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router  receiving mcast router unencapsulates to get mcast datagram physical topology logical topology

51. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 51 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 Sparse:  # networks with group members small wrt # interconnected networks  group members “widely dispersed”  bandwidth not plentiful

52. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 52 Consequences of Sparse-Dense Dichotomy: Dense group membership by routers assumed until routers explicitly prune data-driven construction on mcast tree (e.g., RPF) bandwidth and non- group-router processing profligate Sparse : no membership until routers explicitly join receiver- driven construction of mcast tree (e.g., center-based) bandwidth and non- group-router processing conservative

53. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 53 PIM- Dense Mode flood-and-prune RPF, similar to DVMRP but  underlying unicast protocol provides RPF info for incoming datagram  less complicated (less efficient) downstream flood than DVMRP reduces reliance on underlying routing algorithm  has protocol mechanism for router to detect it is a leaf-node router

54. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 54 PIM - Sparse Mode center-based approach router sends join msg to rendezvous point (RP) –intermediate routers update state and forward join after joining via RP, router can switch to source- specific tree –increased performance: less concentration, shorter paths R1 R2 R3 R4 R5 R6 R7 join all data multicast from rendezvous point rendezvous point

55. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 55 PIM - Sparse Mode sender(s): unicast data to RP, which distributes down RP- rooted tree RP can extend mcast tree upstream to source RP can send stop msg if no attached receivers –“no one is listening!” R1 R2 R3 R4 R5 R6 R7 join all data multicast from rendezvous point rendezvous point

56. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 56 Multicast Peer to peer applications Multicast protocols –Types –Addressing –Using and example Java program –Group management –Message distribution –Reliable multicast

57. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 57 Reliable Multicast Remember: IP Multicast uses IP - it’s unreliable! We need a “reliable” multicast Let’s review what we mean by “reliable” –message gets to ALL receivers –sending order is preserved –no duplicates –no corruption

58. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 58 Reliable Multicast Problems: –Retransmission can make reliable multicast as inefficient as replicated unicast Ack-implosion if all destinations ack at once Nak-implosion if a all destinations ack at once –Source does not know # of destinations. Or even if all destinations are still “up” –one bad link affects entire group –Heterogeneity: receivers, links, group sizes

59. Some slides Copyright 1996-2002, Kurose and Ross, others Joe Conron 59 Reliable Multicast RM protocols have to deal with: –Scalability. –Heterogeneity. –Adaptive flow/congestion control. –Reliability. Not all multicast applications need reliability of the type provided by TCP. Some can tolerate reordering, delay, etc Let’s look at two very different approaches –PGM (Pragmatic General Multicast) –RMP (Reliable Multicast Protocol)