MAGMA Hui Liu Internet Draft wei cao Expires: December 2006 Huawei Technologies Co.,Ltd. June 26, 2006 Simplifying Process for IGMPv3 and MLDv2 Protocols draft-liu-magma-igmpv3-mldv2-lite-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 26, 2006. Abstract This document suggests a simplifying implementation for IGMPv3 and MLDv2 protocols, which is called IGMPv3-lite or MLDv2-lite. The interoperability with other versions of IGMP and MLD is considered. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in Liu etc. Expires December, 2006 [Page 1] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 this document are to be interpreted as described in RFC- 2119[KEYWORDS]. Table of Contents 1. Introduction................................................2 2. Simplification Method overview...............................3 2.1. Behavior of Group Members...............................4 2.2. Behavior of Multicast Routers...........................4 3. IGMPv3-lite protocol for Group Members.......................5 3.1. Group Record Types......................................5 3.2. Action on Change of Interface State.....................5 4. IGMPv3-lite protocol for Multicast Routers...................5 4.1. Group timers and source timers in lite version...........5 4.2. Source-Specific Forwarding Rules........................6 4.3. Reception of Current-State Records......................6 4.4. Reception of Source-List-Change and Filter-Mode-Change Records.....................................................7 5. Interoperability............................................8 5.1. Interoperation with IGMPv1/IGMPv2.......................9 5.2. Interoperation with full IGMPv3.........................9 6. Affects to other protocols..................................10 7. Security Considerations.....................................10 8. References.................................................10 Author's Addressess...........................................10 Intellectual Property Statement................................10 Disclaimer of Validity........................................11 Copyright Statement...........................................11 Acknowledgment................................................11 1. Introduction The purpose of this draft is to suggest the simplification of IGMPv3 [IGMPv3] and MLDv2 [MLDv2] protocols. IGMPv3 and MLDv2 implement source filtering capability compared to their earlier versions IGMPv2 and MLDv1, i.e., the end host not only tells which group it would like to join, but also specifies which sources it does or does not intend to receive multicast traffic from. Filter-modes are defined for the end hosts and router parts of the protocols respectively. If a receiver on a host wants to receive from specific sources, it'll send an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. On the other hand if the host does not need to receive from some sources, Liu,etc. Expires December,2006 [Page 2] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 the filter-mode of the report should be set to EXCLUDE. A source list for the given sources shall be included in the report message. Filter mode INCLUDE and EXCLUDE are also defined in the multicast router to process the IGMPv3 or MLDv2 reports appropriately. And group timer and source timer are maintained. The multicast router decides its filter-mode, type and value of the timers and forwarding methods according to specific rules when group report arrives or timer expires, and the router has to switch its filter-mode under certain conditions. All above factors correlated with each other, the determination rule is relatively complex as the state changes. The introduction of filter-mode improves the expressing ability of the multicast receiver. And it is very useful in support of SSM (which making use of INCLUDE mode). But in practical applications, EXCLUDE mode(which means blocking some sources) is not used so often, because the scenario is rare that a user is unwilling to receive from some sources. Even if such application exists, it is possible that other users in the same shared network have interest in these sources. Then the multicast traffic has to be forwarded down either. Then it can not be guaranteed that undesired traffic not received. Thus in most applications, excluding specific sources does not seem a useful implementation. In many applications, it is enough to implement part of IGMPv3/MLDv2 without EXCLUDE mode. Considering the limited effects of EXCLUDE filter-mode, and the complicacy of the operation introduced by it, it is suggested in this draft that the function of EXCLUDE mode is simplified. The protocol operation would be greatly reduced as a result. The elimination of the EXCLUDE mode does not only simplify the process of IGMPv3/MLDv2 hosts and routers, but also reduces the complexity of related protocols realization on other equipments(e.g., switches that perform IGMPv3/MLDv2 snooping). 2. Simplification Method overview The simplifying principle is to simplify the host and router parts as much as possible to improve efficiency, while guaranteeing the interoperability with full versions, and introducing no side effects on the applications. For convenience, we just mention IGMPv3, because the source filtering mechanism is the same for the two protocols. Liu,etc. Expires December,2006 [Page 3] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 2.1. Behavior of Group Members In this method, we take the same service interface model as that of IGMPv3 [IGMPv3]: IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list) In the lite protocol, EXCLUDE mode on the host part is preserved for the expression of non-source-specific group join, which is equivalent to IGMPv2/IGMPv1/MLDv1 join. It is denoted as EXCLUDE in this draft. The detailed host operation of IGMPv3- lite is described in section 3. 2.2. Behavior of Multicast Routers According to [IGMPv3], the filter-mode of the router is defined to optimize the state description of a group. As a rule, once a member report is in EXCLUDE mode, the router filter-mode for the group will be set to EXCLUDE. Otherwise when all systems with a group record in EXCLUDE mode for that group cease reporting, the router's filter-mode may transit back to INCLUDE mode. Group timer is used to identify such transition. In IGMPv3-lite, member reports carry mainly the INCLUDE mode information with only one exception for EXCLUDE, which can be interpreted as including all sources as well. Without EXCLUDE mode group information, it is unnecessary for the router to maintain the EXCLUDE filter-mode. With INLCUDE filter-mode as a default processing mode, the state model for multicast router can be simplified as: (multicast address, group timer,(source records)) Here group timer is kept to represent ASM group. Its basic behavior is: when a router receives an ASM group join, it will set its group timer, and the source list for the SSM group will be kept. As the group timer expires, the router may change to the reception for the listed sources. The elimination of the filter-mode will greatly simplify the router behavior, e.g. the action on reception of reports and the setting of the timers. The detailed operation of router operation is described in section 4. Liu,etc. Expires December,2006 [Page 4] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 3. IGMPv3-lite protocol for Group Members 3.1. Group Record Types There are three group record types defined in the full IGMPv3: Current-State Record (taking value of NODE_IS_INCLUDE and NODE_IS_EXCLUDE), Filter-Mode-Change Record (CHANGE_TO_INCLUDE_MODE and CHANGE_TO_EXCLUDE_MODE) and Source-List-Change Record (ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES). Among these messages, CHANGE_TO_EXCLUDE_MODE is not used, for the process related to it is completely the same as that of MODE_IS_EXCLUDE. The formats of other five messages are the same as that of full IGMPv3. MODE_IS_EXCLUDE is solely used for EXCLUDE. 3.2. Action on Change of Interface State The interface state change rules are simplified as the elimination of EXCLUDE mode, which can be expressed by: Old State New State State-Change Record Sent --------- --------- ------------------------ INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK(A-B) INCLUDE (A) EXCLUDE (NULL) IS_EX(NULL) EXCLUDE (NULL) INCLUDE (B) TO_IN(B) 4. IGMPv3-lite protocol for Multicast Routers 4.1. Group timers and source timers in lite version As section 2.2 mentioned, it is possible for IGMPv3-lite to discard filter-mode denotation in the router. The group timer, which being previously used as a mechanism for transitioning the router filter- mode from EXCLUDE to INCLUDE, now is redefined for the transitioning between the ASM and SSM receiving state on the router. The role of the group timer can be summarized as follows: Group Timer Value Actions/Comments ------------------ ----------------- G_Timer > 0 All members in this group. Liu,etc. Expires December,2006 [Page 5] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 G_Timer == 0 No more listeners to this ASM group. If all source timers have expired then delete group record. If there are still source record timers running, use those source records with running timers as the source record state. The operation related to the group and source timers is different compared to the full IGMPv3. In the full version, if a source timer expires under the EXCLUDE router filter-mode, its corresponding source record is not deleted until the group timer expires. In lite version, if a source timer expires, its source record should be deleted immediately, not waiting for the time-out of the group timer. 4.2. Source-Specific Forwarding Rules The forwarding rules depend on group and source timer values. Now they can be expressed as follows: Group Timer Source Timer Action ----------- ------------------ ---------------------- G_Timer == 0 S_TIMER > 0 Suggest to forward traffic from source G_Timer == 0 S_TIMER == 0 Suggest to stop forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record. G_Timer == 0 No Source Elements Suggest not to forward traffic from the source G_Timer > 0 S_TIMER >= 0 Suggest to forward traffic from source G_Timer > 0 No Source Elements Suggest to forward traffic from source 4.3. Reception of Current-State Records When receiving Current-State Records, the IGMPv3-lite router needs reset its group or source timers, and update its source list within the group. In SSM group (G_Timer==0), the source list includes Liu,etc. Expires December,2006 [Page 6] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 sources to be forwarded by the router, while in ASM group (G_Timer >0) the source list remembers the sources to be forwarded after switching back to SSM mode. Old Source new Source Group Timer list Report Rec'd list Actions ----------- ------ ------------ ------- --------- G_Timer==0 A IS_IN(B) A+B (B)=GMI G_Timer==0 A IS_EX(NULL) A G_Timer= GMI G_Timer >0 A IS_IN(B) A+B (B)=GMI G_Timer >0 A IS_EX(NULL) A G_Timer = GMI And the above table could be further simplified for the processes are completely the same for the two values of the G-Timer: Old Source new Source list Report Rec'd list Actions ------ ------------ ------- --------- A IS_IN(B) A+B (B)=GMI A IS_EX(NULL) A G_Timer= GMI 4.4. Reception of Source-List-Change and Filter-Mode-Change Records On receiving Source-List-Change Records, the IGMPv3-lite router needs reset its group and source timers, update its source list within the group, or trigger group queries. Old Source new Source Group Timer list Report Rec'd list Actions ----------- ------ ------------ ------- --------- G_Timer==0 A ALLOW(B) A+B (B)=GMI G_Timer==0 A BLOCK(B) A Send Q(G,A*B) Liu,etc. Expires December,2006 [Page 7] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 G_Timer==0 A TO_IN(B) A+B (B)=GMI Send Q(G,A-B) G_Timer >0 A ALLOW(B) A+B (B)=GMI G_Timer >0 A BLOCK(B) A Send Q(G,A*B) G_Timer >0 A TO_IN(B) A+B (B)=GMI SendQ(G,A-B) Send Q(G) The table could be further simplified by merging duplicate lines: Old Source new Source list Report Rec'd list Actions ------ ------------ ------- --------- A ALLOW(B) A+B (B)=GMI A BLOCK(B) A Send Q(G,A*B) A TO_IN(B) A+B (B)=GMI Send Q(G,A-B) If G_Timer>0 Send Q(G) 5. Interoperability IGMPv3-lite hosts and routers should interoperate gracefully with hosts and routers that running IGMPv1/IGMPv2/IGMPv3. The simplification in IGMPv3-lite introduces no changes on the message format of the group query and report. The member sends a subset of IGMPv3 reports, which can be recognized by full IGMPv3 protocols. The discard of the filter-mode on the router just simplified the processing inside the router, not influencing the outside behavior of the protocol. From above discussion, IGMPv3-lite can be treated as a ''parallel version'' of full IGMPv3. Its interoperability method with lower Liu,etc. Expires December,2006 [Page 8] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 versions (i.e. IGMPv1 and IGMPv2) should be the same as that of the IGMPv3 and MLDv2. 5.1. Interoperation with IGMPv1/IGMPv2 IGMPv3-lite protocol adopts the same Host/Group Compatibility Mode and keeps Querier Present timers for IGMPv1 and IGMPv2. Their definition and processing is just the same as [IGMPv3]. When Group Compatibility mode is IGMPv2 or IGMPv1, an IGMPv3-lite router translates the following IGMPv2 or IGMPv1 messages for that group to their IGMPv2 or IGMPv1 equivalents, as following: IGMP Message IGMPv3 lite Equivalent -------------- ----------------- v1 Report IS_EX(NULL) v2 Report IS_EX(NULL) v2 Leave TO_IN(NULL) 5.2. Interoperation with full IGMPv3 If an IGMPv3-lite router receives reports from the full IGMPv3 host, it should treat the messages as follows: IGMPv3 Report IGMPv3-lite Equivalent -------------- ----------------- IS_IN(x) IS_IN(x) IS_EX(x) IS_EX(NULL) TO_IN(x) TO_IN(x) TO_EX(x) IS_EX(NULL) ALLOW(x) ALLOW(x) BLOCK(x) BLOCK(x) Liu,etc. Expires December,2006 [Page 9] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 6. Affects to other protocols The simplified protocols put no additional burden on the implementation of other related protocols, e.g. IGMP/MLD snooping, multicast routing protocol and operation of application sockets. On the other hand, the processing load on the switches and routers that running IGMPv3 (snooping) and multicast routing protocols will be greatly decreased. 7. Security Considerations The security consideration is the same as that of the original IGMPv3/MLDv2. 8. References [IGMPv3] Cain, B.,"Internet Group Management Protocol, Version3", RFC3376, October 2002. [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC3810, June 2004. Author's Addressess Hui Liu Huawei Technologies Co., Ltd Liuhui47967@huawei.com Wei Cao Huawei Technologies Co., Ltd Email: caowayne@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Liu,etc. Expires December,2006 [Page 10] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment The author would like to thank magma and mboned mailing lists for discussion and contribution for the ideas. Liu,etc. Expires December,2006 [Page 11]