Multimob Group H. Liu Internet Draft Q. Wu Category: Standard Track Huawei Technologies Expires: September 2010 March 1, 2010 Reliable IGMP and MLD Protocols in Wireless Environment draft-liu-multimob-reliable-igmp-mld-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 1, 2010. Liu, et al. Expires September 1, 2010 [Page 1] Internet-Draft Wireless IGMP and MLD March 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo specifies the reliability enhancement of IGMP and MLD group management protocol, which is intended to be used in wireless and/or mobile network environment. The reliability is simply achieved by providing acknowledgment to IGMP/MLD join messages. Table of Contents 1. Introduction.................................................2 2. General Discussions..........................................3 3. Protocol Behavior Description................................4 3.1. Group Member Operations.................................5 3.2. Multicast Router Operations.............................6 4. Message Format...............................................6 5. Interoperability Considerations.............................11 6. New Parameters Defined......................................12 7. Security Considerations.....................................13 8. References..................................................13 8.1. Normal References......................................13 8.2. Informative References.................................14 Authors' Addresses.............................................14 1. Introduction IGMP (Internet Group Management Protocol) was originally designed according to wired shared-medium Ethernet network model. It has several versions (IGMPv1/v2/v3 [1][2][3], MLDv1/v2[4][5]) which are liu, et al. Expires September 1, 2010 [Page 2] Internet-Draft Wireless IGMP and MLD March 2010 evolved with new features added to meet the increased requirements but they all keep on the original shared Ethernet model. With the emerging of wireless network and techniques, mobile or wireless IP multicast sees their potentiality to be deployed to enable efficient delivery of mobile video service. Because the networking conditions in these scenarios are different from that of fixed Ethernet, e.g. with possibly higher packet loss rate, current versions of IGMP and MLD are somewhat inadequate and there is the demand that IGMP/MLD protocol should be enhanced to meet the reliability requirements in these scenarios [8][9]. This memo introduces the reliability enhancement of group management protocol on wireless or mobile IP networks. The reliability is enhanced by providing acknowledgement for group join request messages. The document is arranged as follows: section 2 discusses the general issues including the requirements and basic mechanism. Section 3 describes the protocol behavior on both the host and the router part. Section 4 defines the message format and Section 5 discusses interoperability issue with the earlier deployed versions. Section 6 defines the timer and counter parameters. The state- machine of the new protocol will be included in the later version of draft. 2. General Discussions Wireless network has the characteristics that its packet delivery is sometimes unreliable (e.g. with much higher packet loss rate) due to its unstable media transmission conditions. And in some mobile IP multicast designs, the IGMP/MLD messages have to be sent from foreign network to home network. In these two cases, IGMP and MLD reports are prone to loss due to network conditions degradation or long distance travel. IGMP and MLD (except for IGMPv1) define a retransmission parameter [Robustness Variable] which determines the transmission times the report was sent. It improves the reliability to some degree but is inadequate for several reasons. First, because the value for the variable is constant, if the network is in good condition, the packet retransmission is a waste of resources. Secondly, on lossy network, even multiple packets are sent, all of them may be lost, thus robustness can not be guaranteed. Finally, if the link condition changes from time to time, or if the host moves from one liu, et al. Expires September 1, 2010 [Page 3] Internet-Draft Wireless IGMP and MLD March 2010 network or link to another, it is difficult to arrange a reasonable value for the parameter. This memo suggests adopting acknowledgement-retransmission mechanism, which is commonly deployed in today's protocol design, to enhance the reliable delivery of IGMP/MLD join report. Its basic protocol behavior is direct and simple. IGMP or MLD host after sending a join report, starts a retransmission timer and waits for the acknowledgement (ACK) message from the router. If the ACK is not received when the timer expires, another report is retransmitted. The protocol should also use a parameter [RETRANS_COUNT]), to limit the maximum retransmission times when make the joining. The acknowledgment mechanism was proposed in an earlier work [8] which suggests providing feedback for the group join messages instead of periodical Queries on point-to-point network. Draft [10] discusses another feedback method when group join can not be processed normally by the router. It can be seen that acknowledgment to join is not a rare thought related to group management protocol. Retransmission enhanced with acknowledgment is more efficient because if a report is successfully acknowledged, its retransmission is not needed. 3. Protocol Behavior Description The reliable group management protocol does not change the general protocol behavior prescribed in previous IGMP and MLD. The difference lies in the use of ACK message, which are sent in response to the join report that require acknowledgement. There are two kinds of report generated by an IGMP/MLD host - unsolicited reports when host initially join a group to request reception of the multicast data, and passive report in response to router's Queries to refresh the state database of the host on the router. Because unsolicited reports have direct effects on user' experience, their reliability requirements are stronger than those of the passive ones. It is suggested that only unsolicited report is acknowledged by the router, while the passive report is not acknowledged because in IGMP/MLD they are generated continuously, the acknowledgement on them will produce too many extra packets on the network. For some mobile IP multicast networks, IGMP/MLD reports, which may be generated by a host or a router, have to travel from foreign liu, et al. Expires September 1, 2010 [Page 4] Internet-Draft Wireless IGMP and MLD March 2010 network to home network. These reports can be acknowledged by the router on the home network to improve reliability. To differentiate whether an IGMP/MLD report should be acknowledged or not, an ACK flag can be set in the report message. The router on receiving a report message decides whether to feedback an ACK message or not according to this flag, which can be set in the reserved field of an IGMP/MLD message. In this memo the extension is made based on IGMPv2 and MLDv2 messages. For unacknowledged reports, the process of the host and router on them are the same as the fixed IGMP/MLD protocols. That is, the host sends the report without the ACK flag, for [Robustness Variable] times. The router will not generate ACK message in reception of this report. The definition of the timers and counters aforementioned will be described later in this memo. Their names will appear in square brackets. 3.1. Group Member Operations Host actively sends IGMP or MLD Report to the attached router when it wants to join a multicast group or a source-group channel, which will be confirmed by the router by an IGMP or MLD Acknowledgment (ACK) message. If after an [RETRANS_INTERVAL] interval the ACK is not received, the host should resend the report and wait another ACK. Host stops its retransmission attempt as the retransmission number reach the [RETRANS_COUNT]. There is the possibility that the ACK message for a report is sent by a router but lost. Because in this case the router will forward the multicast traffic after the acknowledgment, the multicast data received by the host can be used to make the acknowledgement by the host. Thus if a host receives the multicast data it asks for, it will stop retransmitting report even though ACK message is not received. The host also sends reports on receiving the Queries from the router. In this case, it does not wait for the acknowledgement of the router and the host's behavior is the same as those defined in its fixed IGMP/MLD versions. When IGMP/MLD reports have to travel from one part of the network to another, they can also be acknowledged because they have more possibilities of being lost. These reports could be produced by liu, et al. Expires September 1, 2010 [Page 5] Internet-Draft Wireless IGMP and MLD March 2010 either a host or router, depending on the arrangement of a mobile network. The acknowledgement and retransmission method for the report is the same as that of unsolicited report. 3.2. Multicast Router Operations The router according to the ACK flag decides whether to provide acknowledgment to the received report. The destination address of ACK packet is set to the unicast address of the host to be acknowledged. The router after acknowledging the unsolicited report will create the state for this receiver and start to send the multicast data toward the receiver. In some situations the router has already created states for the report sender (which may be an attached host or a remote host/router). When the router still receive the sender's report requesting ACK, it will still provide acknowledgement to the sender. Other protocol behavior on the router should be same as the those described in fixed network IGMPv3 and MLDv2 versions [3][5]. 4. Message Format For convenience of illustration, we refer to the IGMP/MLD defined in this version as Wireless IGMP/WMLD (WIGMP/WMLD) protocols, whose suggested message formats are constructed based on IGMPv3/MLDv2 messages. The differences between the message sets of WIGMP/WMLD and IGMPv3/MLDv2 are that WIGMP/WMLD report uses an additional flag to indicate whether the message is to be acknowledged or not, and an ACK message is introduced, as shown in figure 1 to 6. The formats of Queries are the same as those of IGMPv3 and MLDv2 messages, which are not illustrated here. For WIGMP the length of multicast group address and source address should be 32 bits and for WMLD their length should be 128 bits. For the quick processing by the router, this memo recommends an unsolicited WIGMP/WMLD report not to be merged with other reports when generated on an interface, thus only *one* Group Record is present in its message. A new 'flag' field is introduced in the header to denote ACK flag, as respectively shown in Figure 1, and 2. liu, et al. Expires September 1, 2010 [Page 6] Internet-Draft Wireless IGMP and MLD March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved |A| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M)= 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. WIGMP active Report message format with ACK flag set (A=1), sent when the host joins a group liu, et al. Expires September 1, 2010 [Page 7] Internet-Draft Wireless IGMP and MLD March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved |A| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. WIGMP passive Report message format without ACK flag set (A=0), sent in response to a Query liu, et al. Expires September 1, 2010 [Page 8] Internet-Draft Wireless IGMP and MLD March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x8F | Reserved |A| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Addr. Records(M)= 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. WMLD active Report message format with ACK flag set (A=1), sent when host joins a group liu, et al. Expires September 1, 2010 [Page 9] Internet-Draft Wireless IGMP and MLD March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x8F | Reserved |A| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. WMLD passive Report message format without ACK flag set (A=0), sent in response to a Query The format of the Group Records and Multicast Address Record in figure 1, 2, 3 and 4 are defined in [3] and [5]. The ACK message for WIGMP and WMLD are newly introduced. It is unicast sent from a multicast router to a host. There are two options to define ACK messages: one is to reuse current Report message format with a flag for identification for ACK message, the other is to define a new message type. The former has the advantage that it requires no IANA assignment and is more compatible with original IGMP and MLD protocols. The definition of the two message type are shown in figure 5 and 6 liu, et al. Expires September 1, 2010 [Page 10] Internet-Draft Wireless IGMP and MLD March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved |K|0| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M)= 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. WIGMP ACK message format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x8F | Reserved |K|0| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M)= 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. WMLD ACK message format In the second option, new messages chould be defined (e.g Type = 0x33 for WIGMP ACK and Type = 0x99 for WMLD ACK) the other part of the message format are same as figure 1 and figure 2. 5. Interoperability Considerations Only interoperability of WIGMP is discussed and that for WMLD is similar thus is omitted for simplicity. liu, et al. Expires September 1, 2010 [Page 11] Internet-Draft Wireless IGMP and MLD March 2010 If a WIGMP/WMLD host connects to an IGMPv3/MLDv2 router, the router can not process the ACK flag in the report and might do not provide acknowledgement to the report. To enable communication in this scenario, if the router can not process the report and if the host recognizes the version from the Queries, the host should send report without ACK flag and do not wait for the ACK message. The retransmission times could be identified by the [ROBUST_VARIABLE] parameter. The communication should be done without the confirmation of reports, which is the same as IGMPv3/MLD protocols. If a WIGMP/WMLD router faces an IGMPv3/MLDv2 host, the router need not provide feedback on the host's unsolicited report. The WIGMP router must behave as the version used by the host and it must not acknowledge the report sent by the host. The interaction with PIM protocol is that the interface with PIM protocol could be created by the router before or after the ACK- flagged report is acknowledged according to the implementation considerations. For an IGMP/MLD snooping switch, to simplify the processing, the forwarding port is required to be created by snooping the Report message instead of by snooping the ACK message. If the report is acknowledged by the ACK message or the multicast traffic, the switch will normally forward the multicast traffic on this port. Otherwise if the forwarding port was created without the successful acknowledgement of the router, the switch will timeout this port because it could not receive multicast traffic from the router. Thus no special processing is required on the switch when IGMP/MLD is enhanced with ACK mechanism. For IGMP/MLD proxy, the processing is the same as the requirements given by WIGMP/WMLD host and router. The host interface could send a report with or without an ACK flag, and the router interface decide to acknowledge the report message or not according to the ACK flag. 6. New Parameters Defined [RETRANS_INTERVAL]: The time interval between repetitions of a host's report of membership in a group when ACK flag is set. For a unsolicited report, this interval could be set to the same value as [Unsolicited Report Interval] defined in IGMPv3 and MLDv2, whose default value is 1 second. liu, et al. Expires September 1, 2010 [Page 12] Internet-Draft Wireless IGMP and MLD March 2010 [RETRANS_COUNT]: The maximum retransmission number of ACK-flagged report. When the retransmission number reaches this value, the host stops the retransmission efforts even if the ACK message is not received. Default value: 2. Other timer and counter parameter value should be the same as those defined in IGMPv3 and MLDv2. They will not be re-illustrated in this memo. 7. Security Considerations Security will be considered in the future version of this memo. 8. References 8.1. Normal References [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989 [2] Fenner, W., "Internet Group Management Protocol, Version2", RFC 2236, November 1997. [3] B. Cain, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [4] S. Deering, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [5] R. Vida, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [6] M. Christensen, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC4541, May 2006. [7] Fenner, "Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006 liu, et al. Expires September 1, 2010 [Page 13] Internet-Draft Wireless IGMP and MLD March 2010 8.2. Informative References [8] A. Sen Mazumder, "Facilitating Robust Multicast Group Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington, USA. [9] H. Liu, "Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu-multimob-igmp-mld-mobility-req- 02.txt, July 2009. [10] T. Morin, "IGMP/MLD Error Feedback", draft-morin-mboned- igmpmld-error-feedback-02, May 2009. Authors' Addresses Hui Liu Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China EMail: Liuhui47967@huawei.com Qin Wu Huawei Technologies Co., Ltd. Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd. Nanjing, Jiangsu 21001 China liu, et al. Expires September 1, 2010 [Page 14] Internet-Draft Wireless IGMP and MLD March 2010 Phone: +86-25-84565892 EMail: sunseawq@huawei.com liu, et al. Expires September 1, 2010 [Page 15]