1 / 44

IP Multicast Part I: Fundamentals

IP Multicast Part I: Fundamentals. Carl Harris Communications Network Services Virginia Tech. Game Plan. Part I: IP Multicast Fundamentals Part II: Protocol Independent Multicast, Sparse Mode (PIM-SM). Part III: Interdomain Multicast, Multicast-Only Topologies.

aviva
Télécharger la présentation

IP Multicast Part I: Fundamentals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IP MulticastPart 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. 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... Multicast Packet Format RTP or UDP packet payload 224.2.153.83 128.173.12.15

  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 ExampleHosts join group G 1. Host H1 joins group G by sending an IGMP membership report to G. 2. Create (*,G) iif=NULL oif=1 4. Update (*,G) iif=NULL oif=1,2 6. Refresh the outgoing interface timer for interface 1. H1 H3 5. Host H3 joins group G. H2 3. Host H2 joins group G R 1 2

  25. IGMP ExampleR sends a Membership Query 2. H1 and H3 both receive the query and set their timers for group G. Assume H3’s delay time is smaller. 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. 3. H3’s timer expires and the membership report is sent. H1 H3 H2 1. R sends a membership query on interface 1. (*,G) iif=NULL oif=1,2 R 1 2

  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 ExampleH2 leaves group G 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 H1 H3 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. H2 1. H2 sends a Leave Group message for G, and stops listening to the group. (*,G) iif=NULL oif=1,2 R 1 2

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

  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 ExampleSource S sends a packet to group 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. What if this state doesn’t exist when R receives the packet? H1 H3 3. The packet matches only (*,G). R creates (S,G) iif=3 oif=1,2. R refreshes the entry timer for (*,G). Bull. 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. What if the TTL threshold for interface 2 is set to 16? H2 S 3 (*,G) iif=NULL oif=1,2 R 1 2

  39. Forwarding ExamplePreventing a Loop 2. A and B both receive the packet RPF passes, and each router forwards a copy of the packet to segment 2. 1. S sends a packet to group G, TTL=2. S 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. 3. R receives two copies of the packet. R RPF does not prevent packet duplication. We’ll need something more sophisticated to solve that problem. 1 1 1 A B (*,G) iif=NULL oif=2 (S,G) iif=1 oif=2 2 2 (*,G) iif=NULL oif=2 (S,G) iif=1 oif=2 2

  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

More Related