18. Multicast Communication Multicast within a subnet Reverse path forwarding IGMP PIM, SSM Roch Guerin (with adaptations from Jon Turner and John DeHart, and material from Kurose and Ross)

What Is Network Multicast? 8 Delivery of packets to a (sub)set of users Distinct from broadcast that targets all users Network multicast means that the network rather than the sender makes copies of the packet Main goal is to realize more efficient delivery Fewer packet copies consuming network bandwidth 4 4 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1

Multicast Routing Multicast address (Class D) leading 1110 in first byte (from 224 to 239) Originated in the classful network architecture of the early internet. Has been continued to be used in the Classless Inter-Domain Routing (CIDR) era of the Internet. Identifies content not destinations (a bidirectional channel or group ID) Users can subscribe to receive content sent to a group address Users can contribute content by sending it to a group address

Multicast Routing (continued) Two basic issues Group membership, i.e., joining a group (hosts expresses interest in receiving packets addressed to a given multicast group) Forwarding packets addressed to a group to all interested hosts To all subnets with subscribers, to all subscribers in a subnet

Multicast Routing (continued) Components IGMP: Internet Group Multicast Protocol protocol for registering host interest in multicast group Multicast routing protocol(s) (DVMRP, MOSPF, PIM, SSM, MP-BGP) build network forwarding state deliver packets to subnets Ethernet multicast/broadcast for subnet delivery IGMP determines what groups are needed in the subnet Multicast Routing protocol (like PIM) build forwarding state to deliver packets to subnets Ethernet multicast takes care of delivery within subnet.

Internet Group Multicast (RFC 2236) query membership report To forward among subnets, router needs to know about multicast subscribers within subnets router multicasts membership query packets hosts respond with membership reports after random delay suppress duplicate reports; usually just one report per group If host sees another host report, knows it doesn’t need to send one Router forwards multicast packets among networks based on membership information subscriptions timeout if not renewed periodically

IGMP Details Message fields type – query, report, leave group max response time – max wait time before responding to query group address – “subject” multicast addr; 0 for “general query” On each subnet, one router plays role of “Querier” router with smallest IP address acts as querier issues periodic general membership queries sent on “all systems” multicast address: 224.0.0.1 Hosts send reports to “subject” multicast address in response to general queries or when first joining a group Leave group message sent by host when leaving sent to “all routers” multicast address (224.0.0.2) querier responds with a group-specific query verify that no other group members still out there

IGMP Snooping (RFC 4541) Objective Reduce unnecessary traffic in switches use group membership to limit propagation of multicast packets learn which hosts are in which group by snooping on IGMP Suppression of duplicate membership reports by hosts would interfere with snooping Switches send report packets only to routers, not to hosts implies switches must be able to detect which ports go to routers most switches also suppress redundant reports to routers Forwarding based on group membership forwarding can use either Ethernet or IP addresses IP addresses preferred due to inexact multicast address mapping R Switches use this to reduce unnecessary traffic. What does the “Forwarding based on …” bullet mean?

Multicast Listener Discovery (IPv6) – (1) Goals Detects what multicast (and source) addresses have listeners on a given interface/link Offer filtering capabilities based on including or excluding specific multicast and source addresses Allow hosts to proactively notify router of changes MLD overview Two types of entities: Routers and listeners Two types of messages: Queries and Reports Queries are generated periodically or in response to changes on multicast subscriptions Reports can be generated in response to queries or after local changes in multicast subscriptions Host suppression has been eliminated from MLDv2, i.e., all hosts respond to a query

Multicast Listener Discovery (IPv6) – (2) Router’s behavior Election of “querier” if more than one router on a link Periodically transmit (general) queries Transmit targeted queries to rapidly validate new state after changes, e.g., after deletions by one listener Pass state information to (multicast) routing protocol Listener’s behavior Generate reports in response to Timer expiration Queries Local changes in interface state

Multicast Listener Discovery (IPv6) – (3) Multicast Listener Queries (from querier to listeners) General Query: No multicast address specified, asks for general report of multicast interest on link Multicast Address Specific: Targets information for one multicast address Multicast Address and Source Specific: Targets information for specific sources for a multicast address Multicast Listener Report (from listeners to routers) Include multiple “records”, one per multicast address A record identifies multicast address, list of sources, and record type Record type specifies the current state or targeted state change State can be INCLUDE or EXCLUDE, which determines how the list of sources is to be handled State change can be TO_INCLUDE or TO_EXCLUDE or specify a change to the list of sources, i.e., sources to be allowed or blocked

Multicast in a Subnet subscriber to 125.1.1.1:30123 packet to 125.1.1.1:30123 Within switched subnet, multicasting relies on Ethernet IP multicast address embedded in Ethernet multicast address more precisely, low 23 bits are embedded switches deliver multicast packets to all hosts (simple case) Receiving application configures multicast socket (UDP) bind to specific port, join multicast group Sending app sends UDP packet on multicast socket use multicast address/port, set TTL to 1

