idnits 2.17.1 draft-ietf-mboned-lightweight-igmpv3-mldv2-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 14, 2009) is 5301 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group H. Liu 3 Internet-Draft W. Cao 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 17, 2010 H. Asaeda 6 Keio University 7 October 14, 2009 9 Lightweight IGMPv3 and MLDv2 Protocols 10 draft-ietf-mboned-lightweight-igmpv3-mldv2-06 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 17, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes lightweight IGMPv3 and MLDv2 protocols (LW- 59 IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of 60 IGMPv3 and MLDv2. The interoperability with the full versions and 61 the previous versions of IGMP and MLD is also taken into account. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Simplification Method Overview . . . . . . . . . . . . . . . . 7 68 3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 7 69 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7 70 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9 71 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9 72 4.2. Action on Change of Interface State . . . . . . . . . . . 9 73 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10 74 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10 75 5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 76 5.1. Group Timers and Source Timers in the Lightweight 77 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 79 5.3. Reception of Current-State Records . . . . . . . . . . . . 13 80 5.4. Reception of Source-List-Change and Filter-Mode-Change 81 Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 83 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16 84 6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 16 85 6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 16 86 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 87 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 88 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 89 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 17 90 7. Implementation Considerations . . . . . . . . . . . . . . . . 19 91 7.1. Implementation of Source-Specific Multicast . . . . . . . 19 92 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 97 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 IGMP version 3 [2] and MLD version 2 [3] implement source filtering 103 capabilities that are not supported by their earlier versions, IGMPv1 104 [4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can 105 tell its upstream router which group it would like to join by 106 specifying which sources it does or does not intend to receive 107 multicast traffic from. IGMPv3 and MLDv2 add the capability for a 108 multicast router to learn sources which are of interest or which are 109 of not interested for a particular multicast address. This 110 information is used during forwarding of multicast data packets. 112 INCLUDE and EXCLUDE filter-modes are introduced to support the source 113 filtering function. If a host wants to receive from specific 114 sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to 115 INCLUDE. If the host does not want to receive from some sources, it 116 sends a report with filter-mode set to EXCLUDE. A source list for 117 the given sources shall be included in the report message. 119 INCLUDE and EXCLUDE filter modes are also defined in a multicast 120 router to process the IGMPv3 or MLDv2 reports. When a multicast 121 router receives the report messages from its downstream hosts, it 122 forwards the corresponding multicast traffic by managing requested 123 group and source addresses. Group timers and source timers are used 124 to maintain the forwarding state of desired groups and sources under 125 certain filter modes. When a group report arrives or a certain timer 126 expires, a multicast router may update the desired or undesired 127 source lists, reset related timer values, change filter mode, or 128 trigger group queries. With all of the above factors correlating 129 with each other, the determination rules become relatively complex, 130 as the interface states could be frequently changed. 132 The multicast filter-mode improves the ability of the multicast 133 receiver to express its desires. It is useful to support Source- 134 Specific Multicast (SSM) [7] by specifying interesting source 135 addresses with INCLUDE mode. However, practical applications do not 136 use EXCLUDE mode to block sources very often, because a user or 137 application usually wants to specify desired source addresses, not 138 undesired source addresses. Even if a user wants to explicitly 139 refuse traffic from some sources in a group, when other users in the 140 same shared network have an interest in these sources, the 141 corresponding multicast traffic is forwarded to the network. It is 142 generally unnecessary to support the filtering function that blocks 143 sources. 145 This document proposes simplified versions of IGMPv3 and MLDv2, named 146 Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2). 147 LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2. 149 These protocols support both ASM and SSM communications without a 150 filtering function that blocks sources. Not only are they compatible 151 with the standard IGMPv3 and MLDv2, but also the protocol operations 152 made by hosts and routers or switches (performing IGMPv3/MLDv2 153 snooping) are simplified to reduce the complicated operations. Since 154 LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2, 155 hosts or routers that have implemented the full version do not need 156 to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 157 hosts or routers. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 162 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in RFC 2119 [1]. 165 In addition, the following terms are used in this document. 167 (*,G) join: 168 An operation triggered by a host that wants to join the group G. In 169 this case, the host receives from all sources sending to group G. 170 This is typical in the ASM communication. 172 (S,G) join: 173 An operation triggered by a host that wants to join the group G, with 174 specifying desired source S. In this case, the host receives only 175 from source S sending to group G. 177 INCLUDE (S,G) join: 178 An operation triggered by a host that wants to join a group G under 179 INCLUDE filter-mode, with specifying desired source S. The same 180 meaning of (S,G) join. 182 EXCLUDE (*,G) join: 183 An operation triggered by a host that wants to join a group G under 184 EXCLUDE filter-mode. The same meaning of (*,G) join. 186 EXCLUDE (S,G) join: 187 An operation triggered by a host that wants to join a group G under 188 EXCLUDE filter-mode, with specifying undesired source S. This 189 operation is not supported by LW-IGMPv3/LW-MLDv2. 191 3. Simplification Method Overview 193 The principle is to simplify the host and router's behavior as much 194 as possible to improve efficiency, while guaranteeing 195 interoperability with the full versions, and introducing no side 196 effects on applications. 198 For convenience, this document mainly discusses IGMPv3, since MLDv2 199 inherits the same source filtering mechanism, but this document 200 additionally shows MLDv2's unique specifications when needed. 202 3.1. Behavior of Group Members 204 In LW-IGMPv3, the same service interface model as that of IGMPv3 is 205 inherited: 207 IPMulticastListen ( socket, interface, multicast-address, 208 filter-mode, source-list ) 210 In the lightweight protocol, INCLUDE mode on the host part has the 211 same usage with the full version for INCLUDE (S,G) join, while 212 EXCLUDE mode on the host part is preserved only for excluding null 213 source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/ 214 MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is 215 described in Section 4. 217 3.2. Behavior of Multicast Routers 219 In IGMPv3, router filter-mode is defined to optimize the state 220 description of a group membership [2][3]. As a rule, once a member 221 report is in EXCLUDE mode, the router filter-mode for the group will 222 be set to EXCLUDE. When all systems cease sending EXCLUDE mode 223 reports, the filter-mode for that group may transit back to INCLUDE 224 mode. Group timer is used to identify such transition. 226 In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can 227 request an EXCLUDE (*,G) join, which can be interpreted by the router 228 as a request to include all sources. Without the more general form 229 of EXCLUDE requests, it is unnecessary for the router to maintain the 230 EXCLUDE filter-mode, and the state model for multicast router can be 231 simplified as: 233 (multicast address, group timer, (source records)) 235 Here a group timer is kept to represent a (*,G) join. Its basic 236 behavior is: when a router receives a (*,G) join, it will set its 237 group timer and keep the source list for sources specified in the 238 previously received source records. When the group timer expires, 239 the router may change to the reception for the listed sources. The 240 definition of the source record is the same as that of full version. 242 The elimination of the filter-mode will greatly simplify the router 243 behavior. The detailed operation of router operation is described in 244 Section 5. 246 4. LW-IGMPv3 Protocol for Group Members 248 4.1. Query and Report Messages 250 LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, 251 being the same as the full version protocols. There is no difference 252 between the definition and usage of the Query message. But the 253 report types in lightweight protocols are reduced because an 254 operation that triggers EXCLUDE (S,G) join is omitted. 256 There are three Group Record Types defined in the full IGMPv3: 257 Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) 258 or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by 259 CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and 260 Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or 261 BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the action on change 262 of interface state and reception of a Query, but IS_IN and IS_EX 263 record types are eliminated and Current-State Records are noted by 264 other records. The following sections explain the details. 266 4.2. Action on Change of Interface State 268 When the state of an interface of a group member host is changed, a 269 State-Change Report for that interface is immediately transmitted 270 from that interface. The type and contents of the Group Record(s) in 271 that Report are determined by comparing the filter mode and source 272 list for the affected multicast address before and after the change. 273 While the requirements are the same as the full version for the 274 computation, in the lightweight version host, the interface state 275 change rules are simplified due to the reduction of message types. 276 The contents of the new transmitted report are calculated as follows 277 (Group Record Types are described in Section 4.4): 279 Old State New State State-Change Record Sent 280 ----------- ----------- ------------------------ 282 INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) 284 INCLUDE (A) EXCLUDE ({}) TO_EX({}) 286 INCLUDE ({}) EXCLUDE ({}) TO_EX({}) 288 EXCLUDE ({}) INCLUDE (B) TO_IN(B) 290 As in the full version, to cover the possibility of the State-Change 291 Report being missed by one or more multicast routers, it is 292 retransmitted [Robustness Variable]-1 more times, at intervals chosen 293 at random from the range (0, [Unsolicited Report Interval]). (These 294 values are defined in [2][3].) 296 4.3. Action on Reception of a Query 298 As in the full version, when a lightweight version host receives a 299 Query, it does not respond immediately. Instead, it delays its 300 response by a random amount of time, bounded by the Max Resp Time 301 value derived from the Max Resp Code in the received Query message 302 [2][3]. The system may receive a variety of Queries on different 303 interfaces and of different kinds (e.g., General Queries, Group- 304 Specific Queries, and Group-and-Source-Specific Queries), each of 305 which may require its own delayed response. 307 Before scheduling a response to a Query, the system must first 308 consider previously scheduled pending responses and in many cases 309 schedule a combined response. Therefore, the lightweight version 310 host must be able to maintain the following state: 312 o A timer per interface for scheduling responses to General Queries. 314 o A per-group and interface timer for scheduling responses to Group- 315 Specific and Group-and-Source-Specific Queries. 317 o A per-group and interface list of sources to be reported in the 318 response to a Group-and-Source-Specific Query. 320 LW-IGMPv3 inherits the full version's rules that are used to 321 determine if a Report needs to be scheduled. The difference is 322 regarding the simplification of EXCLUDE filter-mode and the type of 323 Report as detailed in Section 4.4. 325 4.4. LW-IGMPv3 Group Record Types 327 Among Group Record Types defined in the full IGMPv3, several record 328 types are not used in LW-IGMPv3 as some of the processes related to 329 the filter mode change to the EXCLUDE mode are eliminated and some of 330 the report messages are converged with a record having null source 331 address list. All of the record types of report messages used by the 332 full and lightweight version protocols are shown as follows: 334 IGMPv3 LW-IGMPv3 Comments 335 --------- --------- ------------------------------------- 337 IS_EX({}) TO_EX({}) Query response for (*,G) join 339 IS_EX(x) N/A Query response for EXCLUDE (x,G) join 341 IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join 343 ALLOW(x) ALLOW(x) INCLUDE (x,G) join 345 BLOCK(x) BLOCK(x) INCLUDE (x,G) leave 347 TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join 349 TO_IN({}) TO_IN({}) (*,G) leave 351 TO_EX(x) N/A Change to EXCLUDE (x,G) join 353 TO_EX({}) TO_EX({}) (*,G) join 355 where "x" represents a non-null source address list and "({})" 356 represents null source address list. For instance, IS_EX({}) means a 357 report whose record type is IS_EX with null source address list. 358 "N/A" represents not applicable (or no use) because the corresponding 359 operation should not occur in the lightweight version protocols. 361 LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source 362 address list. A multicast router creates the same state when it 363 receives a report message containing either IS_EX({}) or TO_EX({}) 364 record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) 365 operation with the TO_EX({}) operation. 367 When a LW-IGMPv3 host needs to make a query response for the state of 368 INCLUDE (x,G) join, it makes a response whose message type is 369 expressed with ALLOW(x), instead of using the IS_IN record type. 370 Because the router's processing of the two messages is completely 371 same, the IS_IN(x) type is eliminated for simplification. 373 A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is 374 used the following situation: the host first launches an application 375 (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the 376 host launches another application (AP2) that joins (*,G), and it 377 sends TO_EX({}). In this condition, when AP2 terminates but AP1 378 keeps working on the lightweight version host, the host sends a 379 report with TO_IN(x) record type for [Robustness Variable] times. 381 5. LW-IGMPv3 Protocol for Multicast Routers 383 The major difference between the full and lightweight version 384 protocols on the router part is that for the lightweight version 385 filter-mode is discarded and the function of the group timer is 386 redefined. The states maintained by the lightweight router are 387 reduced and the protocol operation is greatly simplified. 389 5.1. Group Timers and Source Timers in the Lightweight Version 391 In lightweight and full IGMPv3 routers, a source timer is kept for 392 each source record and it is updated when the source is present in a 393 received report. It indicates the validity of the sources and needs 394 to be referred when the router takes its forwarding decision. 396 The group timer being used in the full version of IGMPv3 for 397 transitioning the router's filter-mode from EXCLUDE to INCLUDE, is 398 redefined in the lightweight protocols to identify the non-source- 399 specific receiving states maintaining for (*,G) join. Once a group 400 record of TO_EX({}) is received, the group timer is set to represent 401 this (*,G) group join. The expiration of the group timer indicates 402 that there are no more listeners on the attached network for this 403 (*,G) group. Then if at this moment there are unexpired sources 404 (whose source timers are greater than zero), the router will change 405 to receiving traffic for those sources. The role of the group timer 406 can be summarized as follows: 408 Group Timer Value Actions/Comments 409 ------------------ -------------------------------------- 411 G_Timer > 0 All members in this group. 413 G_Timer == 0 No more listeners to this (*,G) group. 414 If all source timers have expired then 415 delete group record. If there are 416 still source record timers running, 417 use those source records with running 418 timers as the source record state. 420 The operation related to the group and source timers has some 421 difference compared with the full IGMPv3. In the full version, if a 422 source timer expires under the EXCLUDE router filter-mode, its 423 corresponding source record is not deleted until the group timer 424 expires for indicating undesired sources. In the lightweight 425 version, since there is no need to keep such records for blocking 426 specific sources, if a source timer expires, its source record should 427 be deleted immediately, not waiting for the time-out of the group 428 timer. 430 5.2. Source-Specific Forwarding Rules 432 A full version multicast router needs to consult IGMPv3 state 433 information when it makes decisions on forwarding a datagram from a 434 source or its upstream router to its attached network, based on the 435 router filter-mode and source timer. In LW-IGMPv3, because of the 436 absence of the router filter-mode, the group timer and source timer 437 could be used for such decisions. The forwarding suggestion made by 438 LW-IGMPv3 to the routing protocols is summarized as follows: 440 Group Timer Source Timer Action 441 ------------ ------------------ ----------------------- 443 G_Timer == 0 S_TIMER > 0 Suggest forwarding 444 traffic from source 446 G_Timer == 0 S_TIMER == 0 Suggest stopping 447 forwarding traffic from 448 source and remove 449 source record. If there 450 are no more source 451 records for the group, 452 delete group record 454 G_Timer == 0 No Source Elements Suggest not to forward 455 traffic from the source 457 G_Timer > 0 S_TIMER >= 0 Suggest forwarding 458 traffic from source 460 G_Timer > 0 No Source Elements Suggest forwarding 461 traffic from source 463 5.3. Reception of Current-State Records 465 When receiving Current-State Records, the LW-IGMPv3 router resets its 466 group or source timers and updates its source list within the group. 467 For source-specific group reception state (when G_Timer==0 and 468 S_Timer > 0), the source list contains sources whose traffic will be 469 forwarded by the router, while in non-source-specific group reception 470 (when G_Timer>0), the source list remembers the valid sources to 471 receive traffic from after toggling to source-specific reception 472 state. 474 Although the LW-IGMPv3 host only sends a subset of the message of 475 that of the full version, the LW-IGMPv3 router should be able to 476 process as much messages as possible to be compatible with the full 477 version host. Note that if the report type is IS_EX(x) with non- 478 empty source-list, the router will treat it as the same type of 479 report with empty source list. The following table describes the 480 action taken by a multicast router after receiving Current-State 481 Records. The notations have the same meaning as that in the full 482 IGMPv3 protocol. 484 Old New 485 Source Source 486 Group Timer List Report Rec'd List Actions 487 ------------ ------ ------------ ------ ----------- 489 G_Timer == 0 A IS_IN(B) A+B (B)=GMI 491 G_Timer == 0 A IS_EX({}) A G_Timer=GMI 493 G_Timer > 0 A IS_IN(B) A+B (B)=GMI 495 G_Timer > 0 A IS_EX({}) A G_Timer=GMI 497 The above table could be further simplified for the processes that 498 are completely same for the two values of the G_Timer: 500 Old New 501 Source Source 502 List Report Rec'd List Actions 503 ------ ------------ ------ ----------- 505 A IS_IN(B) A+B (B)=GMI 507 A IS_EX({}) A G_Timer=GMI 509 Without EXCLUDE filter-mode, a router's process on receiving Current- 510 State Record is simple: when a router receives an IS_IN report, it 511 appends the reported source addresses to the previous source list 512 with their source timers set to GMI. Upon receiving an IS_EX({}) 513 report, the router sets the non-source-specific receiving states by 514 resetting the group timer value and keeps the previous source list 515 without modification. 517 5.4. Reception of Source-List-Change and Filter-Mode-Change Records 519 On receiving Source-List-Change and Filter-Mode-Change Records, the 520 LW-IGMPv3 router needs to reset its group and source timers, update 521 its source list within the group, or trigger group queries. The 522 queries are sent by the router for the sources that are requested to 523 be no longer forwarded to a group. Note that if the report type is 524 TO_EX(x) with non-empty source-list, the router will treat it as the 525 same type of report with empty source list. The table below 526 describes the state change and the actions that should be taken. 528 Old New 529 Source Source 530 Group Timer List Report Rec'd List Actions 531 ------------ ------ ------------ ------ ------------- 533 G_Timer == 0 A ALLOW(B) A+B (B)=GMI 535 G_Timer == 0 A BLOCK(B) A Send Q(G,A*B) 537 G_Timer == 0 A TO_IN(B) A+B (B)=GMI 538 Send Q(G,A-B) 540 G_Timer == 0 A TO_EX({}) A G_Timer=GMI 542 G_Timer > 0 A ALLOW(B) A+B (B)=GMI 544 G_Timer > 0 A BLOCK(B) A Send Q(G,A*B) 546 G_Timer > 0 A TO_IN(B) A+B (B)=GMI 547 SendQ(G,A-B) 548 Send Q(G) 550 G_Timer > 0 A TO_EX({}) A G_Timer=GMI 552 The table could be further simplified by merging duplicate lines: 554 Old New 555 Source Source 556 List Report Rec'd List Actions 557 ------ ------------ ------ ---------------------- 559 A ALLOW(B) A+B (B)=GMI 561 A BLOCK(B) A Send Q(G,A*B) 563 A TO_IN(B) A+B (B)=GMI 564 Send Q(G,A-B) 565 If G_Timer>0 Send Q(G) 566 A TO_EX({}) A G_Timer=GMI 568 6. Interoperability 570 LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and 571 routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts 572 and routers must interoperate gracefully with hosts and routers 573 running IGMPv1/v2 or MLDv1. 575 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 577 LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format 578 of the group query and report messages the full version protocols 579 use. 581 6.1.1. Behavior of Group Members 583 A LW-IGMPv3 host's compatibility mode is determined from the Host 584 Compatibility Mode variable which can be in one of three states: 585 IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its 586 interface as LW-IGMPv3, its Host Compatibility Mode of that interface 587 is set to IGMPv3, and the host sends a subset of IGMPv3 report 588 messages, which can be recognized by a multicast router running the 589 full or the lightweight IGMPv3 protocol on the same LAN. 591 6.1.2. Behavior of Multicast Routers 593 A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and 594 TO_EX(x) records that are used by the full version. When a LW- 595 IGMPv3/LW-MLDv2 router receives these report messages from the full 596 version host, it MUST translate them internally to IS_EX({}) and 597 TO_EX({}) respectively and behaves accordingly. 599 6.2. Interoperation with IGMPv1/IGMPv2 601 Since the lightweight protocols can be treated as the parallel 602 version of full version of IGMPv3/MLDv2, its compatibility principle 603 and method with the older version are generally the same as that of 604 full IGMPv3/MLDv2. 606 6.2.1. Behavior of Group Members 608 The Host Compatibility Mode of an interface is set to IGMPv2 and its 609 IGMPv2 Querier Present timer is set to Older Version Querier Present 610 Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is 611 received on that interface. The Host Compatibility Mode of an 612 interface is set to IGMPv1 and its IGMPv1 Querier Present timer is 613 set to Older Version Querier Present Timeout seconds whenever an 614 IGMPv1 Membership Query is received on that interface. 616 In the presence of older version group members, LW-IGMPv3 hosts may 617 allow its report message to be suppressed by either an IGMPv1 or 618 IGMPv2 membership report. However, because the transmission of 619 IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, 620 as a potential protection mechanism, the choice to enable or disable 621 the use of backward compatibility may be configurable. 623 6.2.2. Behavior of Multicast Routers 625 The behavior of a LW-IGMPv3 router when placed on a network where 626 there are routers that have not been upgraded to IGMPv3, is 627 completely the same with a full IGMPv3 router in this situation [2]. 629 A full IGMPv3 router uses Group Compatibility Mode (whose value is 630 either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate 631 which version of IGMP protocol it behaves for the group. This value 632 is set according to the version of the received IGMP report. When 633 Group Compatibility Mode is IGMPv3, the lightweight router acts with 634 LW-IGMPv3 protocol for that group. 636 When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits 637 this compatibility mechanism with the following rules: 639 IGMP Message LW-IGMPv3 Equivalent 640 -------------- -------------------- 642 v2 Report TO_EX({}) 644 v2 Leave TO_IN({}) 646 When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router 647 internally translates the following IGMPv1 and IGMPv2 messages for 648 that group to their LW-IGMPv3 equivalents: 650 IGMP Message LW-IGMPv3 Equivalent 651 -------------- -------------------- 653 v1 Report TO_EX({}) 655 v2 Report TO_EX({}) 657 6.3. Interoperation with MLDv1 659 LW-MLDv2 hosts and routers MUST interoperate with the hosts and 660 routers running MLDv1. The method is the same as described in 661 Section 6.2. The difference is that when a LW-MLDv2 router has a 662 MLDv1 listener on its network, it translates the following MLDv1 663 messages to their LW-MLDv2 equivalents: 665 MLDv1 Message LW-MLDv2 Equivalent 666 ------------- ------------------- 668 Report TO_EX({}) 670 Done TO_IN({}) 672 7. Implementation Considerations 674 The lightweight protocols require no additional procedure on the 675 implementation of the related protocols or systems, e.g. IGMP/MLD 676 snooping, multicast routing protocol, and operation of application 677 sockets, while the processing loads on the switches and routers that 678 running IGMPv3/MLDv2 (snooping) and multicast routing protocols may 679 be greatly decreased. 681 In the following sections, the implementation related aspects are 682 described for the lightweight version protocols. 684 7.1. Implementation of Source-Specific Multicast 686 [8] illustrates the requirements of implementation of Source-Specific 687 Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight 688 protocol follows the same rule given in [8] except the changing of 689 the message types due to the simplification. 691 A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., 692 TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for the application 693 whose multicast address is in the SSM address range. The upstream 694 LW-IGMPv3/LW-MLDv2 router will ignore the these messages and may log 695 an error on reception of them. Other types of messages should be 696 processed as [8] describes. 698 7.2. Implementation of Multicast Source Filter (MSF) APIs 700 Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF 701 API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF 702 API, and (4) Protocol-Independent Advanced MSF API. 704 According to the MSF APIs definition, a LW-IGMPv3 host should 705 implement either IPv4 Basic MSF API or Protocol-Independent Basic MSF 706 API, and a LW-MLDv2 host should implement Protocol-Independent Basic 707 MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent 708 Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2 709 host. 711 8. Security Considerations 713 The security considerations are the same as that of the full version 714 of IGMPv3/MLDv2. 716 9. Acknowledgements 718 The authors would like to appreciate MBONED and MAGMA working group 719 members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark 720 Fine, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and 721 Gong Xiangyang for their valuable comments and suggestions on this 722 document. 724 10. References 726 10.1. Normative References 728 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 729 levels", RFC 2119, March 1997. 731 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 732 Thyagarajan, "Internet Group Management Protocol, Version 3", 733 RFC 3376, October 2002. 735 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 736 (MLDv2) for IPv6", RFC 3810, June 2004. 738 [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 739 August 1989. 741 [5] Fenner, W., "Internet Group Management Protocol, Version 2", 742 RFC 2236, November 1997. 744 [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 745 Discovery (MLD) for IPv6", RFC 2710, October 1999. 747 [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 748 RFC 4607, August 2006. 750 [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group 751 Management Protocol Version 3 (IGMPv3) and Multicast Listener 752 Discovery Protocol Version 2 (MLDv2) for Source-Specific 753 Multicast", RFC 4604, August 2006. 755 10.2. Informative References 757 [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 758 Extensions for Multicast Source Filters", RFC 3678, 759 January 2004. 761 Authors' Addresses 763 Hui Liu 764 Huawei Technologies Co., Ltd. 765 Huawei Bld., No.3 Xinxi Rd. 766 Shang-Di Information Industry Base 767 Hai-Dian Distinct, Beijing 100085 768 China 770 Email: Liuhui47967@huawei.com 772 Wei Cao 773 Huawei Technologies Co., Ltd. 774 Huawei Bld., No.3 Xinxi Rd. 775 Shang-Di Information Industry Base 776 Hai-Dian Distinct, Beijing 100085 777 China 779 Email: caowayne@huawei.com 781 Hitoshi Asaeda 782 Keio University 783 Graduate School of Media and Governance 784 5322 Endo 785 Fujisawa, Kanagawa 252-8520 786 Japan 788 Email: asaeda@wide.ad.jp