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]