idnits 2.17.1 draft-ietf-mboned-lightweight-igmpv3-mldv2-05.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 (May 22, 2009) is 5450 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: BCP Huawei Technologies Co., Ltd. 5 Expires: November 23, 2009 H. Asaeda 6 Keio University 7 May 22, 2009 9 Lightweight IGMPv3 and MLDv2 Protocols 10 draft-ietf-mboned-lightweight-igmpv3-mldv2-05 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 November 23, 2009. 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 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 66 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in RFC 2119 [1]. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Simplification Method Overview . . . . . . . . . . . . . . . . 8 74 3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 8 75 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 8 76 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 10 77 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 10 78 4.2. Action on Change of Interface State . . . . . . . . . . . 10 79 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 11 80 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 11 81 5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 13 82 5.1. Group Timers and Source Timers in the Lightweight 83 Version . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 14 85 5.3. Reception of Current-State Records . . . . . . . . . . . . 14 86 5.4. Reception of Source-List-Change and Filter-Mode-Change 87 Records . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 17 90 6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 17 91 6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 92 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 17 93 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 17 94 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 18 95 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 18 96 7. Implementation Considerations . . . . . . . . . . . . . . . . 20 97 7.1. Implementation of Source-Specific Multicast . . . . . . . 20 98 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 20 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 IGMP version 3 [2] and MLD version 2 [3] implement source filtering 109 capabilities that are not supported by their earlier versions, IGMPv1 110 [4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can 111 tell its upstream router which group it would like to join by 112 specifying which sources it does or does not intend to receive 113 multicast traffic from. IGMPv3 and MLDv2 add the capability for a 114 multicast router to learn sources which are of interest or which are 115 of not interested for a particular multicast address. This 116 information is used during forwarding of multicast data packets. 118 INCLUDE and EXCLUDE filter-modes are introduced to support the source 119 filtering function. If a host wants to receive from specific 120 sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to 121 INCLUDE. If the host does not want to receive from some sources, it 122 sends a report with filter-mode set to EXCLUDE. A source list for 123 the given sources shall be included in the report message. 125 INCLUDE and EXCLUDE filter modes are also defined in a multicast 126 router to process the IGMPv3 or MLDv2 reports. When a multicast 127 router receives the report messages from its downstream hosts, it 128 forwards the corresponding multicast traffic by managing requested 129 group and source addresses. Group timers and source timers are used 130 to maintain the forwarding state of desired groups and sources under 131 certain filter modes. When a group report arrives or a certain timer 132 expires, a multicast router may update the desired or undesired 133 source lists, reset related timer values, change filter mode, or 134 trigger group queries. With all of the above factors correlating 135 with each other, the determination rules become relatively complex, 136 as the interface states could be frequently changed. 138 The multicast filter-mode improves the ability of the multicast 139 receiver to express its desires. It is useful to support Source- 140 Specific Multicast (SSM) [7] by specifying interesting source 141 addresses with INCLUDE mode. However, practical applications do not 142 use EXCLUDE mode to block sources very often, because a user or 143 application usually wants to specify desired source addresses, not 144 undesired source addresses. Even if a user wants to explicitly 145 refuse traffic from some sources in a group, when other users in the 146 same shared network have an interest in these sources, the 147 corresponding multicast traffic is forwarded to the network. It is 148 generally unnecessary to support the filtering function that blocks 149 sources. 151 This document proposes simplified versions of IGMPv3 and MLDv2, named 152 Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2). 153 LW-IGMPv3 and LW-MLDv2 support both ASM and SSM communications 154 without a filtering function that blocks sources. Not only are they 155 compatible with the standard IGMPv3 and MLDv2, but also the protocol 156 operations made by hosts and routers or switches (performing IGMPv3/ 157 MLDv2 snooping) are simplified to reduce the complicated operations. 158 Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full 159 version of these protocols (i.e., the standard IGMPv3 and MLDv2), 160 hosts or routers that have implemented the full version do not need 161 to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 162 hosts or routers. 164 2. Terminology 166 Following notations are used in several places in this specification. 168 (*,G) join: 169 An operation triggered by a host that wants to join the group G. In 170 this case, the host receives from all sources sending to group G. 171 This is typical in the ASM communication. 173 (S,G) join: 174 An operation triggered by a host that wants to join the group G, with 175 specifying desired source S. In this case, the host receives only 176 from source S sending to group G. 178 INCLUDE (S,G) join: 179 An operation triggered by a host that wants to join a group G under 180 INCLUDE filter-mode, with specifying desired source S. The same 181 meaning of (S,G) join. 183 EXCLUDE (*,G) join: 184 An operation triggered by a host that wants to join a group G under 185 EXCLUDE filter-mode. The same meaning of (*,G) join. 187 EXCLUDE (S,G) join: 188 An operation triggered by a host that wants to join a group G under 189 EXCLUDE filter-mode, with specifying undesired source S. This 190 operation is not supported by LW-IGMPv3/LW-MLDv2. 192 3. Simplification Method Overview 194 The principle is to simplify the host and router's behavior as much 195 as possible to improve efficiency, while guaranteeing 196 interoperability with the full versions, and introducing no side 197 effects on applications. 199 For convenience, this document mainly discusses IGMPv3, since MLDv2 200 inherits the same source filtering mechanism, but this document 201 additionally shows MLDv2's unique specifications when needed. 203 3.1. Behavior of Group Members 205 In LW-IGMPv3, the same service interface model as that of IGMPv3 is 206 inherited: 208 IPMulticastListen ( socket, interface, multicast-address, 209 filter-mode, source-list ) 211 In the lightweight protocol, INCLUDE mode on the host part has the 212 same usage with the full version for INCLUDE (S,G) join, while 213 EXCLUDE mode on the host part is preserved only for excluding null 214 source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/ 215 MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is 216 described in Section 4. 218 3.2. Behavior of Multicast Routers 220 In IGMPv3, router filter-mode is defined to optimize the state 221 description of a group membership [2][3]. As a rule, once a member 222 report is in EXCLUDE mode, the router filter-mode for the group will 223 be set to EXCLUDE. When all systems cease sending EXCLUDE mode 224 reports, the filter-mode for that group may transit back to INCLUDE 225 mode. Group timer is used to identify such transition. 227 In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can 228 request an EXCLUDE (*,G) join, which can be interpreted by the router 229 as a request to include all sources. Without the more general form 230 of EXCLUDE requests, it is unnecessary for the router to maintain the 231 EXCLUDE filter-mode, and the state model for multicast router can be 232 simplified as: 234 (multicast address, group timer, (source records)) 236 Here a group timer is kept to represent a (*,G) join. Its basic 237 behavior is: when a router receives a (*,G) join, it will set its 238 group timer and keep the source list for sources specified in the 239 previously received source records. When the group timer expires, 240 the router may change to the reception for the listed sources. The 241 definition of the source record is the same as that of full version. 243 The elimination of the filter-mode will greatly simplify the router 244 behavior. The detailed operation of router operation is described in 245 Section 5. 247 4. LW-IGMPv3 Protocol for Group Members 249 4.1. Query and Report Messages 251 LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, 252 being the same as the full version protocols. There is no difference 253 between the definition and usage of the Query message. But the 254 report types in lightweight protocols are reduced because an 255 operation that triggers EXCLUDE (S,G) join is omitted. 257 There are three Group Record Types defined in the full IGMPv3: 258 Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) 259 or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by 260 CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and 261 Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or 262 BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the action on change 263 of interface state and reception of a Query, but IS_IN and IS_EX 264 record types are eliminated and Current-State Records are noted by 265 other records. The following sections explain the details. 267 4.2. Action on Change of Interface State 269 When the state of an interface of a group member host is changed, a 270 State-Change Report for that interface is immediately transmitted 271 from that interface. The type and contents of the Group Record(s) in 272 that Report are determined by comparing the filter mode and source 273 list for the affected multicast address before and after the change. 274 While the requirements are the same as the full version for the 275 computation, in the lightweight version host, the interface state 276 change rules are simplified due to the reduction of message types. 277 The contents of the new transmitted report are calculated as follows 278 (Group Record Types are described in Section 4.4): 280 Old State New State State-Change Record Sent 281 ----------- ----------- ------------------------ 283 INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) 285 INCLUDE (A) EXCLUDE ({}) TO_EX({}) 287 INCLUDE ({}) EXCLUDE ({}) TO_EX({}) 289 EXCLUDE ({}) INCLUDE (B) TO_IN(B) 291 As in the full version, to cover the possibility of the State-Change 292 Report being missed by one or more multicast routers, it is 293 retransmitted [Robustness Variable]-1 more times, at intervals chosen 294 at random from the range (0, [Unsolicited Report Interval]). (These 295 values are defined in [2][3].) 297 4.3. Action on Reception of a Query 299 As in the full version, when a lightweight version host receives a 300 Query, it does not respond immediately. Instead, it delays its 301 response by a random amount of time, bounded by the Max Resp Time 302 value derived from the Max Resp Code in the received Query message 303 [2][3]. The system may receive a variety of Queries on different 304 interfaces and of different kinds (e.g., General Queries, Group- 305 Specific Queries, and Group-and-Source-Specific Queries), each of 306 which may require its own delayed response. 308 Before scheduling a response to a Query, the system must first 309 consider previously scheduled pending responses and in many cases 310 schedule a combined response. Therefore, the lightweight version 311 host must be able to maintain the following state: 313 o A timer per interface for scheduling responses to General Queries. 315 o A per-group and interface timer for scheduling responses to Group- 316 Specific and Group-and-Source-Specific Queries. 318 o A per-group and interface list of sources to be reported in the 319 response to a Group-and-Source-Specific Query. 321 LW-IGMPv3 inherits the full version's rules that are used to 322 determine if a Report needs to be scheduled. The difference is 323 regarding the simplification of EXCLUDE filter-mode and the type of 324 Report as detailed in Section 4.4. 326 4.4. LW-IGMPv3 Group Record Types 328 Among Group Record Types defined in the full IGMPv3, several record 329 types are not used in LW-IGMPv3 as some of the processes related to 330 the filter mode change to the EXCLUDE mode are eliminated and some of 331 the report messages are converged with a record having null source 332 address list. All of the record types of report messages used by the 333 full and lightweight version protocols are shown as follows: 335 IGMPv3 LW-IGMPv3 Comments 336 --------- --------- ------------------------------------- 338 IS_EX({}) TO_EX({}) Query response for (*,G) join 340 IS_EX(x) N/A Query response for EXCLUDE (x,G) join 342 IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join 344 ALLOW(x) ALLOW(x) INCLUDE (x,G) join 346 BLOCK(x) BLOCK(x) INCLUDE (x,G) leave 348 TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join 350 TO_IN({}) TO_IN({}) (*,G) leave 352 TO_EX(x) N/A Change to EXCLUDE (x,G) join 354 TO_EX({}) TO_EX({}) (*,G) join 356 where "x" represents a non-null source address list and "({})" 357 represents null source address list. For instance, IS_EX({}) means a 358 report whose record type is IS_EX with null source address list. 359 "N/A" represents not applicable (or no use) because the corresponding 360 operation should not occur in the lightweight version protocols. 362 LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source 363 address list. A multicast router creates the same state when it 364 receives a report message containing either IS_EX({}) or TO_EX({}) 365 record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) 366 operation with the TO_EX({}) operation. 368 When a LW-IGMPv3 host needs to make a query response for the state of 369 INCLUDE (x,G) join, it makes a response whose message type is 370 expressed with ALLOW(x), instead of using the IS_IN record type. 371 Because the router's processing of the two messages is completely 372 same, the IS_IN(x) type is eliminated for simplification. 374 A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is 375 used the following situation: the host first launches an application 376 (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the 377 host launches another application (AP2) that joins (*,G), and it 378 sends TO_EX({}). In this condition, when AP2 terminates but AP1 379 keeps working on the lightweight version host, the host sends a 380 report with TO_IN(x) record type for [Robustness Variable] times. 382 5. LW-IGMPv3 Protocol for Multicast Routers 384 The major difference between the full and lightweight version 385 protocols on the router part is that for the lightweight version 386 filter-mode is discarded and the function of the group timer is 387 redefined. The states maintained by the lightweight router are 388 reduced and the protocol operation is greatly simplified. 390 5.1. Group Timers and Source Timers in the Lightweight Version 392 In lightweight and full IGMPv3 routers, a source timer is kept for 393 each source record and it is updated when the source is present in a 394 received report. It indicates the validity of the sources and needs 395 to be referred when the router takes its forwarding decision. 397 The group timer being used in the full version of IGMPv3 for 398 transitioning the router's filter-mode from EXCLUDE to INCLUDE, is 399 redefined in the lightweight protocols to identify the non-source- 400 specific receiving states maintaining for (*,G) join. Once a group 401 record of TO_EX({}) is received, the group timer is set to represent 402 this (*,G) group join. The expiration of the group timer indicates 403 that there are no more listeners on the attached network for this 404 (*,G) group. Then if at this moment there are unexpired sources 405 (whose source timers are greater than zero), the router will change 406 to receiving traffic for those sources. The role of the group timer 407 can be summarized as follows: 409 Group Timer Value Actions/Comments 410 ------------------ -------------------------------------- 412 G_Timer > 0 All members in this group. 414 G_Timer == 0 No more listeners to this (*,G) group. 415 If all source timers have expired then 416 delete group record. If there are 417 still source record timers running, 418 use those source records with running 419 timers as the source record state. 421 The operation related to the group and source timers has some 422 difference compared with the full IGMPv3. In the full version, if a 423 source timer expires under the EXCLUDE router filter-mode, its 424 corresponding source record is not deleted until the group timer 425 expires for indicating undesired sources. In the lightweight 426 version, since there is no need to keep such records for blocking 427 specific sources, if a source timer expires, its source record should 428 be deleted immediately, not waiting for the time-out of the group 429 timer. 431 5.2. Source-Specific Forwarding Rules 433 A full version multicast router needs to consult IGMPv3 state 434 information when it makes decisions on forwarding a datagram from a 435 source or its upstream router to its attached network, based on the 436 router filter-mode and source timer. In LW-IGMPv3, because of the 437 absence of the router filter-mode, the group timer and source timer 438 could be used for such decisions. The forwarding suggestion made by 439 LW-IGMPv3 to the routing protocols is summarized as follows: 441 Group Timer Source Timer Action 442 ------------ ------------------ ----------------------- 444 G_Timer == 0 S_TIMER > 0 Suggest forwarding 445 traffic from source 447 G_Timer == 0 S_TIMER == 0 Suggest stopping 448 forwarding traffic from 449 source and remove 450 source record. If there 451 are no more source 452 records for the group, 453 delete group record 455 G_Timer == 0 No Source Elements Suggest not to forward 456 traffic from the source 458 G_Timer > 0 S_TIMER >= 0 Suggest forwarding 459 traffic from source 461 G_Timer > 0 No Source Elements Suggest forwarding 462 traffic from source 464 5.3. Reception of Current-State Records 466 When receiving Current-State Records, the LW-IGMPv3 router resets its 467 group or source timers and updates its source list within the group. 468 For source-specific group reception state (when G_Timer==0 and 469 S_Timer > 0), the source list contains sources whose traffic will be 470 forwarded by the router, while in non-source-specific group reception 471 (when G_Timer>0), the source list remembers the valid sources to 472 receive traffic from after toggling to source-specific reception 473 state. 475 Although the LW-IGMPv3 host only sends a subset of the message of 476 that of the full version, the LW-IGMPv3 router should be able to 477 process as much messages as possible to be compatible with the full 478 version host. Note that if the report type is IS_EX(x) with non- 479 empty source-list, the router will treat it as the same type of 480 report with empty source list. The following table describes the 481 action taken by a multicast router after receiving Current-State 482 Records. The notations have the same meaning as that in the full 483 IGMPv3 protocol. 485 Old New 486 Source Source 487 Group Timer List Report Rec'd List Actions 488 ------------ ------ ------------ ------ ----------- 490 G_Timer == 0 A IS_IN(B) A+B (B)=GMI 492 G_Timer == 0 A IS_EX({}) A G_Timer=GMI 494 G_Timer > 0 A IS_IN(B) A+B (B)=GMI 496 G_Timer > 0 A IS_EX({}) A G_Timer=GMI 498 The above table could be further simplified for the processes that 499 are completely same for the two values of the G_Timer: 501 Old New 502 Source Source 503 List Report Rec'd List Actions 504 ------ ------------ ------ ----------- 506 A IS_IN(B) A+B (B)=GMI 508 A IS_EX({}) A G_Timer=GMI 510 Without EXCLUDE filter-mode, a router's process on receiving Current- 511 State Record is simple: when a router receives an IS_IN report, it 512 appends the reported source addresses to the previous source list 513 with their source timers set to GMI. Upon receiving an IS_EX({}) 514 report, the router sets the non-source-specific receiving states by 515 resetting the group timer value and keeps the previous source list 516 without modification. 518 5.4. Reception of Source-List-Change and Filter-Mode-Change Records 520 On receiving Source-List-Change and Filter-Mode-Change Records, the 521 LW-IGMPv3 router needs to reset its group and source timers, update 522 its source list within the group, or trigger group queries. The 523 queries are sent by the router for the sources that are requested to 524 be no longer forwarded to a group. Note that if the report type is 525 TO_EX(x) with non-empty source-list, the router will treat it as the 526 same type of report with empty source list. The table below 527 describes the state change and the actions that should be taken. 529 Old New 530 Source Source 531 Group Timer List Report Rec'd List Actions 532 ------------ ------ ------------ ------ ------------- 534 G_Timer == 0 A ALLOW(B) A+B (B)=GMI 536 G_Timer == 0 A BLOCK(B) A Send Q(G,A*B) 538 G_Timer == 0 A TO_IN(B) A+B (B)=GMI 539 Send Q(G,A-B) 541 G_Timer == 0 A TO_EX({}) A G_Timer=GMI 543 G_Timer > 0 A ALLOW(B) A+B (B)=GMI 545 G_Timer > 0 A BLOCK(B) A Send Q(G,A*B) 547 G_Timer > 0 A TO_IN(B) A+B (B)=GMI 548 SendQ(G,A-B) 549 Send Q(G) 551 G_Timer > 0 A TO_EX({}) A G_Timer=GMI 553 The table could be further simplified by merging duplicate lines: 555 Old New 556 Source Source 557 List Report Rec'd List Actions 558 ------ ------------ ------ ---------------------- 560 A ALLOW(B) A+B (B)=GMI 562 A BLOCK(B) A Send Q(G,A*B) 564 A TO_IN(B) A+B (B)=GMI 565 Send Q(G,A-B) 566 If G_Timer>0 Send Q(G) 567 A TO_EX({}) A G_Timer=GMI 569 6. Interoperability 571 LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and 572 routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts 573 and routers must interoperate gracefully with hosts and routers 574 running IGMPv1/v2 or MLDv1. 576 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 578 LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format 579 of the group query and report messages the full version protocols 580 use. 582 6.1.1. Behavior of Group Members 584 A LW-IGMPv3 host's compatibility mode is determined from the Host 585 Compatibility Mode variable which can be in one of three states: 586 IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its 587 interface as LW-IGMPv3, its Host Compatibility Mode of that interface 588 is set to IGMPv3, and the host sends a subset of IGMPv3 report 589 messages, which can be recognized by a multicast router running the 590 full or the lightweight IGMPv3 protocol on the same LAN. 592 6.1.2. Behavior of Multicast Routers 594 A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and 595 TO_EX(x) records that are used by the full version. When a LW- 596 IGMPv3/LW-MLDv2 router receives these report messages from the full 597 version host, it MUST translate them internally to IS_EX({}) and 598 TO_EX({}) respectively and behaves accordingly. 600 6.2. Interoperation with IGMPv1/IGMPv2 602 Since the lightweight protocols can be treated as the parallel 603 version of full version of IGMPv3/MLDv2, its compatibility principle 604 and method with the older version are generally the same as that of 605 full IGMPv3/MLDv2. 607 6.2.1. Behavior of Group Members 609 The Host Compatibility Mode of an interface is set to IGMPv2 and its 610 IGMPv2 Querier Present timer is set to Older Version Querier Present 611 Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is 612 received on that interface. The Host Compatibility Mode of an 613 interface is set to IGMPv1 and its IGMPv1 Querier Present timer is 614 set to Older Version Querier Present Timeout seconds whenever an 615 IGMPv1 Membership Query is received on that interface. 617 In the presence of older version group members, LW-IGMPv3 hosts may 618 allow its report message to be suppressed by either an IGMPv1 or 619 IGMPv2 membership report. However, because the transmission of 620 IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, 621 as a potential protection mechanism, the choice to enable or disable 622 the use of backward compatibility may be configurable. 624 6.2.2. Behavior of Multicast Routers 626 The behavior of a LW-IGMPv3 router when placed on a network where 627 there are routers that have not been upgraded to IGMPv3, is 628 completely the same with a full IGMPv3 router in this situation [2]. 630 A full IGMPv3 router uses Group Compatibility Mode (whose value is 631 either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate 632 which version of IGMP protocol it behaves for the group. This value 633 is set according to the version of the received IGMP report. When 634 Group Compatibility Mode is IGMPv3, the lightweight router acts with 635 LW-IGMPv3 protocol for that group. 637 When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits 638 this compatibility mechanism with the following rules: 640 IGMP Message LW-IGMPv3 Equivalent 641 -------------- -------------------- 643 v2 Report TO_EX({}) 645 v2 Leave TO_IN({}) 647 When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router 648 internally translates the following IGMPv1 and IGMPv2 messages for 649 that group to their LW-IGMPv3 equivalents: 651 IGMP Message LW-IGMPv3 Equivalent 652 -------------- -------------------- 654 v1 Report TO_EX({}) 656 v2 Report TO_EX({}) 658 6.3. Interoperation with MLDv1 660 LW-MLDv2 hosts and routers MUST interoperate with the hosts and 661 routers running MLDv1. The method is the same as described in 662 Section 6.2. The difference is that when a LW-MLDv2 router has a 663 MLDv1 listener on its network, it translates the following MLDv1 664 messages to their LW-MLDv2 equivalents: 666 MLDv1 Message LW-MLDv2 Equivalent 667 ------------- ------------------- 669 Report TO_EX({}) 671 Done TO_IN({}) 673 7. Implementation Considerations 675 The lightweight protocols require no additional procedure on the 676 implementation of the related protocols or systems, e.g. IGMP/MLD 677 snooping, multicast routing protocol, and operation of application 678 sockets, while the processing loads on the switches and routers that 679 running IGMPv3/MLDv2 (snooping) and multicast routing protocols may 680 be greatly decreased. 682 In the following sections, the implementation related aspects are 683 described for the lightweight version protocols. 685 7.1. Implementation of Source-Specific Multicast 687 [8] illustrates the requirements of implementation of Source-Specific 688 Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight 689 protocol follows the same rule given in [8] except the changing of 690 the message types due to the simplification. 692 A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., 693 TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for the application 694 whose multicast address is in the SSM address range. The upstream 695 LW-IGMPv3/LW-MLDv2 router will ignore the these messages and may log 696 an error on reception of them. Other types of messages should be 697 processed as [8] describes. 699 7.2. Implementation of Multicast Source Filter (MSF) APIs 701 Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF 702 API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF 703 API, and (4) Protocol-Independent Advanced MSF API. 705 According to the MSF APIs definition, a LW-IGMPv3 host should 706 implement either IPv4 Basic MSF API or Protocol-Independent Basic MSF 707 API, and a LW-MLDv2 host should implement Protocol-Independent Basic 708 MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent 709 Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2 710 host. 712 8. Security Considerations 714 The security considerations are the same as that of the full version 715 of IGMPv3/MLDv2. 717 9. Acknowledgements 719 The authors would like to appreciate MBONED and MAGMA working group 720 members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark 721 Fine, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and 722 Gong Xiangyang for their valuable comments and suggestions on this 723 document. 725 10. References 727 10.1. Normative References 729 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 730 levels", RFC 2119, March 1997. 732 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 733 Thyagarajan, "Internet Group Management Protocol, Version 3", 734 RFC 3376, October 2002. 736 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 737 (MLDv2) for IPv6", RFC 3810, June 2004. 739 [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 740 August 1989. 742 [5] Fenner, W., "Internet Group Management Protocol, Version 2", 743 RFC 2236, November 1997. 745 [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 746 Discovery (MLD) for IPv6", RFC 2710, October 1999. 748 [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 749 RFC 4607, August 2006. 751 [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group 752 Management Protocol Version 3 (IGMPv3) and Multicast Listener 753 Discovery Protocol Version 2 (MLDv2) for Source-Specific 754 Multicast", RFC 4604, August 2006. 756 10.2. Informative References 758 [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 759 Extensions for Multicast Source Filters", RFC 3678, 760 January 2004. 762 Authors' Addresses 764 Hui Liu 765 Huawei Technologies Co., Ltd. 766 Huawei Bld., No.3 Xinxi Rd. 767 Shang-Di Information Industry Base 768 Hai-Dian Distinct, Beijing 100085 769 China 771 Email: Liuhui47967@huawei.com 773 Wei Cao 774 Huawei Technologies Co., Ltd. 775 Huawei Bld., No.3 Xinxi Rd. 776 Shang-Di Information Industry Base 777 Hai-Dian Distinct, Beijing 100085 778 China 780 Email: caowayne@huawei.com 782 Hitoshi Asaeda 783 Keio University 784 Graduate School of Media and Governance 785 5322 Endo 786 Fujisawa, Kanagawa 252-8520 787 Japan 789 Email: asaeda@wide.ad.jp