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 <S,G> 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<S,G> mode. Considering the limited effects of EXCLUDE
<S,G> 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 <S,G> 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<NULL> 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<NULL>, 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<NULL>.
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) 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]