Multicast routing

1. Multicast routing Multicast Routing Prof. A. Sahoo KReSIT, IIT Bombay

2. Topics • Multicasting for group communication • Mechanisms • Wide area multicasting • Multicast IP address • Reverse path forwarding (RPF), multicast shortest path tree, joining, pruning, cost of joining and pruning, Integration with Unicast protocol • MOSPF ( Multicast extension of OSPF) • MDVRP ( Multicast extension of distance vector) • Core based tree (CBT) • Protocol Independent Multicast ( PIM) • Overlay Multicast network for Internet ( MBONE) • Multicasting in Local Area Network • Multicast address in 802 address space • Internet Group Management Protocol ( IGMP)

3. Multicasting ( Group Communication) • Multiparty application • Distance education • Video/voice conferencing • Resource discovery All of these application require source send data to multiple receiver or multicast capability of sender. • Different mode of packet communication in a network • Broadcast, • Unicast • Multicast • Anycast • Multicast group:

4. Multicast group • Associates a set of senders and receivers with each other • but they are independent of each other • group created either when a sender starts sending from a group • or a receiver expresses interest in receiving • even if no one else is there! • Sender does not need to know receivers’ identities • Multicast group address serves as a rendezvous point between potential senders and receiver of that group • Can view as receivers waiting at the rendezvous point for some sender to send them information , and the network takes care of distributing every packet that arrives at the rendezvous point to every registered receiver.

5. Addressing • Multicast group in the Internet has its own Class D address • looks like a host address, but isn’t • Class D address in IP address space are used as multicast destination address • 224.0.0.0 to 239.255.255.255, 28 bits can be used, over 250 million groups possible • Multicast address can appear only as destination address, never as source address • When send to a multicast address, the packet reaches to all host who are currently belonging to that group • Senders send to the address • Receivers anywhere in the world request packets from that address • “Magic” is in associating the two: dynamic directory service • Four problems: • which groups are currently active • how to express interest in joining a group • discovering the set of receivers in a group • delivering data to members of a group

6. Multicast flavors • Unicast: point to point • Multicast: • point to multipoint • multipoint to multipoint • Can simulate point to multipoint by a set of point to point unicasts • Can simulate multipoint to multipoint by a set of point to multipoint multicasts • The difference is efficiency • Ideally we need to send a packet only once over a link that is one the way of one or more receiver for a certain group

7. Example • Suppose A wants to talk to B, G, H, I, B to A, G, H, I • With unicast, 4 messages sent from each source • links AC, BC carry a packet in triplicate • With point to multipoint multicast, 1 message sent from each source • but requires establishment of two separate multicast groups • With multipoint to multipoint multicast, 1 message sent from each source, • single multicast group

8. Shortest path tree • Ideally, want to send exactly one multicast packet per link • forms a multicast tree rooted at sender • Optimal multicast tree provides shortest path from sender to every receiver • shortest-path tree rooted at sender

9. Issues in wide-area multicast • Difficult because • sources may join and leave dynamically • need to dynamically update shortest-path tree • leaves of tree are often members of broadcast LAN • would like to exploit LAN broadcast capability • would like a receiver to join or leave without explicitly notifying sender • otherwise it will not scale

10. Multicast in a broadcast LAN • After reaching edge router D ( refer last slide), how should the packet reach all multicast reveiver in the broadcast LAN? • Wide area multicast can exploit a LAN’s broadcast capability • E.g. Ethernet will multicast all packets with multicast bit set on destination address ( see next slide) • Two problems: • what multicast MAC address corresponds to a given Class D IP address? • does the LAN contain any members for a given group (why do we need to know this?) • How to inform the network that there are receiver for group x in this LAN

11. 23 Bits Multicast Bit Reserved 6 byte 802 address Multicasting in Ethernet LAN • Instead of sending multiple link layer packets to each host, or to avoid broadcasting, link/mac level multicast address should be used. • In Ethernet, a portion of 6 byte Ethernet address is used to identify multicast groups in local LAN • The lowest bit of most significant byte is set to 1 to designate multicast address at Ethernet MAC address space • 802 hosts can configure their host adaptor cards to listen to MAC layer multicast packets ( usually 16 or 32 in number)

