CMPT 471 Networking II

1. CMPT 471Networking II Multicasting protocols

2. State machine for an entry in host's multicast route table Comer 2000: fig 17.4

3. IGMP states: 1 • Consider a router with at least one host on a connected network that is a member of a particular multicast group • Every 125 seconds the router will generate a query and send it to the multicast group.. • When the host receives the query it moves from member state to delaying member state, it builds its report and sets its random delay timer (random in a specified interval which defaults to 10 sec) • If it hears another report before it is due to send its own it will drop the report without sending an moves back to idle member state. (v2 only) • When its timer expires it sends its report and moves back to idle member state.

4. IGMP states: 2 • Consider a router with a connected network. No host on that connected network is a member of the multicast group. Then consider that one host on the connected network wishes to join the multicast group • The host will be in the nonmember state. • The host builds a membership report packet. • The host starts a timer and sends the membership report packet • The host moves into the delaying member state. • When the timer expires the host resends the member report packet and moves into the member state. • Sending the membership report twice (each time in a best effort UDP packet) provides a measure of security that the membership report will reach the server

5. Need for dynamic routing • Membership in groups changes not only when topology changes, but also when new hosts/application programs join/leave a group or update filtering information. • Routing requires knowledge of both source and destination to avoid loops (router A-B-C-A) • Senders need not be members of the multicast group and multicast messages may be routed across networks with no members in the multicast group. Routing must adapt to any sender.

6. Reverse path forwarding • When a source wishes to flood a message across the network to reach all routers • Determine which interface the packet should arrive through • Extract the source address • Consult the routing table to determine which interface the packet would be sent through in if was to be forwarded to the source address. This is the reverse path interface • If the packet arrives on the reverse path interface flood it through all other interfaces • If the packet arrives on any interface other than the reverse path interface drop it

7. Reverse path forwarding • Using the RPF algorithm the packet will be flooding throughout the internet reaching all potential group members • Multiple copies of each packet may reach any given network. • Copies of the packet are sent to networks that are not part of the path from source to receiver and have no members in the multicast group

8. Source based tree for source x Group has members only on networks with hosts illustrated Comer 2000: fig 17.9

9. Source based tree for source z Group has members only on networks with hosts illustrated Comer 2000: fig 17.9

10. Truncated RPF (1) • Reverse path forwarding with an added step • Each router keeps both a conventional routing table and a multicast routing table which is a list of multicast groups reachable through each interface • On a network with more than one directly connected multicast router TRPF may still result in multiple copies of a multicast packet reaching a multicast group member

11. Truncated RPF (2) • If RPF indicates the message should be dropped, it is. OTHERWISE • If a router has no members on any of its attached networks it will check an additional list of reachable multicast groups and forward the packet through interfaces that lead to members of the group. The router truncates forwarding (does not flood the packet through the interface) when no group members are reachable through that interface.

12. Source based tree for source x Group has members only on networks with hosts illustrated zz Comer 2000: fig 17.9

13. Source based tree for source z Group has members only on networks with hosts illustrated zz Comer 2000: fig 17.9

14. reverse path multicasting (RPM): • TRPF + Any router that has no members attached and no paths to multicast group members will be ‘pruned’. A prune message will be sent back to the previous router for the flooded message telling it to stop sending messages to the originating router of the prune message. • The flood and prune process results in the gradual development of a source based tree for multicast routing. • A router that has previously sent a prune message may later send a graft message to ask for the resumption of exchange of multicast messages (for example if one of the hosts on its connected networks decides to join the multicast group)

15. RPM: routing • When a new member (receiver) joins the group, the tree may need to be updated. • By flooding an announcement of the new member • By having each router remember how to contact the rest of the multicast group. • Distance Vector Multicast Routing Protocol (DVMRP) is an extension of distance vector routing protocols used for unicast (works with RIP). DVMRP implements RPM • DVRMP is (like RIP) an IRP, it is used for hosts and routers within a single AS. Parts of that AS may be at different physical locations and be connected by tunnels.

