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 <S,G> 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 <S,G> 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 <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 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<NULL> 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<NULL> 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<NULL>). 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<NULL> 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<NULL>). 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]