1. IP Multicast Part I: Fundamentals Carl Harris Communications Network Services Virginia Tech

2. Game Plan Part I: IP Multicast Fundamentals Part II: Protocol Independent Multicast, Sparse Mode (PIM-SM). Part III: Interdomain Multicast, Multicast- Only Topologies. Part IV: Layer 2 Optimizations and Other Oddities. PIM-DM, DVMRP Overview.

3. Part I Agenda Multicast IP addressing. Multicast forwarding states (routes) and associated terminology, notation. Group membership –Internet Group Management Protocol (IGMP). Multicast sources and packet forwarding.

4. Multicast Group Addressing IP addresses from 224.0.0.0 to 239.255.255.255 are designated as multicast addresses. A multicast IP packet reaches a subset of all hosts on the network; those hosts that have indicated an interest in the multicast group address.

5. Multicast Group Addressing Group addresses have inherent scope: –Link scope:224.0.0.0 -- 224.0.0.255 These are never forwarded by any router. –Global scope:224.0.1.0 -- 238.255.255.255 Can be delivered throughout the Internet. –Administrative scope : 239.0.0.0 -- 239.255.255.255 Not forwarded beyond an organization’s intranet.

6. Multicast Packet Format Source is always a unicast address. Destination is a multicast group address. Packet payload is typically –Real Time Protocol (RTP) –User Datagram Protocol (UDP) Need to map multicast group addresses to layer 2 (e.g Ethernet) multicast addresses. Later... RTP or UDP packet payload 128.173.12.15 224.2.153.83

7. Multicast Forwarding States We use the term state to refer to an entry in the IP multicast forwarding table of a router. A state is used to determine how a multicast packet will be forwarded. You may also see the term mroute (as in the IOS command show ip mroute ) -- this term is dangerously overloaded: –can refer to a forwarding state –can refer to a RPF table entry

8. Multicast Forwarding States A forwarding state (or simply “state”) consists of several elements: –source address –group address –incoming interface –outgoing interface list –various timers (needed to deal with aging entries out of the forwarding table) –flags (needed later for PIM-SM)

9. Forwarding State Maintenance Forwarding states are created, modified, and deleted dynamically –Created when receivers join a multicast group and when sources send packets addressed to the group. –Deleted after receivers leave a multicast group or senders stop sending packets addressed to the group.

10. Forwarding State Maintenance Every forwarding state has a fixed lifetime. –The entry timer for a forwarding state is set to its maximum value when the state is created. –The timer counts down toward zero as long as the state exists. When the timer reaches zero, the state is deleted. –Certain events cause the timer to be refreshed (set to its maximum value), deferring deletion of the associated forwarding state for at least one more full lifetime.

11. Forwarding States: Notation In general, we won’t use literal IP source or group addresses. Instead we’ll use S to refer to some arbitrary source and G to refer to an arbitrary group. When more than one source is of interest, we’ll use S1, S2, Si, Sj, etc. On the rare occasions when we’re interested in more than one group we’ll likewise use G1, G2, etc.

12. Forwarding States: Notation The notation (S,G) is used to indicate a state specific to some source S sending packets to a group G. Every state (S,G) has an incoming interface. We denote this with the abbreviation iif. In our examples, we will use small integers to identify router interfaces (e.g. iif=2). In some cases iif=NULL.

13. Forwarding States: Notation Every (S,G) state has an outgoing interface list. This list may be null, or may contain one or more interface identifiers. This list is denoted with the abbreviation oif. Examples: –(S,G) iif=2 oif=NULL –(S1,G) iif=1 oif=2 –(S2,G) iif=1 oif=2,4,5

14. Forwarding States: Notation We use the notation (*,G) to denote a state that matches any source sending to group G. –created and updated whenever receivers appear for group G. –deleted when no more receivers for group G exist. The oif for the (*,G) state is used to initialize the oif for the (S,G) state created when source S begins to send packets to group G.

15. OIF List Maintenance Every entry in the outgoing interface list of a forwarding state has a fixed lifetime. –The timer for a particular interface is set to its maximum value when it is added to the list. –This timer counts down toward zero as long as the interface is in the list. When it reaches zero, the interface is removed from the list. –Certain events cause the timer to be reset to its maximum value, thus deferring removal of the interface from the list.

16. Multicast Group Membership Internet Group Management Protocol (IGMP) is used by hosts to indicate their interest in receiving packets addressed to a particular multicast group G. –IGMP version 1 is described in RFC 1112 –IGMP version 2 is described in RFC 2236 and is backward-compatible with version 1. IGMP messages aren’t forwarded by routers.