12. Class D to MAC translation • Multiple Class D addresses map to the same MAC address • Well-known translation algorithm => no need for a translation table 23 bits copied from IP address 5E 01 00 IEEE 802 MAC Address Reserved bit Multicast bit Class D IP address ‘1110’ = Class D indication Ignored

13. Internet Group Management Protocol • Detects if a LAN has any members for a particular group • If no members, then we can prune (cut-off) the parent router from the shortest path tree for that group by updating upstream parent • Two type of IGMP message: • Router periodically broadcasts a query message • Hosts reply with the list of groups they are interested in • To suppress traffic • reply after random timeout • broadcast reply • if someone else has expressed interest in a group, drop out • To receive multicast packets: • translate from class D to MAC and configure adapter

14. Simplest solution • Flood packets from a source to entire network • If a router has not seen a packet before, forward it to all interfaces except the incoming one • Pros • simple • always works! • Cons • routers receive duplicate packets • detecting that a packet is a duplicate requires storage, which can be expensive for long multicast sessions

15. A clever solution • Reverse path forwarding (RFP) • Rule • forward packet from S to all interfaces if and only if packet arrives on the interface that corresponds to the shortest path to S • no need to remember past packets • C need not forward packet received from D

16. Cleverer • Don’t send a packet downstream if you are not on the shortest path from the downstream router to the source • C need not forward packet from A to E • Potential confusion if downstream router has a choice of shortest paths to source (see figure on previous slide)

17. Pruning • RPF does not completely eliminate unnecessary transmissions • B and C get packets even though they do not need it • Pruning => router tells parent in tree to stop forwarding • Can be associated either with a multicast group or with a source and group • trades selectivity for router memory

18. Rejoining • What if host on C’s LAN wants to receive messages from A after a previous prune by C? • IGMP lets C know of host’s interest • C can send a join(group, A) message to B, which propagates it to A • or, periodically flood a message; C refrains from pruning. • The later is called Flood and Prune approach to multicast tree management. • Flood and Prune was used in first implementation of multicast in Internet

19. Contd… • Cost of pruning and joining • Prunes can be associated with a multicast group or a particular [multicast group & source] • In first case: • Routers need to store only one prune indication per output interface per group • Receivers the prunes message from one source cannot receive message from other source in the same group • In second case: • Routers need to store prune indication per source per group for each interface. • Second case is much costly with regard to storage space.

20. Internet Multicast Protocol • MOSPF & DVMRP • What modification is required in link state routing and distance vector routing to support multicasting • What if not all routers but only a subset of routers in Internet supports multicasting mechanism • Multicast version of OSPF • In link state each router monitors it’s directly connected links and broadcasts to all other routers whenever a change in link state occurs • The extension requires to support multicasting is following: • - The link state part also contains all multicast groups for which the link has member(s) • -with this information each router can compute the shortest path multicast tree for each source of each group • Since router has to store this tree for each source for each group, overhead is high, hence not scalable

21. Internet Multicast Protocol • MOSPF & DVMRP • What modification is required in link state routing and distance vector routing to support multicasting • What if not all routers but only a subset of routers in Internet supports multicasting mechanism

22. DVMRP • DVMRP ( Distance vector multicast routing protocol) • Very similar to RIP • distance vector • hop count metric • reverse-path forwarding (to decide where to forward a packet) • Used in conjunction with • flood-and-prune (to determine memberships) • prunes store per-source and per-group information • Each router stores prune information for reverse path multicasting I.e. selective forwarding. ( per source, per group for each interface) • explicit join messages to reduce join latency (but no source info, so still need flooding)

23. MOSPF • MOSPF (Multicast OSPF) • Multicast extension to OSPF • Routers flood group membership information with LSPs (LSP extended) • Each router independently computes shortest-path tree that only includes multicast-capable routers • no need to flood and prune • Group joining and leaving information gets updated in all router through Link State Update • Complex • interactions with external and summary records • need storage per group per link • need to compute shortest path tree per source and group • Since router has to store this tree for each source for each group, overhead is high, hence not scalable

