Unnecessary Multicast Flooding Problem Statement

draft-dizhou-pim-umf-problem-statement-01

Application scenarios

Source

Source

Source

switch

FHR （ PIM Router）

switch

MS

….

Phenomena:Even there’s no request behind FHR, all the multicast streams will still flood to FHR

Multicast stream

Other application streams

FHR First hop router running PIM

o FHR running PIM SM/DM needs to receive all multicast streamso Switch running IGMP-Snooping and PIM-Snooping must forward all multicast streams through router ports

Background：

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)

Multicast stream

PIM message

Source

FHRUNICASTPIM Prune

(S,G) with pruned

interface

(S,G) with pruned

interface

IGMP message

UNICASTPIM Prune

(S,G) no out interface

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

IGMP-SNOOPINGPIM-Snooping

IGMP-SNOOPINGPIM-Snooping PIM SM/SSM/DM

Solution profile （ 2）—— based on PIM (FHR) and PIM-Snooping (Switch)

Multicast stream

PIM message

Source

FHRUNICASTPIM Prune

(S,G) with pruned

interface

(S,G) with pruned

interface

IGMP message

UNICASTPIM Prune

(S,G) no out interface

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

Solution profile （ 3）—— based on PIM (FHR) and PIM-Snooping (Switch)

Multicast stream

PIM message

Source

FHR

IGMP message

(S,G) with out interface

(S,G) with downstream

interface

(S,G) with downstream

interface

UNICASTPIM Join

UNICASTPIM 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

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