idnits 2.17.1 draft-ietf-mboned-lightweight-igmpv3-mldv2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 803. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 6, 2008) is 5705 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 (==), 7 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: March 10, 2009 H. Asaeda 6 Keio University 7 September 6, 2008 9 Lightweight IGMPv3 and MLDv2 Protocols 10 draft-ietf-mboned-lightweight-igmpv3-mldv2-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 10, 2009. 37 Abstract 39 This document describes lightweight IGMPv3 and MLDv2 protocols (LW- 40 IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of 41 IGMPv3 and MLDv2. The interoperability with the full versions and 42 the previous versions of IGMP and MLD is also taken into account. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 47 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in RFC 2119 [1]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. Simplification Method Overview . . . . . . . . . . . . . . . . 7 55 3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 7 56 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7 57 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9 58 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9 59 4.2. Action on Change of Interface State . . . . . . . . . . . 9 60 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10 61 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10 62 5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 63 5.1. Group Timers and Source Timers in the Lightweight 64 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 66 5.3. Reception of Current-State Records . . . . . . . . . . . . 13 67 5.4. Reception of Source-List-Change and Filter-Mode-Change 68 Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 70 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16 71 6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 16 72 6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 16 73 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 74 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 75 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 76 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 17 77 7. Implementation Considerations . . . . . . . . . . . . . . . . 19 78 7.1. Implementation of Source-Specific Multicast . . . . . . . 19 79 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . . . . 23 87 1. Introduction 89 IGMP version 3 [2] and MLD version 2 [3] implement source filtering 90 capabilities that are not supported by their earlier versions, IGMPv1 91 [4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can 92 tell its upstream router which group it would like to join by 93 specifying which sources it does or does not intend to receive 94 multicast traffic from. IGMPv3 and MLDv2 add the capability for a 95 multicast router to learn sources which are of interest or which are 96 of not interested for a particular multicast address. This 97 information is used during forwarding of multicast data packets. 99 INCLUDE and EXCLUDE filter-modes are introduced to support the source 100 filtering function. If a host wants to receive from specific 101 sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to 102 INCLUDE. If the host does not want to receive from some sources, it 103 sends a report with filter-mode set to EXCLUDE. A source list for 104 the given sources shall be included in the report message. 106 INCLUDE and EXCLUDE filter modes are also defined in a multicast 107 router to process the IGMPv3 or MLDv2 reports. When a multicast 108 router receives the report messages from its downstream hosts, it 109 forwards the corresponding multicast traffic by managing requested 110 group and source addresses. Group timers and source timers are used 111 to maintain the forwarding state of desired groups and sources under 112 certain filter modes. When a group report arrives or a certain timer 113 expires, a multicast router may update the desired or undesired 114 source lists, reset related timer values, change filter mode, or 115 trigger group queries. With all of the above factors correlating 116 with each other, the determination rules become relatively complex, 117 as the interface states could be frequently changed. 119 The multicast filter-mode improves the ability of the multicast 120 receiver to express its desires. It is useful to support Source- 121 Specific Multicast (SSM) [7] by specifying interesting source 122 addresses with INCLUDE mode. However, practical applications do not 123 use EXCLUDE mode to block sources very often, because a user or 124 application usually wants to specify desired source addresses, not 125 undesired source addresses. Even if a user wants to explicitly 126 refuse traffic from some sources in a group, when other users in the 127 same shared network have an interest in these sources, the 128 corresponding multicast traffic is forwarded to the network. It is 129 generally unnecessary to support the filtering function that blocks 130 sources. 132 This document proposes simplified versions of IGMPv3 and MLDv2, named 133 Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2). 134 LW-IGMPv3 and LW-MLDv2 support both ASM and SSM communications 135 without a filtering function that blocks sources. Not only are they 136 compatible with the standard IGMPv3 and MLDv2, but also the protocol 137 operations made by hosts and routers or switches (performing IGMPv3/ 138 MLDv2 snooping) are simplified to reduce the complicated operations. 139 Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full 140 version of these protocols (i.e., the standard IGMPv3 and MLDv2), 141 hosts or routers that have implemented the full version do not need 142 to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 143 hosts or routers. 145 2. Terminology 147 Following notations are used in several places in this specification. 149 (*,G) join: 150 An operation triggered by a host that wants to join the group G. In 151 this case, the host receives from all sources sending to group G. 152 This is typical in the ASM communication. 154 (S,G) join: 155 An operation triggered by a host that wants to join the group G, with 156 specifying desired source S. In this case, the host receives only 157 from source S sending to group G. 159 INCLUDE (S,G) join: 160 An operation triggered by a host that wants to join a group G under 161 INCLUDE filter-mode, with specifying desired source S. The same 162 meaning of (S,G) join. 164 EXCLUDE (*,G) join: 165 An operation triggered by a host that wants to join a group G under 166 EXCLUDE filter-mode. The same meaning of (*,G) join. 168 EXCLUDE (S,G) join: 169 An operation triggered by a host that wants to join a group G under 170 EXCLUDE filter-mode, with specifying undesired source S. This 171 operation is not supported by LW-IGMPv3/LW-MLDv2. 173 3. Simplification Method Overview 175 The principle is to simplify the host and router's behavior as much 176 as possible to improve efficiency, while guaranteeing 177 interoperability with the full versions, and introducing no side 178 effects on applications. 180 For convenience, this document mainly discusses IGMPv3, since MLDv2 181 inherits the same source filtering mechanism, but this document 182 additionally shows MLDv2's unique specifications when needed. 184 3.1. Behavior of Group Members 186 In LW-IGMPv3, the same service interface model as that of IGMPv3 is 187 inherited: 189 IPMulticastListen ( socket, interface, multicast-address, 190 filter-mode, source-list ) 192 In the lightweight protocol, INCLUDE mode on the host part has the 193 same usage with the full version for INCLUDE (S,G) join, while 194 EXCLUDE mode on the host part is preserved only for excluding null 195 source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/ 196 MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is 197 described in Section 4. 199 3.2. Behavior of Multicast Routers 201 In IGMPv3, router filter-mode is defined to optimize the state 202 description of a group membership [2][3]. As a rule, once a member 203 report is in EXCLUDE mode, the router filter-mode for the group will 204 be set to EXCLUDE. When all systems cease sending EXCLUDE mode 205 reports, the filter-mode for that group may transit back to INCLUDE 206 mode. Group timer is used to identify such transition. 208 In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can 209 request an EXCLUDE (*,G) join, which can be interpreted by the router 210 as a request to include all sources. Without the more general form 211 of EXCLUDE requests, it is unnecessary for the router to maintain the 212 EXCLUDE filter-mode, and the state model for multicast router can be 213 simplified as: 215 (multicast address, group timer, (source records)) 217 Here a group timer is kept to represent a (*,G) join. Its basic 218 behavior is: when a router receives a (*,G) join, it will set its 219 group timer and keep the source list for sources specified in the 220 previously received source records. When the group timer expires, 221 the router may change to the reception for the listed sources. The 222 definition of the source record is the same as that of full version. 224 The elimination of the filter-mode will greatly simplify the router 225 behavior. The detailed operation of router operation is described in 226 Section 5. 228 4. LW-IGMPv3 Protocol for Group Members 230 4.1. Query and Report Messages 232 LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, 233 being the same as the full version protocols. There is no difference 234 between the definition and usage of the Query message. But the 235 report types in lightweight protocols are reduced because an 236 operation that triggers EXCLUDE (S,G) join is omitted. 238 There are three Group Record Types defined in the full IGMPv3: 239 Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) 240 or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by 241 CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and 242 Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or 243 BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the action on change 244 of interface state and reception of a Query, but IS_IN and IS_EX 245 record types are eliminated and Current-State Records are noted by 246 other records. The following sections explain the details. 248 4.2. Action on Change of Interface State 250 When the state of an interface of a group member host is changed, a 251 State-Change Report for that interface is immediately transmitted 252 from that interface. The type and contents of the Group Record(s) in 253 that Report are determined by comparing the filter mode and source 254 list for the affected multicast address before and after the change. 255 While the requirements are the same as the full version for the 256 computation, in the lightweight version host, the interface state 257 change rules are simplified due to the reduction of message types. 258 The contents of the new transmitted report are calculated as follows 259 (Group Record Types are described in Section 4.4): 261 Old State New State State-Change Record Sent 262 ----------- ----------- ------------------------ 264 INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) 266 INCLUDE (A) EXCLUDE ({}) TO_EX({}) 268 INCLUDE ({}) EXCLUDE ({}) TO_EX({}) 270 EXCLUDE ({}) INCLUDE (B) TO_IN(B) 272 As in the full version, to cover the possibility of the State-Change 273 Report being missed by one or more multicast routers, it is 274 retransmitted [Robustness Variable]-1 more times, at intervals chosen 275 at random from the range (0, [Unsolicited Report Interval]). (These 276 values are defined in [2][3].) 278 4.3. Action on Reception of a Query 280 As in the full version, when a lightweight version host receives a 281 Query, it does not respond immediately. Instead, it delays its 282 response by a random amount of time, bounded by the Max Resp Time 283 value derived from the Max Resp Code in the received Query message 284 [2][3]. The system may receive a variety of Queries on different 285 interfaces and of different kinds (e.g., General Queries, Group- 286 Specific Queries, and Group-and-Source-Specific Queries), each of 287 which may require its own delayed response. 289 Before scheduling a response to a Query, the system must first 290 consider previously scheduled pending responses and in many cases 291 schedule a combined response. Therefore, the lightweight version 292 host must be able to maintain the following state: 294 o A timer per interface for scheduling responses to General Queries. 296 o A per-group and interface timer for scheduling responses to Group- 297 Specific and Group-and-Source-Specific Queries. 299 o A per-group and interface list of sources to be reported in the 300 response to a Group-and-Source-Specific Query. 302 LW-IGMPv3 inherits the full version's rules that are used to 303 determine if a Report needs to be scheduled. The difference is 304 regarding the simplification of EXCLUDE filter-mode and the type of 305 Report as detailed in Section 4.4. 307 4.4. LW-IGMPv3 Group Record Types 309 Among Group Record Types defined in the full IGMPv3, several record 310 types are not used in LW-IGMPv3 as some of the processes related to 311 the filter mode change to the EXCLUDE mode are eliminated and some of 312 the report messages are converged with a record having null source 313 address list. All of the record types of report messages used by the 314 full and lightweight version protocols are shown as follows: 316 IGMPv3 LW-IGMPv3 Comments 317 --------- --------- ------------------------------------- 319 IS_EX({}) TO_EX({}) Query response for (*,G) join 321 IS_EX(x) N/A Query response for EXCLUDE (x,G) join 323 IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join 325 ALLOW(x) ALLOW(x) INCLUDE (x,G) join 327 BLOCK(x) BLOCK(x) INCLUDE (x,G) leave 329 TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join 331 TO_IN({}) TO_IN({}) (*,G) leave 333 TO_EX(x) N/A Change to EXCLUDE (x,G) join 335 TO_EX({}) TO_EX({}) (*,G) join 337 where "x" represents a non-null source address list and "({})" 338 represents null source address list. For instance, IS_EX({}) means a 339 report whose record type is IS_EX with null source address list. 340 "N/A" represents not applicable (or no use) because the corresponding 341 operation should not occur in the lightweight version protocols. 343 LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source 344 address list. A multicast router creates the same state when it 345 receives a report message containing either IS_EX({}) or TO_EX({}) 346 record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) 347 operation with the TO_EX({}) operation. 349 When a LW-IGMPv3 host needs to make a query response for the state of 350 INCLUDE (x,G) join, it makes a response whose message type is 351 expressed with ALLOW(x), instead of using the IS_IN record type. 352 Because the router's processing of the two messages is completely 353 same, the IS_IN(x) type is eliminated for simplification. 355 A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is 356 used the following situation: the host first launches an application 357 (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the 358 host launches another application (AP2) that joins (*,G), and it 359 sends TO_EX({}). In this condition, when AP2 terminates but AP1 360 keeps working on the lightweight version host, the host sends a 361 report with TO_IN(x) record type for [Robustness Variable] times. 363 5. LW-IGMPv3 Protocol for Multicast Routers 365 The major difference between the full and lightweight version 366 protocols on the router part is that for the lightweight version 367 filter-mode is discarded and the function of the group timer is 368 redefined. The states maintained by the lightweight router are 369 reduced and the protocol operation is greatly simplified. 371 5.1. Group Timers and Source Timers in the Lightweight Version 373 In lightweight and full IGMPv3 routers, a source timer is kept for 374 each source record and it is updated when the source is present in a 375 received report. It indicates the validity of the sources and needs 376 to be referred when the router takes its forwarding decision. 378 The group timer being used in the full version of IGMPv3 for 379 transitioning the router's filter-mode from EXCLUDE to INCLUDE, is 380 redefined in the lightweight protocols to identify the non-source- 381 specific receiving states maintaining for (*,G) join. Once a group 382 record of TO_EX({}) is received, the group timer is set to represent 383 this (*,G) group join. The expiration of the group timer indicates 384 that there are no more listeners on the attached network for this 385 (*,G) group. Then if at this moment there are unexpired sources 386 (whose source timers are greater than zero), the router will change 387 to receiving traffic for those sources. The role of the group timer 388 can be summarized as follows: 390 Group Timer Value Actions/Comments 391 ------------------ -------------------------------------- 393 G_Timer > 0 All members in this group. 395 G_Timer == 0 No more listeners to this (*,G) group. 396 If all source timers have expired then 397 delete group record. If there are 398 still source record timers running, 399 use those source records with running 400 timers as the source record state. 402 The operation related to the group and source timers has some 403 difference compared with the full IGMPv3. In the full version, if a 404 source timer expires under the EXCLUDE router filter-mode, its 405 corresponding source record is not deleted until the group timer 406 expires for indicating undesired sources. In the lightweight 407 version, since there is no need to keep such records for blocking 408 specific sources, if a source timer expires, its source record should 409 be deleted immediately, not waiting for the time-out of the group 410 timer. 412 5.2. Source-Specific Forwarding Rules 414 A full version multicast router needs to consult IGMPv3 state 415 information when it makes decisions on forwarding a datagram from a 416 source or its upstream router to its attached network, based on the 417 router filter-mode and source timer. In LW-IGMPv3, because of the 418 absence of the router filter-mode, the group timer and source timer 419 could be used for such decisions. The forwarding suggestion made by 420 LW-IGMPv3 to the routing protocols is summarized as follows: 422 Group Timer Source Timer Action 423 ------------ ------------------ ----------------------- 425 G_Timer == 0 S_TIMER > 0 Suggest forwarding 426 traffic from source 428 G_Timer == 0 S_TIMER == 0 Suggest stopping 429 forwarding traffic from 430 source and remove 431 source record. If there 432 are no more source 433 records for the group, 434 delete group record 436 G_Timer == 0 No Source Elements Suggest not to forward 437 traffic from the source 439 G_Timer > 0 S_TIMER >= 0 Suggest forwarding 440 traffic from source 442 G_Timer > 0 No Source Elements Suggest forwarding 443 traffic from source 445 5.3. Reception of Current-State Records 447 When receiving Current-State Records, the LW-IGMPv3 router resets its 448 group or source timers and updates its source list within the group. 449 For source-specific group reception state (when G_Timer==0), the 450 source list contains sources whose traffic will be forwarded by the 451 router, while in non-source-specific group reception (when 452 G_Timer>0), the source list remembers the valid sources to receive 453 traffic from after toggling to source-specific reception state. 455 Although the LW-IGMPv3 host only sends a subset of the message of 456 that of the full version, the LW-IGMPv3 router should be able to 457 process as much messages as possible to be compatible with the full 458 version host. Note that if the report type is IS_EX(x) with non- 459 empty source-list, the router will treat it as the same type of 460 report with empty source list. The following table describes the 461 action taken by a multicast router after receiving Current-State 462 Records. The notations have the same meaning as that in the full 463 IGMPv3 protocol. 465 Old New 466 Source Source 467 Group Timer List Report Rec'd List Actions 468 ------------ ------ ------------ ------ ----------- 470 G_Timer == 0 A IS_IN(B) A+B (B)=GMI 472 G_Timer == 0 A IS_EX({}) A G_Timer=GMI 474 G_Timer > 0 A IS_IN(B) A+B (B)=GMI 476 G_Timer > 0 A IS_EX({}) A G_Timer=GMI 478 The above table could be further simplified for the processes that 479 are completely same for the two values of the G_Timer: 481 Old New 482 Source Source 483 List Report Rec'd List Actions 484 ------ ------------ ------ ----------- 486 A IS_IN(B) A+B (B)=GMI 488 A IS_EX({}) A G_Timer=GMI 490 Without EXCLUDE filter-mode, a router's process on receiving Current- 491 State Record is simple: when a router receives an IS_IN report, it 492 appends the reported source addresses to the previous source list 493 with their source timers set to GMI. Upon receiving an IS_EX({}) 494 report, the router sets the non-source-specific receiving states by 495 resetting the group timer value and keeps the previous source list 496 without modification. 498 5.4. Reception of Source-List-Change and Filter-Mode-Change Records 500 On receiving Source-List-Change and Filter-Mode-Change Records, the 501 LW-IGMPv3 router needs to reset its group and source timers, update 502 its source list within the group, or trigger group queries. The 503 queries are sent by the router for the sources that are requested to 504 be no longer forwarded to a group. Note that if the report type is 505 TO_EX(x) with non-empty source-list, the router will treat it as the 506 same type of report with empty source list. The table below 507 describes the state change and the actions that should be taken. 509 Old New 510 Source Source 511 Group Timer List Report Rec'd List Actions 512 ------------ ------ ------------ ------ ------------- 514 G_Timer == 0 A ALLOW(B) A+B (B)=GMI 516 G_Timer == 0 A BLOCK(B) A Send Q(G,A*B) 518 G_Timer == 0 A TO_IN(B) A+B (B)=GMI 519 Send Q(G,A-B) 521 G_Timer == 0 A TO_EX({}) A G_Timer=GMI 523 G_Timer > 0 A ALLOW(B) A+B (B)=GMI 525 G_Timer > 0 A BLOCK(B) A Send Q(G,A*B) 527 G_Timer > 0 A TO_IN(B) A+B (B)=GMI 528 SendQ(G,A-B) 529 Send Q(G) 531 G_Timer > 0 A TO_EX({}) A G_Timer=GMI 533 The table could be further simplified by merging duplicate lines: 535 Old New 536 Source Source 537 List Report Rec'd List Actions 538 ------ ------------ ------ ---------------------- 540 A ALLOW(B) A+B (B)=GMI 542 A BLOCK(B) A Send Q(G,A*B) 544 A TO_IN(B) A+B (B)=GMI 545 Send Q(G,A-B) 546 If G_Timer>0 Send Q(G) 547 A TO_EX({}) A G_Timer=GMI 549 6. Interoperability 551 LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and 552 routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts 553 and routers must interoperate gracefully with hosts and routers 554 running IGMPv1/v2 or MLDv1. 556 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 558 LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format 559 of the group query and report messages the full version protocols 560 use. 562 6.1.1. Behavior of Group Members 564 A LW-IGMPv3 host's compatibility mode is determined from the Host 565 Compatibility Mode variable which can be in one of three states: 566 IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its 567 interface as LW-IGMPv3, its Host Compatibility Mode of that interface 568 is set to IGMPv3, and the host sends a subset of IGMPv3 report 569 messages, which can be recognized by a multicast router running the 570 full or the lightweight IGMPv3 protocol on the same LAN. 572 6.1.2. Behavior of Multicast Routers 574 A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and 575 TO_EX(x) records that are used by the full version. When a LW- 576 IGMPv3/LW-MLDv2 router receives these report messages from the full 577 version host, it MUST translate them internally to IS_EX({}) and 578 TO_EX({}) respectively and behaves accordingly. 580 6.2. Interoperation with IGMPv1/IGMPv2 582 Since the lightweight protocols can be treated as the parallel 583 version of full version of IGMPv3/MLDv2, its compatibility principle 584 and method with the older version are generally the same as that of 585 full IGMPv3/MLDv2. 587 6.2.1. Behavior of Group Members 589 The Host Compatibility Mode of an interface is set to IGMPv2 and its 590 IGMPv2 Querier Present timer is set to Older Version Querier Present 591 Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is 592 received on that interface. The Host Compatibility Mode of an 593 interface is set to IGMPv1 and its IGMPv1 Querier Present timer is 594 set to Older Version Querier Present Timeout seconds whenever an 595 IGMPv1 Membership Query is received on that interface. 597 In the presence of older version group members, LW-IGMPv3 hosts may 598 allow its report message to be suppressed by either an IGMPv1 or 599 IGMPv2 membership report. However, because the transmission of 600 IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, 601 as a potential protection mechanism, the choice to enable or disable 602 the use of backward compatibility may be configurable. 604 6.2.2. Behavior of Multicast Routers 606 The behavior of a LW-IGMPv3 router when placed on a network where 607 there are routers that have not been upgraded to IGMPv3, is 608 completely the same with a full IGMPv3 router in this situation [2]. 610 A full IGMPv3 router uses Group Compatibility Mode (whose value is 611 either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate 612 which version of IGMP protocol it behaves for the group. This value 613 is set according to the version of the received IGMP report. When 614 Group Compatibility Mode is IGMPv3, the lightweight router acts with 615 LW-IGMPv3 protocol for that group. 617 When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits 618 this compatibility mechanism with the following rules: 620 IGMPv2 Message LW-IGMPv3 Equivalent 621 -------------- -------------------- 623 v2 Report TO_EX({}) 625 v2 Leave TO_IN({}) 627 When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router 628 internally translates the following IGMPv1 and IGMPv2 messages for 629 that group to their IGMPv3 equivalents: 631 IGMPv1 Message LW-IGMPv3 Equivalent 632 -------------- -------------------- 634 v1 Report TO_EX({}) 636 v2 Report TO_EX({}) 638 6.3. Interoperation with MLDv1 640 The MLDv2 hosts and routers MUST interoperate with the hosts and 641 routers running MLDv1. The method is the same as described in 642 Section 6.2. The difference is that when a MLDv2 router has a MLDv1 643 listener on its network, it translates the following MLDv1 messages 644 to their MLDv2 equivalents: 646 MLDv1 Message LW-MLDv2 Equivalent 647 ------------- ------------------- 649 Report TO_EX({}) 651 Done TO_IN({}) 653 7. Implementation Considerations 655 The lightweight protocols require no additional procedure on the 656 implementation of the related protocols or systems, e.g. IGMP/MLD 657 snooping, multicast routing protocol, and operation of application 658 sockets, while the processing loads on the switches and routers that 659 running IGMPv3/MLDv2 (snooping) and multicast routing protocols may 660 be greatly decreased. 662 In the following sections, the implementation related aspects are 663 described for the lightweight version protocols. 665 7.1. Implementation of Source-Specific Multicast 667 [8] illustrates the requirements of implementation of Source-Specific 668 Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight 669 protocol does not impose any bad influences on an SSM application. 670 The requirements of LW-IGMPv3/LW-MLDv2 for supporting SSM are 671 illustrated below. 673 A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., 674 TO_EX({})) and IGMPv2 Leave and MLDv1 Done messages (i.e., TO_IN({})) 675 for the application whose multicast address is in the SSM address 676 range. The reception of a (*,G) join with an SSM group address 677 should indicate an error to the application. The SSM-aware router 678 will ignore TO_EX({}) reports with SSM addresses. Other types of 679 Reports should be processed normally. 681 7.2. Implementation of Multicast Source Filter (MSF) APIs 683 Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF 684 API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF 685 API, and (4) Protocol-Independent Advanced MSF API. 687 According to the MSF APIs definition, a LW-IGMPv3 host should 688 implement either IPv4 Basic MSF API or Protocol-Independent Basic MSF 689 API, and a LW-MLDv2 host should implement Protocol-Independent Basic 690 MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent 691 Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2 692 host. 694 8. Security Considerations 696 The security considerations are the same as that of the full version 697 of IGMPv3/MLDv2. 699 9. References 701 9.1. Normative References 703 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 704 levels", RFC 2119, March 1997. 706 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 707 Thyagarajan, "Internet Group Management Protocol, Version 3", 708 RFC 3376, October 2002. 710 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 711 (MLDv2) for IPv6", RFC 3810, June 2004. 713 [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 714 August 1989. 716 [5] Fenner, W., "Internet Group Management Protocol, Version 2", 717 RFC 2236, November 1997. 719 [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 720 Discovery (MLD) for IPv6", RFC 2710, October 1999. 722 [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 723 RFC 4607, August 2006. 725 [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group 726 Management Protocol Version 3 (IGMPv3) and Multicast Listener 727 Discovery Protocol Version 2 (MLDv2) for Source-Specific 728 Multicast", RFC 4604, August 2006. 730 9.2. Informative References 732 [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 733 Extensions for Multicast Source Filters", RFC 3678, 734 January 2004. 736 Authors' Addresses 738 Hui Liu 739 Huawei Technologies Co., Ltd. 740 Huawei Bld., No.3 Xinxi Rd. 741 Shang-Di Information Industry Base 742 Hai-Dian Distinct, Beijing 100085 743 China 745 Email: Liuhui47967@huawei.com 747 Wei Cao 748 Huawei Technologies Co., Ltd. 749 Huawei Bld., No.3 Xinxi Rd. 750 Shang-Di Information Industry Base 751 Hai-Dian Distinct, Beijing 100085 752 China 754 Email: caowayne@huawei.com 756 Hitoshi Asaeda 757 Keio University 758 Graduate School of Media and Governance 759 5322 Endo 760 Fujisawa, Kanagawa 252-8520 761 Japan 763 Email: asaeda@wide.ad.jp 765 Full Copyright Statement 767 Copyright (C) The IETF Trust (2008). 769 This document is subject to the rights, licenses and restrictions 770 contained in BCP 78, and except as set forth therein, the authors 771 retain all their rights. 773 This document and the information contained herein are provided on an 774 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 775 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 776 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 777 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 Intellectual Property 783 The IETF takes no position regarding the validity or scope of any 784 Intellectual Property Rights or other rights that might be claimed to 785 pertain to the implementation or use of the technology described in 786 this document or the extent to which any license under such rights 787 might or might not be available; nor does it represent that it has 788 made any independent effort to identify any such rights. Information 789 on the procedures with respect to rights in RFC documents can be 790 found in BCP 78 and BCP 79. 792 Copies of IPR disclosures made to the IETF Secretariat and any 793 assurances of licenses to be made available, or the result of an 794 attempt made to obtain a general license or permission for the use of 795 such proprietary rights by implementers or users of this 796 specification can be obtained from the IETF on-line IPR repository at 797 http://www.ietf.org/ipr. 799 The IETF invites any interested party to bring to its attention any 800 copyrights, patents or patent applications, or other proprietary 801 rights that may cover technology that may be required to implement 802 this standard. Please address the information to the IETF at 803 ietf-ipr@ietf.org.