24. Core based tree Multicasting • DVMRP and MOSPF were source based multicast tree • Each source uses different source specific shortest path tree for data forwarding • Cost of group formation with these schemes: join/prune information store per source per group per interface in each router. • Both suffer from scaling problems.Building trees installs state in the routers. It is easy to observe that both does not scale well when a relatively small proportion (sparse mode) of routers wants to receive packet from a particular group. CBT and PIM( see next slides) are primarily for sparse mode situation.

25. Core based tree Multicasting • Core based Tree: Key idea with core-based tree • coordinate multicast with a core router • host sends a join request to core router • routers along path mark incoming interface for forwarding.

26. Example • Pros • routers not part of a group are not involved in pruning • explicit join/leave makes membership changes faster • router needs to store only one record per group • Cons • all multicast traffic traverses core, which is a bottleneck • traffic travels on non-optimal paths

27. Protocol independent multicast (PIM) • Tries to bring together best aspects of CBT and DVMRP • Choose different strategies depending on whether multicast tree is dense or sparse • In dense mode the receivers are densely situated and most f the routes need to participate in the multicast forwarding • flood and prune good for dense groups • only need a few prunes • CBT needs explicit join per source/group • In sparse mode receivers are sparsely situated, Flood and prune is a wastage. Too many prune message. Join and prune is better • CBT good for sparse groups • Dense mode PIM == DVMRP • Sparse mode PIM is similar to CBT • but receivers can switch from CBT to a shortest-path tree

28. Protocol independent multicast (PIM) • PIM uses a notion of central node (rendezvous point) RP for each group, which maintains multicast shortest path tree for each group • We assume in a domain of routers each router knows the unicast IP address for RP of a particular group • In PIM sparse there are two type of trees : shared tree for a group and source specific tree • Typically shared tree is built first and then source specific tree if required

29. RP join R3 R2 R4 R1 R5 RP R3 R2 R4 join R1 R5 Protocol independent multicast (PIM) • R4 send a join message ( *, G) to RP of G. * denotes all senders. • All routers in path make an entry in multicast forwarding table for (*, G) on the incoming link R2-R4 • Then R2 selects a link for forwarding the join request to RP, ( here R2-RP). This will be only acceptable incoming interface for incoming packets sent to this group. • This completes the a branch of the shared tree installation at RP and in all routers required to reach receiver R4 • Joining request from R5 for group G needs only to go up to router router R2, this is another branch of shared tree for receiver R5

30. RP R3 R2 R4 join R1 R5 Protocol independent multicast (PIM) • Problem: cost of encapsulation and de-encapsulation • When R1 wants to send to packet to group G, R1 tunnels it through unicast IP packet to RP, RP then forwards the packet with the help of shared tree for group G rooted in it • Approach: for long lived session RP sends a join message to R1 which installs state in R3, Then R1 can send native multicast packets • This join message from RP is sender specific (S,G) ( the previous join message from R4 and R5 were not) and installs sender specific state in R3 • So, source specific tree till RP and then not-source specific tree from RP upto receivers

31. RP R3 R2 R4 join R1 R5 RP R3 R2 R4 join join R1 R5 Protocol independent multicast (PIM) Further Optimization : • Clearly the route from R1 to R4 is is not the shortest one. • So entire shared tree can be replaced by source specific tree for long sessions • R4 can send a join request of the form to R1, which takes the shortest path installing state ( S, G) in all intermediate routers. Thus bypassing RP completely for sender S • But the shared tree for (*,G) remains at RP for all receivers to handle the situation for any new sender in the group. • This is called protocol independent as it works any unicast routing mechanism in the internet

32. More on core • Renamed a rendezvous point • because it no longer carries all the traffic like a CBT core • Rendezvous points periodically send “I am alive” messages downstream • Leaf routers set timer on receipt • If timer goes off, send a join request to alternative rendezvous point • Problems • how to decide whether to use dense or sparse mode? • how to determine “best” rendezvous point?