16. RPM: routing • Like RIP, DVMRP is not very scalable, larger amounts of data are exchanged as the network grows, a small value for infinity is used, and information on prune messages must be kept so graft messages can be executed

17. When DVMRP message are sent • Periodically a router should send out DVMRP messages with all of its routing information to all of its virtual interfaces (physical interfaces and tunnels). • Whenever a route is changed, a routing update should be sent for that route. These triggered updates should have added random delays. • To supply information about some or all routes in response to a request. • A request for all routes should be sent on all virtual interfaces when an DVMRP router is restarted. • If possible, on termination a DVMRP router should send out DVMRP messages with metrics equal to infinity for all of its routes, on all virtual interfaces.

18. What is a DVMRP message • DVMRP uses the Internet Group Management Protocol (IGMP) to exchange routing datagrams. • DVMRP datagrams are composed of two portions: an IGMP header, and a stream of tagged data. The fixed length IGMP header of DVMRP messages is: • The version is 1. The type for DVMRP is 3. Version Type Subtype CHECKSUM 32 4 8 16

19. What is a DVMRP message • Subtypes • 1 = Response; provides routes to some destination(s). • 2 = Request; requests routes to some destination(s). • 3 = Non-membership report; • 4 = Non-membership cancellation; the message cancels previous non-membership report(s). • Checksum is calculated over entire message • Tagged Data, each containing a command. Each command includes a tag and necessary data • A DVMRP message is limited to 512 bytes

20. Implementing DVMRP • There are multiple ways to implement DVMRP routing on a UNIX system • mrouted is can be used to support DVMRP and multicast forwarding and tunnelling • quagga (or zebra) routing suite can be used not only to implement DVMRP distance vector routing protocol but also link state multicast routing protocols (more later) and unicast routing protocols.

21. mrouted • Uses DVMRP (RFC 1075) to propagate multicast routing information between routers. (in version 3 only). A pruned routing tree is determined for each multicast group with routes that have no members pruned from the multicast tree • A router running mrouted is a multicast router and maintains a multicast routing table • mrouted does not replace conventional unicast routing processes, they work in parallel

22. mrouted • mrouted provides multicast tunnels • Propagate multicast packets between network segments or AS’s that support multicasting through parts of the internet that do not support multicasting • Multicast IP packet is encapsulated in a unicast IP packet then unicast to the next router that supports multicasting

23. Tunneling Comer 2000: fig 17.10

24. Tunneling: IP in IP encapsulation Comer 2000: fig 17.11

25. MBONE • RFC 1458, 1889 • Multicast backbone: a virtual network of multicast routers that form a backbone for multicast routing over the internet • Growing exponentially just like the internet

26. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example • Network to consider F s A C B P D A E Q A

27. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPF • STEP 1: Send packet from s to A (hops between routers all have cost 1). Reaches multicast router A F s A C B P D A E Q A

28. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPF • STEP 1: RPF at A F s A C B P D A E Q A

29. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPF • STEP 2: RPF from B, C, and F F s A C B P D A E Q A

30. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPF • STEP 2: RPF from E, P, and Q F s A C B P D A E Q A

31. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: TRPF • All destination networks without members need not be part of the broadcast tree F s A C B P D A E Q A

32. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPM • All destination routers that do not have outgoing paths to any group members send prune messages F s A C B P prune D A prune prune E Q A prune

33. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPM • All routers receiving a prune message send back a prune ack F s A C B ack P D A ack ack E Q A ack

34. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: RPM • Leaf routers have been pruned F s A C B P D A E Q A

35. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: changes • Change Topology, new member added on network attached to router Q, sends ICMP report to join F s A C B P D A E Q A Join report

36. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: changes • Change Topology, new member added on network attached to router Q, sends ICMP report to join F s A C B P D A Graft E Q A

37. mrouted mrouted mrouted mrouted mrouted mrouted mrouted mrouted A DVMRP example: changes • Change Topology, new member added on network attached to router Q, sends ICMP report to join F s A C B P D A E Q A

