idnits 2.17.00 (12 Aug 2021) /tmp/idnits14148/draft-ietf-pim-explicit-tracking-00.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 -- 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 document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 10, 2011) is 3875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2373 (ref. '6') (Obsoleted by RFC 3513) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Asaeda 3 Internet-Draft Keio University 4 Intended status: Informational N. Leymann 5 Expires: April 12, 2012 Deutsche Telekom AG 6 October 10, 2011 8 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 9 Routers 10 draft-ietf-pim-explicit-tracking-00 12 Abstract 14 This document describes the IGMP/MLD-based explicit membership 15 tracking function for multicast routers. The explicit tracking 16 function is useful for accounting and contributes to saving network 17 resource and fast leaves (i.e. shortened leave latency). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 12, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 6 68 3.1. Reducing the Number of Specific Queries . . . . . . . . . 6 69 3.2. Shortening Leave Latencies . . . . . . . . . . . . . . . . 6 70 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Membership State Information . . . . . . . . . . . . . . . . . 9 72 5. Multicast Router Behavior . . . . . . . . . . . . . . . . . . 10 73 6. Interoperability and Compatibility . . . . . . . . . . . . . . 11 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The Internet Group Management Protocol (IGMP) [2] for IPv4 and the 84 Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the 85 standard protocols used by listener hosts and multicast routers. 86 When a host starts listening particular multicast channels, it sends 87 IGMP/MLD State-Change Report messages specifying the corresponding 88 channel information as the join/leave request to its upstream router 89 (i.e., an adjacent multicast router or IGMP/MLD proxy [8]). This 90 "unsolicited" Report is sent only once upon reception. 92 IGMP/MLD are non-reliable protocols; the unsolicited Report messages 93 may be lost or not be reached to upstream routers. To recover the 94 problem, the routers need to update membership information by sending 95 IGMP/MLD General Query messages periodically. Member hosts then 96 reply with "solicited" Report messages whenever they receive the 97 Query messages. 99 Multicast routers are able to periodically maintain the multicast 100 listener (or membership) state of downstream hosts attached on the 101 same link by getting unsolicited Report messages and synchronize the 102 actual membership state within the General Query timer interval 103 (i.e., [Query Interval] value defined in [2][3].) However, this 104 approach does not guarantee that the membership state is always 105 perfectly synchronized. To minimize the possibility of having the 106 outdated membership information, routers may shorten the periodic 107 General Query timer interval. Unfortunately, this would increase the 108 number of transmitted solicited Report messages and induce network 109 congestion. And the more the network congestion is occured, the more 110 IGMP/MLD Report messages may be lost and the membership state 111 information may be outdated in the router. 113 The IGMPv3 [2] and MLDv2 [3] protocols can provide the capability of 114 keeping track of downstream (adjacent) multicast listener state to 115 multicast routers. This document describes the "IGMP/MLD-based 116 explicit member tracking function" for multicast routers and details 117 the way for routers to implement the function. By enabling the 118 explicit tracking function, routers can keep track of the downstream 119 multicast membership state. This function implements the following 120 requirements: 122 o Per-host accounting 124 o Reducing the number of transmitted Query and Report messages 126 o Shortening leave latencies 127 o Maintaining multicast channel characteristics (or statistics) 129 where this document mainly focuses on the above second and third 130 bullets in the following sections. 132 The explicit tracking function does not change message formats used 133 by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight 134 version protocols [4]. It does not change a multicast data sender's 135 and receiver's behavior as well. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 140 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 141 this document are to be interpreted as described in RFC 2119 [1]. 143 3. Explicit Tracking Function 145 3.1. Reducing the Number of Specific Queries 147 The explicit tracking function reduces the number of Group-Specific 148 or Group-and-Source Specific Query messages transmitted from a 149 router, and then the number of Current-State Report messages 150 transmitted from member hosts. As the result, network resources used 151 for IGMP/MLD query-and-reply communications between a router and 152 member hosts can be saved. 154 According to [2] and [3], whenever a router receives the State-Change 155 Report, it sends the corresponding Group-Specific or Group-and-Source 156 Specific Query messages to confirm whether the Report sender is the 157 last member host or not. After getting these Query messages, all 158 member hosts joining the corresponding channel reply with own 159 Current-State Report messages. This condition requires transmitting 160 a number of Current-State Report messages and consumes network 161 resources especially when many hosts have been joining the same 162 channel. 164 On the other hand, if a router enables the explicit tracking 165 function, it does not need to always ask Current-State Report message 166 transmission to the member hosts whenever it receives the State- 167 Change Report. This is because the explicit tracking function works 168 with the expectation that the State-Change Report sender is the last 169 remaining member of the channel. Even if this expectation is wrong 170 (i.e., the State-Change Report sender was not the sole member), other 171 members remaining in the same channel will reply with identical 172 Report messages, so the end result is the same and no problem occurs. 173 (Section 4 details the point.) 175 In addition, the processing of IGMP membership or MLD listener 176 reports consumes CPU ressources on the IGMP/MLD querier devices 177 itself. Therefore, the explicit tracking function reduces not only 178 the network load but also the CPU load on the querier devices as 179 well. 181 3.2. Shortening Leave Latencies 183 The explicit tracking function works with the expectation that the 184 State-Change Report sender is the last remaining member of the 185 channel. Thanks to this functionality, a router can tune timers and 186 values related to decide that the State-Change Report sender was the 187 sole member. 189 The [Last Member Query Interval] (LMQI) and [Last Listener Query 190 Interval] (LLQI) values specify the maximum time allowed before 191 sending a responding Report. The [Last Member Query Count] (LMQC) 192 and [Last Listener Query Count] (LLQC) are the number of Group- 193 Specific Queries or Group-and-Source Specific Queries sent before the 194 router assumes there are no local members. The [Last Member Query 195 Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the 196 total time the router should wait for a report, after the Querier has 197 sent the first query. 199 The default values for LMQI/LLQI defined in the standard 200 specifications [2][3] are 1 second. For the router enabling the 201 explicit tracking function, LMQI/LLQI would be set to 1 second or 202 shorter. The LMQC/LLQC may be set to "1" for the router, whereas 203 their default values are the [Robustness Variable] value whose 204 default value is "2". Smaller LMQC/LLQC give smaller LMQT/LLQT; this 205 condition shortens the leave latencies. 207 3.3. Considerations 209 As with the basic concepts of IGMP and MLD, the explicit tracking 210 function does not guarantee the membership state is always perfectly 211 synchronized; routers enabling the explicit tracking function still 212 need to send IGMPv3/MLDv2 Query messages and inquire solicited 213 IGMPv3/MLDv2 Report messages from downstream members to maintain 214 downstream membership state. 216 o IGMP/MLD messages are non-reliable and may be lost in the 217 transmission, therefore routers need to confirm the membership by 218 sending Query messages. 220 o To preserve compatibility with older versions of IGMP/MLD, routers 221 need to support downstream hosts that are not upgraded to the 222 latest versions of IGMP/MLD and run the report suppression 223 mechanism. 225 o It is impossible to identify hosts when hosts send IGMP reports 226 with a source address of 0.0.0.0. 228 Regarding the last bullet, the IGMPv3 specification [2] mentions that 229 an IGMPv3 Report is usually sent with a valid IP source address, 230 although it permits that a host uses the 0.0.0.0 source address (as 231 it happens that the host has not yet acquired an IP address), and 232 routers MUST accept a report with a source address of 0.0.0.0. The 233 MLDv2 specification [3] mentions that an MLDv2 Report MUST be sent 234 with a valid IPv6 link-local source address, although an MLDv2 Report 235 can be sent with the unspecified address (::), if the sending 236 interface has not acquired a valid link-local address yet. [3] also 237 mentions that routers silently discard a message that is not sent 238 with a valid link-local address or sent with the unspecified address, 239 without taking any action, because of the security consideration. 241 Another concern is that the explicit tracking function requires 242 additional processing capability and a possibly large memory for 243 routers to keep all membership states. Especially when a router 244 needs to maintain a large number of member hosts, this resource 245 requirement may be potentially-impacted. Operators may decide to 246 disable this function when their routers do not have enough memory 247 resources. 249 4. Membership State Information 251 The explicit tracking function is implemented with the following 252 membership state information: 254 (S, G, number of receivers, (receiver records)) 256 where each receiver record is of the form: 258 (IGMP/MLD Membership/Listener Report sender's address) 260 This state information must work properly when a receiver (i.e., 261 Report sender) sends the same Report messages multiple times. 263 In the state information, each "S" and "G" indicates a single IPv4/ 264 IPv6 address. "S" is set to "Null" for an Any-Source Multicast (ASM) 265 communication (i.e., (*,G) join reception). In order to simplify the 266 implementation, the explicit tracking function does not keep the 267 state of (S,G) join with EXCLUDE filter mode. If a router receives 268 (S,G) join/leave request with EXCLUDE filter mode from the downstream 269 hosts, it translates the join/leave request to (*,G) join state/leave 270 requst and records the state and the receivers' addresses into the 271 maintained membership state information. Note that this membership 272 state translation does not change the routing protocol behavior; the 273 routing protocol must deal with the original join/leave request and 274 translate the request only for the membership state information. 276 5. Multicast Router Behavior 278 The explicit tracking function makes routers expect whether the 279 State-Change Report sender is the last remaining member of the 280 channel. Therefore the router transmits a corresponding Current- 281 State Report message only when the router thinks that the State- 282 Change Report sender is the last remaining member of the channel. 283 This contributes to saving the network resources and also shortening 284 leave latency. 286 To synchronize the membership state information, when a multicast 287 router receives a Current-State or State-Change Report message, it 288 adds the receiver IP address to or delete from the receiver records 289 or creates the corresponding membership state information. If there 290 are no more receiver records left, the membership state information 291 is deleted from the router. 293 However, the membership state information may be still outdated in 294 the router. It may be happened especially in a mobile multicast 295 environment that some member hosts have joined to or left from the 296 network without sending State-Change Report messages. Or, some 297 State-Change Report messages are lost due to network congestion. 298 Therefore, the router enabling the explicit tracking function MUST 299 send the periodic General Query regularly. 301 Regarding the leave latency, as specified in Section 3.2, the 302 explicit tracking function contributes to the fast leave by setting 303 LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1". However, if 304 LMQC/LLQC is configured "2" or bigger value, then the router's 305 behavior MAY be changed from the standard specification. According 306 to [2] and [3], a router sends a Group- (and-Source) Specific Query 307 [LMQC - 1] or [LLQC - 1] times when it receives State Change Report 308 message (e.g. leave request) from a member host, in order to confirm 309 whether or not the host is the only remaining member. However, this 310 document RECOMMENDS that if the router enabling the explicit tracking 311 function receives the corresponding Current State Report before the 312 Specific Query retransmission, it cancels sending the same Specific 313 Query for other [LMQC - 1] or [LLQC - 1] times. 315 Note that there is some risk that a router misses or looses Report 316 messages sent from remaining members if the router adopts small LMQC/ 317 LLQC; however the wrong expectation would be lower happened for the 318 router enabling the explicit tracking function. And to avoid the 319 problem, a router can start sending a Group- (and-Source) Specific 320 Query message when it expects the number of the remaining members is 321 small, such as 5, but not 0. 323 6. Interoperability and Compatibility 325 The explicit tracking function does not work with the older versions 326 of IGMP or MLD, IGMPv1 [5], IGMPv2 [6] or MLDv1 [7], because a member 327 host using these protocols adopts a report suppression mechanism by 328 which a host would cancel sending a pending membership Reports if a 329 similar Report was observed from another member on the network. 331 If a multicast router enabling the explicit tracking function changes 332 its compatibility mode to the older versions of IGMP or MLD, the 333 router should turn off the explicit tracking function but should not 334 flush the maintained membership state information (i.e., keep the 335 current membership state information as is). When the router changes 336 back to IGMPv3 or MLDv2 mode, it would resume the function with the 337 kept membership state information, even if the state information is 338 outdated. This manner would give "smooth state transition" that does 339 not initiate the membership state from scratch and synchronizes the 340 actual membership state smoothly. 342 There are several points TBD in the further discussions regarding the 343 interoperability and compatibility issues. At first, it is necessary 344 whether a multicast router enabling the explicit tracking function 345 needs to detect adjacent routers that do not support the explicit 346 tracking function on the link or not. After the clarification, this 347 document will describe the method how to detect them. It would be 348 done by a new signaling message, but the new message leads 349 compatibility problems for older routers or other routing protocols 350 such as PIM-DM. All of these discussions are TBD. 352 7. Security Considerations 354 There is no additional security considerations. 356 8. Acknowledgements 358 Toerless Eckert, Stig Venaas, and others provided many constructive 359 and insightful comments. 361 9. References 363 9.1. Normative References 365 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 366 levels", RFC 2119, March 1997. 368 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 369 Thyagarajan, "Internet Group Management Protocol, Version 3", 370 RFC 3376, October 2002. 372 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 373 (MLDv2) for IPv6", RFC 3810, June 2004. 375 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 376 Management Protocol Version 3 (IGMPv3) and Multicast Listener 377 Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. 379 9.2. Informative References 381 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 382 August 1989. 384 [6] Fenner, W., "Internet Group Management Protocol, Version 2", 385 RFC 2373, July 1997. 387 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 388 Discovery (MLD) for IPv6", RFC 2710, October 1999. 390 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 391 Group Management Protocol (IGMP) / Multicast Listener Discovery 392 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 393 RFC 4605, August 2006. 395 Authors' Addresses 397 Hitoshi Asaeda 398 Keio University 399 Graduate School of Media and Governance 400 5322 Endo 401 Fujisawa, Kanagawa 252-0882 402 Japan 404 Email: asaeda@wide.ad.jp 405 URI: http://web.sfc.wide.ad.jp/~asaeda/ 407 Nicolai Leymann 408 Deutsche Telekom AG 409 Winterfeldtstrasse 21-27 410 Berlin 10781 411 Germany 413 Email: n.leymann@telekom.de