Multicast

1. Multicast Henning Schulzrinne Dept. of Computer Science Columbia University Fall 2003

2. Overview • IP multicast service models • any source, source-specific multicast, … • Multicast protocol components • address assignment • local group management • intra- and inter-domain routing • Programming IP multicast applications

3. Multicast service models • Basic idea: same data needs to reach multiple receivers  avoid transmitting it once for each receiver • particularly useful if access link has bandwidth limitations • can be implemented at link, network and application layer • e.g., mailing list as example • Variations: reach unknown destination by membership (“foo server”) rather than address  also anycast

4. *Cast • Broadcast = all nodes on (small, local) network • Directed broadcast = copies to all hosts on remote network • DDOS  not supported any more (RFC 2644) • Multicast = copies to >= 1 hosts (group) • Anycast = packet to 1 of N hosts

5. Diversion: Anycast • RFC 1546 (“Host Anycasting Service”) • RFC 2373 (“IP Version 6 Addressing Architecture”) • “locate a host which supports a particular service but, if several servers support the service, does not particularly care which server is used.” • Example uses: • DNS root servers (F.root-servers.net = 192.5.5.241 ); see http://www.isc.org • root servers are hard-configured in DNS resolvers • 272 million queries a day • all access routers providing Internet service • Anycast  deliver to single host • special form of unicast routing • deliver to nearest host (by routing metric) • Multicast  deliver to >= 1 host (and maybe get answers from > 1 host)

6. Anycast routing • Assign same address within subnet • supernet is advertised either globally (“global nodes”) or locally (“local nodes”) • advertise whole prefix, not just single address  avoid route filtering • BGP automatically ensures routing to closest local or global node • Distributes (or localizes) denial-of-service traffic • Does not scale well due to address usage (unless all services within the same subnet)

7. Multicast applications • audio-video distribution (1-to-many) • audio-video conferences (all-to-all) • distributed simulation (war gaming, multi-player Doom, …) • resource discovery (where’s the next time server?) • instances of resource identified by multicast address • file distribution (stock market quotes, new software releases, OS patches, …) • network news (Usenet)

8. Multicast trees • spanning tree ≡ tree that connects all vertices • vertices = hosts and routers • shared tree = single tree for all sources S • minimum cost spanning tree (MST) • minimum-weight tree in a weighted graph which contains all of the graph's vertices • cost = hops, delay, transmission cost ($), … • does not minimize length of S to individual destination • all traffic concentrated on tree  reservation failure • per-source tree • build independently for each source

9. Multicast trees – Steiner trees • “given a weighted graph in which a subset of vertices are identified as terminals, find a minimum-weight connected subgraph that includes all the terminals” • Differs from MST in that Steiner vertices must be identified • NP-complete problem (see traveling salesman) • unstable: small additions to graph  large changes in traffic flows

10. Finding MST via Prim’s algorithm • centralized, finds MST for G = (V,E) • U: set of vertices connected, start with one • add lowest-cost edge (u,v) with u U and v in V – U • tree T  T  (u,v) • U  U  v

11. Connection-oriented multicast • enumerate sources explicitly  source-based tree • examples: • ATM: explicitly add each end point to tree • ST-II (IPv5): enumerate end points in setup message • End nodes can also attach themselves to tree • only connection-oriented  enumeration only in setup message • source needs to know destinations • resource discovery not possible • dynamic groups difficult • but: natural transition from 2-party to N-party • same routing algorithm

12. Host group model • Multicast service model • S. Deering, 1991 (RFC 1112) • senders need not be members • groups may have any number of members • there are no topological restrictions on group membership • membership is dynamic and autonomous • host groups may be dynamic or permanent •  receiver-driven model • “subscriptions”

13. Local multicast • Some local networks are by (original) nature multicast or broadcast: • Ethernet: original coax contention (CDMA), 802.11 wireless • need to emulate in Ethernet switches • token ring • FDDI • wireless links (BlueTooth, cellular), powerline networks • Ethernet, token ring: • broadcast: all-1 address • multicast: 01.xx.xx.xx.xx.xx • adapter hardware can filter dynamic list of addresses • ATM: point-to-point links  ATM multicast server or replication in switches

14. IP multicast: model & addresses • host-group model • network level: data packets remain same, only address changes • need help from routers to replicate and route • special IP addresses (class D): 224.0.0.0 through 239.255.255.255 (224/4) • 28 bits  268 million groups • in addition, scoping • 224.0.0.x: local network only • 224.0.0.1: all hosts • 224.0.0.2: all routers • 224.0.1.x: internetwork control block • 224.0.2.0-224.0.255.0: ad-hoc • 224.2.0.0-224.2.255.255: SDP/SAP block • some pre-assigned by IANA • map into Ethernet: 01.00.5E.00.00.00 + lower 23 bits

