idnits 2.17.1 draft-ietf-mboned-lightweight-igmpv3-mldv2-00.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 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (December 19, 2006) is 6331 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 Expires: June, 2007 Huawei Technologies Co., Ltd. 5 H. Asaeda 6 Keio University 7 December 19, 2006 9 Lightweight IGMPv3 and MLDv2 Protocols 10 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 The list of Internet-Draft 31 Shadow Directories can be accessed at http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 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 50 [KEYWORDS]. 52 Table of Contents 54 1. Introduction ................................................... 2 55 2. Simplification Method Overview ................................. 4 56 2.1. Behavior of Group Members ................................. 4 57 2.2. Behavior of Multicast Routers ............................. 4 58 3. LW-IGMPv3 Protocol for Group Members ........................... 5 59 3.1. Action on Change of Interface State ....................... 5 60 3.2. Action on Reception of a Query ............................ 6 61 3.3. Applicable Group Record Types ............................. 7 62 4. LW-IGMPv3 Protocol for Multicast Routers ....................... 8 63 4.1. Group Timers and Source Timers 64 in the Lightweight Version ................................ 8 65 4.2. Source-Specific Forwarding Rules .......................... 9 66 4.3. Reception of Current-State Records ....................... 10 67 4.4. Reception of Source-List-Change and 68 Filter-Mode-Change Records ............................... 11 69 5. Interoperability .............................................. 12 70 5.1. Interoperation with the Full Version of IGMPv3 ........... 12 71 5.2. Interoperation with IGMPv1/IGMPv2 ........................ 13 72 5.2.1. Behavior of Group Members ........................... 13 73 5.2.2. Behavior of Multicast Routers ....................... 13 74 6. Implementation Considerations ................................. 13 75 6.1. Implementation of Source-Specific Multicast .............. 14 76 6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 14 77 7. Security Considerations ....................................... 14 78 8. Normative References .......................................... 14 79 9. Informative References ........................................ 15 80 Intellectual Property Statement .................................. 16 81 Disclaimer of Validity ........................................... 16 82 Copyright Statement .............................................. 16 83 Acknowledgment ................................................... 16 85 1. Introduction 87 IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2] implement source 88 filtering capability that is not suported by their earlier versions 89 IGMPv2 [IGMPv2] and MLDv1 [MLDv1]. An IGMPv3 or MLDv2 capable host 90 can tell which group it would like to join to its upstream router 91 with specifying which sources it does or does not intend to receive 92 multicast traffic from. IGMPv3 and MLDv2 add the capability for a 93 multicast router to also learn which sources are of interest to 94 neighboring systems, for packets sent to any particular multicast 95 address. 97 The filter-modes are defined for the host and router parts of the 98 protocols respectively to support the source filtering function. If 99 a receiver host wants to receive from specific sources, it sends an 100 IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. If the host 101 does not want to receive from some sources, it sends the report with 102 filter-mode set to EXCLUDE. A source list for the given sources 103 shall be included in the report message. 105 INCLUDE and EXCLUDE filter modes are also defined in a multicast 106 router to process the IGMPv3 or MLDv2 reports. When a multicast 107 router receives the report messages from its downstream hosts, it 108 forwards the corresponding multicast traffic by managing requested 109 group and source addresses. Group timer and source timer are used to 110 maintain forwarding state of desired group and source. A multicast 111 router decides its filter-mode, type, and value of the timers and 112 forwarding methods according to the specific rules when a group 113 report message arrives or the timer expires. The router then has to 114 switch its filter-mode under certain conditions. With all above 115 factors correlating with each other, the determination rule becomes 116 relatively complex as the interface states could be frequently 117 changed. 119 The multicast filter-mode improves the expressing ability of the 120 multicast receiver. It is useful to support Source-Specific 121 Multicast (SSM) [SSM] by specifying interesting source addresses with 122 INCLUDE mode. However, practical applications do not use EXCLUDE 123 mode to block sources so often, because a user or application usually 124 wants to specify desired source addresses, not undesired source 125 addresses to not receive from them. Even if a user wants to 126 explicitly refuse traffic from some sources in a group, when other 127 users in the same shared network have interest in these sources, the 128 corresponding multicast traffic is forwarded to the network after 129 all. 131 This document aims to propose the simplified IGMPv3 and MLDv2, being 132 named Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW- 133 MLDv2), in which EXCLUDE filter-mode that supports to exclude data 134 come from specified sources is eliminated. Not only LW-IGMPv3 and 135 LW-MLDv2 are compatible with the standard IGMPv3 and MLDv2, but also 136 the protocol operations made by data receiver hosts and routers or 137 switches (performing IGMPv3/MLDv2 snooping) are simplified in the 138 lightweight protocol and complicated operations are hence effectively 139 reduced. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the 140 full 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. Simplification Method Overview 147 The principle is to simplify the host and router parts as much as 148 possible to improve efficiency, while guaranteeing the 149 interoperability with the full versions, and introducing no side 150 effects on the applications. 152 For convenience, this document mainly discusses IGMPv3 since MLDv2 153 inherits the same source filtering mechanism, but additionally shows 154 MLDv2's unique specifications when needed. 156 2.1. Behavior of Group Members 158 In the LW-IGMPv3, the same service interface model as that of IGMPv3 159 is inherited: 161 IPMulticastListen ( socket, interface, multicast-address, 162 filter-mode, source-list ) 164 In the lightweight protocol, EXCLUDE mode on the host part is 165 preserved only for EXCLUDE (*,G) join, which denotes non-source- 166 specific group report (as known as (*,G) join) and is equivalent to 167 the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The 168 detailed host operation of LW-IGMPv3/LW-MLDv2 is described in section 169 3. 171 2.2. Behavior of Multicast Routers 173 According to [IGMPv3], router filter-mode is defined to optimize the 174 state description of a group. As a rule, once a member report is in 175 EXCLUDE mode, the router filter-mode for the group will be set to 176 EXCLUDE. When all systems cease sending EXCLUDE mode reports, the 177 filter-mode for that group may transit back to INCLUDE mode. Group 178 timer is used to identify such transition. 180 In LW-IGMPv3, member reports carry mainly the INCLUDE mode 181 information with only one exception for EXCLUDE (*,G), which means 182 including all sources and can also be interpreted as INCLUDE mode. 183 Without EXCLUDE mode report information, it is unnecessary for the 184 router to maintain the EXCLUDE filter-mode, and the state model for 185 multicast router can be simplified as: 187 (multicast address, group timer, (source records)) 189 Here group timer is kept to represent (*,G) group join. Its basic 190 behavior is: when a router receives a (*,G) group join, it will set 191 its group timer, and the source list for the source-specific group 192 will be kept. As the group timer expires, the router may change to 193 the reception for the listed sources. 195 The elimination of the filter-mode will greatly simplify the router 196 behavior, e.g. the action on reception of reports and the setting of 197 the timers. The detailed operation of router operation is described 198 in section 4. 200 3. LW-IGMPv3 Protocol for Group Members 202 LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, 203 being the same as the full version protocols. Although most of these 204 message types and corresponding group records are inherited from the 205 full version protocols, an operation that triggers EXCLUDE (S,G) join 206 is omitted and the corresponding record types of the Report are 207 modified on the lightweight protocols. 209 There are three Group Record Types defined in the full IGMPv3: 210 Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) 211 or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by 212 CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and 213 Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or 214 BLOCK_OLD_SOURCES (BLOCK). 216 3.1. Action on Change of Interface State 218 When an interface state of a group member host is changed, a State- 219 Change Report for that interface is immediately transmitted from that 220 interface. The type and contents of the Group Record(s) in that 221 Report are determined by comparing the filter mode and source list 222 for the affected multicast address before and after the change. 223 While the requirements are the same as the full version for the 224 computation, in the lightweight version host, the interface state 225 change rules are simplified due to the reduction of message types. 226 The contents of the new transmitted report are calculated as follows 227 (Group Record Types are described in section 3.3): 229 Old State New State State-Change Record Sent 230 ----------- ----------- ------------------------ 232 INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) 234 INCLUDE (A) EXCLUDE () IS_EX() 235 INCLUDE () EXCLUDE () IS_EX() 237 EXCLUDE () INCLUDE (B) TO_IN(B) 239 To cover the possibility of the State-Change Report being missed by 240 one or more multicast routers, it is retransmitted [Robustness 241 Variable]-1 more times, at intervals chosen at random from the range 242 (0, [Unsolicited Report Interval]). (These values are defined in 243 [IGMPv3, MLDv2].) 245 In the full version of IGMPv3, as was done with the first report, the 246 interface state for the affected group before and after the latest 247 change is compared, and the report records expressing the difference 248 are built and merged with the contents of the pending report, to 249 create the new State-Change report. However, it is optional that a 250 LW-IGMPv3 host merges with the contents of the pending report. If 251 the LW-IGMPv3 host does not merge with the contents of the pending 252 report, it transmits each report sequentially. Doing so can greatly 253 simplified the operation for scheduling the reports. 255 3.2. Action on Reception of a Query 257 When a lightweight version host receives a Query, it does not respond 258 immediately. Instead, it delays its response by a random amount of 259 time, bounded by the Max Resp Time value derived from the Max Resp 260 Code in the received Query message [IGMPv3, MLDv2]. The system may 261 receive a variety of Queries on different interfaces and of different 262 kinds (e.g., General Queries, Group-Specific Queries, and Group-and- 263 Source-Specific Queries), each of which may require its own delayed 264 response. 266 Before scheduling a response to a Query, the system must first 267 consider previously scheduled pending responses and in many cases 268 schedule a combined response. Therefore, the lightweight version 269 host must be able to maintain the following state: 271 o A timer per interface for scheduling responses to General Queries. 273 o A per-group and interface timer for scheduling responses to Group- 274 Specific and Group-and-Source-Specific Queries. 276 o A per-group and interface list of sources to be reported in the 277 response to a Group-and-Source-Specific Query. 279 LW-IGMPv3 inherits most of the rules that are used to determine if a 280 Report needs to be scheduled from the full version. The different 281 point is regarding the simplification of EXCLUDE filter-mode and the 282 type of Report to schedule as detailed in section 3.3. 284 While it is optional that a LW-IGMPv3 host merges with the contents 285 of the pending report for unsolicited report (i.e. State-Change 286 report) as mentioned in the previous section, if the received Query 287 is a Group-and-Source-Specific Query and there is a pending response 288 for this group with a non-empty source-list, then the group source 289 list is augmented to contain the list of sources in the new Query and 290 a single response is scheduled using the group timer as with the full 291 version host. The new response is then scheduled to be sent at the 292 earliest of the remaining time for the pending report and the 293 selected delay. 295 3.3. Applicable Group Record Types 297 Among Group Record Types defined in the full IGMPv3, several record 298 types are not used in LW-IGMPv3 as some of the processes related to 299 the filter mode change to the EXCLUDE mode are eliminated and some of 300 the report messages are converged with a record having null source 301 address list. All of the record types of report messages used by the 302 full and lightweight version protocols are shown as follows: 304 IGMPv3 LW-IGMPv3 Comments 305 -------- --------- ------------------------------------- 307 IS_EX() IS_EX() Query response for (*,G) join 309 IS_EX(x) N/A Query response for EXCLUDE (x,G) join 311 IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join 313 ALLOW(x) ALLOW(x) INCLUDE (x,G) join 315 BLOCK(x) BLOCK(x) INCLUDE (x,G) leave 317 TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join 319 TO_IN() TO_IN() (*,G) leave 321 TO_EX(x) N/A Change to EXCLUDE (x,G) join 323 TO_EX() IS_EX() (*,G) join 325 where "x" represents non-null source address list and "()" represents 326 null source address list. For instance, IS_EX() means a report whose 327 record type is IS_EX with null source address list. "N/A" represents 328 not applicable (or no use) because the corresponding operation should 329 not occur in the lightweight version protocols. 331 LW-IGMPv3 does not use EXCLUDE filter-mode with non-null source 332 address list. And a multicast router creates the same state when it 333 receives a report message containing either of IS_EX or TO_EX record 334 types. Therefore, LW-IGMPv3 integrates the TO_EX operation to the 335 IS_EX operation. 337 When a LW-IGMPv3 host needs to make a query response for the state of 338 INCLUDE (x,G) join, the host makes the response whose message type is 339 expressed with ALLOW(x), instead of using IS_IN record type, for 340 router's processing of the two messages are completely the same, the 341 IS_IN(x) type is eliminated for simplification. 343 A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is 344 used with the following situation: the host firstly launches an 345 application (AP1) that requests INCLUDE (x,G) join, and it sends 346 ALLOW(x). Then the host launches another application (AP2) that 347 joins (*,G), and it sends IS_EX(). In this condition, when AP2 348 terminates but AP1 keeps working on the lightweight version host, the 349 host sends a report with TO_IN(x) record type for [Robustness 350 Variable] times. 352 4. LW-IGMPv3 Protocol for Multicast Routers 354 The major difference between the full and lightweight version 355 protocol on the router is that filter-mode is discarded for the 356 lightweight version, as section 2.2 mentioned. Then the IGMP state 357 maintained by the router for each attached network can be simplified 358 as: 360 (multicast address, group timer, (source records)) 362 where the source record includes pairs of source address and its 363 corresponding source timer. In this model, the filter-mode is 364 omitted and the meaning of the group timer is redefined to implement 365 simplified processing. 367 4.1. Group Timers and Source Timers in the Lightweight Version 369 The source timer is kept for each source record and it is updated 370 when the source is present in a received report. It indicates the 371 validity of the sources and needs to be referred when the router 372 takes its forwarding decision. 374 The group timer being used in the full version of IGMPv3 as a 375 mechanism for transitioning the router's filter-mode from EXCLUDE to 376 INCLUDE, is now redefined for the identification of the non-source- 377 specific receiving states, i.e., (*,G)join. Once a group record of 378 IS_EX() is received, the group timer is used to represent this (*,G) 379 group join. The expiration of the group timer indicates that there 380 are no listeners on the attached network for this (*,G) group. Then 381 if at this moment there are unexpired sources (whose source timers 382 are greater than zero), the router will change to receiving for those 383 sources. The role of the group timer can be summarized as follows: 385 Group Timer Value Actions/Comments 386 ------------------ -------------------------------------- 388 G_Timer > 0 All members in this group. 390 G_Timer == 0 No more listeners to this (*,G) group. 391 If all source timers have expired then 392 delete group record. If there are 393 still source record timers running, 394 use those source records with running 395 timers as the source record state. 397 The operation related to the group and source timers has some 398 difference compared with the full IGMPv3. In the full version, if a 399 source timer expires under the EXCLUDE router filter-mode, its 400 corresponding source record is not deleted until the group timer 401 expires. They are kept for indicating undesired sources. In the 402 lightweight version, since there is no need to keep such records for 403 blocking specific sources, if a source timer expires, its source 404 record should be deleted immediately, not waiting for the time-out of 405 the group timer. 407 4.2. Source-Specific Forwarding Rules 409 A multicast router needs to consult IGMPv3 state information when it 410 makes decisions on forwarding a datagram from a source to its 411 attached network. In the full IGMPv3, the router filter-mode and 412 source timer are taken as the necessary judging conditions. In LW- 413 IGMPv3, because of the absence of the router filter-mode, the group 414 timer and source timer could be used for such decisions. The 415 forwarding suggestion made by LW-IGMPv3 to the routing protocols can 416 be summarized as follows: 418 Group Timer Source Timer Action 419 ------------ ------------------ ----------------------- 421 G_Timer == 0 S_TIMER > 0 Suggest to forward 422 traffic from source 424 G_Timer == 0 S_TIMER == 0 Suggest to stop 425 forwarding traffic from 426 source and remove 427 source record. If there 428 are no more source 429 records for the group, 430 delete group record 432 G_Timer == 0 No Source Elements Suggest not to forward 433 traffic from the source 435 G_Timer > 0 S_TIMER >= 0 Suggest to forward 436 traffic from source 438 G_Timer > 0 No Source Elements Suggest to forward 439 traffic from source 441 4.3. Reception of Current-State Records 443 When receiving Current-State Records, the LW-IGMPv3 router resets its 444 group or source timers and updates its source list within the group. 445 For source-specific group reception state (G_Timer==0), the source 446 list includes sources to be forwarded by the router, while in non- 447 source-specific group reception (G_Timer>0) the source list remembers 448 the sources to be forwarded after toggling to source-specific 449 reception state. 451 The following table describes the action taken by a multicast router 452 after receiving Current-State Records. The notations have the same 453 meaning as that in the full IGMPv3. 455 Old New 456 Source Source 457 Group Timer List Report Rec'd List Actions 458 ------------ ------ ------------ ------ ----------- 460 G_Timer == 0 A IS_IN(B) A+B (B)=GMI 462 G_Timer == 0 A IS_EX() A G_Timer=GMI 464 G_Timer > 0 A IS_IN(B) A+B (B)=GMI 466 G_Timer > 0 A IS_EX() A G_Timer=GMI 468 And the above table could be further simplified for the processes 469 that are completely same for the two values of the G_Timer: 471 Old New 472 Source Source 473 List Report Rec'd List Actions 474 ------ ------------ ------ ----------- 475 A IS_IN(B) A+B (B)=GMI 477 A IS_EX() A G_Timer=GMI 479 Without EXCLUDE filter-mode, a router's process on receiving Current- 480 State Record is simple: when a router receives an IS_IN report, it 481 appends the reported source addresses to the previous source list 482 with their source timers set to GMI. Upon receiving an IS_EX() 483 report, the router sets the non-source-specific receiving states with 484 GMI group timer value and keeps the previous source list without 485 modification. 487 4.4. Reception of Source-List-Change and Filter-Mode-Change Records 489 On receiving Source-List-Change and Filter-Mode-Change Records, the 490 LW-IGMPv3 router needs to reset its group and source timers, update 491 its source list within the group, or trigger group queries. The 492 queries are sent by the router for the sources that are requested to 493 be no longer forwarded to a group. The table below describes the 494 state change and the actions that should be taken. 496 Old New 497 Source Source 498 Group Timer List Report Rec'd List Actions 499 ------------ ------ ------------ ------ ------------- 501 G_Timer == 0 A ALLOW(B) A+B (B)=GMI 503 G_Timer == 0 A BLOCK(B) A Send Q(G,A*B) 505 G_Timer == 0 A TO_IN(B) A+B (B)=GMI 506 Send Q(G,A-B) 508 G_Timer > 0 A ALLOW(B) A+B (B)=GMI 510 G_Timer > 0 A BLOCK(B) A Send Q(G,A*B) 512 G_Timer > 0 A TO_IN(B) A+B (B)=GMI 513 SendQ(G,A-B) 514 Send Q(G) 516 The table could be further simplified by merging duplicate lines: 518 Old New 519 Source Source 520 List Report Rec'd List Actions 521 ------ ------------ ------ ---------------------- 522 A ALLOW(B) A+B (B)=GMI 524 A BLOCK(B) A Send Q(G,A*B) 526 A TO_IN(B) A+B (B)=GMI 527 Send Q(G,A-B) 528 If G_Timer>0 Send Q(G) 530 5. Interoperability 532 LW-IGMPv3/LW-MLDv2 hosts and routers should interoperate gracefully 533 with the full version protocols [IGMPv3, MLDv2]. Also, LW-IGMPv3/LW- 534 MLDv2 hosts and routers should interoperate gracefully with hosts and 535 routers running IGMPv1/v2 or MLDv1. 537 5.1. Interoperation with the Full Version of IGMPv3 539 Eliminating EXCLUDE filter-mode from the full version protocols 540 simplifies the processes inside the host and router. On the other 541 hand, LW-IGMPv3 does not introduce any change on the message format 542 of the group query and report messages the full version protocols 543 use. Therefore, the group member sends a subset of IGMPv3 report 544 messages, which can be recognized by a multicast router running the 545 full or the lightweight IGMPv3 protocol on the same LAN. 547 A LW-IGMPv3 router translates IS_EX(x) and TO_EX(x) records that are 548 used with the full IGMPv3 but not used with LW-IGMPv3. When a LW- 549 IGMPv3 router receives these report messages from the full version 550 host, it translates them to IS_EX() records and makes the 551 corresponding behavior. All possible record types are compared as 552 follows: 554 IGMPv3 Report LW-IGMPv3 Equivalent 555 ------------- -------------------- 557 IS_IN(x) IS_IN(x) 559 IS_EX(x) IS_EX() 561 TO_IN(x) TO_IN(x) 563 TO_EX(x) IS_EX() 565 ALLOW(x) ALLOW(x) 567 BLOCK(x) BLOCK(x) 569 5.2. Interoperation with IGMPv1/IGMPv2 571 The LW-IGMPv3 protocol basically adopts the same Host/Group 572 Compatibility Mode and keeps Querier Present timers for IGMPv1 and 573 IGMPv2. Their definition and processing is the same as that of 574 IGMPv3. 576 5.2.1. Behavior of Group Members 578 A host's compatibility mode is determined from the Host Compatibility 579 Mode variable which can be in one of three states: IGMPv1, IGMPv2 or 580 IGMPv3. The Host Compatibility Mode of an interface is set to IGMPv2 581 and IGMPv2 Querier Present is set to Older Version Querier Present 582 Timeout second (defined in [IGMPv3]) whenever an IGMPv2 General Query 583 is received on that interface. The Host Compatibility Mode of an 584 interface is set to IGMPv1 and IGMPv1 Querier Present is set to Older 585 Version Querier Present Timeout second whenever an IGMPv1 Membership 586 Query is received on that interface. Based on the Host Compatibility 587 Mode variable, a host acts using the IGMPv3, IGMPv2, or IGMPv1 588 protocol on that interface 590 While above manner is inherited from the definition of [IGMPv3], LW- 591 IGMPv3 may enable to configure the Host Compatibility Mode variable 592 by other means: when a LW-IGMPv3 host is placed on a link where there 593 are IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message 594 to be suppressed by an IGMPv1 or IGMPv2 report message. 596 5.2.2. Behavior of Multicast Routers 598 When Group Compatibility mode is IGMPv2 or IGMPv1, a LW-IGMPv3 router 599 translates the following IGMPv2 or IGMPv1 messages for that group to 600 their IGMPv2 or IGMPv1 equivalents: 602 IGMP Message LW-IGMPv3 Equivalent 603 ------------- -------------------- 605 v1 Report IS_EX() 607 v2 Report IS_EX() 609 v2 Leave TO_IN() 611 6. Implementation Considerations 613 The lightweight protocols requires no additional burden on the 614 implementation of the related protocols or systems, e.g. IGMP/MLD 615 snooping, multicast routing protocol, and operation of application 616 sockets, while the processing loads on the switches and routers that 617 running IGMPv3 (snooping) and multicast routing protocols could be 618 greatly decreased. 620 In the following sections, the implementation related topics are 621 described for the lightweight version protocols. 623 6.1. Implementation of Source-Specific Multicast 625 [IGMP-SSM] illustrates the requirements of implementation of Source- 626 Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The 627 lightweight protocol does not impose any bad influences on an SSM 628 application. The requirements of LW-IGMPv3/LW-MLDv2 for supporting 629 SSM are illustrated below. 631 A LW-IGMPv3/LW-MLDv2 host should not send a non-source-specific join, 632 i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the 633 application whose multicast address is in the SSM address range. The 634 reception of a non-source-specific join with an SSM group address 635 should indicate an error to the application. The SSM-aware router 636 will ignore IS_EX() reports with SSM addresses. Other types of 637 Reports should be processed normally. 639 6.2. Implementation of Multicast Source Filter (MSF) APIs 641 Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF 642 API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF 643 API, and (4) Protocol-Independent Advanced MSF API. 645 According to the MSF APIs definition, a LW-IGMPv3 host should 646 implement at least one of IPv4 Basic MSF API and Protocol-Independent 647 Basic MSF API, and a LW-MLDv2 host should implement Protocol- 648 Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and 649 Protocol-Independent Advanced MSF API, are optional to implement in 650 LW-IGMPv3/LW-MLDv2 host. 652 7. Security Considerations 654 The security consideration is the same as that of the full version of 655 IGMPv3/MLDv2. 657 8 Normative References 659 [KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate 660 requirement levels," RFC 2119, March 1997. 662 [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and 663 Thyagarajan, A., "Internet Group Management Protocol, Version3," 664 RFC 3376, October 2002. 666 [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version 667 2 (MLDv2) for IPv6," RFC 3810, June 2004. 669 9 Informative References 671 [SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP," 672 RFC 4607, August 2006. 674 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 675 RFC 2236, November 1997. 677 [MLDv1] Deering, S., Fenner, W., and Haberman, B., "Multicast 678 Listener Discovery (MLD) for IPv6," RFC 2710, October 1999. 680 [IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet 681 Group Management Protocol Version 3 (IGMPv3) and Multicast 682 Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific 683 Multicast," RFC 4604, August 2006. 685 [MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface 686 Extensions for Multicast Source Filters," RFC 3678, January 2004. 688 Author's Addressess 690 Hui Liu 691 Huawei Technologies Co., Ltd. 692 Huawei Bld., No.3 Xinxi Rd., 693 Shang-Di Information Industry Base, 694 Hai-Dian Distinct, Beijing 100085, 695 China 697 Email: Liuhui47967@huawei.com 699 Wei Cao 700 Huawei Technologies Co., Ltd. 701 Huawei Bld., No.3 Xinxi Rd., 702 Shang-Di Information Industry Base, 703 Hai-Dian Distinct, Beijing 100085, 704 China 706 Email: caowayne@huawei.com 707 Hitoshi Asaeda 708 Graduate School of Media and Governance 709 Keio University 710 5322 Endo, Fujisawa, Kanagawa 252-8520, 711 Japan 713 Email: asaeda@wide.ad.jp 715 Intellectual Property Statement 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at ietf 737 ipr@ietf.org. 739 Disclaimer of Validity 741 This document and the information contained herein are provided on an 742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 744 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 745 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 746 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Copyright Statement 751 Copyright (C) The Internet Society (2006). 753 This document is subject to the rights, licenses and restrictions 754 contained in BCP 78, and except as set forth therein, the authors 755 retain all their rights. 757 Acknowledgment 759 The author would like to thank magma and mboned mailing lists for 760 discussion and contribution for the ideas.