17. IGMP Overview Periodically, a router attached to a particular subnet sends a General Membership Query to determine what group addresses have members on the subnet. –These queries are sent to multicast address 224.0.0.1 (the all systems group). All hosts (and routers) listen to this group.

18. IGMP Overview One router on every subnet is designated as the IGMP Querier. –The querier is responsible for sending membership queries to the subnet to determine group membership. –Other routers on the subnet listen to the membership reports sent by hosts and maintain forwarding states accordingly, regardless of which router is the querier.

19. IGMP Overview The “election” of a querier is carried out as routers overhear each other’s membership queries. –When a router first starts up, it assumes it is the querier for each of its interfaces. –If the router overhears a query on an interface for which it believes itself to be the querier, and the IP address of the source of the query is numerically smaller than its own IP address on that interface, the router stops sending queries.

20. IGMP Overview When a host receives a general membership query, it does not respond immediately. –The host sets a timer for every group G for which it is a member, using a random value between zero and D seconds. –If the timer for a group G expires, the host sends a Membership Report addressed to G. –While the timer for a group G is non-zero, if the host overhears a report from another member of G, it clears the timer and does not send a report.

21. IGMP Overview The maximum value of the query response timer D depends on the version of IGMP: –version 1: D = 10 seconds –version 2: the membership query contains a field that specifies the value of D, in tenths of a second.

22. IGMP Overview When a host wishes to join a group G it immediately sends an unsolicited Group Membership Report –Speeds up the join process when the host is the first on the subnet to join group G.

23. IGMP Overview When any router on a subnet receives a membership report for group G –if there are no states for group G, the router creates (*,G) state, and sets the oif to the interface on which the report was received. –if one or more states exist for group G, the oif list for every state involving G is updated to include the interface on which the report was received. If the interface is already in the oif list, its timer is refreshed.

24. IGMP Example Hosts join group G R 1 2 H1 1. Host H1 joins group G by sending an IGMP membership report to G. 2. Create (*,G) iif=NULL oif=14. Update (*,G) iif=NULL oif=1,2 H2 3. Host H2 joins group G H3 5. Host H3 joins group G. 6. Refresh the outgoing interface timer for interface 1.

25. IGMP Example R sends a Membership Query R 1 2 H2 H1H3 (*,G) iif=NULL oif=1,2 2. H1 and H3 both receive the query and set their timers for group G. Assume H3’s delay time is smaller. 3. H3’s timer expires and the membership report is sent. 1. R sends a membership query on interface 1. 4. H1 receives the report, clears the timer for group G, and sends nothing. R receives the report and refreshes the outgoing interface timer for interface 1.

26. IGMP Overview When an IGMPv2 host wishes to leave a group G it may send a Leave Group message. –Sent to 224.0.0.2 (all routers) since other hosts don’t care when any particular host leaves. –Not required if the host wasn’t the last membership reporter for G. –Can be sent even if the host wasn’t the last reporter for G.

27. IGMP Overview When a host sends a leave group message for a group G, the router sends a Group- Specific Membership Query. –Addressed to the group, G. –Hosts follow the same rules as for the general query (i.e. delay before replying, and don’t reply if someone else does first).

28. IGMP Overview When a router does not receive any reply on an interface for a group G for which forwarding states exist: –The outgoing interface timer for every state involving G continues to count down. –When the timer for that interface in a G state expires, the interface is removed from the oif list for that state.

29. IGMP Example H2 leaves group G R 1 2 H1 H2 H3 (*,G) iif=NULL oif=1,2 1. H2 sends a Leave Group message for G, and stops listening to the group. 3. The timer for responding to the query for group G expires, and since no report was received, the timer for interface 2 is not updated. (*,G) iif=NULL oif=1 4. Later, the outgoing interface timers for interface 2 in all G states expire, and the interface is removed from the respective oif lists. 2. R receives the Leave Group G from H2, and sends a Group-Specific membership query on the same interface.

30. IGMP Example H1 leaves group G R 1 2 H1H3 (*,G) iif=NULL oif=1 1. H1 vanishes from the network. 2. Later, R sends a general membership query. 3. H3 receives the membership query, sets the timer for G, and when the timer expires, sends a report for G. 4. R receives the report and refreshes the outgoing interface timer for interface 1 in every state involving G.

31. An Optimization? Why not immediately delete an interface from the oif list for all G states when no report for G is received in response to a membership query? What if the interface in question leads to downstream receivers and downstream routers, e.g. PIM routers that don’t participate in IGMP?

32. Multicast Sources A source S that sends packets addressed to group G need not be a member of group G. –S doesn’t need to join group G unless S is interested in receiving packets addressed to group G. We will often refer to packets sent by S to group G as (S,G) packets.

