Spring 2007CSci5221: IP Multicast1 Internet Design Case Study: IP Multicast What is multicast? Why multicast? Understand the “spirit”, not necessarily the detail Some design/implementation principles we’ll use: –indirection –soft state –randomization –… Evolution of IP Multicast and Lessons learned

Spring 2007CSci5221: IP Multicast2 Motivation Often want to send data to many machines at once –Video distribution (TV broadcast) –Teleconferences, etc. –News updates Using unicast to reach each individual is hard and wasteful –Sender state: ~O(n) and highly dynamic –Total load: ~O(nd) where d is net diameter –Hotspot load: load ~O(n) on host and first link Multicast: –Sender state: O(1), total load O(d log n), hotspot load O(1)

Spring 2007CSci5221: IP Multicast3 Multicast: one sender to many receivers Multicast: act of sending datagram to multiple receivers with single “transmit” operation Question: how to achieve multicast Network multicast router actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers Multicast routers (red) duplicate and forward multicast datagrams

Spring 2007CSci5221: IP Multicast4 Indirection Indirection: rather than reference an entity directly, reference it (“indirectly) via another entity, which in turn can or will access the original entity " Every problem in computer science can be solved by adding another level of indirection" -- Butler Lampson A B x

Spring 2007CSci5221: IP Multicast5 Multicast via Indirection multicast group concept: represented by a “logical” (multicast) address -- use of indirection –sender sends IP datagrams to the “logical” multicast address –routers forward multicast datagrams to hosts that have “joined” that multicast group multicast group

Spring 2007CSci5221: IP Multicast6 Issues and Challenges How does a host (user) join in a multicast group? What to do to leave the group? Who manages group membership dynamics? –Membership is dynamic, but should it be open, i.e., anyone can join a multicast group? Who can send to the multicast group? What state does a router need to maintain? –When a router receives an IP datagram destined to a multicast group, where should it forward to? Scalability: –With number of members in a group; also with number of groups Other issues: –address allocation, mapping applications to multicast groups

Spring 2007CSci5221: IP Multicast7 Design Alternatives Telephone/ATM Model: –source/root-based: “one-to-many” multicast mcast group associated and controlled by source/root –receiver joins a group by sending request to source/root –routing state installed during the “signaling” process –routing entry: [mcast address, {interface1,…, interfacek}] IP Multicast Model –“many-to-many” multicast –open membership: anyone can join and leave at will –also anyone (not necessarily part of mcast) can send! –best-effort delivery

Spring 2007CSci5221: IP Multicast8 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.

Spring 2007CSci5221: IP Multicast9 IP Multicast Addresses Class D IP addresses – – How to allocated these addresses? –Well-known multicast addresses, assigned by IANA –Transient multicast addresses, assigned and reclaimed dynamically, e.g., by “sdr” program 1110Group ID

Spring 2007CSci5221: IP Multicast10 IP Multicast Service Model (cont’d) Division of Responsibilities: Host’s responsibility to register interest with networks –IGMP (Internet Group Management Protocol) Network’s responsibility to deliver packets to host –Multicast Routing Protocols Left unspecified: –Address assignment (random, MASC, etc.) –Application-to-group mapping (session directory, etc.) Performance Goal: roughly equivalent to unicast best-effort service in terms of drops/delays –efficient tree –no complicated forwarding machinery, etc. low join/leave latency

Spring 2007CSci5221: IP Multicast11 IP Multicast Architecture Hosts Routers Service model Host-to-router protocol (IGMP) Multicast routing protocols (various)

Spring 2007CSci5221: IP Multicast12 IP Multicast API and Multicast Routers 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 Multicast Routers: –Learn of existence of multicast groups (through advertisement) –Identify links with group members –Establish state to route packets replicate packets on appropriate interfaces routing entry: mcast address src, incoming interface List of outgoing interfaces

Spring 2007CSci5221: IP Multicast13 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

Spring 2007CSci5221: IP Multicast14 How IGMP Works On each link, one router is elected the “querier” Querier periodically sends a Membership Query message to the all-systems group ( ), with TTL = 1 On receipt, hosts start random timers (between 0 and 10 seconds) for each multicast group to which they belong QRouters: Hosts:

Spring 2007CSci5221: IP Multicast15 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 GGGG Routers: Hosts:

Spring 2007CSci5221: IP Multicast16 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 seconds When a host first joins a group, it sends one or two immediate reports, instead of waiting for a query

Spring 2007CSci5221: IP Multicast17 Multicast Scope Control – Small TTLs TTL expanding-ring search to reach or find a nearby subset of a group s 1 2 3

Spring 2007CSci5221: IP Multicast18 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

Spring 2007CSci5221: IP Multicast19 Routing Techniques Basic objective – build distribution tree for multicast packets Three Basic Techniques Source-based trees: flood and prune –Separate shortest path tree for each sender –Begin by flooding traffic to entire network –Prune branches with no receivers –Examples: DVMRP, PIM-DM –Unwanted state where there are no receivers

