idnits 2.17.00 (12 Aug 2021) /tmp/idnits52086/draft-ietf-pim-explicit-tracking-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In the state information, each S and G indicates a single IPv4/IPv6 address. S is set to "Null" for Any-Source Multicast (ASM) communication (i.e., (*,G) join reception). In order to simplify the implementation, the explicit tracking function MAY NOT keep the state of (S,G) joined with EXCLUDE filter mode. In that case, if a router receives an (S,G) join/leave request with EXCLUDE filter mode from the downstream hosts, the router translates the request to a (*,G) join state/leave request and records the state and the receivers' addresses in the maintained membership state information. Note that this membership state translation does not change the routing protocol behavior. The routing protocol must deal with the original join/leave request and translate the request only for the membership state information. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: To preserve compatibility with older versions of IGMP/MLD, routers need to support downstream hosts that are not upgraded to the latest versions and run membership report suppression. Therefore, if a multicast router enabling the explicit tracking function changes its compatibility mode to the older versions, the router SHOULD disable the explicit tracking function. On the other hand, the router MAY NOT flush the maintained membership state information. When the router changes back to IGMPv3 or MLDv2 mode, it resumes the function with the old membership state information even if the state information is outdated. This provides "smooth state transition" that does not initiate the membership state information from scratch and synchronizes the actual membership state smoothly. -- The document date (January 29, 2013) is 3398 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) -- Obsolete informational reference (is this intentional?): RFC 2373 (ref. '7') (Obsoleted by RFC 3513) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). 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 January 29, 2013 5 Expires: August 2, 2013 7 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 8 Routers 9 draft-ietf-pim-explicit-tracking-04 11 Abstract 13 This document describes the IGMP/MLD-based explicit membership 14 tracking function for multicast routers supporting IGMPv3/MLDv2. The 15 explicit tracking function contributes to saving network resources 16 and fast leaves (i.e. 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 August 2, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4 55 3.1. Membership State Information . . . . . . . . . . . . . . . 4 56 3.2. Specific Query Suppression . . . . . . . . . . . . . . . . 5 57 3.3. Shortening Leave Latency . . . . . . . . . . . . . . . . . 6 58 4. Lowering the Possibility of Outdated Membership State . . . . 7 59 5. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8 60 6. Compatibility with Older Version Protocols . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The Internet Group Management Protocol (IGMP) version 3 [1] for IPv4 72 and the Multicast Listener Discovery Protocol (MLD) version 2 [2] for 73 IPv6 are the standard protocols used by member hosts and multicast 74 routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and 75 LW-MLDv2) [3] are subsets of the standard IGMPv3 and MLDv2. When a 76 host starts/finishes listening to particular multicast channels, it 77 sends IGMP/MLD State-Change Report messages specifying the 78 corresponding channel information as the join/leave request to its 79 upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy 80 device [5]). The "unsolicited" report messages are sent only when 81 the host joins/leaves the channels. 83 IGMP/MLD are non-reliable protocols; the unsolicited report messages 84 may be lost or may not reach upstream routers. To alleviate the 85 problem, routers need to update membership information by 86 periodically sending IGMP/MLD General Query messages. Member hosts 87 then reply with "solicited" report messages whenever they receive the 88 query messages. 90 Multicast routers are capable of periodically maintaining the 91 multicast membership state of downstream hosts attached to the same 92 link by acquiring unsolicited report messages and synchronizing the 93 actual membership state within the General Query timer interval 94 (i.e., [Query Interval] value defined in [1][2].) However, this 95 approach does not guarantee that the membership state is always 96 perfectly synchronized. To minimize the possibility of having 97 outdated membership information, routers may shorten the periodic 98 General Query timer interval. Unfortunately, this increases the 99 number of transmitted solicited report messages and induces network 100 congestion. And the greater the amount of network congestion, the 101 greater the potential for IGMP/MLD report messages being lost and the 102 membership state information being outdated in the router. 104 The IGMPv3 [1] and MLDv2 [2] protocols and these lightweight 105 protocols [3] can provide the ability to keep track of the downstream 106 (adjacent) multicast membership state to 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 details a way for routers to implement the function. By 110 enabling this explicit tracking function, routers can keep track of 111 the downstream multicast membership state. This function enables the 112 following: 114 o Reducing the number of transmitted query and report messages 115 o Shortening leave latencies 117 o Per-host accounting 119 o Maintaining multicast channel characteristics (or statistics) 121 In addition, the processing of IGMP membership or MLD listener 122 messages consumes CPU resources on individual IGMP/MLD querier and 123 report sender devices. The explicit tracking function therefore 124 reduces not only the network load but also the CPU load on these 125 devices. 127 The explicit tracking function does not guarantee that the membership 128 state will always be perfectly synchronized; the list of tracked 129 member hosts may be outdated in the router because of host departure 130 from the network without sending State-Change Report messages or loss 131 of such messages due to network congestion. Therefore, a router 132 enabling the function ought to send periodic IGMPv3/MLDv2 General 133 Query messages and solicit IGMPv3/MLDv2 report messages from 134 downstream member hosts to maintain an up-to-date membership state. 136 The explicit tracking function potentially requires a large amount of 137 memory so that routers keep all membership states. Particularly when 138 a router needs to maintain a large number of member hosts, this 139 resource requirement could have an impact. Operators may decide to 140 disable this function when their routers have insufficient memory 141 resources, despite the benefits mentioned above. 143 The explicit tracking function does not change message formats used 144 by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight 145 version protocols [3]; nor does it change a multicast data sender's 146 and receiver's behavior. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 151 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 152 this document are to be interpreted as described in RFC 2119 [4]. 154 3. Explicit Tracking Function 156 3.1. Membership State Information 158 A router enabling the explicit tracking function maintains the 159 "membership state information". When a multicast router receives a 160 Current-State or State-Change Report message, it creates this 161 membership state information or adds or deletes the receiver IP 162 address to or from it. If there are no more receivers maintained, 163 the router may keep the membership state information with an empty 164 receiver list. 166 The membership state information consists of the following 167 information: 169 (S, G, number of receivers, (receiver records)) 171 where each receiver record is of the form: 173 (IGMP/MLD membership/listener report sender's address) 175 This state information must work properly when a receiver (i.e., 176 report sender) sends the identical report messages multiple times. 178 In the state information, each S and G indicates a single IPv4/IPv6 179 address. S is set to "Null" for Any-Source Multicast (ASM) 180 communication (i.e., (*,G) join reception). In order to simplify the 181 implementation, the explicit tracking function MAY NOT keep the state 182 of (S,G) joined with EXCLUDE filter mode. In that case, if a router 183 receives an (S,G) join/leave request with EXCLUDE filter mode from 184 the downstream hosts, the router translates the request to a (*,G) 185 join state/leave request and records the state and the receivers' 186 addresses in the maintained membership state information. Note that 187 this membership state translation does not change the routing 188 protocol behavior. The routing protocol must deal with the original 189 join/leave request and translate the request only for the membership 190 state information. 192 3.2. Specific Query Suppression 194 In accordance with [1] and [2], whenever a router receives the State- 195 Change Report, it sends the corresponding Group-Specific or Group- 196 and-Source Specific Query messages to confirm whether or not the 197 report sender is the sole member host. All member hosts joining the 198 identical channel send their own Current-State Report messages after 199 acquiring these query messages. Transmitting a large number of 200 Current-State Report messages consumes network resources, and this 201 may pose a particular problem when many hosts joining the identical 202 channel send these reports simultaneously. 204 The explicit tracking function can reduce the number of Group- 205 Specific or Group-and-Source Specific Query messages transmitted from 206 a router, and reduce the number of Current-State Report messages 207 transmitted from member hosts. If a router enables the explicit 208 tracking function with "specific query suppression", it suppresses 209 specific query transmission and transmits specific query messages 210 only when the router expects that the State-Change Report sender is 211 the sole member of the channel, based on its membership state 212 information (expressed in Section 3.1). 214 As standard behavior for [1] and [2], a router also sends a Group- 215 Specific or Group-and-Source Specific Query multiple times when it 216 receives a State Change Report message (e.g., leave request) from a 217 member host. This is in order to confirm whether or not the host is 218 the sole member. However, if the router enabling the explicit 219 tracking function runs specific query suppression and receives one or 220 more replies for the specific query retransmission from the 221 downstream member(s), the router can cancel resending of the 222 identical specific query message(s). 224 Note that the default behavior of the router that supports the 225 explicit tracking function SHOULD disable this specific query 226 suppression in order to avoid the risk caused by the situation in 227 which multiple multicast routers exist on a LAN and the querier 228 router is not the forwarder router. When the querier suppresses the 229 specific query message transmission, and expects that the State- 230 Change Report sender is not the sole member of the channel, it does 231 not send the specific query and none of the routers on the same LAN 232 receive a Current-State Report message from the corresponding member 233 hosts. The forwarder in this case may prune the routing path though 234 there are other member hosts subscribing to the channel on the LAN. 236 3.3. Shortening Leave Latency 238 A router enabling the explicit tracking function can shorten leave 239 latencies by tuning several timers and values to what it expects 240 whether or not the State-Change Report sender is the channel's sole 241 member. 243 The [Last Member Query Interval] (LMQI) and [Last Listener Query 244 Interval] (LLQI) values specify the maximum time allowed for a member 245 host to send a responding Report before the router prunes the channel 246 from the network. The [Last Member Query Count] (LMQC) and [Last 247 Listener Query Count] (LLQC) are the number of Group-Specific Queries 248 or Group-and-Source Specific Queries sent before the router assumes 249 there are no local members. The [Last Member Query Time] (LMQT) and 250 [Last Listener Query Time] (LLQT) values are the total time the 251 router should wait for a report after the Querier has sent the first 252 query. 254 The default value for LMQI/LLQI defined in the standard 255 specifications [1][2] is 1 second. For a router enabling the 256 explicit tracking function, the LMQI/LLQI MAY be set to 1 second or 257 shorter. The LMQC/LLQC values MAY be set to 1 for the router, 258 whereas their default values are the [Robustness Variable] value 259 whose default value is 2. Smaller LMQC/LLQC values give smaller 260 LMQT/LLQT, which shortens the leave latencies. On the other hand, 261 setting smaller LMQC/LLQC values poses the risk described in 262 Section 4. Operators setting smaller LMQC/LLQC values must recognize 263 this tradeoff. 265 4. Lowering the Possibility of Outdated Membership State 267 There are possibilities that a router enables the explicit tracking 268 function but its membership expectation will be inconsistent due to 269 an outdated membership state. For example, (1) a router expects that 270 more than one corresponding member host exists on its LAN, but in 271 fact no member host exists for that multicast channel, or (2) a 272 router expects that no corresponding member host exists on its LAN, 273 but in fact more than one member host exists for that multicast 274 channel. These cases are particularly likely for a router that 275 enables specific query suppression (as in Section 3.2) and configures 276 small LMQC/LLQC for shortening leave latency (as in Section 3.3). 278 The first of these cases may occur in an environment where the sole 279 member host departs the network without sending a State-Change Report 280 message. This is because a router enabling specific query 281 suppression does not send a specific query if it believes the report 282 sender is not the sole member host. The router later detects that 283 there is no member host for the corresponding channels when it does 284 not receive a Current-State Report within the timeout of the response 285 for the periodic General Query. However, this situation prolongs 286 leave latency and wastes network resources since the router forwards 287 unneeded traffic until that point. 289 The second case occurs when a router sends a specific query but does 290 not receive a State-Change Report from a downstream host within an 291 LMQT or LLQT period. It recognizes that no member host exists on the 292 LAN and might prune the routing path. The router reestablishes the 293 routing path when it receives the solicited report message for the 294 channels. However, the downstream hosts may loose the data packets 295 until the routing path is reestablished and the data forwarding is 296 restarted. 298 In order to reduce the possibility of the incorrect membership 299 expectation and keep the up-to-date membership state information, 300 when a router enabling the explicit tracking function enables 301 specific query suppression, the router SHOULD configure the LMQC/LLQC 302 value to 2 (the default value of the [Robustness Variable] value) or 303 higher; or, when a router enabling the explicit tracking function 304 configures a small LMQC/LLQC, the router SHOULD NOT enable specific 305 query suppression. 307 5. All-Zero and Unspecified Source Addresses 309 The IGMPv3 specification [1] mentions that an IGMPv3 report is 310 usually sent with a valid IP source address, yet it permits a host to 311 use the 0.0.0.0 source address (since the host has not yet acquired 312 an IP address), and routers must accept a report with this source 313 address. The MLDv2 specification [2] mentions that an MLDv2 report 314 must be sent with a valid IPv6 link-local source address, yet an 315 MLDv2 report may be sent with the unspecified address (::) if the 316 sending interface has not acquired a valid link-local address. [2] 317 also mentions that routers silently discard a message that is not 318 sent with a valid link-local address or sent with the unspecified 319 address, without taking any action, because of security 320 considerations. 322 When a router enabling the explicit tracking function receives IGMP/ 323 MLD report messages with an all-zero or unspecified source address, 324 it deals with the IGMP/MLD report messages correctly as defined in 325 [1][2] and continuously keeps track of the membership state, but 326 SHOULD NOT maintain the host specifying all-zero or an unspecified 327 source address in its membership state information. 329 6. Compatibility with Older Version Protocols 331 The explicit tracking function does not work with older versions of 332 IGMP or MLD, IGMPv1 [6], IGMPv2 [7], or MLDv1 [8], because a member 333 host using these protocols enables "membership report suppression" by 334 which the host will cancel sending pending membership reports if a 335 similar report is observed from another member on the network. 337 To preserve compatibility with older versions of IGMP/MLD, routers 338 need to support downstream hosts that are not upgraded to the latest 339 versions and run membership report suppression. Therefore, if a 340 multicast router enabling the explicit tracking function changes its 341 compatibility mode to the older versions, the router SHOULD disable 342 the explicit tracking function. On the other hand, the router MAY 343 NOT flush the maintained membership state information. When the 344 router changes back to IGMPv3 or MLDv2 mode, it resumes the function 345 with the old membership state information even if the state 346 information is outdated. This provides "smooth state transition" 347 that does not initiate the membership state information from scratch 348 and synchronizes the actual membership state smoothly. 350 7. IANA Considerations 352 This document has no actions for IANA. 354 8. Security Considerations 356 There is no additional security consideration for [1][2][3] provided. 358 9. Acknowledgements 360 Toerless Eckert, Sergio Figueiredo, Nicolai Leymann, Stig Venaas, and 361 others provided many constructive and insightful comments. 363 10. References 365 10.1. Normative References 367 [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 368 Thyagarajan, "Internet Group Management Protocol, Version 3", 369 RFC 3376, October 2002. 371 [2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 372 (MLDv2) for IPv6", RFC 3810, June 2004. 374 [3] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 375 Management Protocol Version 3 (IGMPv3) and Multicast Listener 376 Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. 378 [4] Bradner, S., "Key words for use in RFCs to indicate requirement 379 levels", RFC 2119, March 1997. 381 10.2. Informative References 383 [5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 384 Group Management Protocol (IGMP) / Multicast Listener Discovery 385 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 386 RFC 4605, August 2006. 388 [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 389 August 1989. 391 [7] Fenner, W., "Internet Group Management Protocol, Version 2", 392 RFC 2373, July 1997. 394 [8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 395 Discovery (MLD) for IPv6", RFC 2710, October 1999. 397 Author's Address 399 Hitoshi Asaeda 400 National Institute of Information and Communications Technology (NICT) 401 Network Architecture Laboratory 402 4-2-1 Nukui-Kitamachi 403 Koganei, Tokyo 184-8795 404 Japan 406 Email: asaeda@nict.go.jp