MAGMA Hui Liu Internet Draft wei cao Expires: December 2006 Huawei Technologies Co.,Ltd. June 15, 2006 Simplifying Process for IGMPv3 and MLDv2 Protocols draft-liu-magma-igmpv3-mldv2-lite-00.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 15, 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. Liu etc. Expires November, 2006 [Page 1] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 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. Detailed Simplifying Method of the Group Members.............5 3.1. Group Record Types Adopted..............................5 3.2. Action on Change of Interface State.....................5 4. Detailed Simplifying method of the router....................6 4.1. Redefinition of Group timers............................6 4.2. IGMPv3-lite Source-Specific Forwarding Rules............6 4.3. Action on Reception of Current-State Report.............7 4.4. Action on Reception of Source-List-Change Records........7 5. Interoperability............................................8 5.1. Interoperation with IGMPv1/IGMPv2.......................8 5.2. Interoperation with IGMPv3..............................9 6. Affects to other protocols...................................9 7. Security Considerations......................................9 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. With this filtering function, 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. Liu,etc. Expires December,2006 [Page 2] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 If a receiver on a host wants to receive from specific sources, it'll send an IGMP or MLD report with filter-mode set to INCLUDE. On the other hand if the host needs to receive some sources, the filter-mode of the report should be 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 IGMP or MLD 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, thus 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 shows he is unwilling to receive from some sources. Even if such application existed, 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 do not seem a useful implementation. Considering the limited effects of EXCLUDE filter-mode, and the complicacy of the operation related to 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 IGMP snooping). 2. Simplification Method overview The simplifying principle is to introduce changes to IGMPv3 and MLDv2 as minimal as possible and to realize the interoperability easily. For convenience, we just mention IGMPv3, because the source filtering mechanism is the same for IGMPv3 and MLDv2 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 just take the same service interface model as that of IGMPv3 [IGMPv3]: IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list) In the simplified protocol, EXCLUDE mode on the group member part is preserved just for the expression of non-source-specific group join, which is equivalent to IGMPv2/IGMPv1/MLDv1 join. It is denoted as EXCLUDE < NULL > in this draft. Group members just send four types of report: MODE_IS_INCLUDE, ALLOW_NEW_SOURCES, BLOCK_OLD_SOURCES and MODE_IS_EXCLUDE (for EXCLUDE only). The other two report types defined for mode- switching are not used in the IGMPv3-lite. The interface state change action needs not consider the mode-change operation. And the corresponding interface timer and group timer act just on the INCLUDE and the EXCLUDE operation. The detailed operation of host operation is described in section 3. 2.2. Behavior of Multicast Routers According to IGMPv3[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. The router in general should not receive EXLUDE-mode report (except for EXCLUDE). So it is considered unnecessary here for the router to maintain the EXCLUDE mode. Further, it is possible that the router filter-mode representation be discarded thoroughly, with INCLUDE as a default mode for processing. Then the state model for multicast router can be changed to: (multicast address, group timer,(source records)) Here group timer is kept to represent ASM group, not for EXCLUDE group as its original meaning. Its basic behavior is as following: when a router receives an ASM group join (i.e. EXCLUDE report), it will set its group timer, and the source list for the source- Liu,etc. Expires December,2006 [Page 4] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 specific group will be kept. When 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 forwarding rules, the action on reception of reports, the setting of the timers and the generation of the query messages. The detailed operation of router operation is described in section 4. 3. Detailed Simplifying Method of the Group Members This section describes the simplifying method from full IGMPv3 to IGMPv3-lite. The common part between them is not illustrated here. 3.1. Group Record Types Adopted There are three group 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 types of report messages, NODE_IS_EXCLUDE is used to denote ASM join(i.e. EXCLUDE). CHANGE_TO_INCLUDE_MODE and CHANGE_TO_EXCLUDE_MODE are not used, and ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES are used only for INCLUDE mode. 3.2. Action on Change of Interface State The interface state change rules are simplified as the elimination of EXCLUDE(S,G) 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) EXCLUDE (NULL) EXCLUDE (NULL) INCLUDE (B) INCLUDE (B) Editor Note: When interface state changes from EXCLUDE(NULL) to INCLUDE(B), maybe it is better to send INCLUDE(NULL) before sending INCLUDE(B) for fast blocking unwanted old source. Liu,etc. Expires December,2006 [Page 5] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 4. Detailed Simplifying method of the router 4.1. Redefinition of Group timers As section 2.2 mentioned, it is possible for IGMPv3-lite to discard filter-mode denotation in the router. The group timer, which previously used as a mechanism for transitioning the router filter- mode from EXCLUDE to INCLUDE, now is redefined for ASM join state maintenance 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. G_Timer == 0 No more listeners to this (*,G) 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. 4.2. IGMPv3-lite Source-Specific Forwarding Rules The original forwarding rules depend on filter-mode and source timer value. Now they can be expressed as follows: Group Timer Source Timer Value 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 Liu,etc. Expires December,2006 [Page 6] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 G_Timer > 0 S_TIMER >= 0 Suggest to forward traffic from all sources in this group G_Timer > 0 No Source Elements Suggest to forward traffic from all sources in this group 4.3. Action on Reception of Current-State Report When receiving Current State Records, the IGMPv3-lite router needs only reset its group and source timers, and update its source list within the group. Operations related to mode processing and switching are not required. 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 4.4. Action on Reception of Source-List-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 specific group queries. The complex operations related to mode processing and switching are not required. 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) G_Timer >0 A ALLOW(B) A+B (B)=GMI Liu,etc. Expires December,2006 [Page 7] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 G_Timer >0 A BLOCK(B) A+B Send Q(G,B) 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 original 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 versions (i.e. IGMPv1, IGMPv2, and MLDv1) should be the same as that of the IGMPv3 and MLDv2. 5.1. Interoperation with IGMPv1/IGMPv2 IGMPv3-lite protocol can 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 that of original IGMPv3 [IGMPv3]. There is only a little difference that when Group Compatibility mode is IGMPv2 or IGMPv1, a IGMPv3-lite router internally translates the following IGMPv2 or IGMPv1 messages for that group to their IGMPv2 or IGMPv1 equivalents, as following IGMP Message IGMPv3 Equivalent -------------- ----------------- v1 Report IS_EX( {} ) v1 Leave IS_IN( {} ) v2 Report IS_EX( {} ) v2 Leave IS_IN( {} ) Liu,etc. Expires December,2006 [Page 8] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 5.2. Interoperation with IGMPv3 As earlier mentioned, the interoperation between IGMPv3-lite and original IGMPv3 protocol can be easily implemented. There is no difficulty for IGMPv3 to recognize IGMPv3-lite protocol messages, for the later is only a subset of that of IGMPv3. If an IGMPv3-lite router receives the original IGMPv3 reports, it should treat them as follows: IGMPv3 Report IGMPv3-lite Equivalent -------------- ----------------- IS_IN(x) IS_IN(x) IS_EX(x) IS_EX({}) TO_IN(x) IS_IN(x) TO_EX(x) IS_EX({}) ALLOW(x) ALLOW(x) BLOCK(x) BLOCK(x) 6. Affects to other protocols The simplified protocols put no additional burden on the behavior of other related protocols, e.g. IGMP/MLD snooping, multicast routing protocol and operation of application sockets. On the other hand, the degree of complexity is decreased for processing procedures of the switches and routers that running IGMP(snooping) and multicast routing protocols. The processing load on the equipments will be reduced accordingly. 7. Security Considerations The security consideration is the same as that of the original IGMPv3/MLDv2. Liu,etc. Expires December,2006 [Page 9] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 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. 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 Liu,etc. Expires December,2006 [Page 10] Internet-Draft IGMPv3 & MLDv2 Lite June 2006 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]