idnits 2.17.1 draft-dizhou-pim-umf-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2010) is 4909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Zhou, Ed. 3 Internet-Draft Hangzhou H3C Tech. Co., Ltd. 4 Intended status: Informational H. Deng 5 Expires: April 22, 2011 China Mobile Research Institute 6 Y. Shi 7 Hangzhou H3C Tech. Co., Ltd. 8 H. Liu 9 Huawei Technologies Co., Ltd. 10 I. Bhattacharya 11 Cisco Systems 12 October 19, 2010 14 Unnecessary Multicast Flooding Problem Statement 15 draft-dizhou-pim-umf-problem-statement-01 17 Abstract 19 This document describes the unnecessary multicast stream flooding 20 problem in the link layer switches between multicast source and PIM 21 First Hop Router (FHR). The IGMP-Snooping Switch will forward 22 multicast streams to router ports, and the PIM FHR must receive all 23 multicast streams even if there is no request from receiver. This 24 often leads to waste of switchs' cache and link bandwidth when the 25 multicast streams are not actually required. This document details 26 the problem and defines design goals for a generic mechanism to 27 restrain the unnecessary multicast stream flooding. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 22, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 1. Introduction 63 The Protocol Independent Multicast (PIM) is now the most popular 64 multicast routing protocol in the world. The router on the edge of 65 PIM routing domain is called PIM First Hop Router (FHR). PIM has 66 four modes: Sparse Mode (SM), Dense Mode (DM), Bidirectional PIM 67 (Bidir-PIM), Source-Specific Multicast (SSM). DM and Bidir-PIM 68 suppose that the receivers are always existing. SM and SSM are 69 designed for multicast streams to be transferred on demand. 71 The IGMP-Snooping, specified in RFC 4541 [RFC4541], is a link layer 72 multicast streams forwarding control mechanism. It forwards all 73 multicast streams to the router ports and selected multicast stream 74 to membership ports. It also forwards IGMP Membership report 75 messages to router ports and IGMP Query messages to all ports except 76 the incoming port. 78 The PIM-Snooping is another link layer multicast streams forwarding 79 control mechanism. It forwards the selected multicast streams to the 80 requested router ports. But it can not run on the path between 81 multicast source and PIM FHR because there is no PIM Join and PIM 82 Prune messages. 84 In many typical deployment scenarios, some link layer switches are 85 existing between multicast sources and PIM FHR. The receivers may be 86 only exist between the source and PIM FHR, maybe exist in the network 87 behind the PIM FHR, maybe even not exist temporarily. But if only 88 the PIM FHR exists, the multicast streams are always transferred 89 through these switches to PIM FHR, even if no receivers exist. 91 These unnecessary multicast streams will lead to waste of the 92 switches' cache and link bandwidth. And the cache and link bandwidth 93 are essential for application streams to transfer with less packet 94 loss, latency, and jitter. 96 There are some attempts made to solve the problem of unnecessary 97 multicast streams flooding on switches between the sources and PIM 98 FHR in various ways. However, those solutions are either scenario- 99 limited or deployment-limited. 101 This document provides a detailed description of protocol design 102 goals for efficient PIM and PIM-Snooping based mechanism to solve 103 this problem. 105 2. Terminology 107 In this document, several words are used to signify the requirements 108 of the specification. These words are often capitalized. The key 109 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 110 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 111 are to be interpreted as described in RFC 2119 [RFC2119] 113 With respect to PIM, this document follows the terminology that has 114 been defined in RFC 4601 [RFC4601]. 116 3. Problem Statement 118 Under the existing model, the PIM FHR sends out PIM hello messages, 119 as well as IGMP query messages if it is an IGMP querier in the 120 network segment. The IGMP-Snooping switches between the sources and 121 PIM FHR receive multicast streams from the sources and forward them 122 to PIM FHR, even there is no request from receivers. If there are 123 many sources, the multicast streams will flood to all PIM FHRs. 125 This will bring about some serious problems. 127 Firstly, the unnecessary multicast streams will seriously consume 128 link bandwidth . 130 If there are many sources and PIM FHRs, the bandwidth between the 131 source and PIM FHR will be seriously wasted. This problem will be 132 more serious especially in such a type of application: 134 o The sources are much more than receivers. 136 o Each source may be requested simultaneously by some receivers. 138 o Most sources are NOT requested at most time. 140 o Receivers may be only exist between the source and PIM FHR, maybe 141 exist in the network behind the PIM FHR, maybe even not exist 142 temporarily. 144 In the application mentioned above, it is not acceptable to afford 145 plenty of bandwidth to forward all multicast streams from the 146 sources. 148 Secondly, the unnecessary multicast streams will consume outgress 149 cache of switches. 151 In any network deployment, the switch between the sources and PIM FHR 152 forwarding unnecessary multicast streams will also consume the 153 outgress cache of switch including out-port specified cache and the 154 cache shared by all ports. The cache is the key resource of switch 155 to reduce streams' packet loss ratio, latency, and jitter. 157 Finally, the unnecessary multicast streams forwarding will increase 158 the power consumption. 160 In summary, it is desirable to afford a mechanism to prohibit the 161 switches between the source and PIM FHR from forwarding unnecessary 162 multicast stream when it is not requested, and drive the switches to 163 forward multicast stream in time when it is required. 165 4. Design Goals 167 The following are the goals and constraints in designing the 168 mechanism for switch to restrain unnecessary multicast streams 169 flooding: 171 o Switch SHALL forward the requested streams and SHALL NOT forward 172 unrequired streams. 174 o Streams SHALL just be terminated at the exact switch. 176 o If a receiver appears, it MUST receive multicast streams in time. 178 o Deployment SHALL be flexible. The number and topology of switches 179 between source and PIM FHR SHALL NOT be limited. The ip address 180 deployment of multicast sources and receivers SHALL NOT be limited 181 either. Sources and receivers may be in the same ip address 182 segment, for example. 184 o The CPUs of switches SHALL receive no multicast stream data, but 185 only protocol messages. 187 5. Use Cases and Related Work 189 In order to further clarify the items listed in scope of the proposed 190 work, this section provides some background on related work and the 191 use cases envisioned for the proposed work. 193 5.1. Source sending stream on demand 195 By adding a central controlling server, the multicast sources may be 196 controlled to send streams on demand. 198 Note that once a receiver sends a request, the multicast stream will 199 flow down toward switch's router ports, even if there is no other 200 receivers behind the router ports. 202 5.2. Host simulation of PIM FHR 204 PIM FHR may be prohibited to send PIM hello messages and IGMP Query 205 messages toward multicast sources. Instead, it can simulate host to 206 send IGMP Membership Report and Leave messages if it receives PIM 207 Join and Prune messages. So the switches between the sources and PIM 208 FHRs would have no router ports. 210 But for PIM SM, the PIM FHR does not know at which port to send out 211 IGMP messages, unless configured some information at the requested 212 ports by network manager. 214 On the other hand, the switch will not forward IGMP Membership Report 215 and Leave messages towards sources. It will only forward IGMP 216 Membership Report and Leave messages to router ports. 218 5.3. IGMP Querier simulation of first-hop switch 220 For the second problem of PIM FHR host simulation, the switch 221 directly connected to source can simulate IGMP Querier. 223 But when there are two or more switches simulating IGMP Queriers, the 224 phenomenon of unnecessary multicast streams flooding still exists. 226 5.4. Replacing link layer switches with Routers 228 Replacing link layer switches directly connected to sources with 229 Routers is not a perfect solution either. It will limit the 230 flexibility of networking, and will further lead to waste of ip 231 address and many ip address segments seriously if there are many 232 sources. It will also bring about many ip address segments and then 233 complicate network management. 235 6. some potential solutions 237 6.1. solution based on PIM and PIM-Snooping 239 The key points of it are as follows: 241 o When the PIM FHR receives a multicast stream, it creates an entry 242 of (S,G) if the entry did not exist. And it judges whether the 243 (S,G) entry has out interfaces. If the (S,G) has no out 244 interface, the PIM router sends out an unicast PIM prune message 245 towards the multicast source. The upstream neighbor address in 246 the message is the source address. 248 o The switch between multicast sources and PIM FHR runs PIM snooping 249 and IGMP snooping. When it intercepts the unicast PIM prune 250 message by ip protocol field identification and finds out that the 251 upstream neighbor address of the message is not in its PIM 252 neighbor lists, it creates a (S,G) entry with a pruned port and an 253 upstream port if not created before. The upstream port is found 254 by looking up the unicast mac table. That (S,G) entry is punched 255 with a specific sign which means that entry is different from 256 traditional PIM-Snooping entry. The pruned port SHALL NOT forward 257 multicast stream and has a lifetime which is 1/3 of that of PIM 258 FHR's (S,G) entry, then converted to be a downstream port, so that 259 the multicast stream will arrive at PIM FHR to refresh the (S,G) 260 entry. 262 o Looking up IGMP-snooping entry and PIM-snooping entry, if the 263 switch find there is no need to forward the multicast stream, it 264 SHALL forward the unicast PIM prune message towards multicast 265 source. 267 o When the switch receives an IGMP membership report, it shall 268 forward the message through its router ports and upstream port. 270 o When PIM FHR creates an out interface for a (S,G) entry that had 271 no out interface before, it shall send unicast PIM join message 272 towards multicast source. The upstream neighbor address of the 273 message is the source address. 275 o When the switch receives the unicast PIM join message and finds 276 out that the upstream neighbor address of the message is not in 277 its PIM neighbor lists, it will convert the pruned port to be 278 downstream port. When the (S,G) entry with specific sign has no 279 pruned ports, it should be deleted in order to save the entry 280 space. 282 o By the information from IGMP-snooping entry and PIM-snooping 283 entry, the switch can decide whether it shall forward the unicast 284 PIM join message towards multicast source. 286 o The role of membership port is prior than that of pruned port, and 287 the role of pruned port is prior than that of router port or 288 downstream port. 290 o If two or more switches or PIM FHRs are connected by one port 291 directly, or through HUB or normal switch, some query mechanism 292 shall be implemented. 294 6.2. solution based on IGMP and IGMP-Snooping 296 The key points of it are as follows: 298 o When the PIM FHR receives a multicast stream, it creates an entry 299 of (S,G) if the entry did not exist. And it judges whether the 300 (S,G) entry has out interfaces. If the (S,G) has no out 301 interface, the PIM router sends out an unicast IGMP prune message 302 towards multicast source. 304 o The switch between multicast sources and PIM FHR runs IGMP 305 snooping. When it intercepts the unicast IGMP prune message by ip 306 protocol field identification, it creates a IGMP-Snooping entry 307 with a pruned port and an source port. The source port is found 308 by looking up the unicast mac table. The pruned port has a 309 lifetime which is 1/3 of the lifetime of PIM FHR's (S,G) entry, so 310 that the multicast stream will arrive at PIM FHR before its (S,G) 311 entry dies out. 313 o By the information from IGMP-snooping entry, the switch can decide 314 whether it shall forward the unicast IGMP prune message towards 315 multicast source. 317 o When the switch receives an IGMP membership report, it shall 318 forward the message through its router ports and source port. 320 o When PIM FHR creates an out interface for a (S,G) entry that had 321 no out interface before, it shall send unicast IGMP graft message 322 towards multicast source. 324 o When the switch receives the unicast IGMP graft message, it will 325 change the pruned port to be router port. When the IGMP-Snooping 326 entry has only router ports and source ports, it should be deleted 327 in order to save the entry space. 329 o By the information from IGMP-snooping entry, the switch can decide 330 whether it shall forward the unicast IGMP graft message towards 331 multicast source. 333 o The role of membership port is prior than that of pruned port, and 334 the role of pruned port is prior than that of router port. 336 o If two or more switches or PIM FHRs are connected by one port 337 directly, or through HUB or normal switch, some query mechanism 338 shall be implemented. 340 The first solution is more simple than the second one because the 341 PIM-snooping has afforded some essential information and there is no 342 need to add some new messages. In the first solution the switches 343 must run PIM-snooping besides IGMP-snooping. 345 Any advice is welcome. 347 7. Security Considerations 348 8. Contributors 349 9. Acknowledgements 350 10. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 356 "Considerations for Internet Group Management Protocol 357 (IGMP) and Multicast Listener Discovery (MLD) Snooping 358 Switches", RFC 4541, May 2006. 360 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 361 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 362 Protocol Specification (Revised)", RFC 4601, August 2006. 364 Authors' Addresses 366 Di Zhou (editor) 367 Hangzhou H3C Tech. Co., Ltd. 368 310 Liuhe Road 369 Hangzhou, Zhejiang 370 China(310053) 372 Phone: +86-571-86761327 373 Email: zhoudi@h3c.com 375 Hui Deng 376 China Mobile Research Institute 377 Unit2,28 Xuanwumenxi Ave,Xuanwu District 378 Beijing, Beijing 379 China(100053) 381 Phone: +86-010-15801696688-3314 382 Email: denghui@chinamobile.com 384 Yang Shi 385 Hangzhou H3C Tech. Co., Ltd. 386 Beijing R&D Center of H3C, Digital Technology Plaza, 387 NO.9 Shangdi 9th Street,Haidian District, 388 Beijing 389 China(100085) 391 Phone: +86 010 82775276 392 Email: young@h3c.com 394 Hui Liu 395 Huawei Technologies Co., Ltd. 396 Huawei Bld., No.3 Xinxi Rd. 397 Shang-Di Information Industry Base, Hai-Dian Distinct, 398 Beijing 399 China(100085) 401 Email: Liuhui47967@huawei.com 402 Indranil Bhattacharya 403 Cisco Systems 404 India(560037) 406 Email: myselfindranil@gmail.com