Internet Engineering Task Force D. Zhou, Ed. Internet-Draft Hangzhou H3C Tech. Co., Ltd. Intended status: Informational H. Deng Expires: January 2, 2011 China Mobile Research Institute Y. Shi Hangzhou H3C Tech. Co., Ltd. H. Liu Huawei Technologies Co., Ltd. 17 August 2010 Unnecessary Multicast Flooding Problem Statement draft-dizhou-pim-umf-problem-statement-00 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 January 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Zhou, et al. Expires January 2, 2011 [Page 1] Internet-Draft Unnecessary Multicast Flooding July 2010 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 January 2, 2011 [Page 2] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 3] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 4] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 5] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 6] Internet-Draft Unnecessary Multicast Flooding July 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. Note that this solution will lead to waste of ip address seriously if there are many sources. It will also bring about so many ip address segments and then complicated network management. After all, this solution will put some multicast sources and receivers in some different ip address segment. Zhou, et al. Expires January 2, 2011 [Page 7] Internet-Draft Unnecessary Multicast Flooding July 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 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. 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 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 and PIM-snooping entry, the switch can decide whether 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 change 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. 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. Zhou, et al. Expires January 2, 2011 [Page 8] Internet-Draft Unnecessary Multicast Flooding July 2010 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. 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. 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. Zhou, et al. Expires January 2, 2011 [Page 9] Internet-Draft Unnecessary Multicast Flooding July 2010 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 January 2, 2011 [Page 10] Internet-Draft Unnecessary Multicast Flooding July 2010 7. Security Considerations Zhou, et al. Expires January 2, 2011 [Page 11] Internet-Draft Unnecessary Multicast Flooding July 2010 8. Contributors Zhou, et al. Expires January 2, 2011 [Page 12] Internet-Draft Unnecessary Multicast Flooding July 2010 9. Acknowledgements Zhou, et al. Expires January 2, 2011 [Page 13] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 14] Internet-Draft Unnecessary Multicast Flooding July 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 January 2, 2011 [Page 15]