Internet and Intranet Protocols and Applications IP Multicast

Internet and Intranet Protocols and Applications IP Multicast March, 2004 Prof. Arthur Goldberg Computer Science Department New York University Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron

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

P 2 P file sharing r Example r Alice runs P 2 P 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! Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 3

P 2 P: centralized directory Bob 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 1 peers 1 3 1 2 1 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron Alice 4

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

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

More about decentralized directory r overlay network r peers are nodes r edges between peers r r and their group leaders edges between some pairs of group leaders virtual neighbors bootstrap node 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 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 7

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

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

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

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 routers forward unicast datagrams multicast receiver (red) not a multicast receiver (red) Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 11

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

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

Internet Multicast Service Model 128. 59. 16. 12 128. 119. 40. 186 multicast group 226. 17. 30. 197 128. 34. 108. 63 128. 34. 108. 60 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 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 14

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

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

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

*cast Definitions • Unicast - send to one destination • General Broadcast - send to EVERY local node (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 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 18

Multicast addresses • Class D addresses: 224. 0. 0. 0 - 239. 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 are reserved for private network (or intranet) use Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 19

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

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

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 builds “filter” to match MAC addresses Latch on to: • Own address, MAC broadcast, or “Group” address Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 22

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

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

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

IP Multicast in Java • Java has a Multicast Socket Class • Use it to “join” a multicast group. Multicast. Socket s; Inet. Address group; try { group = Inet. Address. get. By. Name(“ 227. 1. 2. 3”); s = new Multicast. Socket(5555); s. join. Group(group); } catch (Unknown. Host. Exception e) { } catch (IOException e) { } Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 26

IP Multicast in Java • Receive Datagram. Packets on a Multicast. Socket Datagram. Packet recv = new Datagram. Packet(buf, buf. length); try { s. receive(recv); } catch (IOException e) { System. out. println("mcast. Receive: " + e. to. String()); return; } // get message String msg = new String(recv. get. Data(), recv. get. Offset(), recv. get. Length()); Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 27

IP Multicast in Java • To send, just send a Datagram. Packet to the multicast address, port (no need to use a Multicast. Socket, although you could) group = Inet. Address. get. By. Name(“ 227. 1. 2. 3”); s = new Datagram. Socket(); Datagram. Packet snd = new Datagram. Packet(buf, buf. length, group, 5555); try { s. send(snd); } catch (IOException e) { System. out. println("mcast. Send: " + e. to. String()); return; } Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 28

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 <= TTLthreshold – Useful at edges of a large intranet as a blanket parameter Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 29

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

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

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

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 v 2: 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 v 3: under development as Internet draft Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 33

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

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 Source-based trees Shared tree Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 35

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

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

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

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

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

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

Reverse Path Forwarding q rely on router’s knowledge of unicast shortest path from it to sender q each router has simple forwarding behavior: if (mcast datagram received on incoming link on shortest path back to sender) then flood datagram onto all outgoing links else ignore datagram Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 42

Reverse Path Forwarding: example S: source LEGEND R 1 R 4 router with attached group member R 2 R 5 R 3 R 6 R 7 router with no attached group member datagram will be forwarded datagram will not be forwarded • result is a source-specific reverse SPT • Problems – A bad choice with asymmetric links – Substantial extra traffic Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 43

Reverse Path Forwarding: pruning • forwarding tree contains subtrees with no mcast group members – “prune” msgs sent upstream by router with no downstream group members LEGEND S: source R 1 router with attached group member R 4 R 2 P R 5 R 3 R 6 P R 7 P router with no attached group member prune message links with multicast forwarding Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 44

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

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

Center-based trees: an example Suppose R 6 chosen as center: LEGEND R 1 3 R 2 router with attached group member R 4 2 R 5 R 3 1 R 6 1 router with no attached group member path order in which join messages generated R 7 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 47

Internet Multicasting Routing: DVMRP • DVMRP: distance vector multicast routing protocol, RFC 1075 • flood and prune: reverse path forwarding, sourcebased 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 Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 48

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

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

PIM: Protocol Independent Multicast • not dependent on any specific underlying unicast routing algorithm (works with all) • two different multicast distribution scenarios : Dense: Sparse: q group members q # networks with group densely packed, in “close” proximity. q bandwidth more plentiful members small wrt # interconnected networks q group members “widely dispersed” q bandwidth not plentiful Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron 51

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

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

PIM - Sparse Mode • center-based approach • router sends join msg to rendezvous point (RP) R 1 R 2 – intermediate routers update state and forward join • after joining via RP, router can switch to sourcespecific tree – increased performance: less concentration, shorter paths R 4 join R 3 join R 5 join R 6 all data multicast from rendezvous point Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron R 7 rendezvous point 54

PIM - Sparse Mode sender(s): • unicast data to RP, which distributes down RProoted tree • RP can extend mcast tree upstream to source • RP can send stop msg if no attached receivers – “no one is listening!” R 1 R 4 join R 2 R 3 join R 5 join R 6 all data multicast from rendezvous point Some slides Copyright 1996 -2002, Kurose and Ross, others Joe Conron R 7 rendezvous point 55

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

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

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

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