MAGMA Working Group H. Liu
Internet-Draft W. Cao
Expires: April, 2007 Huawei Technologies Co., Ltd.
H. Asaeda
Keio University
October 14, 2006
Simplifying Process for IGMPv3 and MLDv2 Protocols
<draft-liu-magma-igmpv3-mldv2-lite-02.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
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes simplified IGMPv3 and MLDv2 protocols, which
are called IGMPv3-lite and MLDv2-lite. The interoperability with
other versions of IGMP and MLD is also considered.
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].
H. Liu et. al. [Page 1]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
Table of Contents
1. Introduction ................................................... 2
2. Simplification Method Overview ................................. 3
2.1. Behavior of Group Members ................................. 3
2.2. Behavior of Multicast Routers ............................. 4
3. IGMPv3-lite Protocol for Group Members ......................... 4
3.1. Action on Change of Interface State ....................... 5
3.2. Action on Reception of a Query ............................ 5
3.3. Group Record Types ........................................ 6
4. IGMPv3-lite Protocol for Multicast Routers ..................... 7
4.1. Group Timers and Source Timers in the Lite Version ........ 8
4.2. Source-Specific Forwarding Rules .......................... 9
4.3. Reception of Current-State Records ........................ 9
4.4. Reception of Source-List-Change and
Filter-Mode-Change Records ............................... 10
5. Interoperability .............................................. 11
5.1. Interoperation with IGMPv1/IGMPv2 ........................ 11
5.2. Interoperation with the Full Version of IGMPv3 ........... 12
6. Implementation Considerations ................................. 12
6.1. Implementation of Source-Specific Multicast .............. 12
6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 13
7. Security Considerations ....................................... 13
8. Normative References .......................................... 13
9. Informative References ........................................ 13
Intellectual Property Statement .................................. 14
Disclaimer of Validity ........................................... 14
Copyright Statement .............................................. 15
Acknowledgment ................................................... 15
1. Introduction
IGMPv3 [IGMPv3] and MLDv2 [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 host wants to receive from specific sources, it sends
an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. On the
other hand if the host does not want to receive from some sources, it
sends the report with filter-mode set to EXCLUDE. A source list for
the given sources shall be included in the report message.
INCLUDE and EXCLUDE filter modes are also defined in a multicast
H. Liu et. al. [Page 2]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
router to process the IGMPv3 or MLDv2 reports. Group timer and source
timer are used to maintain forwarding state of desired group and
source. A multicast router decides its filter-mode, type, and value
of the timers and forwarding methods according to the specific rules
when a group report message arrives or timer expires. The router then
has to switch its filter-mode under certain conditions. All above
factors correlated with each other, while the determination rule is
relatively complex as the receiving state could be frequently
changed.
The multicast filter-mode improves the expressing ability of the
multicast receiver. It is useful to support Source-Specific Multicast
(SSM) [SSM] by specifying interesting source addresses with INCLUDE
mode. However, practical applications do not use EXCLUDE mode to
block sources so often, because a user or application usually wants
to specify desired source addresses, not undesired source addresses
to not receive from them. Even if a user wants to explicitly refuse
traffic from some sources in a group, when other users in the same
shared network have interest in these sources, the corresponding
multicast traffic is forwarded to the network after all.
This document aims to propose the simplified IGMPv3 and MLDv2
(referred to as IGMPv3-lite and MLDv2-lite) in which EXCLUDE filter
mode that supports to exclude data come from specified sources is
eliminated. Not only IGMPv3-lite and MLDv2-lite are compatible with
the standard IGMPv3 and MLDv2, but also the protocol operations made
by data receiver hosts and routers or switches (performing
IGMPv3/MLDv2 snooping) are simplified in the lite version protocol
and complicated operations are hence effectively reduced. Since
IGMPv3-lite and MLDv2-lite are fully compatible with the full version
of these protocols (i.e. the standard IGMPv3 and MLDv2), hosts or
routers that have implemented the full version do not need to
implement or modify anything to cooperate with IGMPv3/MLDv2-lite
hosts or routers.
2. Simplification Method Overview
The 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, this document mainly discusses IGMPv3 since MLDv2
inherits the same source filtering mechanism, but additionally shows
MLDv2's unique specifications when needed.
2.1. Behavior of Group Members
H. Liu et. al. [Page 3]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
In the IGMPv3-lite, the same service interface model as that of
IGMPv3 [IGMPv3] is inherited:
IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list )
In the lite version protocol, EXCLUDE mode on the host part is
preserved only for EXCLUDE (*,G) join, which denotes non-source-
specific group report (as known as (*,G) join) and is equivalent to
the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The
detailed host operation of IGMPv3/MLDv2-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 (*,G), which means
including all sources and can also be interpreted as INCLUDE mode.
Without EXCLUDE mode report information, it is unnecessary for the
router to maintain the EXCLUDE filter-mode, and the state model for
multicast router can be simplified as:
(multicast address, group timer, (source records))
Here group timer is kept to represent (*,G) group join. Its basic
behavior is: when a router receives a (*,G) group join, it will set
its group timer, and the source list for the source-specific 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.
3. IGMPv3-lite Protocol for Group Members
IGMPv3-lite uses two sets of messages, i.e., Query messages and
Report messages the same as the full version protocols. Although
H. Liu et. al. [Page 4]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
most of these message types and corresponding group records are
inherited from the full version protocols, an operation that triggers
EXCLUDE (S,G) join is omitted and the corresponding record types of
the Report are modified on the lite version protocols.
3.1. Action on Change of Interface State
When an interface state of a group member host is changed, a State-
Change Report for that interface is immediately transmitted from that
interface. The type and contents of the Group Record(s) in that
Report are determined by comparing the filter mode and source list
for the affected multicast address before and after the change. While
the requirements are the same as the full version for the
computation, in the lite version host, the interface state change
rules are simplified due to the reduction of message types. The
contents of the new transmitted report are calculated as described in
section 3.3.
To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness
Variable]-1 more times, at intervals chosen at random from the range
(0, [Unsolicited Report Interval]). (These values are defined in
[IGMPv3, MLDv2].)
In the full version of IGMPv3, as was done with the first report, the
interface state for the affected group before and after the latest
change is compared, and the report records expressing the difference
are built and merged with the contents of the pending report, to
create the new State-Change report. However, it is optional that an
IGMPv3-lite host merges with the contents of the pending report. If
the IGMPv3-lite host does not merge with the contents of the pending
report, it transmits each report sequentially. Doing so can greatly
simplified the operation for scheduling the reports.
3.2. Action on Reception of a Query
When a lite version host receives a Query, it does not respond
immediately. Instead, it delays its response by a random amount of
time, bounded by the Max Resp Time value derived from the Max Resp
Code in the received Query message [IGMPv3, MLDv2]. The system may
receive a variety of Queries on different interfaces and of different
kinds (e.g., General Queries, Group-Specific Queries, and Group-and-
Source-Specific Queries), each of which may require its own delayed
response.
Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the lite version host must
H. Liu et. al. [Page 5]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
be able to maintain the following state:
o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
IGMPv3-lite inherits most of the rules that are used to determine if
a Report needs to be scheduled from the full version. The different
point is regarding the simplification of EXCLUDE filter-mode and the
type of Report to schedule as detailed in section 3.3.
On the other hand, while it is optional that an IGMPv3-lite host
merges with the contents of the pending report for unsolicited report
(i.e. State-Change report) as mentioned in the previous section, if
the received Query is a Group-and-Source-Specific Query and there is
a pending response for this group with a non-empty source-list, then
the group source list is augmented to contain the list of sources in
the new Query and a single response is scheduled using the group
timer as with the full version host. The new response is then
scheduled to be sent at the earliest of the remaining time for the
pending report and the selected delay.
3.3. Group Record Types
There are three Group Record Types defined in the full IGMPv3:
Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN)
or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by
CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and
Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or
BLOCK_OLD_SOURCES (BLOCK).
Among these messages, several record types defined in the full IGMPv3
are not used in IGMPv3-lite as some of the processes related to the
filter mode change to the EXCLUDE mode are eliminated and some of the
report messages are converged with a record having null source
address list. All of the record types of report messages used by the
full and lite version protocols are shown as follows:
Full ver. Lite ver. Comments
--------- --------- --------------------------------
IS_EX() IS_EX() Query response for (*,G) join
H. Liu et. al. [Page 6]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
IS_EX(x) N/A Query response for EX (x,G) join
IS_IN(x) ALLOW(x) Query response for IN (x,G) join
ALLOW(x) ALLOW(x) IN (x,G) join
BLOCK(x) BLOCK(x) IN (x,G) leave
TO_IN(x) TO_IN(x) Change to IN (x,G) join
TO_IN() TO_IN() (*,G) leave
TO_EX(x) N/A Change to EX (x,G) join
TO_EX() IS_EX() (*,G) join
where "x" represents non-null source address list and "()" represents
null source address list. For instance, IS_EX() means a report whose
record type is IS_EX with null source address list. "N/A" represents
not applicable (or no use) because the corresponding operation should
not occur in the lite version protocols.
IGMPv3-lite does not use EXCLUDE filter-mode with non-null source
address list. And a multicast router creates the same state when it
receives a report message containing either of IS_EX or TO_EX record
types. Therefore, IGMPv3-lite integrates the TO_EX operation to the
IS_EX operation.
On the other hand, when an IGMPv3-lite version host needs to make a
query response for the state of INCLUDE (x,G) join, the host makes
the response whose message type is expressed with ALLOW(x), instead
of using IS_IN record type, for router's processing of the two
messages are completely the same, the IS_IN(x) type is eliminated for
simplification.
An IGMPv3-lite version host does not use EXCLUDE mode, while TO_IN
record is used with the following situation; the host firstly
launches an application (AP1) that requests INCLUDE (x,G) join, and
it sends ALLOW(x). Then the host launches another application (AP2)
that joins (*,G), and it sends IS_EX(). In this condition, when AP2
terminates but AP1 keeps working on the lite version host, the host
sends a report with TO_IN(x) record type for [Robustness Variable]
times.
4. IGMPv3-lite Protocol for Multicast Routers
The major difference between the full and lite version protocol on
H. Liu et. al. [Page 7]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
the router is that filter-mode is discarded for the lite version, as
section 2.2 mentioned. Then the IGMP state maintained by the router
for each attached network can be simplified as:
(multicast address, group timer, (source records))
where the source record includes pairs of source address and its
corresponding source timer. The reduction of filtering mode will
change the meaning of the group timer and will simplify the router's
processing.
4.1. Group Timers and Source Timers in the Lite Version
The source timer is kept for each source record and it is updated
when the source is present in a received report. It indicates the
validity of the sources and needs to be referred when the router
takes its forwarding decision.
The group timer, which being used in full IGMPv3 as a mechanism for
transitioning the router's filter-mode from EXCLUDE to INCLUDE, is
now redefined for the identification of the non-source-specific
receiving states. Once a group record of IS_EX() is received, the
group timer is used to represent this (*,G) group join. The
expiration of the group timer indicates that there are no listeners
on the attached network for this (*,G) group. Then if at this moment
there are unexpired sources (whose source timers are greater than
zero), the router will change to receiving for those sources. 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.
The operation related to the group and source timers has some
difference compared with 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. They are kept for indicating undesired sources. In the lite
version, since there is no need to keep such records for blocking
H. Liu et. al. [Page 8]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
specific sources, 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 suggestion made by igmpv3-lite to the routing
protocols is 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 resets
its group or source timers and updates its source list within the
group. For source-specific group reception state(G_Timer==0), the
source list includes sources to be forwarded by the router, while in
non-source-specific group reception(G_Timer>0) the source list
remembers the sources to be forwarded after toggling to source-
specific reception state.
Old New
Source Source
Group Timer List Report Rec'd List Actions
----------- ------ ------------ ------- -----------
H. Liu et. al. [Page 9]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_EX() A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX() 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 New
Source Source
List Report Rec'd List Actions
------ ------------ ------- ------------
A IS_IN(B) A+B (B)=GMI
A IS_EX() 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
to reset its group and source timers, update its source list within
the group, or trigger group queries.
Old New
Source 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 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)
H. Liu et. al. [Page 10]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
The table could be further simplified by merging duplicate lines:
Old New
Source 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
IGMPv3/MLDv2-lite hosts and routers should interoperate gracefully
with hosts and routers that running IGMPv1/v2/v3 or MLDv1/v2.
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/MLDv2-lite can be treated as a
"parallel version" of the full IGMPv3/MLDv2. Its interoperability
method with lower versions (i.e. IGMPv1/v2 and MLDv1) 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
H. Liu et. al. [Page 11]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
-------------- ----------------------
v1 Report IS_EX()
v2 Report IS_EX()
v2 Leave TO_IN()
5.2. Interoperation with the Full Version of 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()
TO_IN(x) TO_IN(x)
TO_EX(x) IS_EX()
ALLOW(x) ALLOW(x)
BLOCK(x) BLOCK(x)
6. Implementation Considerations
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 loads on the switches and routers that
running IGMPv3 (snooping) and multicast routing protocols will be
greatly decreased.
In the following sections, the protocols related to the
implementation of IGMPv3/MLDv2 are restated for the lite version.
6.1. Implementation of Source-Specific Multicast
RFC [IGMP-SSM] illustrates the requirements of implementation of
Source-Specific Multicast on IGMPv3/MLDv2 hosts and routers. The lite
protocol does not impose any bad influences on SSM application. The
requirements of IGMPV3/MLDv2-lite for support of SSM are illustrated
H. Liu et. al. [Page 12]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
below.
For an SSM-aware host, the application should not send a non-source-
specific join, i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages
for the SSM address. The reception of a non-source-specific join with
an SSM group address should indicate an error to the application. The
SSM-aware router will ignore IS_EX() reports with SSM addresses.
Other types of Reports should be processed normally.
6.2. Implementation of Multicast Source Filter (MSF) APIs
Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF
API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF
API, and (4) Protocol-Independent Advanced MSF API.
According to the MSF APIs definition, an IGMPv3-lite version host
should implement IPv4 Basic MSF API and an MLDv2-lite version host
should implement Protocol-Independent Basic MSF API. Other APIs, IPv4
Advanced MSF API and Protocol-Independent Advanced MSF API, are
optional to implement in IGMPv3/MLDv2-lite version host.
7. Security Considerations
The security consideration is the same as that of the full version of
IGMPv3/MLDv2.
8 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate
requirement levels," RFC 2119, March 1997.
9 Informative References
[SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP,"
RFC 4607, August 2006.
[IGMPv3] Cain, B.,"Internet Group Management Protocol, Version3," RFC
3376, October 2002.
[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version
2 (MLDv2) for IPv6," RFC 3810, June 2004.
[IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific
H. Liu et. al. [Page 13]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
Multicast," RFC 4604, August 2006.
[MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface
Extensions for Multicast Source Filters," RFC 3678, January 2004.
Author's Addressess
Hui Liu
Huawei Technologies Co., Ltd
Email: Liuhui47967@huawei.com
Wei Cao
Huawei Technologies Co., Ltd
Email: caowayne@huawei.com
Hitoshi Asaeda
Keio University
Email: asaeda@wide.ad.jp
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
this standard. Please address the information to the IETF at ietf
ipr@ietf.org.
Disclaimer of Validity
H. Liu et. al. [Page 14]
Internet Draft IGMPv3 and MLDv2 Lite October 2006
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.
H. Liu et. al. [Page 15]