38. Other multicast protocols • MOSPF (RFC 1585) • Multicast extension of OSPF. • Demand driven • uses OSPF topology information to compute a forwarding tree for each multicast source • Useful in a particular area of an AS. • Propagate membership information from each area to the backbone through MABRs (multicast area border routers)

39. Other multicast protocols • PIM-SM, PIM-DM Protocol independent routing for sparse or dense multicast networks

40. Sparse and dense multicast • Consider an internet composed of many network segments. One or more routers is connected to each segment. • If you expect most segments to contain hosts that will be part of a multicasting group you have a dense multicast network • If you expect only a few of the segments to contain hosts that will be a part of the multicast group you have a sparse multicast network.

41. Sparse and Dense multicast • Consider an internet composed of many network segments. One or more routers is connected to each segment. • For PIM (protocol independent multicast) a different approach is taken for dense multicast networks (usually a single enterprise with a small number of ASs) and for sparse multicast networks ( ISP’s with varied usage, general internets) • DVMRP is the simplest form of Dense Multicast, • PIM-SM is the most commonly used multicast protocol

42. PIM • PIM-DM Uses a broadcast and prune (flood and prune) process similar to DVRMP. • Forward multicast datagrams until told not to (pruned) • PIM-SM Uses a demand driven approach • Do not forward multicast datagrams until asked • End station sends request to its local multicast router. • Local multicast router propagates request to other multicast routers till the request reaches a router that is currently forwarding multicast packets.

43. PIM-SM: finding active routers • Designate one or more routers as core routers or Rendezvous points (RP). Only one should be active • Each RP maintains a database of all its multicast groups and their sources. • Each multicast router must know the addresses of the RPs. (addresses learned using protocols we will not cover) • Each multicast group has one RP

44. PIM-SM: finding active routers • Designate one or more routers as core routers or Rendezvous points (RP). Only one should be active • Each RP maintains a database of multicast groups and their sources. • Each multicast router must know the addresses of the RPs. (addresses learned using protocols we will not cover) • A core based tree (CBT) rooted at the RP can then be generated. The CBT will connect to all active (with present members) routers • Used to route multicast datagrams to multiple groups • Demand driven, only add to the tree when a new host, which may be on an unserviced router, requests to become a member of the group

45. Example: • Based on material from ftp://ftp-eng.cisco.com/ipmulticast/training/Module1.pdf

46. Example: Receiver Joining Group • Uses RPF, • source is the RP for shared trees (RP to receivers), • New receivers register with RP then their local multicast router becomes part of the shared tree (if it is not already) and traffic flows up the shared tree to them

47. PIM-SM: adding a receiver to CBT • The new receiver will send an IGMP report requesting that it join group G to its local router • If the local router is not a part of the CBT it will send a join message to the router one hop closer to the RP • If a the local router is already a part of the CBT for a local RP • it is already forwarding multicast packets. • The local multicast router will add the host to the multicast group and begin forwarding packets to the host from the RP

48. PIM-SM: adding a receiver to CBT • If a the local router is not already a part of the CBT (shared tree) for a local RP • The local multicast router will send a join request to the next hop router on the path to the RP (along the unicast path) • When the join message reaches the next hop router that router will • add an entry in its forwarding table to forward group G multicast datagrams to the local router • If it is a member of the CBT for group G it will add the originating host to its list of member for group G • If it is not a member of the CBT it will send a join message to the router one hop closer to the RP

49. PIM-SM: adding a receiver to CBT • The next hop router will (loops) • add an entry in its forwarding table to forward group G multicast datagrams to the originating router of the join message • If the next hop router is a member of the CBT for group G it will add the originating host to its list of member for group G • If it is not a member of the CBT it will send a join message to the router one hop closer to the RP • The loop above continues until a router that is a member of the CBT is reached

50. pim-SM pim-SM pim-SM pim-SM pim-SM pim-SM pim-SM pim-SM pim-SM pim-SM A PIM-SM example: changes • New receiver unicasts join to RP. At each router F RP Unicast join message Resulting shared tree New receiver