1 IP Multicast – Single Source & Multiple Source Brian J.S. Chee Associate Director: Advanced Network Computing Laboratory University of Hawaii Karl Auerbach Advanced Internet Architectures, Office of the CSO Cisco Systems The iLabs Multicast Team: Jim Martin, Nortel Networks Helen Gary Brian Chee, Univ. of Hawaii ICS Dept. Karl Auerbach, Cisco Systems
2 Multicast-Overview What is Multicast anyway? What are its two main flavors: Single Source Multicast (SSM) Any Source Multicast (ASM) Why the difference? What are the ramifications? Multicast Routing Protocols Intra-Domain Inter-Domain Conclusions
3 What is IP Multicast? IP Multicast exists at Layer 3 Don’t confuse it with Layer 2 multicast One IP packet, many receivers The set of receivers is expressed as an IP address 224/8 (I.e. 224.x.x.x through ) There addresses are very different from normal IP addresses. –These addresses represent a dynamic “group” of receivers –Receivers can come and go from the group as they please.
4 SSM and ASM (Classic IP Multicast) Both send to a group SSM has a single sender One to many. Uses addresses 232/8 – … ASM (Classic IP Multicast) allows anyone and everyone to be a sender Many to many Uses addresses 224/8 through 239/8 (with a hole for SSM at 232/8) – … – …
5 Many Receivers? How Many? The number of receivers can range from zero to infinity The number of receivers can change as receivers join and leave the group at any time. The sender is not aware of the number of-, or identity of-, the receivers. Packets from the source(s) are delivered to all destinations that have expressed an interest. IGMP is used to express that interest. In ASM, a receiver needs to merely indicate the group address In SSM a receiver needs to indicate both the source and the group address.
6 What Kind of Data Delivery Service? IP Multicast is a datagram service. One can layer on streaming services. Today most IP Multicast applications use UDP encapsulation UDP provides data checksums –IP itself checks only the header, not the data UDP provides further demultiplexing via “ports”.
7 IP Multicast and Reliability IP Multicast is an “unreliable” datagram service Don’t read the word “unreliable” too strongly. –It merely means that there are no guarantees made IP multicast carries datagrams –That means that it doesn’t have the notion of a connection. There are several protocols that build reliable data distribution services on top of IP multicast.
8 Why SSM and ASM? Any Source Multicast (ASM) is a well established technology Standard IP multicast is a many-to-many medium It’s been running for more than a decade However it often requires babysitting. Single Source Multicast (SSM) is a new approach SSM is a one-to-many medium. It may prove to require much less supporting mechanism than many-to-many multicast. Both forms can coexist Indeed SSM uses many of the infrastructure elements of standard IP multicast.
9 Multicast Basics R RR R* source r e c e i v e r R receiver Multicast Tree links receiver Data flow is controlled by routers Data only flows to those that request the data through IGMP “Joins” (ASM) or “Subscribes” (SSM) Data is addressed to a Class “D” IP addresses
10 Internet Group Management Protocol (IGMP) Not a Routing Protocol Common to ALL IP multicast systems Receivers join a multicast group by sending a IGMP REPORT message. Routers send IGMP QUERY messages to establish continued receiver interest. One receiver responds with an IGMP REPORT for each group in use. (added to V2) Receivers send IGMP LEAVE messages when they are no longer interested in a group. (added to V3) Receiver specifies source(s) of interest.
11 IGMP (continued) Version History Version 1 · Basic REPORT and QUERY mechanism Version 2 · Adds LEAVE messages and variable response timers Version 3 · Adds ability to do source specific joins and leaves (This is NOT widely available yet, new spec)
12 Multicast routing issues - DVMRP Distance Vector Multicast Routing Protocol Uses “flood & prune” to control who receives the stream –Floods data from new sources across the entire network. –Routers without receivers then prune back any sources that are not of interest, upstream routers do the same, until only links that have downstream users have the data –Periodically, prune state is removed and the process begins again. Takes time to for receiver joins/leaves to propagate. Can result in traffic floods when things go wrong.
13 Flood and Prune… receiver R2 G 1 Multicast data flow R1 R3 Sender, S 1 Data Control Prune S 1,G 1
14 PIM:Protocol Independent Multicast PIM-SM (sparse mode) & PIM-DM (dense mode) are VERY different protocols….!!! Dense Mode is more like DVMRP –it uses flood and prune Sparse Mode uses Rendezvous Points to control flows –Qualified routers advertise willingness to be an RP, and the actual RP is elected from those advertising –Senders send traffic to the RP for distribution –If warranted, a sender also distributes the multicast traffic directly. –Rendezvous Point’s are configured as part of PIM-Sparse mode
15 PIM-Sparse Mode How PIM-SM works Advertises RP-to-multicast-group mapping If a host joins a group, the serving router joins the shared tree rooted at the Rendezvous Point (RP) Sender’s router forwards group data to the RP RP forwards data on shared tree Once data is received, an endpoint router can switch to an efficient Shortest Path Tree (SPT) –Router sends join towards source Shared tree must be used to support Shortest Path Tree (SPT)
16 PIM-Sparse Mode (cont.) The shared tree gives a common place to setup the flow of traffic from sender to receivers The Rendezvous Point provides a common control point to switch over from a less efficient “shared tree” to a more efficient “shortest path tree”. Alternate Rendezvous Points provide for less chance of a single point of failure. Transitions from RP to source base tree (and vice-versa) can be an operational nuisance.
17 receiver RP G 1 Multicast data flow R R sender Join: G 1 Shared tree Data Control Join Multicast Group G 1 Shared Tree to Shortest Path Tree (SPT)
18 receiver RP Multicast data flow R R sender Join: SPT Data Control Shared Tree to Shortest Path Tree (SPT)
19 receiver RP Multicast data flow R R sender Prune Shared Tree Data Control Shared Tree to Shortest Path Tree (SPT)
20 receiver RP Multicast data flow R R sender Data Control Shared Tree to Shortest Path Tree (SPT)
21 Single Source Multicast (SSM) Needs IGMP v3 that has ability to include sender information for the “subscribe”s and “unsubscribe”s No longer needs rendezvous points Everything is now shortest path trees since you already know who the sender is Allows reuse of multicast address space Removes the need for VERY complex router code
22 Multicast Basics - Source Specific Multicast R RR R* source r e c e i v e r R receiver Multicast Tree links receiver Subscribe channel “n” at IP Addr “x”
23 References - ASM Deploying Ip Multicast in the Enterprise by Thomas A. Maufer Deering, S., "Host Extensions for IP Multicasting," RFC 1112, August Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, November 1997.
24 References – ASM (continued) Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, November Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 Dense Mode Specification," Work in Progress. Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, June Waitzman, D., Partridge, C., and S. Deering., "Distance Vector Multicast Routing Protocol," RFC 1075, Nov Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July, 1998.
25 References - SSM 00.txt arch-00.txt igmpv3-ssm-00.txt
26 The players…. Jim Martin - Nortel Innovations Lab (Lead) Helen Garey - Independent Consultant Brian Chee - University of Hawaii ICS Dept. Karl Auerbach - Cisco Systems Jeff Danley - Berkeley Daniel Bui - Ixia Angus Robertson - Adtech The I-labs is designed to highlight emerging technologies…not everything is fully baked yet...