Class D to MAC Address Mapping (From IP Multicast to E/N Multicast) 23 bits copied from IP address 01 00 5E IEEE 802 MAC Address Multicast bit Reserved bit Class D IP address ‘1110’ = Class D indication Ignored IP Multicast delivers multicast packets to routers Routers need to deliver multicast packets to hosts MAC address used to “encode” IP multicast address MAC multicast bit set 23 bits (out of 28) copied from IP address to MAC address Probability of multicast collision? Is it a problem?

IPv6 Multicast to MAC Address Mapping An IPv6 multicast address consists of 16 octets of the form FF:flgs+scop:X(3):…:X(16) flgs denotes flags with 0000 for well-known multicast addresses, and 0001 for transient multicast addresses scop identifies the scope of the multicast group, with five defined values: 0001 (node-local), 0010 (link-local), 0101 (site-local), 1000 (organization-local), and 1110 (global) Note that the “meaning” of a well-known multicast address is independent of its scope An IPv6 multicast address is mapped to a 48-bit MAC address of the form 33:33:X(13):X(14):X(15):X(16) IEEE 802 MAC Address 00110011:00110011:X(13):X(14):X(15):X(16) IPv6 multicast address FF : flags,scope : group ID 8 4 112 X(3):…:X(13):X(14):X(15):X(16) 8 8 32

Multicast Issues in Larger Networks B R2 R1 IGMP is not always enough suppose a multicast has members in subnets A and C, but not B routers will not forward packets across B Multiple paths among subnets can produce multicast duplicates need to restrict routing of each multicast group to a tree requires routers to maintain forwarding information for each multicast group

Reverse Path Forwarding C B R2 R1 F E R6 R5 unicast path to A multicast from A Efficient distribution of multicast packets requires that packets be forwarded along a tree in principle, any tree joining subnets can be used and each multicast can use a different tree Internet generally uses reverse of unicast routes Shortest path tree to sender (not necessarily symmetric) so routing based on combination of (source adr, multicast adr) means multicast with many senders requires more routing state more efficient to use shared tree through “rendezvous point”

Shortest Path Tree vs. Minimum Spanning Tree The two are NOT the same. Why not? SPT: shortest path from root to EACH node MST: minimal TOTAL weight Shortest Path Tree (from A) Minimum Spanning Tree A 50 10 A 50 10

Current Multicast Routing Protocols Protocol Independent Multicast (PIM) Two different modes of operation based on the distribution of subscribed receivers, i.e., dense vs. sparse Flood and prune for dense groups Build targeted (shortest-path) tree for sparse groups Receivers need to explicitly join per source/group Sparse mode (PIM-SM) is the more commonly deployed Source Specific Multicast (SSM) Basically PIM-SM but assumes single known sender This affords significant simplifications in both protocol operation and packet forwarding The emerging solution of choice in practice Well-matched to service model of most multicast applications, e.g., video broadcast typically comes from one or a few well-know servers

Multicast Using Shared Tree (PIM) B R2 R1 F E R6 R5 Rendezvous Point multicast tree links denotes subnet’s Designated Router * Rendez-vous point (RP) serves as multicast tree root different groups can have different RPs, routers can determine assigned RP for each multicast address When Designated Router (DR) discovers new subscriber sends join message to RP, creating multicast state along path Sending hosts just send packets to multicast address initially, DR may forward to RP inside unicast packet

Joining a Multicast Group Rendezvous Point * C R2 R6 B A D IGMP Report join DR on new leaf node’s subnet observes IGMP report Join packets sent on shortest unicast path to RP multicast routing state added at each hop (graft new branch to tree) Packets delivered to new leaf along new tree path packets from leaf also use this path

Non-Subscriber Sending to Group Rendezvous Point * C R2 R6 B A D multicast packet encapsulated in unicast packet join Non-subscribing sender’s packets sent to RP by DR RP extracts multicast packet and forwards on shared tree RP may initiate join on source’s multicast tree adds multicast routing state along path, merges with RP tree when native packets reach RP, it tells DR to stop encapsulating

Switch to More Direct Path Rendezvous Point * C R2 R6 B A D prune join Router in tree may choose to switch to more direct path sends join back towards source after packets arrive on direct path, prune links in original path from source Note: expensive for multicasts with many senders

More About PIM (RFC 4601) PIM stands for Protocol Independent Multicast PIM can use routing data from any routing protocol e.g., unicast routing state, or multicast BGP PIM generally used only within single routing domain RFC omits essential details for inter-domain routing e.g., how are RPs coordinated among different domains BGP extensions may eventually enable inter-domain multicast Routers must be able to determine RP for any address can use statically configured mapping based on address ranges or, a PIM domain can use a Bootstrap Router (BSR) to distribute information used to map a multicast address to an RP domain has a defined set of RPs distributed by BSR PIM routers use a hash function to select an RP in this set e.g., if N candidate RPs, hash(multicast address) mod N selects one

