idnits 2.17.1 draft-asaeda-mboned-explicit-tracking-02.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 (March 9, 2011) is 4769 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. '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 MBONED Working Group H. Asaeda 3 Internet-Draft Y. Uchida 4 Intended status: Standards Track Keio University 5 Expires: September 10, 2011 March 9, 2011 7 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 8 Routers 9 draft-asaeda-mboned-explicit-tracking-02 11 Abstract 13 This document describes the IGMP/MLD-based explicit membership 14 tracking function for multicast routers. The explicit tracking 15 function is useful for accounting and contributes to saving network 16 resource and fast leaves (i.e. shortened 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 September 10, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 6 67 3.1. Reducing the Number of Specific Queries . . . . . . . . . 6 68 3.2. Shortening Leave Latencies . . . . . . . . . . . . . . . . 6 69 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Membership State Information . . . . . . . . . . . . . . . . . 9 71 5. Multicast Router Behavior . . . . . . . . . . . . . . . . . . 10 72 6. Interoperability and Compatibility . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 The Internet Group Management Protocol (IGMP) [2] for IPv4 and the 83 Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the 84 standard protocols used by listener hosts and multicast routers. 85 When a host starts listening particular multicast channels, it sends 86 IGMP/MLD State-Change Report messages specifying the corresponding 87 channel information as the join/leave request to its upstream router 88 (i.e., an adjacent multicast router or IGMP/MLD proxy [8]). This 89 "unsolicited" Report is sent only once upon reception. 91 IGMP/MLD are non-reliable protocols; the unsolicited Report messages 92 may be lost or not be reached to upstream routers. To recover the 93 problem, the routers need to update membership information by sending 94 IGMP/MLD General Query messages periodically. Member hosts then 95 reply with "solicited" Report messages whenever they receive the 96 Query messages. 98 Multicast routers are able to periodically maintain the multicast 99 listener (or membership) state of downstream hosts attached on the 100 same link by getting unsolicited Report messages and synchronize the 101 actual membership state within the General Query timer interval 102 (i.e., [Query Interval] value defined in [2][3].) However, this 103 approach does not guarantee that the membership state is always 104 perfectly synchronized. To minimize the possibility of having the 105 outdated membership information, routers may shorten the periodic 106 General Query timer interval. Unfortunately, this would increase the 107 number of transmitted solicited Report messages and induce network 108 congestion. And the more the network congestion is occured, the more 109 IGMP/MLD Report messages may be lost and the membership state 110 information may be outdated in the router. 112 The IGMPv3 [2] and MLDv2 [3] protocols can provide the capability of 113 keeping track of downstream (adjacent) multicast listener state to 114 multicast routers. This document describes the "IGMP/MLD-based 115 explicit member tracking function" for multicast routers and details 116 the way for routers to implement the function. By enabling the 117 explicit tracking function, routers can keep track of the downstream 118 multicast membership state. This function implements the following 119 requirements: 121 o Per-host accounting 123 o Reducing the number of transmitted Query and Report messages 125 o Shortening leave latencies 126 o Maintaining multicast channel characteristics (or statistics) 128 where this document mainly focuses on the above second and third 129 bullets in the following sections. 131 The explicit tracking function does not change message formats used 132 by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight 133 version protocols [4]. It does not change a multicast data sender's 134 and receiver's behavior as well. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 139 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 140 this document are to be interpreted as described in RFC 2119 [1]. 142 3. Explicit Tracking Function 144 3.1. Reducing the Number of Specific Queries 146 The explicit tracking function reduces the number of Group-Specific 147 or Group-and-Source Specific Query messages transmitted from a 148 router, and then the number of Current-State Report messages 149 transmitted from member hosts. As the result, network resources used 150 for IGMP/MLD query-and-reply communications between a router and 151 member hosts can be saved. 153 According to [2] and [3], whenever a router receives the State-Change 154 Report, it sends the corresponding Group-Specific or Group-and-Source 155 Specific Query messages to confirm whether the Report sender is the 156 last member host or not. After getting these Query messages, all 157 member hosts joining the corresponding channel reply with own 158 Current-State Report messages. This condition requires transmitting 159 a number of Current-State Report messages and consumes network 160 resources especially when many hosts have been joining the same 161 channel. 163 On the other hand, if a router enables the explicit tracking 164 function, it does not need to always ask Current-State Report message 165 transmission to the member hosts whenever it receives the State- 166 Change Report. This is because the explicit tracking function works 167 with the expectation that the State-Change Report sender is the last 168 remaining member of the channel. Even if this expectation is wrong 169 (i.e., the State-Change Report sender was not the sole member), other 170 members remaining in the same channel will reply with identical 171 Report messages, so the end result is the same and no problem occurs. 172 (Section 4 details the point.) 174 In addition, the processing of IGMP membership or MLD listener 175 reports consumes CPU ressources on the IGMP/MLD querier devices 176 itself. Therefore, the explicit tracking function reduces not only 177 the network load but also the CPU load on the querier devices as 178 well. 180 3.2. Shortening Leave Latencies 182 The explicit tracking function works with the expectation that the 183 State-Change Report sender is the last remaining member of the 184 channel. Thanks to this functionality, a router can tune timers and 185 values related to decide that the State-Change Report sender was the 186 sole member. 188 The [Last Member Query Interval] (LMQI) and [Last Listener Query 189 Interval] (LLQI) values specify the maximum time allowed before 190 sending a responding Report. The [Last Member Query Count] (LMQC) 191 and [Last Listener Query Count] (LLQC) are the number of Group- 192 Specific Queries or Group-and-Source Specific Queries sent before the 193 router assumes there are no local members. The [Last Member Query 194 Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the 195 total time the router should wait for a report, after the Querier has 196 sent the first query. 198 The default values for LMQI/LLQI defined in the standard 199 specifications [2][3] are 1 second. For the router enabling the 200 explicit tracking function, LMQI/LLQI SHOULD be 1 second or shorter. 201 The LMQC/LLQC MAY be set to "1" for the router, whereas their default 202 values are the [Robustness Variable] value whose default value is 203 "2". Smaller LMQC/LLQC give smaller LMQT/LLQT; this condition 204 shortens the leave latencies. 206 3.3. Considerations 208 As with the basic concepts of IGMP and MLD, the explicit tracking 209 function does not guarantee the membership state is always perfectly 210 synchronized; routers enabling the explicit tracking function still 211 need to send IGMPv3/MLDv2 Query messages and inquire solicited 212 IGMPv3/MLDv2 Report messages from downstream members to maintain 213 downstream membership state. 215 o IGMP/MLD messages are non-reliable and may be lost in the 216 transmission, therefore routers need to confirm the membership by 217 sending Query messages. 219 o To preserve compatibility with older versions of IGMP/MLD, routers 220 need to support downstream hosts that are not upgraded to the 221 latest versions of IGMP/MLD and run the report suppression 222 mechanism. 224 o It is impossible to identify hosts when hosts send IGMP reports 225 with a source address of 0.0.0.0. 227 Regarding the last bullet, the IGMPv3 specification [2] mentions that 228 an IGMPv3 Report is usually sent with a valid IP source address, 229 although it permits that a host uses the 0.0.0.0 source address (as 230 it happens that the host has not yet acquired an IP address), and 231 routers MUST accept a report with a source address of 0.0.0.0. The 232 MLDv2 specification [3] mentions that an MLDv2 Report MUST be sent 233 with a valid IPv6 link-local source address, although an MLDv2 Report 234 can be sent with the unspecified address (::), if the sending 235 interface has not acquired a valid link-local address yet. [3] also 236 mentions that routers silently discard a message that is not sent 237 with a valid link-local address or sent with the unspecified address, 238 without taking any action, because of the security consideration. 240 Another concern is that the explicit tracking function requires 241 additional processing capability and a possibly large memory for 242 routers to keep all membership states. Especially when a router 243 needs to maintain a large number of member hosts, this resource 244 requirement may be potentially-impacted. Operators may decide to 245 disable this function when their routers do not have enough memory 246 resources. 248 4. Membership State Information 250 The explicit tracking function is implemented with the following 251 membership state information: 253 (S, G, number of receivers, (receiver records)) 255 where each receiver record is of the form: 257 (IGMP/MLD Membership/Listener Report sender's address) 259 This state information must work properly when a receiver (i.e., 260 Report sender) sends the same Report messages multiple times. 262 In the state information, each "S" and "G" indicates a single IPv4/ 263 IPv6 address. "S" is set to "Null" for an Any-Source Multicast (ASM) 264 communication (i.e., (*,G) join reception). In order to simplify the 265 implementation, the explicit tracking function does not keep the 266 state of (S,G) join with EXCLUDE filter mode. If a router receives 267 (S,G) join/leave request with EXCLUDE filter mode from the downstream 268 hosts, it translates the join/leave request to (*,G) join state/leave 269 requst and records the state and the receivers' addresses into the 270 maintained membership state information. Note that this membership 271 state translation does not change the routing protocol behavior; the 272 routing protocol must deal with the original join/leave request and 273 translate the request only for the membership state information. 275 5. Multicast Router Behavior 277 The explicit tracking function makes routers expect whether the 278 State-Change Report sender is the last remaining member of the 279 channel. Therefore the router transmits a corresponding Current- 280 State Report message only when the router thinks that the State- 281 Change Report sender is the last remaining member of the channel. 282 This contributes to saving the network resources and also shortening 283 leave latency. 285 To synchronize the membership state information, when a multicast 286 router receives a Current-State or State-Change Report message, it 287 adds the receiver IP address to or delete from the receiver records 288 or creates the corresponding membership state information. If there 289 are no more receiver records left, the membership state information 290 is deleted from the router. 292 However, the membership state information may be still outdated in 293 the router. It may be happened especially in a mobile multicast 294 environment that some member hosts have joined to or left from the 295 network without sending State-Change Report messages. Or, some 296 State-Change Report messages are lost due to network congestion. 297 Therefore, the router enabling the explicit tracking function MUST 298 send the periodic General Query regularly. 300 Regarding the leave latency, as specified in Section 3.2, the 301 explicit tracking function contributes to the fast leave by setting 302 LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1". However, if 303 LMQC/LLQC is configured "2" or bigger value, then the router's 304 behavior MAY be changed from the standard specification. According 305 to [2] and [3], a router sends a Group- (and-Source) Specific Query 306 [LMQC - 1] or [LLQC - 1] times when it receives State Change Report 307 message (e.g. leave request) from a member host, in order to confirm 308 whether or not the host is the only remaining member. However, this 309 document RECOMMENDS that if the router enabling the explicit tracking 310 function receives the corresponding Current State Report before the 311 Specific Query retransmission, it cancels sending the same Specific 312 Query for other [LMQC - 1] or [LLQC - 1] times. 314 Note that there is some risk that a router misses or looses Report 315 messages sent from remaining members if the router adopts small LMQC/ 316 LLQC; however the wrong expectation would be lower happened for the 317 router enabling the explicit tracking function. And to avoid the 318 problem, a router can start sending a Group- (and-Source) Specific 319 Query message when it expects the number of the remaining members is 320 small, such as 5, but not 0. 322 6. Interoperability and Compatibility 324 The explicit tracking function does not work with the older versions 325 of IGMP or MLD, IGMPv1 [5], IGMPv2 [6] or MLDv1 [7], because a member 326 host using these protocols adopts a report suppression mechanism by 327 which a host would cancel sending a pending membership Reports if a 328 similar Report was observed from another member on the network. 330 If a multicast router enabling the explicit tracking function changes 331 its compatibility mode to the older versions of IGMP or MLD, the 332 router SHOULD turn off the explicit tracking function but SHOULD NOT 333 flush the maintained membership state information (i.e., keep the 334 current membership state information as is). When the router changes 335 back to IGMPv3 or MLDv2 mode, it SHOULD resume the function with the 336 kept membership state information, even if the state information is 337 outdated. This manner would give "smooth state transition" that does 338 not initiate the membership state from scratch and synchronizes the 339 actual membership state smoothly. 341 There are several points TBD in the further discussions regarding the 342 interoperability and compatibility issues. At first, it is necessary 343 whether a multicast router enabling the explicit tracking function 344 needs to detect adjacent routers that do not support the explicit 345 tracking function on the link or not. After the clarification, this 346 document will describe the method how to detect them. It would be 347 done by a new signaling message, but the new message leads 348 compatibility problems for older routers or other routing protocols 349 such as PIM-DM. All of these discussions are TBD. 351 7. Security Considerations 353 TBD. 355 8. Acknowledgements 357 Toerless Eckert, Nicolai Leymann, Stig Venaas, and others provided 358 many constructive and insightful comments. 360 9. References 362 9.1. Normative References 364 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 365 levels", RFC 2119, March 1997. 367 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 368 Thyagarajan, "Internet Group Management Protocol, Version 3", 369 RFC 3376, October 2002. 371 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 372 (MLDv2) for IPv6", RFC 3810, June 2004. 374 [4] 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 9.2. Informative References 380 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 381 August 1989. 383 [6] Fenner, W., "Internet Group Management Protocol, Version 2", 384 RFC 2373, July 1997. 386 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 387 Discovery (MLD) for IPv6", RFC 2710, October 1999. 389 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 390 Group Management Protocol (IGMP) / Multicast Listener Discovery 391 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 392 RFC 4605, August 2006. 394 Authors' Addresses 396 Hitoshi Asaeda 397 Keio University 398 Graduate School of Media and Governance 399 5322 Endo 400 Fujisawa, Kanagawa 252-0882 401 Japan 403 Email: asaeda@wide.ad.jp 404 URI: http://www.sfc.wide.ad.jp/~asaeda/ 406 Yogo Uchida 407 Keio University 408 Graduate School of Media and Governance 409 5322 Endo 410 Fujisawa, Kanagawa 252-0882 411 Japan 413 Email: uchida@sfc.wide.ad.jp