33. TTL Scope As in unicast IP forwarding, the TTL field of a multicast IP packet is decremented by every router that forwards it. A source can choose any TTL for multicast packets that it transmits. When a router decrements the TTL of a packet to zero, the packet is dropped. TTL controls how far multicast packets travel before being dropped.

34. TTL Scope Router interfaces can be configured to drop multicast packets with a TTL less than some arbitrary (positive) value, rather than allowing the TTL to count down to zero. –Cisco IOS interface configuration command: ip multicast ttl-threshold 16 –These thresholds create TTL scope boundaries E.g. packets must start with a TTL of at least 16 to be forwarded beyond the campus network.

35. Reverse Path Forwarding (v1) When a multicast packet with source address S is received by a router, the packet will be forwarded only if it arrived on the interface to which the router would forward a (unicast) packet with destination address S. Otherwise, the packet is dropped. –We refer to this as the RPF test. –Plays a role in preventing forwarding loops.

36. Multicast Packet Forwarding When a packet is received by a router from a directly connected source S addressed to a group G: –If neither (S,G) nor (*,G) state exists, the packet is dropped. We make an exception when PIM- SM is the multicast routing protocol. –If (S,G) state exists, its entry timers is refreshed and the packet will be forwarded using the oif list for the (S,G) state.

37. Multicast Packet Forwarding –If no (S,G) state exists and the packet matches (*,G) state, the (S,G) state is created. iif is set to the interface on which the packet was received oif is copied from the (*,G) state. the entry timer for (*,G) is refreshed. Bull. –The packet will be forwarded to an interface in the oif list of the matching forwarding state only if the TTL threshold for that interface is less than the TTL of the packet.

38. Forwarding Example Source S sends a packet to group R 1 2 H1 H2 H3 (*,G) iif=NULL oif=1,2 3 S 4. R decrements the TTL of the packet (now TTL=1). Assuming that neither interface 1 nor 2 has a TTL threshold set, R forwards the packet according to the created (S,G) state. 2. R receives the packet, and verifies that the packet passes the RPF test. 1. S sends a packet addressed to G, with TTL=2. 3. The packet matches only (*,G). R creates (S,G) iif=3 oif=1,2. R refreshes the entry timer for (*,G). Bull. What if the TTL threshold for interface 2 is set to 16? What if this state doesn’t exist when R receives the packet?

39. Forwarding Example Preventing a Loop R (*,G) iif=NULL oif=2 (S,G) iif=1 oif=2 S B A 1 2 1 2 1 2 1. S sends a packet to group G, TTL=2. (*,G) iif=NULL oif=2 (S,G) iif=1 oif=2 2. A and B both receive the packet RPF passes, and each router forwards a copy of the packet to segment 2. 3. R receives two copies of the packet. 4. Each router receives the packet sent by the other router, RPF fails and each router drops the packet, preventing the possibility of a loop. RPF does not prevent packet duplication. We’ll need something more sophisticated to solve that problem.

40. Reverse Path Forwarding (v2) When a router R receives a multicast packet on interface I addressed to group G from a directly connected source S, forwarding states will be created and/or updated and the packet will be eligible for forwarding only if interface I would be used by R to forward unicast packets addressed to S.

41. Exercises What additional forwarding rule(s) is (are) needed if a router has both a source and a receiver on the same interface? Consider the case where all receivers are located on the same subnet as a source and the case where some receivers are on other subnets connected to R. IGMP could be used as a primitive multicast routing protocol. Consider the case of two routers interconnected on a backbone, each with some local subnets that have active receivers for a group G. Place a source on a subnet connected to one of the routers. What additional IGMP actions will need to take place between the routers to forward the source to all receivers?

42. Recommended Reading Deering, S. Host Extensions for IP Multicasting. RFC 1112, IETF Network Working Group, August 1988. Fenner, W. Internet Group Management Protocol, Version 2. RFC 2236, IETF Network Working Group, November 1997. Estrin, D. et. al. Protocol Independent Multicast - Sparse Mode (PIM-SM): Motivation and Architecture. Internet Draft, IETF Interdomain Multicast Routing Working Group, October 1996. http://catarina.usc.edu/pim. Estrin, D. et. al. Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Description. RFC 2362, IETF Network Working Group, June 1998.

43. Interesting URLs http://www.cisco.com/warp/public/674/4.html http://www.cisco.com/warp/public/cc/cisco/mkt/ios/mcastip/tech/ipcas_dg.htm http://www.ietf.org/html.charters/idmr-charter.html http://www.ipmulticast.com/

44. End of Part I