unnecessary multicast flooding problem statement
DESCRIPTION
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: - PowerPoint PPT PresentationTRANSCRIPT
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