idnits 2.17.1 draft-ietf-pim-explicit-tracking-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2015) is 3097 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Experimental November 1, 2015 5 Expires: May 4, 2016 7 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 8 Routers 9 draft-ietf-pim-explicit-tracking-13 11 Abstract 13 This document describes the IGMP/MLD-based explicit membership 14 tracking function for multicast routers and IGMP/MLD proxy devices 15 supporting IGMPv3/MLDv2. The explicit membership tracking function 16 contributes to saving network resources and shortening leave latency. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 4, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Motivation and Experimentation . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Membership State Information . . . . . . . . . . . . . . . . 4 56 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 5 57 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 58 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7 59 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8 60 8. Compatibility with Older Version Protocols . . . . . . . . . 9 61 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 13.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 73 and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for 74 IPv6 are the standard protocols used by member hosts and multicast 75 routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and 76 LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. 78 When a host starts/finishes listening to particular multicast 79 channels, it sends IGMP/MLD State-Change Report messages specifying 80 the corresponding channel information as the join/leave request to 81 its upstream router (i.e., an adjacent multicast router or IGMP/MLD 82 proxy device [8]). The "unsolicited" report messages are sent only 83 when the host joins/leaves the channels. Since IGMP/MLD are non- 84 reliable protocols, unsolicited report messages may be lost or may 85 not reach upstream routers. To alleviate this problem, unsolicited 86 report messages are retransmitted a number of times according to the 87 value of the [Robustness Variable] defined in [2][3]. 89 In addition, a querier router periodically sends IGMP/MLD General 90 Query messages every General Query timer interval (i.e. [Query 91 Interval] value defined in [2][3]). Upon receiving the query 92 messages, the member hosts reply with "solicited" report messages. 93 Routers then keep their membership state information up to date. 94 However, this approach still does not guarantee that the membership 95 state is always perfectly synchronized. To minimize the possibility 96 of having outdated membership information, routers may shorten the 97 periodic General Query timer interval. Unfortunately, this increases 98 the number of transmitted solicited report messages and induces 99 network congestion. And the greater the amount of network 100 congestion, the greater the potential for IGMP/MLD report messages 101 being lost and the membership state information being outdated in the 102 router. 104 IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can 105 provide the ability to keep track of the downstream (adjacent) 106 multicast membership state in multicast routers, yet the 107 specifications are not clearly given. This document describes the 108 "IGMP/MLD-based explicit member tracking function" for multicast 109 routers and a way for routers to implement the function. By enabling 110 this explicit tracking function, routers can keep track of the 111 downstream multicast membership state. The explicit tracking 112 function contributes to saving network resources and shortening leave 113 latency. 115 The explicit tracking function does not change message formats used 116 by IGMPv3 [2], MLDv2 [3], and their lightweight version protocols 117 [4]; nor does it change a multicast data sender's and receiver's 118 behavior. 120 1.1. Motivation and Experimentation 122 This document specifies an experimental extension to IGMPv3/MLDv2. 123 It makes some fundamental changes to how IGMPv3/MLDv2 works in that 124 membership state does not require periodic updates, and it partly 125 turns IGMPv3/MLDv2 into a hard-state protocol. Also, a mechanism 126 called "specific query suppression" with a robust link state is a new 127 concept. It does not make the router send any specific query 128 message(s) and immediately leave the group or sources when the sole 129 member has left according to its membership state information. 131 The explicit tracking function does not change the reliability of the 132 message transmission. The list of tracked member hosts may be 133 outdated in the router because of host departure from the network 134 without sending State-Change Report messages or loss of such messages 135 due to network congestion. This document describes the risk of 136 having wrong membership state and guides for setting up appropriate 137 values or mechanisms used with the explicit tracking function in 138 routers. 140 The explicit tracking function potentially requires a large amount of 141 memory so that routers keep all membership states. Particularly when 142 a router needs to maintain a large number of member hosts, this 143 resource requirement might be sensitive. As the security 144 consideration, this document describes that operators may decide to 145 disable this function when their routers have insufficient memory 146 resources, despite the benefits. 148 It is likely that experiences from early implementations and 149 deployments will lead to at least minor changes in the protocol. Any 150 experiments using this protocol extension are encouraged. Reports 151 from such experiments planned with pre-specified objectives and 152 scenarios are particularly encouraged. Results from such 153 experiments, documenting the following, are of particular importance: 155 o Operation in networks that contain both routers implementing this 156 extension, and routers implementing only [2][3][4], in particular 157 are there any unexpected interactions that can break the network? 159 o Operation in networks that contain both routers implementing this 160 extension, and routers implementing older versions of IGMP or MLD, 161 IGMPv1 [5], IGMPv2 [6], or MLDv1 [7]. 163 o Operation in networks with dynamic topology changes. 165 o Operation in networks with invalid or outdated membership states. 167 o Network performance, including leave latency and packet delivery 168 results. 170 o Resource requirements observed from running the protocol, 171 including processing, storage, and bandwidth. 173 o Any other implementation issues. 175 Once there is some deployment experience, making this a Standards 176 Track protocol should be considered. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [1]. 184 3. Membership State Information 186 A router enabling the explicit tracking function maintains the 187 "membership state information". When a multicast router receives a 188 Current-State or State-Change Report message, it creates or modifies 189 this membership state information to maintain the membership state up 190 to date. 192 The membership state information consists of the following 193 information: 195 (S, G, number of receivers, (receiver records)) 197 where "S" denotes source address, "G" denotes group or multicast 198 address, and each receiver record is of the form: 200 (IGMP/MLD membership/listener report sender's address) 202 In the state information, each S and G indicates a single IPv4/IPv6 203 address. S is set to "All sources" for Any-Source Multicast (ASM) 204 communication (i.e., (*,G) join reception). In order to simplify the 205 implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of 206 (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G) 207 join/leave request with EXCLUDE filter mode from the downstream 208 hosts, the router translates the request to a (*,G) join state/leave 209 request and records the state and the receivers' addresses in the 210 maintained membership state information. 212 The membership state information must be identified properly even 213 though a receiver (i.e., IGMP/MLD Report sender) sends the identical 214 report messages multiple times. And the maintained membership state 215 information will be flushed when the router reboots or restarts the 216 multicast routing processes. 218 4. Specific Query Suppression 220 In accordance with [2] and [3], when a router receives the State- 221 Change Report and needs to confirm whether any hosts are still 222 interested in a channel or not, the router sends the corresponding 223 Group-Specific or Group-and-Source Specific Query messages as defined 224 in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent 225 by actions defined in these sections need to be transmitted [Last 226 Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) 227 times, once every [Last Member Query Interval] (LMQI) or [Last 228 Listener Query Interval] (LLQI), in order to confirm the sole member. 229 (The default values for LMQI/LLQI defined in [2][3] are 1 second. 230 The default values for LMQC/LLQC are the [Robustness Variable] value 231 whose default value is 2.) All member hosts joining the identical 232 channel then reply with their own states after acquiring these query 233 messages. However, transmitting a large number of IGMP/MLD Report 234 messages consumes network resources, and this may pose a particular 235 problem especially when many hosts joining the identical channel send 236 these reports simultaneously. 238 The explicit tracking function provides a mechanism called "specific 239 query suppression". With the specific query suppression, regardless 240 of the LMQC/LLQC values, if the router receives one or more replies 241 from the downstream member(s), it SHOULD stop (i.e., cancel) 242 retransmitting the specific query message(s) for the specified source 243 and/or group. It reduces the number of Group-Specific or Group-and- 244 Source Specific Query messages transmitted from a router, and in turn 245 reduces the number of Current-State Report messages transmitted from 246 member hosts. This contributes to saving network resources. 248 The specific query suppression MAY define an option called "robust 249 link state". If an operator is confident that the link is stable and 250 robust enough and thus the tracked membership state information is 251 perfectly synchronized with the current (actual) member hosts, s/he 252 can enable the specific query suppression with a robust link state. 253 A router enabling the specific query suppression with a robust link 254 state does not send any specific query message(s) and immediately 255 leave the group or sources when the sole member has left according to 256 its membership state information. The specific query suppression 257 with a robust link state hence does not rely on LMQC/LLQC and LMQI/ 258 LLQI values. This contributes to shortening leave latency described 259 in Section 5. However, this behavior requires that the router 260 perfectly tracks all member hosts. (See a risk of wrong membership 261 expectation described in Section 6.) 263 Note that the default behavior of the router that supports the 264 explicit tracking function SHOULD disable this specific query 265 suppression, in order to avoid the risk caused by the wrong 266 membership expectation or by the case in which multiple multicast 267 routers exist on a LAN and the querier router is not the forwarder 268 router. The former case is described in Section 6. For the latter 269 case, when the querier suppresses the specific query message 270 transmission, and expects that the State-Change Report sender is not 271 the sole member of the channel, it does not send the specific query. 272 Then the routers (including the forwarder) on the same LAN do not 273 receive a Current-State Report message from the corresponding member 274 hosts. The forwarder in this case may prune the routing path, 275 although there are other member hosts subscribing to the channel on 276 the LAN. 278 5. Shortening Leave Latency 280 A router enabling the explicit tracking function can shorten leave 281 latencies by tuning the following values; [Last Member Query Count] 282 (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query 283 Interval] (LMQI), [Last Listener Query Interval] (LLQI), and 284 [Robustness Variable] values. 286 The [Last Member Query Interval] (LMQI) and [Last Listener Query 287 Interval] (LLQI) values defined in the standard specifications [2][3] 288 specify the maximum time allowed for a member host to send a 289 responding Report. The [Last Member Query Count] (LMQC) and [Last 290 Listener Query Count] (LLQC) are the number of Group-Specific Queries 291 or Group-and-Source Specific Queries sent before the router assumes 292 there are no local members. The [Last Member Query Time] (LMQT) and 293 [Last Listener Query Time] (LLQT) values are the total time the 294 router should wait for a report after the Querier has sent the first 295 query. 297 The default values for LMQI/LLQI defined in [2][3] are 1 second, yet, 298 for a router enabling the explicit tracking function, the LMQI/LLQI 299 may be set to 1 second or shorter. As well, the default values for 300 LMQC/LLQC are the [Robustness Variable] value whose default value is 301 2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/ 302 LLQC values give shorter LMQT/LLQT, which shorten the leave 303 latencies. 305 Furthermore, if operators are confident that their link is fairly 306 robust (e.g., the [Robustness Variable] value is appropriately 307 configured so that the chances of unsolicited messages being lost are 308 sufficiently low), and if the querier router always acts as the 309 forwarder router for all multicast channels in the LAN, they will set 310 smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT) 311 with the specific query suppression, or enable the specific query 312 suppression with a robust link state (Section 4) for their routers. 314 Note that setting smaller LMQC/LLQC and shorter LMQI/LLQI values or 315 adopting the specific query suppression with a robust link state 316 poses the risk of wrong membership state described in Section 6. 317 Operators setting these values or enabling that mechanism must 318 recognize this tradeoff. 320 6. Risk of Wrong Membership State 322 There are possibilities that a router's membership expectation is 323 inconsistent due to an outdated membership state. For example, (1) a 324 router expects that more than one corresponding member host exists on 325 its LAN, but in fact no member host exists for that multicast 326 channel, or (2) a router expects that no corresponding member host 327 exists on its LAN, but in fact one or more than one member host 328 exists for that multicast channel. 330 The first case may occur in an environment where the sole member host 331 departs the network without sending a State-Change Report message. 332 The router later detects that there is no member host for the 333 corresponding channels when it does not receive a Current-State 334 Report within the timeout of the response for the periodic General 335 Query (and then the group or source timers are expired). However, 336 this situation prolongs leave latency and wastes network resources 337 since the router forwards unneeded traffic for a while. 339 The second case occurs when a router sends a specific query but does 340 not receive a Current-State Report from a downstream host within an 341 LMQT or LLQT period. It recognizes that no member host exists on the 342 LAN and might prune the routing path. The router reestablishes the 343 routing path when it receives the solicited report message for the 344 channels. However, the downstream hosts may loose the data packets 345 until the routing path is reestablished and the data forwarding is 346 restarted. 348 If operators do not believe that their link is fairly robust or that 349 they can configure the [Robustness Variable] value appropriately, 350 they may configure the LMQC/LLQC value to 2 (the default value of the 351 [Robustness Variable] value) or bigger value for their routers. In 352 this case, the routers would enable the explicit tracking function 353 but may want to disable the specific query suppression specified in 354 Section 4. Such configurations will not contribute to saving network 355 resources, but reduce the risk of the incorrect membership 356 expectation. 358 7. All-Zero and Unspecified Source Addresses 360 The IGMPv3 specification [2] mentions that an IGMPv3 report is 361 usually sent with a valid IP source address, yet it permits a host to 362 use the 0.0.0.0 source address (since the host has not yet acquired 363 an IP address), and routers must accept a report with this source 364 address. 366 When a router enabling the explicit tracking function receives IGMP 367 report messages with an all-zero source address, it deals with the 368 IGMP report messages correctly as defined in [2] and continuously 369 keeps track of the membership state. However, the router SHOULD NOT 370 maintain the host specifying all-zero source address in its 371 membership state information. The router will maintain its 372 membership state information by checking Current-State reports as 373 ordinary routers do. 375 On the other hand, the MLDv2 specification [3] mentions that routers 376 silently discard a message that is sent with an invalid link-local 377 address or sent with the unspecified address (::), without taking any 378 action, because of security considerations. According to this 379 specification, whether the explicit tracking function is used or not, 380 a router does not deal with a member hosts sending an MLD report 381 message with the unspecified source address. 383 8. Compatibility with Older Version Protocols 385 The explicit tracking function does not work with older versions of 386 IGMP or MLD, IGMPv1 [5], IGMPv2 [6], or MLDv1 [7], because a member 387 host using these protocols enables "membership report suppression" by 388 which the host will cancel sending pending membership reports if a 389 similar report is observed from another member on the network. 391 To preserve compatibility with older versions of IGMP/MLD, routers 392 supporting IGMPv3/MLDv2 enable the host compatibility mode defined in 393 [2][3]. The host compatibility mode of an interface changes the 394 operational protocol version on the LAN whenever an older version 395 query (than the current compatibility mode) is heard or when certain 396 timer conditions occur. The routers can hence support downstream 397 hosts that are not upgraded to the latest versions and run membership 398 report suppression. 400 Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling 401 the explicit tracking function changes its compatibility mode to the 402 older versions, the router SHOULD disable the explicit tracking 403 function while it acts as the older version router. 405 9. Interoperability 407 There might be various ways to implement the explicit tracking 408 function. Some existing implementations may not implement the 409 mechanisms such as specific query suppression described in this 410 document. Yet, the explicit tracking function does not change on- 411 wire behavior, and the function or mechanisms described in this 412 document do not break the interoperability between the existing 413 implementations and the implementation based on this specification. 415 On the other hand, for the future implementation for the explicit 416 tracking function, since this document specifies the minimum but 417 effective sets of the explicit tracking function, it is RECOMMENDED 418 to refer and follow this specification as the standard implementation 419 for that function. 421 10. IANA Considerations 423 This document has no actions for IANA. 425 11. Security Considerations 427 The explicit tracking function potentially requires a large amount of 428 memory so that routers keep all membership states. It gives some 429 impact in the cases where (1) a router attaches to a link or an IGMP/ 430 MLD proxy device [8] that has a large number of member hosts, and a 431 router has insufficient memory resources to maintain a large number 432 of member hosts, or (2) a malicious host sends a large number of 433 invalid IGMP/MLD State-Change Report messages without any intent to 434 join the specified channels. 436 For the first case, operators may disable the explicit tracking 437 function, despite the benefits mentioned above. For the second case, 438 some serious threats may be induced. For instance; 440 1. Transmitting a large number of invalid IGMP/MLD report messages 441 consumes network resources. 443 2. Keeping a large number of invalid membership states on a router 444 consumes the router's memory resources. 446 3. Dealing with a large number of invalid membership states on a 447 router consumes the router's CPU resources. 449 In order to mitigate such threats, a router enabling the explicit 450 tracking function may limit a total amount of membership information 451 the router can store, or may rate-limit State-Change Report messages 452 per host. When the router enables rate-limiting per host, the router 453 MAY ignore the received State-Change Report messages to minimize the 454 processing overhead or prevent DoS attacks. The rate limit is left 455 to the router's implementation. 457 12. Acknowledgements 459 Luis M. Contreras, Toerless Eckert, Adrian Farrel, Sergio 460 Figueiredo, Bharat Joshi, Nicolai Leymann, Magnus Nystrom, Alvaro 461 Retana, Stig Venaas, and others provided many constructive and 462 insightful comments. 464 13. References 466 13.1. Normative References 468 [1] Bradner, S., "Key words for use in RFCs to indicate 469 requirement levels", RFC 2119, March 1997. 471 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 472 Thyagarajan, "Internet Group Management Protocol, Version 473 3", RFC 3376, October 2002. 475 [3] Vida, R. and L. Costa, "Multicast Listener Discovery 476 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 478 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 479 Group Management Protocol Version 3 (IGMPv3) and Multicast 480 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 481 February 2010. 483 13.2. Informative References 485 [5] Deering, S., "Host Extensions for IP Multicasting", 486 RFC 1112, August 1989. 488 [6] Fenner, W., "Internet Group Management Protocol, Version 489 2", RFC 2236, November 1997. 491 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast 492 Listener Discovery (MLD) for IPv6", RFC 2710, October 493 1999. 495 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, 496 "Internet Group Management Protocol (IGMP) / Multicast 497 Listener Discovery (MLD)-Based Multicast Forwarding 498 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 500 Author's Address 502 Hitoshi Asaeda 503 National Institute of Information and Communications Technology 504 4-2-1 Nukui-Kitamachi 505 Koganei, Tokyo 184-8795 506 Japan 508 Email: asaeda@nict.go.jp