mutlicast protocols in computer networks
- 1. 15-441 Computer Networking Lecture 11 – Multicast
- 2. Lecture 11: 10-3-2006 2 Multicast Routing • Unicast: one source to one destination • Multicast: one source to many destinations • Main goal: efficient data distribution
- 3. Lecture 11: 10-3-2006 3 Overview • IP Multicast Service Basics • Host/Router Interaction • MOSPF/DVMRP • Overlay Multicast
- 4. Lecture 11: 10-3-2006 4 Multicast – Efficient Data Distribution Src Src
- 5. Lecture 11: 10-3-2006 5 Example Applications • Broadcast audio/video • Push-based systems • Software distribution • Web-cache updates • Teleconferencing (audio, video, shared whiteboard, text editor) • Multi-player games • Server/service location • Other distributed applications
- 6. Lecture 11: 10-3-2006 6 IP Multicast Architecture Hosts Routers Service model Host-to-router protocol (IGMP) Multicast routing protocols (various)
- 7. Lecture 11: 10-3-2006 7 Logical Naming • Single name/address maps to logically related set of destinations • Destination set = multicast group • Key challenge: scalability • Single name/address independent of group growth or changes
- 8. Lecture 11: 10-3-2006 8 Multicast Router Responsibilities • Learn of the existence of multicast groups (through advertisement) • Identify links with group members • Establish state to route packets • Replicate packets on appropriate interfaces • Routing entry: Src, incoming interface List of outgoing interfaces
- 9. Lecture 11: 10-3-2006 9 IP Multicast Service Model (rfc1112) • Each group identified by a single IP address • Groups may be of any size • Members of groups may be located anywhere in the Internet • Members of groups can join and leave at will • Senders need not be members • Group membership not known explicitly • Analogy: • Each multicast address is like a radio frequency, on which anyone can transmit, and to which anyone can tune-in.
- 10. Lecture 11: 10-3-2006 10 IP Multicast Addresses • Class D IP addresses • 224.0.0.0 – 239.255.255.255 • How to allocated these addresses? • Well-known multicast addresses, assigned by IANA • Transient multicast addresses, assigned and reclaimed dynamically, e.g., by “sdr” program 1 1 1 0 Group ID
- 11. Lecture 11: 10-3-2006 11 IP Multicast API • Sending – same as before • 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 IP-Receive operation • Implemented using socket options
- 12. Lecture 11: 10-3-2006 12 Multicast Scope Control – Small TTLs • TTL expanding-ring search to reach or find a nearby subset of a group s 1 2 3
- 13. Lecture 11: 10-3-2006 13 Multicast Scope Control – Large TTLs • Administrative TTL Boundaries to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons An administrative domain TTL threshold set on interfaces to these links, greater than the diameter of the admin. domain The rest of the Internet
- 14. Lecture 11: 10-3-2006 14 Overview • IP Multicast Service Basics • Host/Router Interaction • MOSPF/DVMRP • Overlay Multicast
- 15. Lecture 11: 10-3-2006 15 IP Multicast Architecture Hosts Routers Service model Host-to-router protocol (IGMP) Multicast routing protocols (various)
- 16. Lecture 11: 10-3-2006 16 Internet Group Management Protocol • End system to router protocol is IGMP • Each host keeps track of which mcast groups are subscribed to • Socket API informs IGMP process of all joins • Objective is to keep router up-to-date with group membership of entire LAN • Routers need not know who all the members are, only that members exist
- 17. Lecture 11: 10-3-2006 17 How IGMP Works • On each link, one router is elected the “querier” • Querier periodically sends a Membership Query message to the all-systems group (224.0.0.1), with TTL = 1 • On receipt, hosts start random timers (between 0 and 10 seconds) for each multicast group to which they belong Q Routers: Hosts:
- 18. Lecture 11: 10-3-2006 18 How IGMP Works (cont.) • 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 their timers • Routers hear all reports, and time out non-responding groups Q G G G G Routers: Hosts:
- 19. Lecture 11: 10-3-2006 19 How IGMP Works (cont.) • Note that, in normal case, only one report message per group present is sent in response to a query • Power of randomization + suppression • Query interval is typically 60-90 seconds • When a host first joins a group, it sends one or two immediate reports, instead of waiting for a query
- 20. Lecture 11: 10-3-2006 20 Overview • IP Multicast Service Basics • Host/Router Interaction • MOSPF/DVMRP • Overlay Multicast
- 21. Lecture 11: 10-3-2006 21 IP Multicast Architecture Hosts Routers Service model Host-to-router protocol (IGMP) Multicast routing protocols (various)
- 22. Lecture 11: 10-3-2006 22 Routing Techniques • Basic objective – build distribution tree for multicast packets • Flood and prune • Begin by flooding traffic to entire network • Prune branches with no receivers • Examples: DVMRP, PIM-DM • Unwanted state where there are no receivers • Link-state multicast protocols • Routers advertise groups for which they have receivers to entire network • Compute trees on demand • Example: MOSPF • Unwanted state where there are no senders
- 23. Lecture 11: 10-3-2006 23 Multicast OSPF (MOSPF) • Add-on to OSPF (Open Shortest-Path First, a link-state, intra-domain routing protocol) • Multicast-capable routers flag link state routing advertisements • Link-state packets include multicast group addresses to which local members have joined • Routing algorithm augmented to compute shortest-path distribution tree from a source to any set of destinations
- 24. Lecture 11: 10-3-2006 24 Example Source 1 Receiver 1 Receiver 2 Z W Q T
- 25. Lecture 11: 10-3-2006 25 Link Failure/Topology Change Source 1 Receiver 1 Receiver 2 Z W Q T
- 26. Lecture 11: 10-3-2006 26 Membership Change Source 1 Receiver 1 Receiver 2 Z W Q T Receiver 3
- 27. Lecture 11: 10-3-2006 27 Impact on Route Computation • Can’t pre-compute multicast trees for all possible sources • Compute on demand when first packet from a source S to a group G arrives • New link-state advertisement • May lead to addition or deletion of outgoing interfaces if it contains different group addresses • May lead to re-computation of entire tree if links are changed
- 28. Lecture 11: 10-3-2006 28 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 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
- 29. Lecture 11: 10-3-2006 29 Example Topology G G S G
- 30. Lecture 11: 10-3-2006 30 Broadcast with Truncation G G S G
- 31. Lecture 11: 10-3-2006 31 Prune G G S Prune (s,g) Prune (s,g) G
- 32. Lecture 11: 10-3-2006 32 Graft (s,g) Graft (s,g) Graft G G S G G Report (g)
- 33. Lecture 11: 10-3-2006 33 Steady State G G S G G
- 34. Lecture 11: 10-3-2006 34 Overview • IP Multicast Service Basics • Host/Router Interaction • MOSPF/DVMRP • Overlay Multicast
- 35. Lecture 11: 10-3-2006 35 Failure of IP Multicast • Not widely deployed even after 15 years! • Use carefully – e.g., on LAN or campus, rarely over WAN • Various failings • Scalability of routing protocols • Hard to manage • Hard to implement TCP equivalent • Hard to get applications to use IP Multicast without existing wide deployment • Hard to get router vendors to support functionality and hard to get ISPs to configure routers to enable
- 36. Lecture 11: 10-3-2006 36 Supporting Multicast on the Internet IP Application Internet architecture Network ? ? At which layer should multicast be implemented?
- 37. Lecture 11: 10-3-2006 37 IP Multicast CMU Berkeley MIT UCSD routers end systems multicast flow • Highly efficient • Good delay
- 38. Lecture 11: 10-3-2006 38 End System Multicast MIT1 MIT2 CMU1 CMU2 UCSD MIT1 MIT2 CMU2 Overlay Tree Berkeley CMU1 CMU Berkeley MIT UCSD
- 39. Lecture 11: 10-3-2006 39 • Quick deployment • All multicast state in end systems • Computation at forwarding points simplifies support for higher level functionality Potential Benefits Over IP Multicast MIT1 MIT2 CMU1 CMU2 CMU Berkeley MIT UCSD
- 40. Lecture 11: 10-3-2006 40 Concerns with End System Multicast • Self-organize recipients into multicast delivery overlay tree • Must be closely matched to real network topology to be efficient • Performance concerns compared to IP Multicast • Increase in delay • Bandwidth waste (packet duplication) • Penalty can be kept small in practice MIT2 Berkeley MIT1 UCSD CMU2 CMU1 IP Multicast MIT2 Berkeley MIT1 CMU1 CMU2 UCSD End System Multicast
- 41. Lecture 11: 10-3-2006 41 Important Concepts • Multicast provides support for efficient data delivery to multiple recipients • Requirements for IP Multicast routing • Keeping track of interested parties • Building distribution tree • Broadcast/suppression technique • Difficult to deploy new IP-layer functionality • End system-based techniques can provide similar efficiency • Easier to deploy
- 42. Lecture 11: 10-3-2006 42 Next Lecture: Wide Area Routing • How to make routing scale to the size of the Internet • How to accommodate business relationships in routing
Editor's Notes
- #36: In the hourglass Internet architecture, IP is the compatibility layer in the Internet architecture. All hosts must implement IP Two choices multicast at IP or application: only a subset, customizability One important architecture question is, at which layer should multicast be implemented. The convention wisdom has been to support multicast in the IP layer for efficiency and performance reasons. However, more than 10 years since this is proposed, it still has not been widely deployed. This paper revisits this question with emphasis on Internet evaluation. In particular, we show that multicast at the application layer can be efficient compared to IP Multicast.
- #37: In the IP Multicast architecture, - routers replicate multicast pkts inside the network to all receivers - motivation: highly efficiency - highly efficient: single pkt that traverse each physical link - delay is good from source to all receivers
- #38: Recently, we and others have advocated for an alternative architecture, where all multicast functionality, including pkt replication and group management are pushed to end systems. - We call this architecture End System Multicast - In this architecture, end system organize themselves into an overlay tree root at the source - data is sent along the overlay tree. - It is an overlay in the sense that each link in the overlay tree corresponds to a physical path in the underlying network
- #39: In ESM, there is no additional support from the routers except unicast, so the deployment can be immediate. In IP Multicast, routers need to maintain per-group state. - This causes concerns regards to scalability to number of groups. - In ESM, all multicast state is pushed to end systems. Finally, computation at end systems can potentially simplify support for higher-layer functionality, - such as congestion control and reliability, - as well as application-specific customization, such as XXX. These high-layer functionality is harder to achieve in IP Multicast because - the data splitting points are at the routers and they are constraint in computation.
- #40: However, there are several concerns with ESM. - In the absence of support from the routers, there is a challenge to coordinate among end systems to construct efficient overlay tree. Even with an efficient overlay tree, … - there can be an increase in delay because data can travel through multiple overlay hops, as shown for MIT2. In IP Multicast, data is sent directly along the forwarding path. - moreover, there can be waste in bandwidth because duplicated pkts can traverse the same physical links, as shown in links near UCSD. In IP Multicast, a single pkt traverse each physical link at most once.