Spring 2007CSci5221: IP Multicast20 Routing Techniques (cont’d) Core or share-tree based protocols –Specify “meeting place” aka core –Sources send initial packets to core –Receivers join group at core –Requires mapping between multicast group address and “meeting place” –Examples: CBT, PIM-SM 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

Spring 2007CSci5221: IP Multicast21 Source-based Trees Router Source Receiver S R R R R R S S

Spring 2007CSci5221: IP Multicast22 Shared Tree RP Router Source Receiver S S S R R R R R

Spring 2007CSci5221: IP Multicast23 Shared vs. Source-Based Trees Source-based trees –Shortest path trees – low delay, better load distribution –More state at routers (per-source state) –Efficient for in dense-area multicast Shared trees –Higher delay (bounded by factor of 2), traffic concentration –Choice of core affects efficiency –Per-group state at routers –Efficient for sparse-area multicast Which is better?

Spring 2007CSci5221: IP Multicast24 Distance-Vector Multicast Routing: Basics 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

Spring 2007CSci5221: IP Multicast25 DVMRP (cont’d) Developed as a sequence of protocols: –Reverse Path Flooding (RPF) –Reverse Path Broadcast (RPB) –Truncated Reverse Path Broadcasting (TRPB) –Reverse Path Multicast (RPM) General Philosophy: multicast = pruned broadcast –Don’t construct new tree, merely prune old one Observation: –Unicast routing state tells router shortest path to S –Reversing direction sends packets from S without forming loops

Spring 2007CSci5221: IP Multicast26 Basic Forwarding Rule Routing state: –To reach S, send along link L Flooding Rule: –If a packet from S is received along link L, forward on all other links (reverse path forwarding check) This works fine for symmetric links –Ignore asymmetry today This works fine for point-to-point links –Can result in multiple packets sent on LANs

Spring 2007CSci5221: IP Multicast27 Example Flooding can cause a given packet to be sent multiple times over the same link x x y y z z S S a b duplicate packet

Spring 2007CSci5221: IP Multicast28 Broadcasting Extension For each link, and each source S, define parent and child –Parent: shortest path to S (ties broken arbitrarily) –All other routers on link are children Broadcasting rule: only parent forwards packet to L Problem fixed But this is still broadcast, not multicast!

Spring 2007CSci5221: IP Multicast29 Multicast = Pruned Broadcast Start with full broadcast (RPB) If leaf has no members, prune state –Send non-membership report (NMR) If all children of a router R prune, then router R sends NMR to parent New joins send graft to undo pruning

Spring 2007CSci5221: IP Multicast30 Example Topology GG S G

Spring 2007CSci5221: IP Multicast31 Broadcast with Truncation GG S G

Spring 2007CSci5221: IP Multicast32 Prune GG S Prune (s,g) G

Spring 2007CSci5221: IP Multicast33 Graft (s,g) Graft GG S G G Report (g)

Spring 2007CSci5221: IP Multicast34 Steady State GG S G G

Spring 2007CSci5221: IP Multicast35 Problems with Approach Starting with broadcast means that all first packets go everywhere If group has members on most networks, this is ok But if group is sparse, this is lots of wasted traffic What about a different approach: –Source-specific tree vs shared tree –Pruned broadcast vs explicitly constructed tree

Spring 2007CSci5221: IP Multicast36 Core Based Trees (CBT) Ballardie, Francis, and Crowcroft, –“Core Based Trees (CBT): An Architecture for Scalable Inter-Domain Multicast Routing”, SIGCOMM 93 Similar to Deering’s Single-Spanning Tree Unicast packet to core, but forwarded to multicast group Tree construction by receiver-based “grafts” –One tree per group, only nodes on tree involved Reduce routing table state from O(S x G) to O(G)

Spring 2007CSci5221: IP Multicast37 Example Group members: M1, M2, M3 M1 sends data root M1 M2 M3 control (join) messages data

Spring 2007CSci5221: IP Multicast38 Disadvantages Sub-optimal delay Small, local groups with non-local core –Need good core selection –Optimal choice (computing topological center) is NP complete

Spring 2007CSci5221: IP Multicast39 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

Spring 2007CSci5221: IP Multicast40 Example Source 1 Receiver 1 Receiver 2 Z W Q T

Spring 2007CSci5221: IP Multicast41 Link Failure/Topology Change Source 1 Receiver 1 Receiver 2 Z W Q T

Spring 2007CSci5221: IP Multicast42 Membership Change Source 1 Receiver 1 Receiver 2 Z W Q T Receiver 3

Spring 2007CSci5221: IP Multicast43 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

Spring 2007CSci5221: IP Multicast44 Discussion IP anycast service works fine within a network What about global anycast service (across domains) –Available in special cases: Anycast address for DNS servers AS 112 project: –In general, not scalable at a global scale –Some recently proposed solutions: GIA, PIAS Impact on UDP/TCP and Applications: anycast addr appear same as unicast to senders! –UDP stateless! Okay if applications do not maintain state over multiple datagrams; Example: DNS problematic otherwise: e.g., multimedia applications over UDP –TCP stateful: how to establish a connection with anycast address? routers may deliver datagrams destined to an anycast address to any one of the group work around: only first packet (SYN) uses anycast address as dest. addr; subsequent packets use unicast address of the server