33. Factors evaluating multicast protocol • Scalability • What is the amount of state required in routers? Or how dies the amount of state change with the number of nodes leaving or joining the group • Reliance on underlying unicast protocol • To what extent in relies on information available by underlying unicast protocol? • MOSPF, PIM • Un-needed traffic received • Router chould not receive traffic if it does not have a member for the particular group • Traffic Concentration • Group shared tree tend to use specific links while source based trees distribute traffic • Optimality of forwarding path • Minimum cost multicast tree finding is hard ( Solving Steiner Tree), center based tree is not optimal

34. Some References Research Directions: • Congestion/Rate control in multicast tree, session maintenance, error control. Security is a major issue • Inter AS Multicast protocol ( IDMR Work group of IETF) References • S.E. Deering and D.R. Cheriton, Multicast Routing in Datagram Internetworks and Extended LANs, ACM Trans. On Comp. Sys., Vol 8, No 2, May 1990, pp 85-110. • S.E. Deering, et.al., An Architecture for Wide-Area Multicast Routing, Proc. SIGCOMM ‘94, London, England, August 1994. • V. Johnson and M. Johnson, Introduction to IP Multicast Routing, http://www.ipmulticast.com/community/whitepapers/introrouting.html. • S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, Protocol Independent Multicasting • Scalable Multicast Key Distribution (1994)   Tony Ballardie • Scalable Secure Group Communication over IP  Multicast Suman Banerjee, Bobby Bhattacharjee • L wei, D. Estreen, : A comparison of multicast trees and algorithms: Technical report USC.

35. Some References Multicasting Tools SDR, VIC and RAT for Sun, Linux and Windows multicasting. Quicktime will be the Macintosh application for viewing multicast sessions. Products: • Apple's QuickTime Conferencing software. • ICAST Express Media, video, audio and text clients and servers, beta version available on request. • Merit Network's mrouted, multicast router daemon (server). • Microsoft's NetShow-- Windows video/audio client and server. Multicast-capable. • Precept's IP/TV -- Windows client for receiving video/audio/slide broadcasts. • Van Jacobson's popular multimedia multicasting tools for a Unix X Window server: video (VIC), and audio (VAT).

36. Multicast Overlay • Reverse path forwarding requires a router to know shortest path to a source • known from routing table • Doesn’t work if some routers do not support multicast • virtual links between multicast-capable routers • shortest path to A from E is not C, but F

37. Overlay (contd.) • Two problems • how to build virtual links • how to construct routing table for a network with virtual links • TUNNELS Why do we need them • Consider packet sent from A to F via multicast-incapable D • If packet’s destination is Class D, D drops it • If destination is F’s address, F doesn’t get to know multicast address! • So, put packet destination as F, but carry multicast address internally • Encapsulate IP in IP => set protocol type to IP-in-IP • DVMRP is capable of making virtual links.

38. Reference for MBONE: • Michael R. Macedonia and Donald P. Brutzman. MBONE provides audio and video across the Internet. IEEE Computer, vol. 2Z(no. 4):30-36, April 1994. available at 44 • Hans Eriksson. MBONE: The multicast backbone. Communications of the ACM, vol. 37(no. 8), August 1994. available at • Stephen Casner and Stephen Deering. First IETF Internet audiocast. ACM Sigcomm Computer Communication Review, vol. 22(no. 23):92-97, July 1992. available at ftp://venera.isi.edu/pub/ietf-audiocast.article.ps. • Stephen Casner. Are you on the MBone? IEEE Multimedia, vol. 1(no. 2):76-79, 1994. available at • Mark Handley and Van Jacobson. SDP: Session description protocol, 1996. Internet draft, currently available at http://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp- • Mark Handley. SAP: Session announcement protocol, 1996. Internet draft, • M. Handley, H. Schulzrinne, and E. Schooler. SIP: Session invitation protocol, 1996. Internet draft.