IGMPv3 (RFC 3376) Adds support for source-specific multicast using “filters” include-filter specifies a list of acceptable senders multicast packets are delivered to socket only if sender is on list exclude-filter specifies a list of blocked senders hosts have “interface filters” derived from socket filters not supported by java multicast sockets; linux does support it Queries and membership reports are extended to handle “filtered multicasts” new source-specific query that includes a sender list for target destination address reports can cover multiple groups and includes a filter per group IGMPv3 ignores membership reports from other hosts so all IGMPv3 hosts in a multicast group will respond to a query Can operate in “compatibility mode” with older versions

Source Specific Multicast (SSM) RFC 3569 (overview); RFC 4607 (specifications) Basic motivations In most practical instances, e.g., audio/video distribution, senders are well-known Much complexity arises from “any sender” support (transition from RP tree to sender specific tree) – 19 pages for RFC 4607 vs. 150 pages for PIM-SM RFC

Source Specific Multicast (SSM) Deployment problems faced by current multicast solutions Access control enforcement I want to know who I am receiving data from Allocation and collision of multicast addresses (in IPv4) Multicast address is now qualified by sender, i.e., <S1,G>≠<S2,G> SSM defines a new (more limited) multicast service model Hosts must subscribe to <S,G> Directly builds shortest path tree rooted at S The multicast group is defined by the combination S+G Multicast group is in range 232/8 for IPv4 and FF3x::/32 for IPv6 (currently limited to FF3x::/96, which facilitates mapping to MAC addresses), where x is a valid scope identifier

Which Trees are Best? vs Reverse path forwarding routes multicast packets on shortest paths tends to copy packets near the source copying near destination reduces # of “long-distance packets” Best multicast route is a Steiner tree Steiner tree for a vertex subset S is shortest subtree that includes all vertices in S problem is NP-complete, so no efficient algorithm known for finding optimal solution good approximations based on minimum spanning tree

Other Issues with IP Multicast Separate protocol needed to reserve network capacity RSVP protocol (RFC 2205) can be used for this purpose but cannot select route based on required network capacity QoS routing has been studied but never implemented No “private” multicast groups no way to get short-term exclusive use of a multicast address no way to limit subscribers or limit who can send to an address makes it awkward to use for multi-party teleconferencing privacy requires encryption Largely unavailable in public internet Some remaining technical issues for inter-domain extensions no economic benefit to network providers multicast senders benefit as they need not duplicate traffic but ISPs lose money if senders reduce internet access link rate

Exercise Receiver Consider the network to the right that uses PIM as its multicast routing protocol. All links have unit cost. A host in a subnet of router J wants to receive packets sent to multicast address MG. What multicast tree is constructed as a result, and how is it constructed? Rendez-vous Point A B C D E F G H I J K

Excercise Receiver Consider the network to the right that uses PIM as its multicast routing protocol. All links have unit cost. A host in a subnet of router J wants to receive packets sent to multicast address MG. What multicast tree is constructed as a result, and how is it constructed? Router J receives a multicast group report that includes MG. This triggers a JOIN message sent towards the RP for MG, i.e., F. The message is sent on the shortest path to F and triggers the creation of forwarding state for MG, i.e., with a next hop of J at G, a next hop of G at H, and a next hop of H at F. (Are there other possible shortest paths?) Rendez-vous Point A B C D E F G H I J K

Excercise Host S on a subnet connected to router A sends a packet to multicast address MG. How and where is the packet forwarded? What possible tree extension would this trigger? S A B C D E F G H I J K

Excercise Host S on a subnet connected to router A sends a packet to multicast address MG. How and where is the packet forwarded? What possible tree extension would this trigger, and what would be the benefit of that extension? The multicast packet is encapsulated in a unicast packet addressed to F by router A (it knows the ID of the RP for MG). The packet is forwarded on the shortest path to F (A-C-F). Router F decapsulates the packet and sends it on the shortest path tree that was previously created by the JOIN from J S A B C D E F G H I J K

Exercise Host S on a subnet connected to router A sends a packet to multicast address MG. How and where is the packet forwarded? What possible tree extension would this trigger, and what would be the benefit of that extension? The RP (router F) will likely issue a JOIN message destined to S. The message is sent on the shortest path to S and creates forwarding state for MG at the routers it traverses (at C pointing to F, and at A pointing to C). Once this extension is in place, it will allow A to forwards multicast packets natively (no unicast encapsulation), and conversely won’t require any decapsulation operation at F that will continue forwarding the packets natively (towards H). S A B C D E F G H I J K