Spring 2007CSci5221: IP Multicast45 Why Isn’t Multicast Pervasive? (Reasonably) Sound technology –But fairly complex, with several versions of protocols Implemented in most routers Used by some enterprises But not deployed/used on public Internet

Spring 2007CSci5221: IP Multicast46 Possible Explanations Lack of demand (up until now?) Lack of membership/sender control –Many services need it: who can join, who cannot –Also needed for billing, etc. –Hard to implement sender control: Can be subject to (and used to amplify) DoS attack Multicast address scarcity –global allocation required Inter-domain issues: –Violates current ISP settlement model –No incentive for ISPs to enable multicast ….

Spring 2007CSci5221: IP Multicast47 Design Alternative: Single-Source Multicast Multicast Channel Concept: –Each multicast group associated with a source –Defined by [source, multicast address] Implications: –Each group has only one source, address allocation non-issue! each source can allocate 16 millions “channels” Sender control easy! –Forwarding using source and dest. (multicast) IP addresses Use Reverse Path Multicast algorithm Add a counting mechanism for estimating group size –Use a recursive CountQuery message Use app-level relays to for multiple sources

Spring 2007CSci5221: IP Multicast48 Other Issues w/ Multicast FEC can help, but isn’t perfect Must have retransmissions But sender can’t keep state about each receiver –Has to be told when someone needs a packet For example: How to make multicast reliable? (a la TCP to IP unicast)

Spring 2007CSci5221: IP Multicast49 SRM Design Approach Let receivers detect lost packets –By holes in sequence numbers They send NACK when loss is detected Any node can respond to NACK NACK/Response implosion averted through suppression –Send NACKs at random times –If hear NACK for same data, reset NACK timer –If node has data, it resends it, using similar randomized algorithm

Spring 2007CSci5221: IP Multicast50 Chosen from the uniform distribution on –A : node that lost the packet –S : source –C 1,C 2 : algorithm parameters –d S,A : latency between S and A –i : iteration of repair request tries seen Algorithm –Detect loss  set timer –Receive request for same data  cancel timer, set new timer –Timer expires  send repair request Repair Request Timer Randomization

Spring 2007CSci5221: IP Multicast51 Adaptive Timers C and D parameters depends on topology and congestion  choose adaptively After sending a request: –Decrease start of request timer interval Before each new request timer is set: –If requests sent in previous rounds, and any dup requests were from further away: Decrease request timer interval –Else if average dup requests high: Increase request timer interval –Else if average dup requests low and average request delay too high: Decrease request timer interval

Spring 2007CSci5221: IP Multicast52 Local Recovery Some groups are very large with low loss correlation between nodes –Multicasting requests and repairs to entire group wastes bandwidth Separate recovery multicast groups –e.g. hash sequence number to multicast group address –only nodes experiencing loss join group –recovery delay sensitive to join latency TTL-based scoping –send request/repair with a limited TTL –how to set TTL to get to a host that can retransmit –how to make sure retransmission reaches every host that heard request

Spring 2007CSci5221: IP Multicast53 Discussion Does multicast belong in the network layer? –Why not implemented by end hosts? How important is economic analysis in protocol design? –Should the design drive economics, or the other way around? Multicast addresses are “flat” –Doesn’t that make it hard for routers to scale? –Address allocation and aggregation? Should everything be multicast? What other delivery models are needed?

Spring 2007CSci5221: IP Multicast54 IP Anycast Anycast: any member of a group IP anycast service model –Best effort, stateless –data sent to an anycast group is delivered any member (preferably only one) of the group IP anycast address: represent a virtual host –use unicast IP addresses: assigned to multiple hosts advertise as host-specific route with a network –e.g., /32 can be aggregated outside a network: /16 what about “global” anycast addresses, e.g., well-known anycast address for autoconfiguration of DNS servers? hosts can’t distinguish unicast and anycast addresses! –reserve special IP address allocation for anycast either within a network address prefix –but won’t work for global IP anycast or a global IP address space –not aggregatable, scalability concerns

Spring 2007CSci5221: IP Multicast55 IP Anycast within a Network Hosts that are members of an anycast group –advertise membership to routers (e.g., via IGMP) –anycast address to MAC address translation: one option: map anycast IP address to unicast MAC address using ARP –disadvantage? another option: use link-level (e.g., Ethernet) multicast MAC address, and map anycast IP address to it –hosts of anycast group on LAN configured as members of link- level multicast group Sending hosts: anycast IP addr same as unicast addr Role of routers –listen to membership advertisement and keep track of anycast groups on subnets –advertise anycast groups as host-specific routes using unicast routing protocols (e.g., RIP or OSPF) need some special care –Forwarding: decide what next-hop to forward anycast datagram may need to map link- level multicast MAC address