15. IP multicast scope • Avoid accidental distribution to whole Internet • IP TTL value: 0 = host, 1 = network • Others to reach larger groups • but “split horizon problem” (RFC 2907) • pruning (see later) may fail: larger TTL later • Administrative scoping (RFC 2365) • 239.0.0.0 to 239.255.255.255 • RFC 1884 for IPv6 (16 scopes) • link-local scope • IPv4 local scope • organization local scope • global scope • relative addresses (from top) for common applications within scope

16. IP multicast protocols • tree construction protocol  PIM-SM, PIM-DM • advertise reverse paths towards sources  Multiprotocol Border Gateway Protocol (MBGP) • disseminate information about sources  Multicast Source Discovery Protocol (MSDP) • hosts dynamically join and leave multicast groups  Internet Group Management Protocol (IGMP) • IGMPv2: specify host group

17. Multicast model problems • Host group model now known as Any Source Multicast (ASM) • variant: source-filtered multicast (SFM) • hosts can request data for group G only for specific set of sources • or exclude list of sources •  IGMPv3 for IPv4 and MLD (listener discovery) for IPv6 • host of problems have prevented large-scale deployment: • attacks against multicast groups by unauthorized transmitters • deployment complexity • problems of allocating scarce global class-D IP addresses • lack of inter-domain scalability • single point-of-failure problems K. Almeroth, S. Bhattacharyya, C. Diot, “Challenges of Integrating ASM and SSM IP Multicast Protocol Architectures”

18. Source-Specific Multicast (SSM) • receiving host explicitly specifies the address of the source it wants to receive from • in addition to multicast group • support one-to-many multicast • address range 232/8, ff2x:: and ff3x:: • IGMPv3: allow source specification • remove complexity from network layer  application layer (where needed)

19. SSM, cont’d. • distribution tree for channel (S,G) rooted at S • no shared tree infrastructure • no need for MSDP • only a single source can transmit • avoid access control problem • avoid forwarding unwanted data (cf. SFM) • addresses local to each source  no global address allocation needed • for large groups, often single source • or dominated by single source

20. Xcast • “providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model” (IAB workshop report) • Large number of small groups: • three-party calls • small interactive conferences • networked games •  explicitly enumerate addresses in IP header • each router looks up all addresses • group by interface • remote addresses that don’t apply (why?)

21. Xcast • Thus, sender-driven model • Advantages: • no session setup needed • no address allocation • known set of destinations: simplifies accounting, access control

22. RPF – Reverse path forwarding • Normal (unicast) routing: look up destination address in routing table • forward to listed outgoing interface • RPF: look up source address in IP routing table • only forward if packet arrived on that interface • strictly correct only for symmetric routes Cisco IP multicast technology overview

23. PIM-DM • Uses unicast routing protocols (unlike DVMRP) • push model  send traffic everywhere • non-receivers prune • time out after 3 minutes • only source trees • good for networks where most subnets want traffic

24. PIM-SM • pull model • join only (G,*) • initially, shared tree = rendezvous point (RP) • router closest to receiver registers with RP • sources register with RP and then initially send data via the shared tree • edge routers can force a source tree by sending (S,G) messages towards the source if distance to source is smaller than distance to RP • see draft-ietf-pim-v2-dm Cisco IP multicast technology overview

25. Link Data Control A B G C D F H E I Dense Mode PIM Example Source Receiver 1 Receiver 2 following slides by Salmani

26. A B G C D F H E I Dense Mode PIM Example Source Initial Flood of Dataand Creation of State Receiver 1 Receiver 2

27. A B G C D F H E I Dense Mode PIM Example Source Prune to Non-RPF Neighbor Prune Receiver 1 Receiver 2

28. A B G C D F H E I Dense Mode PIM Example Source C and D Assert to DetermineForwarder for the LAN, C Wins Asserts Receiver 1 Receiver 2

29. A B G C D F H E I Dense Mode PIM Example Source I Gets Pruned E’s Prune is Ignored G’s Prune is Overridden Prune Join Override Prune Receiver 1 Receiver 2

30. A B G C D F H E I Dense Mode PIM Example Source New Receiver, I Sends Graft Graft Receiver 1 Receiver 2 Receiver 3

31. A B G C D F H E I Dense Mode PIM Example Source Receiver 1 Receiver 2 Receiver 3

