Unnecessary Multicast Flooding Problem Statement draft-dizhou-pim-umf-problem-statement-01

Application scenarios MS FHR（PIM Router） switch switch Source …. Source Source Multicast stream Other application streams FHR First hop router running PIM Phenomena: Even there’s no request behind FHR, all the multicast streams will still flood to FHR Background： o FHR running PIM SM/DM needs to receive all multicast streams o Switch running IGMP-Snooping and PIM-Snooping must forward all multicast streams through router ports

Problem statement Problem1: link bandwidth between first hop switch and FHR will be seriously consumed It is not acceptable especially in such a type of application: o The sources are much more than receivers. o Each source may be requested simultaneously by some receivers. o Most sources are NOT requested at most time. It is not acceptable to afford plenty of bandwidth to forward all multicast streams from the sources. Problem2: outgress cache of switches will be seriously wasted if multicast streams have bursts o Video multicast stream is usually full of bursts o Outgress cache is the most important resource to reduce streams' packet loss ratio, latency, and jitter. Problem3: unnecessary multicast streams forwarding will increase power consumption

Design Goals 1: Switch SHALL NOT forward unrequired streams persistently 2: Streams SHALL just be terminated at the exact switch 3: If a receiver appears, it MUST receive multicast streams in time 4: Network deployment SHALL be flexible 5: The CPUs of switches SHALL receive no multicast stream data, but only protocol messages

Solution profile（1） ——based on PIM (FHR) and PIM-Snooping (Switch) (S,G) with pruned interface (S,G) with pruned interface (S,G) no out interface Source IGMP-SNOOPING PIM-Snooping UNICAST PIM Prune FHR UNICAST PIM Prune IGMP-SNOOPING PIM-Snooping PIM SM/SSM/DM o PIM FHR receives a multicast stream, creates an entry of (S,G) o If (S,G) has no out interface, FHR sends UNICAST PIM Prune messages towards source. The upstream neighbor address of PIM Prune is the multicast source o If switch finds that the upstream neighbor address is not in its pim neighbor list, it will create an entry of (S,G) with a pruned port to stop forwarding stream Multicast stream PIM message IGMP message

Solution profile（2） ——based on PIM (FHR) and PIM-Snooping (Switch) (S,G) with pruned interface (S,G) with pruned interface (S,G) no out interface Source UNICAST PIM Prune FHR UNICAST PIM Prune o Pruned port’s lifetime = 1/3 of (S,G) entry’s lifetime o After the pruned port’s lifetime expires, stream will refresh the FHR’s (S,G) entry o If FHR’ (S,G) entry has no out interface, it will send UNICAST PIM prune messages again Multicast stream PIM message IGMP message

Solution profile（3） ——based on PIM (FHR) and PIM-Snooping (Switch) (S,G) with downstream interface (S,G) with downstream interface (S,G) with out interface Source UNICAST PIM Join FHR UNICAST PIM Join o If FHR receives PIM Join or IGMP Join, it will send UNICAST PIM Join messages towards source o Switch’s pruned port will be converted to be downstream port to forward stream Multicast stream PIM message IGMP message

Comments about problem(1) Comment 1: Why not let PIM FHR simulate host sending IGMP Join/Leave message？ —— by LiuHui Limitation: Switch will not forward IGMP Membership Report and Leave messages towards sources. So can not support multiple-level connection of switch. And for PIM SM, the PIM FHR does not know at which port to send IGMP messages. Comment 2: How about statically configuring router ports toward sources ？ —— by LiuHui Limitation: Not flexible and when multiple multicast streams arrive at the same switch, the phenomenon of unnecessary multicast streams flooding still exists for all the stream will be forwarded to those statically configured router ports. Comment 3: How about sending a unicast IGMP Join/Leave messages instead of multicast ones ？ —— by LiuHui Limitation: Unicast Join/leave messages are possibly be treated by switch in the same manner as multicast ones and might not reach source ports.

Comments about problem(2) Comment 4: There is another choice that IGMP reports is permitted be forwarded to route ports by administration control？ —— by LiuHui Limitation: Is only possible for IGMPv3. In IGMPv2 it is prohibited to support host suppression. Comment 5: Why not let first-hop switch simulate IGMP Querier？ —— by LiuHui Limitation: When there are two or more switches simulating IGMP Queriers, the phenomenon of unnecessary multicast streams flooding still exists if multiple streams arrive at the same switch. Comment 3: Why not replace link layer switches with Routers？ —— by DengHui, ShiYang Limitation: Not perfect yet. It will limit the flexibility of networking, and will further lead to waste of ip address and many ip address segments seriously if there are many sources. It will also bring about complicate network management.

Comments about solution(1) Comment 1: This special pim snoop entry needs to be installed in the hash/tcam region of the switch. Otherwise all data will have to hit the cpu of the switch. So better if switch's hw-multicast-entries can be changed based on the pim snooping information. Absence of a snooping entry means forward the data to all interfaces in the same vlan. Presence of a pruned interface in the snooping entry means forward data to all interfaces in that vlan excluding the pruned interface. —— by Indranil Bhattacharya Answer: Multicast stream shall be forwarded to membership ports, downstream ports, but not pruned ports and other ports. But the role of pruned port is needed. Comment 2: Only if connected to a switch can FHR sends unicast PIM message. Otherwise basic pim protocol will be affected. —— by Indranil Bhattacharya Answer: FHR only send unicast PIM message when the （S,G）entry has NULL RPF neighbor.

Comments about solution(2) Comment 3: There must be a way to refresh the pim snooping entry in the switch. This needs to be done by pim j/p message from FHR. Without a refresh mechanism for the entry in the switch there is a problem. After receiving the first data packet FHR send PIM prune. Then the entry expires and switch forwards data again but FHR does not send PIM prune because it already has (S,G) with  NULL OIF —— by Indranil Bhattacharya Answer: Once FHR find the stream it can send the PIM message. But the message shall be rate-limited. Comment 4: This  should not affect the FHR's capability of sending NULL register —— by Indranil Bhattacharya Answer: FHR can send Null-Register Message, and RP will send PIM Join. Comment 5: To whom does the switch forward PIM message? It is connected to source —— by Indranil Bhattacharya Answer: The PIM message is UNICAST message, so the switch can forward it by MAC entry. Switch can forward the message even it is connected to source for the message is not many.

Comments about solution(3) Comment 6: This solution will not work for BiDir because Bidir does not create (S,G) entry. —— by Indranil Bhattacharya Answer: There is no need for bidir and dm because they are designed based on the thought that receivers always exist there. Comment 7: I think we can still support DM as it creates (S,G) entry. —— by Indranil Bhattacharya Answer: Accepted.

Your comments are welcome Whether could it be a work item? Thanks