Internet Engineering Task Force D. Zhou, Ed.
Internet-Draft Hangzhou H3C Tech. Co., Ltd.
Intended status: Informational H. Deng
Expires: April 22, 2011 China Mobile Research Institute
Y. Shi
Hangzhou H3C Tech. Co., Ltd.
H. Liu
Huawei Technologies Co., Ltd.
I. Bhattacharya
Cisco Systems
October 19, 2010
Unnecessary Multicast Flooding Problem Statement
draft-dizhou-pim-umf-problem-statement-01
Abstract
This document describes the unnecessary multicast stream flooding
problem in the link layer switches between multicast source and PIM
First Hop Router (FHR). The IGMP-Snooping Switch will forward
multicast streams to router ports, and the PIM FHR must receive all
multicast streams even if there is no request from receiver. This
often leads to waste of switchs' cache and link bandwidth when the
multicast streams are not actually required. This document details
the problem and defines design goals for a generic mechanism to
restrain the unnecessary multicast stream flooding.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Zhou, et al. Expires April 22, 2011 [Page 1]
Internet-Draft Unnecessary Multicast Flooding October 2010
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhou, et al. Expires April 22, 2011 [Page 2]
Internet-Draft Unnecessary Multicast Flooding October 2010
1. Introduction
The Protocol Independent Multicast (PIM) is now the most popular
multicast routing protocol in the world. The router on the edge of
PIM routing domain is called PIM First Hop Router (FHR). PIM has
four modes: Sparse Mode (SM), Dense Mode (DM), Bidirectional PIM
(Bidir-PIM), Source-Specific Multicast (SSM). DM and Bidir-PIM
suppose that the receivers are always existing. SM and SSM are
designed for multicast streams to be transferred on demand.
The IGMP-Snooping, specified in RFC 4541 [RFC4541], is a link layer
multicast streams forwarding control mechanism. It forwards all
multicast streams to the router ports and selected multicast stream
to membership ports. It also forwards IGMP Membership report
messages to router ports and IGMP Query messages to all ports except
the incoming port.
The PIM-Snooping is another link layer multicast streams forwarding
control mechanism. It forwards the selected multicast streams to the
requested router ports. But it can not run on the path between
multicast source and PIM FHR because there is no PIM Join and PIM
Prune messages.
In many typical deployment scenarios, some link layer switches are
existing between multicast sources and PIM FHR. The receivers may be
only exist between the source and PIM FHR, maybe exist in the network
behind the PIM FHR, maybe even not exist temporarily. But if only
the PIM FHR exists, the multicast streams are always transferred
through these switches to PIM FHR, even if no receivers exist.
These unnecessary multicast streams will lead to waste of the
switches' cache and link bandwidth. And the cache and link bandwidth
are essential for application streams to transfer with less packet
loss, latency, and jitter.
There are some attempts made to solve the problem of unnecessary
multicast streams flooding on switches between the sources and PIM
FHR in various ways. However, those solutions are either scenario-
limited or deployment-limited.
This document provides a detailed description of protocol design
goals for efficient PIM and PIM-Snooping based mechanism to solve
this problem.
Zhou, et al. Expires April 22, 2011 [Page 3]
Internet-Draft Unnecessary Multicast Flooding October 2010
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119 [RFC2119]
With respect to PIM, this document follows the terminology that has
been defined in RFC 4601 [RFC4601].
Zhou, et al. Expires April 22, 2011 [Page 4]
Internet-Draft Unnecessary Multicast Flooding October 2010
3. Problem Statement
Under the existing model, the PIM FHR sends out PIM hello messages,
as well as IGMP query messages if it is an IGMP querier in the
network segment. The IGMP-Snooping switches between the sources and
PIM FHR receive multicast streams from the sources and forward them
to PIM FHR, even there is no request from receivers. If there are
many sources, the multicast streams will flood to all PIM FHRs.
This will bring about some serious problems.
Firstly, the unnecessary multicast streams will seriously consume
link bandwidth .
If there are many sources and PIM FHRs, the bandwidth between the
source and PIM FHR will be seriously wasted. This problem will be
more serious 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.
o Receivers may be only exist between the source and PIM FHR, maybe
exist in the network behind the PIM FHR, maybe even not exist
temporarily.
In the application mentioned above, it is not acceptable to afford
plenty of bandwidth to forward all multicast streams from the
sources.
Secondly, the unnecessary multicast streams will consume outgress
cache of switches.
In any network deployment, the switch between the sources and PIM FHR
forwarding unnecessary multicast streams will also consume the
outgress cache of switch including out-port specified cache and the
cache shared by all ports. The cache is the key resource of switch
to reduce streams' packet loss ratio, latency, and jitter.
Finally, the unnecessary multicast streams forwarding will increase
the power consumption.
In summary, it is desirable to afford a mechanism to prohibit the
switches between the source and PIM FHR from forwarding unnecessary
multicast stream when it is not requested, and drive the switches to
forward multicast stream in time when it is required.
Zhou, et al. Expires April 22, 2011 [Page 5]
Internet-Draft Unnecessary Multicast Flooding October 2010
4. Design Goals
The following are the goals and constraints in designing the
mechanism for switch to restrain unnecessary multicast streams
flooding:
o Switch SHALL forward the requested streams and SHALL NOT forward
unrequired streams.
o Streams SHALL just be terminated at the exact switch.
o If a receiver appears, it MUST receive multicast streams in time.
o Deployment SHALL be flexible. The number and topology of switches
between source and PIM FHR SHALL NOT be limited. The ip address
deployment of multicast sources and receivers SHALL NOT be limited
either. Sources and receivers may be in the same ip address
segment, for example.
o The CPUs of switches SHALL receive no multicast stream data, but
only protocol messages.
Zhou, et al. Expires April 22, 2011 [Page 6]
Internet-Draft Unnecessary Multicast Flooding October 2010
5. Use Cases and Related Work
In order to further clarify the items listed in scope of the proposed
work, this section provides some background on related work and the
use cases envisioned for the proposed work.
5.1. Source sending stream on demand
By adding a central controlling server, the multicast sources may be
controlled to send streams on demand.
Note that once a receiver sends a request, the multicast stream will
flow down toward switch's router ports, even if there is no other
receivers behind the router ports.
5.2. Host simulation of PIM FHR
PIM FHR may be prohibited to send PIM hello messages and IGMP Query
messages toward multicast sources. Instead, it can simulate host to
send IGMP Membership Report and Leave messages if it receives PIM
Join and Prune messages. So the switches between the sources and PIM
FHRs would have no router ports.
But for PIM SM, the PIM FHR does not know at which port to send out
IGMP messages, unless configured some information at the requested
ports by network manager.
On the other hand, the switch will not forward IGMP Membership Report
and Leave messages towards sources. It will only forward IGMP
Membership Report and Leave messages to router ports.
5.3. IGMP Querier simulation of first-hop switch
For the second problem of PIM FHR host simulation, the switch
directly connected to source can simulate IGMP Querier.
But when there are two or more switches simulating IGMP Queriers, the
phenomenon of unnecessary multicast streams flooding still exists.
5.4. Replacing link layer switches with Routers
Replacing link layer switches directly connected to sources with
Routers is not a perfect solution either. 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 many ip address segments and then
complicate network management.
Zhou, et al. Expires April 22, 2011 [Page 7]
Internet-Draft Unnecessary Multicast Flooding October 2010
6. some potential solutions
6.1. solution based on PIM and PIM-Snooping
The key points of it are as follows:
o When the PIM FHR receives a multicast stream, it creates an entry
of (S,G) if the entry did not exist. And it judges whether the
(S,G) entry has out interfaces. If the (S,G) has no out
interface, the PIM router sends out an unicast PIM prune message
towards the multicast source. The upstream neighbor address in
the message is the source address.
o The switch between multicast sources and PIM FHR runs PIM snooping
and IGMP snooping. When it intercepts the unicast PIM prune
message by ip protocol field identification and finds out that the
upstream neighbor address of the message is not in its PIM
neighbor lists, it creates a (S,G) entry with a pruned port and an
upstream port if not created before. The upstream port is found
by looking up the unicast mac table. That (S,G) entry is punched
with a specific sign which means that entry is different from
traditional PIM-Snooping entry. The pruned port SHALL NOT forward
multicast stream and has a lifetime which is 1/3 of that of PIM
FHR's (S,G) entry, then converted to be a downstream port, so that
the multicast stream will arrive at PIM FHR to refresh the (S,G)
entry.
o Looking up IGMP-snooping entry and PIM-snooping entry, if the
switch find there is no need to forward the multicast stream, it
SHALL forward the unicast PIM prune message towards multicast
source.
o When the switch receives an IGMP membership report, it shall
forward the message through its router ports and upstream port.
o When PIM FHR creates an out interface for a (S,G) entry that had
no out interface before, it shall send unicast PIM join message
towards multicast source. The upstream neighbor address of the
message is the source address.
o When the switch receives the unicast PIM join message and finds
out that the upstream neighbor address of the message is not in
its PIM neighbor lists, it will convert the pruned port to be
downstream port. When the (S,G) entry with specific sign has no
pruned ports, it should be deleted in order to save the entry
space.
Zhou, et al. Expires April 22, 2011 [Page 8]
Internet-Draft Unnecessary Multicast Flooding October 2010
o By the information from IGMP-snooping entry and PIM-snooping
entry, the switch can decide whether it shall forward the unicast
PIM join message towards multicast source.
o The role of membership port is prior than that of pruned port, and
the role of pruned port is prior than that of router port or
downstream port.
o If two or more switches or PIM FHRs are connected by one port
directly, or through HUB or normal switch, some query mechanism
shall be implemented.
6.2. solution based on IGMP and IGMP-Snooping
The key points of it are as follows:
o When the PIM FHR receives a multicast stream, it creates an entry
of (S,G) if the entry did not exist. And it judges whether the
(S,G) entry has out interfaces. If the (S,G) has no out
interface, the PIM router sends out an unicast IGMP prune message
towards multicast source.
o The switch between multicast sources and PIM FHR runs IGMP
snooping. When it intercepts the unicast IGMP prune message by ip
protocol field identification, it creates a IGMP-Snooping entry
with a pruned port and an source port. The source port is found
by looking up the unicast mac table. The pruned port has a
lifetime which is 1/3 of the lifetime of PIM FHR's (S,G) entry, so
that the multicast stream will arrive at PIM FHR before its (S,G)
entry dies out.
o By the information from IGMP-snooping entry, the switch can decide
whether it shall forward the unicast IGMP prune message towards
multicast source.
o When the switch receives an IGMP membership report, it shall
forward the message through its router ports and source port.
o When PIM FHR creates an out interface for a (S,G) entry that had
no out interface before, it shall send unicast IGMP graft message
towards multicast source.
o When the switch receives the unicast IGMP graft message, it will
change the pruned port to be router port. When the IGMP-Snooping
entry has only router ports and source ports, it should be deleted
in order to save the entry space.
Zhou, et al. Expires April 22, 2011 [Page 9]
Internet-Draft Unnecessary Multicast Flooding October 2010
o By the information from IGMP-snooping entry, the switch can decide
whether it shall forward the unicast IGMP graft message towards
multicast source.
o The role of membership port is prior than that of pruned port, and
the role of pruned port is prior than that of router port.
o If two or more switches or PIM FHRs are connected by one port
directly, or through HUB or normal switch, some query mechanism
shall be implemented.
The first solution is more simple than the second one because the
PIM-snooping has afforded some essential information and there is no
need to add some new messages. In the first solution the switches
must run PIM-snooping besides IGMP-snooping.
Any advice is welcome.
Zhou, et al. Expires April 22, 2011 [Page 10]
Internet-Draft Unnecessary Multicast Flooding October 2010
7. Security Considerations
Zhou, et al. Expires April 22, 2011 [Page 11]
Internet-Draft Unnecessary Multicast Flooding October 2010
8. Contributors
Zhou, et al. Expires April 22, 2011 [Page 12]
Internet-Draft Unnecessary Multicast Flooding October 2010
9. Acknowledgements
Zhou, et al. Expires April 22, 2011 [Page 13]
Internet-Draft Unnecessary Multicast Flooding October 2010
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Zhou, et al. Expires April 22, 2011 [Page 14]
Internet-Draft Unnecessary Multicast Flooding October 2010
Authors' Addresses
Di Zhou (editor)
Hangzhou H3C Tech. Co., Ltd.
310 Liuhe Road
Hangzhou, Zhejiang
China(310053)
Phone: +86-571-86761327
Email: zhoudi@h3c.com
Hui Deng
China Mobile Research Institute
Unit2,28 Xuanwumenxi Ave,Xuanwu District
Beijing, Beijing
China(100053)
Phone: +86-010-15801696688-3314
Email: denghui@chinamobile.com
Yang Shi
Hangzhou H3C Tech. Co., Ltd.
Beijing R&D Center of H3C, Digital Technology Plaza,
NO.9 Shangdi 9th Street,Haidian District,
Beijing
China(100085)
Phone: +86 010 82775276
Email: young@h3c.com
Hui Liu
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base, Hai-Dian Distinct,
Beijing
China(100085)
Email: Liuhui47967@huawei.com
Zhou, et al. Expires April 22, 2011 [Page 15]
Internet-Draft Unnecessary Multicast Flooding October 2010
Indranil Bhattacharya
Cisco Systems
India(560037)
Email: myselfindranil@gmail.com
Zhou, et al. Expires April 22, 2011 [Page 16]