32. Link Data Control Sparse Mode PIM Example Source A B D RP C E Receiver 1 Receiver 2

33. Sparse Mode PIM Example Receiver 1 Joins Group GC Creates (*, G) State, Sends(*, G) Join to the RP Source A B D RP Join C E Receiver 1 Receiver 2

34. Sparse Mode PIM Example RP Creates (*, G) State Source A B D RP C E Receiver 1 Receiver 2

35. Sparse Mode PIM Example Source Sends DataA Sender Registers to the RP Source Register A B D RP C E Receiver 1 Receiver 2

36. Sparse Mode PIM Example RP de-encapsulates RegistersForwards Data Down the Shared TreeSends Joins Towards the Source Source Join Join A B D RP C E Receiver 1 Receiver 2

37. Sparse Mode PIM Example RP Sends Register-Stop OnceData Arrives Natively Source Register-Stop A B D RP C E Receiver 1 Receiver 2

38. Sparse Mode PIM Example C Sends (S, G) Joins to Join theShortest Path (SPT) Tree Source A B D RP (S, G) Join C E Receiver 1 Receiver 2

39. Sparse Mode PIM Example When C Receives Data Natively,It Sends Prunes Up the RP tree forthe Source. RP Deletes (S, G) OIF andSends Prune Towards the Source Source (S, G) Prune A B D RP (S, G) RP Bit Prune C E Receiver 1 Receiver 2

40. Sparse Mode PIM Example New Receiver 2 JoinsE Creates State and Sends (*, G) Join Source A B D RP (*, G) Join C E Receiver 1 Receiver 2

41. Sparse Mode PIM Example C Adds Link Towards E to the OIFList of Both (*, G) and (S, G)Data from Source Arrives at E Source A B D RP C E Receiver 1 Receiver 2

42. Sparse Mode PIM Example New Source Starts SendingD Sends Registers, RP Sends JoinsRP Forwards Data to Receiversthrough Shared Tree Source Register Source 2 A B D RP C E Receiver 1 Receiver 2

43. MBGP (Multiprotocol BGP) • RFC 2283 (Multiprotocol Extensions for BGP-4) • RPF check for AS • path attributes MP_REACH_NLRI and MP_UNREACH_NLRI  two sets of routing information  non-congruent unicast and multicast topologies

44. MSDP (Multicast source discovery protocol) • Scaling  different RPs for each AS  several PIM-SM domains • each RP only knows local sources and receivers • RPs share source information via MSDP • TCP session mesh • first message from new source sent to other RPs via Source Active (SA) MSDP message

45. MSDP, cont’d. • If receiving router has (*,G) state, it joins other RP and creates (S,G) state • Encapsulated data sent down “remote” RP shared tree • Last-hop router may join shortest path to source directly • MSDP is complex and effectively broadcasts to every RP in the Internet • DOS attack by sending out flood of source announcements • Doesn’t scale for large number of sources  SA flood topology & carry data

46. Multicast address allocation • two different sessions may pick same class-D address and interfere with each other • solutions: • dynamic allocation  SAP (later), but doesn’t fit all applications, scaling problems • explicit request  MALLOC • static delegation  GLOP • interim solution: GLOP (RFC 2770) divides IPv4 multicast address space by AS 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 233 | 16 bits AS | local bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

47. IPv6 multicast address allocation • RFC 3306 (“Unicast-Prefix-based IPv6 Multicast Addresses”) • Like GLOP, unicast prefix based | 8 | 4 | 4 | 112 | +--------+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|0011|scop|reserved| plen | network prefix | group ID | +--------+----+----+--------+--------+----------------+----------+ see RFC 3307: permanent: e.g., 0x40404040 for NTP length of network prefix

48. Multicast address allocation • RFC 2908 (“Internet Multicast Address Allocation Architecture”) • Instance of global identifier allocation problem: • hierarchical blocks (IEEE EUI, DNS, IP addresses, phone numbers, SSN, …) • local mechanism left unspecified • on-demand • centralized server (e.g., DHCP within domain) • distributed pools • usually, combination of both • Two qualifiers: • scope (possibly global) • lifetime (possibly indefinite)

49. Multicast address allocation • core requirements: • robustness: work even if remote parts of the networks don’t • timeliness: seconds • low probability of clashes • avoid fragmentation overhead • unfortunately, can’t have all of them • e.g., reliability  fragmentation to “warehouse” addresses or collisions

50. Multicast address allocation MASC prefix coordinator prefix coordinator Layer 3 or GLOP prefix coordinator MAAS MAAS Layer 2 intra-domain coordination Layer 1 MADCAP HTTP domain (AS)