idnits 2.17.1 draft-ietf-pim-explicit-tracking-09.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 (December 3, 2013) is 3789 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) 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: Standards Track December 3, 2013 5 Expires: June 6, 2014 7 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 8 Routers 9 draft-ietf-pim-explicit-tracking-09 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 June 6, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Membership State Information . . . . . . . . . . . . . . . . 4 55 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 56 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 57 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6 58 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 59 8. Compatibility with Older Version Protocols . . . . . . . . . 8 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 12.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 71 and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for 72 IPv6 are the standard protocols used by member hosts and multicast 73 routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and 74 LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. 76 When a host starts/finishes listening to particular multicast 77 channels, it sends IGMP/MLD State-Change Report messages specifying 78 the corresponding channel information as the join/leave request to 79 its upstream router (i.e., an adjacent multicast router or IGMP/MLD 80 proxy device [8]). The "unsolicited" report messages are sent only 81 when the host joins/leaves the channels. Since IGMP/MLD are non- 82 reliable protocols, unsolicited report messages may be lost or may 83 not reach upstream routers. To alleviate this problem, unsolicited 84 report messages are retransmitted a number of times according to the 85 value of the [Robustness Variable] defined in [2][3]. 87 Also, a querier router periodically sends IGMP/MLD General Query 88 messages every General Query timer interval (i.e. [Query Interval] 89 value defined in [2][3]). Upon receiving the query messages, the 90 member hosts reply with "solicited" report messages. Routers then 91 keep their membership state information up to date. However, this 92 approach still does not guarantee that the membership state is always 93 perfectly synchronized. To minimize the possibility of having 94 outdated membership information, routers may shorten the periodic 95 General Query timer interval. Unfortunately, this increases the 96 number of transmitted solicited report messages and induces network 97 congestion. And the greater the amount of network congestion, the 98 greater the potential for IGMP/MLD report messages being lost and the 99 membership state information being outdated in the router. 101 IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can 102 provide the ability to keep track of the downstream (adjacent) 103 multicast membership state in multicast routers, yet the 104 specifications are not clearly given. This document describes the 105 "IGMP/MLD-based explicit member tracking function" for multicast 106 routers and a way for routers to implement the function. By enabling 107 this explicit tracking function, routers can keep track of the 108 downstream multicast membership state. This function enables the 109 following things: 111 o Reducing the number of transmitted query and report messages 113 o Shortening leave latencies 115 o Per-host accounting 117 o Maintaining multicast channel characteristics (or statistics) 119 where this document mainly focuses on the above first and second 120 bullets in the following sections. 122 Note that the explicit tracking function does not change the 123 reliability of the message transmission. The list of tracked member 124 hosts may be outdated in the router because of host departure from 125 the network without sending State-Change Report messages or loss of 126 such messages due to network congestion. Therefore, a router 127 enabling the function may still need to send periodic IGMPv3/MLDv2 128 General Query messages and solicit IGMPv3/MLDv2 report messages from 129 downstream member hosts to maintain an up-to-date membership state. 131 The explicit tracking function potentially requires a large amount of 132 memory so that routers keep all membership states. Particularly when 133 a router needs to maintain a large number of member hosts, this 134 resource requirement might be sensitive. Operators may decide to 135 disable this function when their routers have insufficient memory 136 resources, despite the benefits mentioned above. 138 The explicit tracking function does not change message formats used 139 by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight 140 version protocols [4]; nor does it change a multicast data sender's 141 and receiver's behavior. 143 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [1]. 148 3. Membership State Information 150 A router enabling the explicit tracking function maintains the 151 "membership state information". When a multicast router receives a 152 Current-State or State-Change Report message, it creates or modifies 153 this membership state information to maintain the membership state up 154 to date. 156 The membership state information consists of the following 157 information: 159 (S, G, number of receivers, (receiver records)) 161 where "S" denotes source address, "G" denotes group or multicast 162 address, and each receiver record is of the form: 164 (IGMP/MLD membership/listener report sender's address) 166 In the state information, each S and G indicates a single IPv4/IPv6 167 address. S is set to "Null" for Any-Source Multicast (ASM) 168 communication (i.e., (*,G) join reception). In order to simplify the 169 implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of 170 (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G) 171 join/leave request with EXCLUDE filter mode from the downstream 172 hosts, the router translates the request to a (*,G) join state/leave 173 request and records the state and the receivers' addresses in the 174 maintained membership state information. 176 The membership state information must be identified properly even 177 though a receiver (i.e., IGMP/MLD Report sender) sends the identical 178 report messages multiple times. And the maintained membership state 179 information will be flushed when the router reboots or restarts the 180 multicast routing processes. 182 4. Specific Query Suppression 184 In accordance with [2] and [3], when a router receives the State- 185 Change Report and needs to confirm whether any hosts are still 186 interested in a channel or not, the router sends the corresponding 187 Group-Specific or Group-and-Source Specific Query messages as defined 188 in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent 189 by actions defined in these sections need to be transmitted [Last 190 Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) 191 times, once every [Last Member Query Interval] (LMQI) or [Last 192 Listener Query Interval] (LLQI), in order to confirm the sole member. 193 (The default values for LMQI/LLQI defined in [2][3] are 1 second. 194 The default values for LMQC/LLQC are the [Robustness Variable] value 195 whose default value is 2.) All member hosts joining the identical 196 channel then reply with their own states after acquiring these query 197 messages. However, transmitting a large number of IGMP/MLD Report 198 messages consumes network resources, and this may pose a particular 199 problem especially when many hosts joining the identical channel send 200 these reports simultaneously. 202 The explicit tracking function provides a method called "specific 203 query suppression" that reduces the number of Group-Specific or 204 Group-and-Source Specific Query messages transmitted from a router. 205 This in turn reduces the number of Current-State Report messages 206 transmitted from member hosts. 208 With the specific query suppression, regardless of the LMQC/LLQC 209 values, if the router receives one or more replies from the 210 downstream member(s), it can stop (i.e., cancel) retransmitting the 211 specific query message(s) for the specified source and/or group. 212 This contributes to saving network resources. 214 If the router is confident that the tracked membership state 215 information is perfectly synchronized with the current (actual) 216 member hosts, the specific query suppression in a "robust link state" 217 may also be implemented with the explicit tracking function. A 218 router enabling the specific query suppression in a robust link state 219 does not send any specific query message(s) and immediately leave the 220 group or sources when the sole member has left according to its 221 membership state information. The specific query suppression in a 222 robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI 223 values. This contributes to shortening leave latency described in 224 Section 5. However, this behavior requires that the router perfectly 225 tracks all member hosts. (See a risk of wrong membership expectation 226 described in Section 6.) 228 Note that the default behavior of the router that supports the 229 explicit tracking function SHOULD disable this specific query 230 suppression, in order to avoid the risk caused by the wrong 231 membership expectation or by the case in which multiple multicast 232 routers exist on a LAN and the querier router is not the forwarder 233 router. The former case is described in Section 6. For the latter 234 case, when the querier suppresses the specific query message 235 transmission, and expects that the State-Change Report sender is not 236 the sole member of the channel, it does not send the specific query. 237 Then the routers (including the forwarder) on the same LAN do not 238 receive a Current-State Report message from the corresponding member 239 hosts. The forwarder in this case may prune the routing path, 240 although there are other member hosts subscribing to the channel on 241 the LAN. 243 5. Shortening Leave Latency 245 A router enabling the explicit tracking function can shorten leave 246 latencies by tuning the following values; [Last Member Query Count] 247 (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query 248 Interval] (LMQI), [Last Listener Query Interval] (LLQI), and 249 [Robustness Variable] values. 251 The [Last Member Query Interval] (LMQI) and [Last Listener Query 252 Interval] (LLQI) values defined in the standard specifications [2][3] 253 specify the maximum time allowed for a member host to send a 254 responding Report. The [Last Member Query Count] (LMQC) and [Last 255 Listener Query Count] (LLQC) are the number of Group-Specific Queries 256 or Group-and-Source Specific Queries sent before the router assumes 257 there are no local members. The [Last Member Query Time] (LMQT) and 258 [Last Listener Query Time] (LLQT) values are the total time the 259 router should wait for a report after the Querier has sent the first 260 query. 262 The default values for LMQI/LLQI defined in [2][3] are 1 second, yet, 263 for a router enabling the explicit tracking function, the LMQI/LLQI 264 may be set to 1 second or shorter. As well, the default values for 265 LMQC/LLQC are the [Robustness Variable] value whose default value is 266 2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/ 267 LLQC values give shorter LMQT/LLQT, which shorten the leave 268 latencies. 270 Furthermore, if operators are confident that their link is fairly 271 robust (e.g., the [Robustness Variable] value is appropriately 272 configured so that the chances of unsolicited messages being lost are 273 sufficiently low), and if the querier router always acts as the 274 forwarder router for all multicast channels in the LAN, they will set 275 smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT) 276 with the specific query suppression, or enable the specific query 277 suppression in a robust link state (Section 4) for their routers. 279 Note that setting smaller LMQC/LLQC values or adopting the specific 280 query suppression in a robust link state poses the risk of wrong 281 membership state described in Section 6. Operators setting smaller 282 LMQC/LLQC values must recognize this tradeoff. 284 6. Risk of Wrong Membership State 286 There are possibilities that a router's membership expectation is 287 inconsistent due to an outdated membership state. For example, (1) a 288 router expects that more than one corresponding member host exists on 289 its LAN, but in fact no member host exists for that multicast 290 channel, or (2) a router expects that no corresponding member host 291 exists on its LAN, but in fact one or more than one member host 292 exists for that multicast channel. 294 The first case may occur in an environment where the sole member host 295 departs the network without sending a State-Change Report message. 296 The router later detects that there is no member host for the 297 corresponding channels when it does not receive a Current-State 298 Report within the timeout of the response for the periodic General 299 Query (and then the group or source timers are expired). However, 300 this situation prolongs leave latency and wastes network resources 301 since the router forwards unneeded traffic for a while. 303 The second case occurs when a router sends a specific query but does 304 not receive a Current-State Report from a downstream host within an 305 LMQT or LLQT period. It recognizes that no member host exists on the 306 LAN and might prune the routing path. The router reestablishes the 307 routing path when it receives the solicited report message for the 308 channels. However, the downstream hosts may loose the data packets 309 until the routing path is reestablished and the data forwarding is 310 restarted. 312 If operators do not believe that their link is fairly robust or that 313 they can configure the [Robustness Variable] value appropriately, 314 they may configure the LMQC/LLQC value to 2 (the default value of the 315 [Robustness Variable] value) or bigger value for their routers. In 316 this case, the routers would enable the explicit tracking function 317 but may want to disable the specific query suppression specified in 318 Section 4. Such configurations will not contribute to saving network 319 resources, but reduce the risk of the incorrect membership 320 expectation. 322 7. All-Zero and Unspecified Source Addresses 324 The IGMPv3 specification [2] mentions that an IGMPv3 report is 325 usually sent with a valid IP source address, yet it permits a host to 326 use the 0.0.0.0 source address (since the host has not yet acquired 327 an IP address), and routers must accept a report with this source 328 address. 330 When a router enabling the explicit tracking function receives IGMP 331 report messages with an all-zero source address, it deals with the 332 IGMP report messages correctly as defined in [2] and continuously 333 keeps track of the membership state. However, the router SHOULD NOT 334 maintain the host specifying all-zero source address in its 335 membership state information. The router will maintain its 336 membership state information by checking Current-State reports as 337 ordinary routers do. 339 On the other hand, the MLDv2 specification [3] mentions that routers 340 silently discard a message that is sent with an invalid link-local 341 address or sent with the unspecified address (::), without taking any 342 action, because of security considerations. According to this 343 specification, whether the explicit tracking function is used or not, 344 a router does not deal with a member hosts sending an MLD report 345 message with the unspecified source address. 347 8. Compatibility with Older Version Protocols 349 The explicit tracking function does not work with older versions of 350 IGMP or MLD, IGMPv1 [5], IGMPv2 [6], or MLDv1 [7], because a member 351 host using these protocols enables "membership report suppression" by 352 which the host will cancel sending pending membership reports if a 353 similar report is observed from another member on the network. 355 To preserve compatibility with older versions of IGMP/MLD, routers 356 supporting IGMPv3/MLDv2 enable the host compatibility mode defined in 357 [2][3]. The host compatibility mode of an interface changes the 358 operational protocol version on the LAN whenever an older version 359 query (than the current compatibility mode) is heard or when certain 360 timer conditions occur. The routers can hence support downstream 361 hosts that are not upgraded to the latest versions and run membership 362 report suppression. 364 Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling 365 the explicit tracking function changes its compatibility mode to the 366 older versions, the router SHOULD disable the explicit tracking 367 function while it acts as the older version router. 369 9. IANA Considerations 371 This document has no actions for IANA. 373 10. Security Considerations 375 The explicit tracking function potentially requires a large amount of 376 memory so that routers keep all membership states. It gives some 377 impact in the cases where (1) a router attaches to a link or an IGMP/ 378 MLD proxy device [8] that has a large number of member hosts, and a 379 router has insufficient memory resources to maintain a large number 380 of member hosts, or (2) a malicious host sends a large number of 381 invalid IGMP/MLD State-Change Report messages without any intent to 382 join the specified channels. 384 For the first case, operators may disable the explicit tracking 385 function, despite the benefits mentioned above. For the second case, 386 some serious threats may be induced. For instance; 388 1. Transmitting a large number of invalid IGMP/MLD report messages 389 consumes network resources. 391 2. Keeping a large number of invalid membership states on a router 392 consumes the router's memory resources. 394 3. Dealing with a large number of invalid membership states on a 395 router consumes the router's CPU and memory resources. 397 In order to mitigate such threats, a router enabling the explicit 398 tracking function may limit a total amount of membership information 399 the router can store, or may rate-limit State-Change Report messages 400 per host. When the router enables rate-limiting per host, the router 401 MAY ignore the received State-Change Report messages to minimize the 402 processing overhead or prevent DoS attacks. The rate limit is left 403 to the router's implementation. 405 11. Acknowledgements 407 Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi, 408 Nicolai Leymann, Magnus Nystrom, Stig Venaas, and others provided 409 many constructive and insightful comments. 411 12. References 413 12.1. Normative References 415 [1] Bradner, S., "Key words for use in RFCs to indicate 416 requirement levels", RFC 2119, March 1997. 418 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 419 Thyagarajan, "Internet Group Management Protocol, Version 420 3", RFC 3376, October 2002. 422 [3] Vida, R. and L. Costa, "Multicast Listener Discovery 423 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 425 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 426 Group Management Protocol Version 3 (IGMPv3) and Multicast 427 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 428 February 2010. 430 12.2. Informative References 432 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 433 1112, August 1989. 435 [6] Fenner, W., "Internet Group Management Protocol, Version 436 2", RFC 2236, November 1997. 438 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast 439 Listener Discovery (MLD) for IPv6", RFC 2710, October 440 1999. 442 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, 443 "Internet Group Management Protocol (IGMP) / Multicast 444 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 445 /MLD Proxying")", RFC 4605, August 2006. 447 Author's Address 449 Hitoshi Asaeda 450 National Institute of Information and Communications Technology 451 4-2-1 Nukui-Kitamachi 452 Koganei, Tokyo 184-8795 453 Japan 455 Email: asaeda@nict.go.jp