draft-ietf-mboned-lightweight-igmpv3-mldv2-00.txt   draft-ietf-mboned-lightweight-igmpv3-mldv2-01.txt 
MBONED Working Group H. Liu MBONED Working Group H. Liu
Internet-Draft W. Cao Internet-Draft W. Cao
Expires: June, 2007 Huawei Technologies Co., Ltd. Expires: December 31, 2007 Huawei Technologies Co., Ltd.
H. Asaeda H. Asaeda
Keio University Keio University
December 19, 2006 June 29, 2007
Lightweight IGMPv3 and MLDv2 Protocols Lightweight IGMPv3 and MLDv2 Protocols
<draft-ietf-mboned-lightweight-igmpv3-mldv2-00.txt> draft-ietf-mboned-lightweight-igmpv3-mldv2-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft http://www.ietf.org/ietf/1id-abstracts.txt.
Shadow Directories can be accessed at http://www.ietf.org/shadow.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes lightweight IGMPv3 and MLDv2 protocols (LW- This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
IGMPv3 and MLDv2. The interoperability with the full versions and IGMPv3 and MLDv2. The interoperability with the full versions and
the previous versions of IGMP and MLD is also taken into account. the previous versions of IGMP and MLD is also taken into account.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119 [1].
[KEYWORDS].
Table of Contents Table of Contents
1. Introduction ................................................... 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Simplification Method Overview ................................. 4 2. Simplification Method Overview . . . . . . . . . . . . . . . . 6
2.1. Behavior of Group Members ................................. 4 2.1. Behavior of Group Members . . . . . . . . . . . . . . . . 6
2.2. Behavior of Multicast Routers ............................. 4 2.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 6
3. LW-IGMPv3 Protocol for Group Members ........................... 5 3. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 8
3.1. Action on Change of Interface State ....................... 5 3.1. Action on Change of Interface State . . . . . . . . . . . 8
3.2. Action on Reception of a Query ............................ 6 3.2. Action on Reception of a Query . . . . . . . . . . . . . . 9
3.3. Applicable Group Record Types ............................. 7 3.3. Applicable Group Record Types . . . . . . . . . . . . . . 10
4. LW-IGMPv3 Protocol for Multicast Routers ....................... 8 4. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12
4.1. Group Timers and Source Timers 4.1. Group Timers and Source Timers in the Lightweight
in the Lightweight Version ................................ 8 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Source-Specific Forwarding Rules .......................... 9 4.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13
4.3. Reception of Current-State Records ....................... 10 4.3. Reception of Current-State Records . . . . . . . . . . . . 13
4.4. Reception of Source-List-Change and 4.4. Reception of Source-List-Change and Filter-Mode-Change
Filter-Mode-Change Records ............................... 11 Records . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Interoperability .............................................. 12 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Interoperation with the Full Version of IGMPv3 ........... 12 5.1. Interoperation with the Full Version of IGMPv3 . . . . . . 16
5.2. Interoperation with IGMPv1/IGMPv2 ........................ 13 5.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16
5.2.1. Behavior of Group Members ........................... 13 5.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16
5.2.2. Behavior of Multicast Routers ....................... 13 5.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17
6. Implementation Considerations ................................. 13 6. Implementation Considerations . . . . . . . . . . . . . . . . 18
6.1. Implementation of Source-Specific Multicast .............. 14 6.1. Implementation of Source-Specific Multicast . . . . . . . 18
6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 14 6.2. Implementation of Multicast Source Filter (MSF) APIs . . . 18
7. Security Considerations ....................................... 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Normative References .......................................... 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Informative References ........................................ 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Intellectual Property Statement .................................. 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Disclaimer of Validity ........................................... 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Copyright Statement .............................................. 16 Intellectual Property and Copyright Statements . . . . . . . . . . 22
Acknowledgment ................................................... 16
1. Introduction 1. Introduction
IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2] implement source IGMP version 3 [2] and MLD version 2 [3] implement source filtering
filtering capability that is not suported by their earlier versions capabilities that are not suported by their earlier versions, IGMPv1
IGMPv2 [IGMPv2] and MLDv1 [MLDv1]. An IGMPv3 or MLDv2 capable host [4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can
can tell which group it would like to join to its upstream router tell its upstream router which group it would like to join by
with specifying which sources it does or does not intend to receive specifying which sources it does or does not intend to receive
multicast traffic from. IGMPv3 and MLDv2 add the capability for a multicast traffic from. IGMPv3 and MLDv2 add the capability for a
multicast router to also learn which sources are of interest to multicast router to also learn which sources are of interest to
neighboring systems, for packets sent to any particular multicast neighboring systems, for packets sent to any particular multicast
address. address.
The filter-modes are defined for the host and router parts of the The INCLUDE and EXCLUDE filter-modes are introduced to support the
protocols respectively to support the source filtering function. If source filtering function. If a host wants to receive from specific
a receiver host wants to receive from specific sources, it sends an sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to
IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. If the host INCLUDE. If the host does not want to receive from some sources, it
does not want to receive from some sources, it sends the report with sends a report with filter-mode set to EXCLUDE. A source list for
filter-mode set to EXCLUDE. A source list for the given sources the given sources shall be included in the report message.
shall be included in the report message.
INCLUDE and EXCLUDE filter modes are also defined in a multicast INCLUDE and EXCLUDE filter modes are also defined in a multicast
router to process the IGMPv3 or MLDv2 reports. When a multicast router to process the IGMPv3 or MLDv2 reports. When a multicast
router receives the report messages from its downstream hosts, it router receives the report messages from its downstream hosts, it
forwards the corresponding multicast traffic by managing requested forwards the corresponding multicast traffic by managing requested
group and source addresses. Group timer and source timer are used to group and source addresses. Group timers and source timers are used
maintain forwarding state of desired group and source. A multicast to maintain the forwarding state of desired groups and sources under
router decides its filter-mode, type, and value of the timers and certain filter modes. When a group report arrives or a certain timer
forwarding methods according to the specific rules when a group expires, a multicast router may update the desired or undesired
report message arrives or the timer expires. The router then has to source lists, reset related timer values, change filter mode, or
switch its filter-mode under certain conditions. With all above trigger group queries. With all of the above factors correlating
factors correlating with each other, the determination rule becomes with each other, the determination rules become relatively complex,
relatively complex as the interface states could be frequently as the interface states could be frequently changed.
changed.
The multicast filter-mode improves the expressing ability of the The multicast filter-mode improves the ability of the multicast
multicast receiver. It is useful to support Source-Specific receiver to express its desires. It is useful to support Source-
Multicast (SSM) [SSM] by specifying interesting source addresses with Specific Multicast (SSM) [7] by specifying interesting source
INCLUDE mode. However, practical applications do not use EXCLUDE addresses with INCLUDE mode. However, practical applications do not
mode to block sources so often, because a user or application usually use EXCLUDE mode to block sources very often, because a user or
wants to specify desired source addresses, not undesired source application usually wants to specify desired source addresses, not
addresses to not receive from them. Even if a user wants to undesired source addresses. Even if a user wants to explicitly
explicitly refuse traffic from some sources in a group, when other refuse traffic from some sources in a group, when other users in the
users in the same shared network have interest in these sources, the same shared network have an interest in these sources, the
corresponding multicast traffic is forwarded to the network after corresponding multicast traffic is forwarded to the network.
all.
This document aims to propose the simplified IGMPv3 and MLDv2, being This document proposes simplified versions of IGMPv3 and MLDv2, named
named Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW- Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2),
MLDv2), in which EXCLUDE filter-mode that supports to exclude data in which EXCLUDE filter-mode is eliminated. Not only are LW-IGMPv3
come from specified sources is eliminated. Not only LW-IGMPv3 and and LW-MLDv2 compatible with the standard IGMPv3 and MLDv2, but also
LW-MLDv2 are compatible with the standard IGMPv3 and MLDv2, but also
the protocol operations made by data receiver hosts and routers or the protocol operations made by data receiver hosts and routers or
switches (performing IGMPv3/MLDv2 snooping) are simplified in the switches (performing IGMPv3/MLDv2 snooping) are simplified in the
lightweight protocol and complicated operations are hence effectively lightweight protocol, and complicated operations are hence
reduced. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the effectively reduced. Since LW-IGMPv3 and LW-MLDv2 are fully
full version of these protocols (i.e. the standard IGMPv3 and MLDv2), compatible with the full version of these protocols (i.e., the
hosts or routers that have implemented the full version do not need standard IGMPv3 and MLDv2), hosts or routers that have implemented
to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 the full version do not need to implement or modify anything to
hosts or routers. cooperate with LW-IGMPv3/LW-MLDv2 hosts or routers.
2. Simplification Method Overview 2. Simplification Method Overview
The principle is to simplify the host and router parts as much as The principle is to simplify the host and router parts as much as
possible to improve efficiency, while guaranteeing the possible to improve efficiency, while guaranteeing interoperability
interoperability with the full versions, and introducing no side with the full versions, and introducing no side effects on
effects on the applications. applications.
For convenience, this document mainly discusses IGMPv3 since MLDv2 For convenience, this document mainly discusses IGMPv3, since MLDv2
inherits the same source filtering mechanism, but additionally shows inherits the same source filtering mechanism, but this document
MLDv2's unique specifications when needed. additionally shows MLDv2's unique specifications when needed.
2.1. Behavior of Group Members 2.1. Behavior of Group Members
In the LW-IGMPv3, the same service interface model as that of IGMPv3 In LW-IGMPv3, the same service interface model as that of IGMPv3 is
is inherited: inherited:
IPMulticastListen ( socket, interface, multicast-address, IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list ) filter-mode, source-list )
In the lightweight protocol, EXCLUDE mode on the host part is In the lightweight protocol, EXCLUDE mode on the host part is
preserved only for EXCLUDE (*,G) join, which denotes non-source- preserved only for EXCLUDE (*,G) join, which denotes a non-source-
specific group report (as known as (*,G) join) and is equivalent to specific group report (as known as (*,G) join) and is equivalent to
the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The
detailed host operation of LW-IGMPv3/LW-MLDv2 is described in section detailed host operation of LW-IGMPv3/LW-MLDv2 is described in
3. Section 4.
2.2. Behavior of Multicast Routers 2.2. Behavior of Multicast Routers
According to [IGMPv3], router filter-mode is defined to optimize the Router filter-mode is defined to optimize the state description of a
state description of a group. As a rule, once a member report is in group [2]. As a rule, once a member report is in EXCLUDE mode, the
EXCLUDE mode, the router filter-mode for the group will be set to router filter-mode for the group will be set to EXCLUDE. When all
EXCLUDE. When all systems cease sending EXCLUDE mode reports, the systems cease sending EXCLUDE mode reports, the filter-mode for that
filter-mode for that group may transit back to INCLUDE mode. Group group may transit back to INCLUDE mode. Group timer is used to
timer is used to identify such transition. identify such transition.
In LW-IGMPv3, member reports carry mainly the INCLUDE mode In LW-IGMPv3, hosts primarily send INCLUDE requests. The only
information with only one exception for EXCLUDE (*,G), which means exception is EXLUDE (*,G) join, which can be interpreted by the
including all sources and can also be interpreted as INCLUDE mode. router as a request to include all sources. Without the more general
Without EXCLUDE mode report information, it is unnecessary for the form of EXCLUDE requests, it is unnecessary for the router to
router to maintain the EXCLUDE filter-mode, and the state model for maintain the EXCLUDE filter-mode, and the state model for multicast
multicast router can be simplified as: router can be simplified as:
(multicast address, group timer, (source records)) (multicast address, group timer, (source records))
Here group timer is kept to represent (*,G) group join. Its basic
Here a group timer is kept to represent (*,G) group join. Its basic
behavior is: when a router receives a (*,G) group join, it will set 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 its group timer and keep the source list for sources specified in the
will be kept. As the group timer expires, the router may change to source records. When the group timer expires, the router may change
the reception for the listed sources. to the reception for the listed sources. The definition of the
source record is the same as that of full version.
The elimination of the filter-mode will greatly simplify the router The elimination of the filter-mode will greatly simplify the router
behavior, e.g. the action on reception of reports and the setting of behavior, e.g. the action on reception of reports and the setting of
the timers. The detailed operation of router operation is described the timers. The detailed operation of router operation is described
in section 4. in Section 4.
3. LW-IGMPv3 Protocol for Group Members 3. LW-IGMPv3 Protocol for Group Members
LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages,
being the same as the full version protocols. Although most of these being the same as the full version protocols. Although most of these
message types and corresponding group records are inherited from the message types and corresponding group records are inherited from the
full version protocols, an operation that triggers EXCLUDE (S,G) join full version protocols, an operation that triggers EXCLUDE (S,G) join
is omitted and the corresponding record types of the Report are is omitted and the corresponding record types of the Report are
modified on the lightweight protocols. modified on the lightweight protocols.
There are three Group Record Types defined in the full IGMPv3: There are three Group Record Types defined in the full IGMPv3:
Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) 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 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 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 Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or
BLOCK_OLD_SOURCES (BLOCK). BLOCK_OLD_SOURCES (BLOCK).
3.1. Action on Change of Interface State 3.1. Action on Change of Interface State
When an interface state of a group member host is changed, a State- When the state of an interface of a group member host is changed, a
Change Report for that interface is immediately transmitted from that State-Change Report for that interface is immediately transmitted
interface. The type and contents of the Group Record(s) in that from that interface. The type and contents of the Group Record(s) in
Report are determined by comparing the filter mode and source list that Report are determined by comparing the filter mode and source
for the affected multicast address before and after the change. list for the affected multicast address before and after the change.
While the requirements are the same as the full version for the While the requirements are the same as the full version for the
computation, in the lightweight version host, the interface state computation, in the lightweight version host, the interface state
change rules are simplified due to the reduction of message types. change rules are simplified due to the reduction of message types.
The contents of the new transmitted report are calculated as follows The contents of the new transmitted report are calculated as follows
(Group Record Types are described in section 3.3): (Group Record Types are described in Section 3.3):
Old State New State State-Change Record Sent Old State New State State-Change Record Sent
----------- ----------- ------------------------ ----------- ----------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B)
INCLUDE (A) EXCLUDE () IS_EX() INCLUDE (A) EXCLUDE () TO_EX()
INCLUDE () EXCLUDE () IS_EX()
INCLUDE () EXCLUDE () TO_EX()
EXCLUDE () INCLUDE (B) TO_IN(B) EXCLUDE () INCLUDE (B) TO_IN(B)
To cover the possibility of the State-Change Report being missed by To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness one or more multicast routers, it is retransmitted [Robustness
Variable]-1 more times, at intervals chosen at random from the range Variable]-1 more times, at intervals chosen at random from the range
(0, [Unsolicited Report Interval]). (These values are defined in (0, [Unsolicited Report Interval]). (These values are defined in
[IGMPv3, MLDv2].) [2][3].)
In the full version of IGMPv3, as was done with the first report, the 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 interface state for the affected group before and after the latest
change is compared, and the report records expressing the difference change is compared, and the report records expressing the difference
are built and merged with the contents of the pending report, to are built and merged with the contents of the pending report, to
create the new State-Change report. However, it is optional that a create the new State-Change report. However, for the LW-IGMPv3 host,
LW-IGMPv3 host merges with the contents of the pending report. If this merge operation is optional. If the LW-IGMPv3 host does not
the LW-IGMPv3 host does not merge with the contents of the pending merge with the contents of the pending report, it transmits each
report, it transmits each report sequentially. Doing so can greatly report sequentially. Doing so can greatly simplified the operation
simplified the operation for scheduling the reports. for scheduling the reports.
3.2. Action on Reception of a Query 3.2. Action on Reception of a Query
When a lightweight version host receives a Query, it does not respond When a lightweight version host receives a Query, it does not respond
immediately. Instead, it delays its response by a random amount of immediately. Instead, it delays its response by a random amount of
time, bounded by the Max Resp Time value derived from the Max Resp time, bounded by the Max Resp Time value derived from the Max Resp
Code in the received Query message [IGMPv3, MLDv2]. The system may Code in the received Query message [2][3]. The system may receive a
receive a variety of Queries on different interfaces and of different variety of Queries on different interfaces and of different kinds
kinds (e.g., General Queries, Group-Specific Queries, and Group-and- (e.g., General Queries, Group-Specific Queries, and Group-and-Source-
Source-Specific Queries), each of which may require its own delayed Specific Queries), each of which may require its own delayed
response. response.
Before scheduling a response to a Query, the system must first Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the lightweight version schedule a combined response. Therefore, the lightweight version
host must be able to maintain the following state: host must be able to maintain the following state:
o A timer per interface for scheduling responses to General Queries. o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group- o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries. Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query. response to a Group-and-Source-Specific Query.
LW-IGMPv3 inherits most of the rules that are used to determine if a LW-IGMPv3 inherits most of the rules that are used to determine if a
Report needs to be scheduled from the full version. The different Report needs to be scheduled from the full version. The difference
point is regarding the simplification of EXCLUDE filter-mode and the is regarding the simplification of EXCLUDE filter-mode and the type
type of Report to schedule as detailed in section 3.3. of Report to schedule as detailed in Section 3.3.
While it is optional that a LW-IGMPv3 host merges with the contents While it is optional that a LW-IGMPv3 host merges with the contents
of the pending report for unsolicited report (i.e. State-Change of the pending report for unsolicited report (i.e., State-Change
report) as mentioned in the previous section, if the received Query report) as mentioned in the previous section, if the received Query
is a Group-and-Source-Specific Query and there is a pending response 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 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 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 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 version host. The new response is then scheduled to be sent at the
earliest of the remaining time for the pending report and the earlier of the remaining time for the pending report and the selected
selected delay. delay.
3.3. Applicable Group Record Types 3.3. Applicable Group Record Types
Among Group Record Types defined in the full IGMPv3, several record Among Group Record Types defined in the full IGMPv3, several record
types are not used in LW-IGMPv3 as some of the processes related to types are not used in LW-IGMPv3 as some of the processes related to
the filter mode change to the EXCLUDE mode are eliminated and some of the filter mode change to the EXCLUDE mode are eliminated and some of
the report messages are converged with a record having null source the report messages are converged with a record having null source
address list. All of the record types of report messages used by the address list. All of the record types of report messages used by the
full and lightweight version protocols are shown as follows: full and lightweight version protocols are shown as follows:
IGMPv3 LW-IGMPv3 Comments IGMPv3 LW-IGMPv3 Comments
-------- --------- ------------------------------------- -------- --------- -------------------------------------
IS_EX() IS_EX() Query response for (*,G) join IS_EX() TO_EX() Query response for (*,G) join
IS_EX(x) N/A Query response for EXCLUDE (x,G) join IS_EX(x) N/A Query response for EXCLUDE (x,G) join
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
ALLOW(x) ALLOW(x) INCLUDE (x,G) join ALLOW(x) ALLOW(x) INCLUDE (x,G) join
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join
TO_IN() TO_IN() (*,G) leave TO_IN() TO_IN() (*,G) leave
TO_EX(x) N/A Change to EXCLUDE (x,G) join TO_EX(x) N/A Change to EXCLUDE (x,G) join
TO_EX() IS_EX() (*,G) join TO_EX() TO_EX() (*,G) join
where "x" represents non-null source address list and "()" represents where "x" represents a non-null source address list and "()"
null source address list. For instance, IS_EX() means a report whose represents null source address list. For instance, IS_EX() means a
record type is IS_EX with null source address list. "N/A" represents report whose record type is IS_EX with null source address list.
not applicable (or no use) because the corresponding operation should "N/A" represents not applicable (or no use) because the corresponding
not occur in the lightweight version protocols. operation should not occur in the lightweight version protocols.
LW-IGMPv3 does not use EXCLUDE filter-mode with non-null source LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source
address list. And a multicast router creates the same state when it address list. A multicast router creates the same state when it
receives a report message containing either of IS_EX or TO_EX record receives a report message containing either IS_EX() or TO_EX() record
types. Therefore, LW-IGMPv3 integrates the TO_EX operation to the types. Therefore, LW-IGMPv3 integrates the IS_EX() operation with
IS_EX operation. the TO_EX() operation.
When a LW-IGMPv3 host needs to make a query response for the state of When a LW-IGMPv3 host needs to make a query response for the state of
INCLUDE (x,G) join, the host makes the response whose message type is INCLUDE (x,G) join, it makes a response whose message type is
expressed with ALLOW(x), instead of using IS_IN record type, for expressed with ALLOW(x), instead of using the IS_IN record type.
router's processing of the two messages are completely the same, the Because the router's processing of the two messages is completely
IS_IN(x) type is eliminated for simplification. same, the IS_IN(x) type is eliminated for simplification.
A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is
used with the following situation: the host firstly launches an used the following situation: the host first launches an application
application (AP1) that requests INCLUDE (x,G) join, and it sends (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the
ALLOW(x). Then the host launches another application (AP2) that host launches another application (AP2) that joins (*,G), and it
joins (*,G), and it sends IS_EX(). In this condition, when AP2 sends TO_EX(). In this condition, when AP2 terminates but AP1 keeps
terminates but AP1 keeps working on the lightweight version host, the working on the lightweight version host, the host sends a report with
host sends a report with TO_IN(x) record type for [Robustness TO_IN(x) record type for [Robustness Variable] times.
Variable] times.
4. LW-IGMPv3 Protocol for Multicast Routers 4. LW-IGMPv3 Protocol for Multicast Routers
The major difference between the full and lightweight version The major difference between the full and lightweight version
protocol on the router is that filter-mode is discarded for the protocols on the router part is that for the lightweight version
lightweight version, as section 2.2 mentioned. Then the IGMP state filter-mode is discarded and the function of the group timer is
maintained by the router for each attached network can be simplified redefined. The states maintained by the lightweight router are
as: reduced and the protocol operation is greatly simplified.
(multicast address, group timer, (source records))
where the source record includes pairs of source address and its
corresponding source timer. In this model, the filter-mode is
omitted and the meaning of the group timer is redefined to implement
simplified processing.
4.1. Group Timers and Source Timers in the Lightweight Version 4.1. Group Timers and Source Timers in the Lightweight Version
The source timer is kept for each source record and it is updated A source timer is kept for each source record and it is updated when
when the source is present in a received report. It indicates the the source is present in a received report. It indicates the
validity of the sources and needs to be referred when the router validity of the sources and needs to be referred when the router
takes its forwarding decision. takes its forwarding decision.
The group timer being used in the full version of IGMPv3 as a The group timer being used in the full version of IGMPv3 for
mechanism for transitioning the router's filter-mode from EXCLUDE to transitioning the router's filter-mode from EXCLUDE to INCLUDE, is
INCLUDE, is now redefined for the identification of the non-source- now redefined to identify the non-source-specific receiving states
specific receiving states, i.e., (*,G)join. Once a group record of maintaining for (*,G) join. Once a group record of IS_EX() is
IS_EX() is received, the group timer is used to represent this (*,G) received, the group timer is used to represent this (*,G) group join.
group join. The expiration of the group timer indicates that there The expiration of the group timer indicates that there are no
are no listeners on the attached network for this (*,G) group. Then listeners on the attached network for this (*,G) group. If there are
if at this moment there are unexpired sources (whose source timers unexpired sources (whose source timers are greater than zero), the
are greater than zero), the router will change to receiving for those router will change to receiving traffic for those sources. The role
sources. The role of the group timer can be summarized as follows: of the group timer can be summarized as follows:
Group Timer Value Actions/Comments Group Timer Value Actions/Comments
------------------ -------------------------------------- ------------------ --------------------------------------
G_Timer > 0 All members in this group. G_Timer > 0 All members in this group.
G_Timer == 0 No more listeners to this (*,G) group. G_Timer == 0 No more listeners to this (*,G) group.
If all source timers have expired then If all source timers have expired then
delete group record. If there are delete group record. If there are
still source record timers running, still source record timers running,
use those source records with running use those source records with running
timers as the source record state. timers as the source record state.
The operation related to the group and source timers has some The operation related to the group and source timers has some
difference compared with the full IGMPv3. In the full version, if a difference compared with the full IGMPv3. In the full version, if a
source timer expires under the EXCLUDE router filter-mode, its source timer expires under the EXCLUDE router filter-mode, its
corresponding source record is not deleted until the group timer corresponding source record is not deleted until the group timer
expires. They are kept for indicating undesired sources. In the expires for indicating undesired sources. In the lightweight
lightweight version, since there is no need to keep such records for version, since there is no need to keep such records for blocking
blocking specific sources, if a source timer expires, its source specific sources, if a source timer expires, its source record should
record should be deleted immediately, not waiting for the time-out of be deleted immediately, not waiting for the time-out of the group
the group timer. timer.
4.2. Source-Specific Forwarding Rules 4.2. Source-Specific Forwarding Rules
A multicast router needs to consult IGMPv3 state information when it A full version multicast router needs to consult IGMPv3 state
makes decisions on forwarding a datagram from a source to its information when it makes decisions on forwarding a datagram from a
attached network. In the full IGMPv3, the router filter-mode and source or its upstream router to its attached network, based on the
source timer are taken as the necessary judging conditions. In LW- router filter-mode and source timer. In LW-IGMPv3, because of the
IGMPv3, because of the absence of the router filter-mode, the group absence of the router filter-mode, the group timer and source timer
timer and source timer could be used for such decisions. The could be used for such decisions. The forwarding suggestion made by
forwarding suggestion made by LW-IGMPv3 to the routing protocols can LW-IGMPv3 to the routing protocols is summarized as follows:
be summarized as follows:
Group Timer Source Timer Action Group Timer Source Timer Action
------------ ------------------ ----------------------- ------------ ------------------ -----------------------
G_Timer == 0 S_TIMER > 0 Suggest to forward G_Timer == 0 S_TIMER > 0 Suggest forwarding
traffic from source traffic from source
G_Timer == 0 S_TIMER == 0 Suggest to stop G_Timer == 0 S_TIMER == 0 Suggest stopping
forwarding traffic from forwarding traffic from
source and remove source and remove
source record. If there source record. If there
are no more source are no more source
records for the group, records for the group,
delete group record delete group record
G_Timer == 0 No Source Elements Suggest not to forward G_Timer == 0 No Source Elements Suggest not to forward
traffic from the source traffic from the source
G_Timer > 0 S_TIMER >= 0 Suggest to forward G_Timer > 0 S_TIMER >= 0 Suggest forwarding
traffic from source traffic from source
G_Timer > 0 No Source Elements Suggest to forward G_Timer > 0 No Source Elements Suggest forwarding
traffic from source traffic from source
4.3. Reception of Current-State Records 4.3. Reception of Current-State Records
When receiving Current-State Records, the LW-IGMPv3 router resets its When receiving Current-State Records, the LW-IGMPv3 router resets its
group or source timers and updates its source list within the group. group or source timers and updates its source list within the group.
For source-specific group reception state (G_Timer==0), the source For source-specific group reception state (when G_Timer==0), the
list includes sources to be forwarded by the router, while in non- source list contains sources whose traffic will be forwarded by the
source-specific group reception (G_Timer>0) the source list remembers router, while in non-source-specific group reception (when
the sources to be forwarded after toggling to source-specific G_Timer>0), the source list remembers the valid sources to receive
reception state. traffic from after toggling to source-specific reception state.
The following table describes the action taken by a multicast router Although the Lightweight host only sends a subset of the message of
after receiving Current-State Records. The notations have the same that of the full version, the LW-router should be able to process as
meaning as that in the full IGMPv3. much messages as possible to be compatible with the full version
host. The following table describes the action taken by a multicast
router after receiving Current-State Records. The notations have the
same meaning as that in the full IGMPv3 protocol.
Old New Old New
Source Source Source Source
Group Timer List Report Rec'd List Actions Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ ----------- ------------ ------ ------------ ------ -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI 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_EX() A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI 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_EX() A G_Timer=GMI
And the above table could be further simplified for the processes The above table could be further simplified for the processes that
that are completely same for the two values of the G_Timer: are completely same for the two values of the G_Timer:
Old New Old New
Source Source Source Source
List Report Rec'd List Actions List Report Rec'd List Actions
------ ------------ ------ ----------- ------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI A IS_IN(B) A+B (B)=GMI
A IS_EX() A G_Timer=GMI A IS_EX() A G_Timer=GMI
Without EXCLUDE filter-mode, a router's process on receiving Current- Without EXCLUDE filter-mode, a router's process on receiving Current-
State Record is simple: when a router receives an IS_IN report, it State Record is simple: when a router receives an IS_IN report, it
appends the reported source addresses to the previous source list appends the reported source addresses to the previous source list
with their source timers set to GMI. Upon receiving an IS_EX() with their source timers set to GMI. Upon receiving an IS_EX()
report, the router sets the non-source-specific receiving states with report, the router sets the non-source-specific receiving states by
GMI group timer value and keeps the previous source list without resetting the group timer value and keeps the previous source list
modification. without modification.
4.4. Reception of Source-List-Change and Filter-Mode-Change Records 4.4. Reception of Source-List-Change and Filter-Mode-Change Records
On receiving Source-List-Change and Filter-Mode-Change Records, the On receiving Source-List-Change and Filter-Mode-Change Records, the
LW-IGMPv3 router needs to reset its group and source timers, update LW-IGMPv3 router needs to reset its group and source timers, update
its source list within the group, or trigger group queries. The its source list within the group, or trigger group queries. The
queries are sent by the router for the sources that are requested to queries are sent by the router for the sources that are requested to
be no longer forwarded to a group. The table below describes the be no longer forwarded to a group. The table below describes the
state change and the actions that should be taken. state change and the actions that should be taken.
skipping to change at page 12, line 4 skipping to change at page 15, line 31
G_Timer > 0 A TO_IN(B) A+B (B)=GMI G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B) SendQ(G,A-B)
Send Q(G) Send Q(G)
The table could be further simplified by merging duplicate lines: The table could be further simplified by merging duplicate lines:
Old New Old New
Source Source Source Source
List Report Rec'd List Actions List Report Rec'd List Actions
------ ------------ ------ ---------------------- ------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B) A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B) Send Q(G,A-B)
If G_Timer>0 Send Q(G) If G_Timer>0 Send Q(G)
In this table, TO_EX() report is not included because the processing
is exactly the same as that of IS_EX(), as described in the previous
section. Section 5.1 gives the lightweight routers's transformation
behavior between the two messages.
5. Interoperability 5. Interoperability
LW-IGMPv3/LW-MLDv2 hosts and routers should interoperate gracefully LW-IGMPv3/LW-MLDv2 hosts and routers should interoperate gracefully
with the full version protocols [IGMPv3, MLDv2]. Also, LW-IGMPv3/LW- with the full version protocols [2][3]. Also, LW-IGMPv3/LW-MLDv2
MLDv2 hosts and routers should interoperate gracefully with hosts and hosts and routers should interoperate gracefully with hosts and
routers running IGMPv1/v2 or MLDv1. routers running IGMPv1/v2 or MLDv1.
5.1. Interoperation with the Full Version of IGMPv3 5.1. Interoperation with the Full Version of IGMPv3
Eliminating EXCLUDE filter-mode from the full version protocols LW-IGMPv3 does not introduce any change on the message format of the
simplifies the processes inside the host and router. On the other group query and report messages the full version protocols use. With
hand, LW-IGMPv3 does not introduce any change on the message format the elimination of the EXLCLUDE filter mode, the LW-IGMPv3 group
of the group query and report messages the full version protocols member sends a subset of IGMPv3 report messages, which can be
use. Therefore, the group member sends a subset of IGMPv3 report recognized by a multicast router running the full or the lightweight
messages, which can be recognized by a multicast router running the IGMPv3 protocol on the same LAN.
full or the lightweight IGMPv3 protocol on the same LAN.
A LW-IGMPv3 router translates IS_EX(x) and TO_EX(x) records that are A LW-IGMPv3 router does not process directly IS_EX(x) and TO_EX(x)
used with the full IGMPv3 but not used with LW-IGMPv3. When a LW- records that are used by the full IGMPv3. When a LW-IGMPv3 router
IGMPv3 router receives these report messages from the full version receives these report messages from the full version host, it
host, it translates them to IS_EX() records and makes the translates them to IS_EX() records and behaves accordingly. All
corresponding behavior. All possible record types are compared as possible record types are compared as follows:
follows:
IGMPv3 Report LW-IGMPv3 Equivalent IGMPv3 Report LW-IGMPv3 Equivalent
------------- -------------------- ------------- --------------------
IS_IN(x) IS_IN(x) IS_IN(x) IS_IN(x)
IS_EX(x) IS_EX() IS_EX(x) IS_EX()
TO_IN(x) TO_IN(x) TO_IN(x) TO_IN(x)
skipping to change at page 13, line 18 skipping to change at page 17, line 6
Compatibility Mode and keeps Querier Present timers for IGMPv1 and Compatibility Mode and keeps Querier Present timers for IGMPv1 and
IGMPv2. Their definition and processing is the same as that of IGMPv2. Their definition and processing is the same as that of
IGMPv3. IGMPv3.
5.2.1. Behavior of Group Members 5.2.1. Behavior of Group Members
A host's compatibility mode is determined from the Host Compatibility A host's compatibility mode is determined from the Host Compatibility
Mode variable which can be in one of three states: IGMPv1, IGMPv2 or Mode variable which can be in one of three states: IGMPv1, IGMPv2 or
IGMPv3. The Host Compatibility Mode of an interface is set to IGMPv2 IGMPv3. The Host Compatibility Mode of an interface is set to IGMPv2
and IGMPv2 Querier Present is set to Older Version Querier Present and IGMPv2 Querier Present is set to Older Version Querier Present
Timeout second (defined in [IGMPv3]) whenever an IGMPv2 General Query Timeout second (defined in [2]) whenever an IGMPv2 General Query is
is received on that interface. The Host Compatibility Mode of an received on that interface. The Host Compatibility Mode of an
interface is set to IGMPv1 and IGMPv1 Querier Present is set to Older interface is set to IGMPv1 and IGMPv1 Querier Present is set to Older
Version Querier Present Timeout second whenever an IGMPv1 Membership Version Querier Present Timeout second whenever an IGMPv1 Membership
Query is received on that interface. Based on the Host Compatibility Query is received on that interface. Based on the Host Compatibility
Mode variable, a host acts using the IGMPv3, IGMPv2, or IGMPv1 Mode variable, a host acts using the IGMPv3, IGMPv2, or IGMPv1
protocol on that interface protocol on that interface.
While above manner is inherited from the definition of [IGMPv3], LW- While above manner is inherited from the definition of [2], LW-IGMPv3
IGMPv3 may enable to configure the Host Compatibility Mode variable may enable to configure the Host Compatibility Mode variable by other
by other means: when a LW-IGMPv3 host is placed on a link where there means: when a LW-IGMPv3 host is placed on a link where there are
are IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message to be
to be suppressed by an IGMPv1 or IGMPv2 report message. suppressed by an IGMPv1 or IGMPv2 report message.
5.2.2. Behavior of Multicast Routers 5.2.2. Behavior of Multicast Routers
If a LW-IGMPv3 router is on a network where at least one router
running IGMPv1 or IGMPv2 protocols, it is required that the lowest
version of querier must be used. This can be administratively
assured by supporting IGMPv1, IGMPv2 or IGMPv3 compatibility mode.
An LW-IGMPv3 router may be placed on a network where there are hosts
that have not been upgraded to IGMPv3. In order to be compatible
with the older version, the lightweight router should keep a Group
compatibility mode for each group record, and IGMPv1 and IGMPv2 Host
present timers are kept to switch gracefully between different
versions of IGMP.
When Group Compatibility mode is IGMPv2 or IGMPv1, a LW-IGMPv3 router When Group Compatibility mode is IGMPv2 or IGMPv1, a LW-IGMPv3 router
translates the following IGMPv2 or IGMPv1 messages for that group to translates the following IGMPv2 or IGMPv1 messages for that group to
their IGMPv2 or IGMPv1 equivalents: their LW-IGMPv3 equivalents:
IGMP Message LW-IGMPv3 Equivalent IGMP Message LW-IGMPv3 Equivalent
------------- -------------------- ------------- --------------------
v1 Report IS_EX() v1 Report IS_EX()
v2 Report IS_EX() v2 Report IS_EX()
v2 Leave TO_IN() v2 Leave TO_IN()
6. Implementation Considerations 6. Implementation Considerations
The lightweight protocols requires no additional burden on the The lightweight protocols requires no additional procedure on the
implementation of the related protocols or systems, e.g. IGMP/MLD implementation of the related protocols or systems, e.g. IGMP/MLD
snooping, multicast routing protocol, and operation of application snooping, multicast routing protocol, and operation of application
sockets, while the processing loads on the switches and routers that sockets, while the processing loads on the switches and routers that
running IGMPv3 (snooping) and multicast routing protocols could be running IGMPv3 (snooping) and multicast routing protocols may be
greatly decreased. greatly decreased.
In the following sections, the implementation related topics are In the following sections, the implementation related aspects are
described for the lightweight version protocols. described for the lightweight version protocols.
6.1. Implementation of Source-Specific Multicast 6.1. Implementation of Source-Specific Multicast
[IGMP-SSM] illustrates the requirements of implementation of Source- [8] illustrates the requirements of implementation of Source-Specific
Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight
lightweight protocol does not impose any bad influences on an SSM protocol does not impose any bad influences on an SSM application.
application. The requirements of LW-IGMPv3/LW-MLDv2 for supporting The requirements of LW-IGMPv3/LW-MLDv2 for supporting SSM are
SSM are illustrated below. illustrated below.
A LW-IGMPv3/LW-MLDv2 host should not send a non-source-specific join, A LW-IGMPv3/LW-MLDv2 host should not send a non-source-specific join,
i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the i.e., IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the
application whose multicast address is in the SSM address range. The application whose multicast address is in the SSM address range. The
reception of a non-source-specific join with an SSM group address reception of a non-source-specific join with an SSM group address
should indicate an error to the application. The SSM-aware router should indicate an error to the application. The SSM-aware router
will ignore IS_EX() reports with SSM addresses. Other types of will ignore IS_EX() reports with SSM addresses. Other types of
Reports should be processed normally. Reports should be processed normally.
6.2. Implementation of Multicast Source Filter (MSF) APIs 6.2. Implementation of Multicast Source Filter (MSF) APIs
Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF
API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF
API, and (4) Protocol-Independent Advanced MSF API. API, and (4) Protocol-Independent Advanced MSF API.
According to the MSF APIs definition, a LW-IGMPv3 host should According to the MSF APIs definition, a LW-IGMPv3 host should
implement at least one of IPv4 Basic MSF API and Protocol-Independent implement at least one of IPv4 Basic MSF API and Protocol-Independent
Basic MSF API, and a LW-MLDv2 host should implement Protocol- Basic MSF API, and a LW-MLDv2 host should implement Protocol-
Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and
Protocol-Independent Advanced MSF API, are optional to implement in Protocol-Independent Advanced MSF API, are optional to implement in
LW-IGMPv3/LW-MLDv2 host. LW-IGMPv3/LW-MLDv2 host.
7. Security Considerations 7. Security Considerations
The security consideration is the same as that of the full version of The security considerations are the same as that of the full version
IGMPv3/MLDv2. of IGMPv3/MLDv2.
8 Normative References 8. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate 8.1. Normative References
requirement levels," RFC 2119, March 1997.
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and [1] Bradner, S., "Key words for use in RFCs to indicate requirement
Thyagarajan, A., "Internet Group Management Protocol, Version3," levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
2 (MLDv2) for IPv6," RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
9 Informative References [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP," [5] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 4607, August 2006. RFC 2373, July 1997.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
RFC 2236, November 1997. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[MLDv1] Deering, S., Fenner, W., and Haberman, B., "Multicast [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
Listener Discovery (MLD) for IPv6," RFC 2710, October 1999. RFC 4607, August 2006.
[IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group
Group Management Protocol Version 3 (IGMPv3) and Multicast Management Protocol Version 3 (IGMPv3) and Multicast Listener
Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Discovery Protocol Version 2 (MLDv2) for Source-Specific
Multicast," RFC 4604, August 2006. Multicast", RFC 4604, August 2006.
[MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface 8.2. Informative References
Extensions for Multicast Source Filters," RFC 3678, January 2004.
Author's Addressess [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
Authors' Addresses
Hui Liu Hui Liu
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd., Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base, Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085, Hai-Dian Distinct, Beijing 100085
China China
Email: Liuhui47967@huawei.com Email: Liuhui47967@huawei.com
Wei Cao Wei Cao
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd., Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base, Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085, Hai-Dian Distinct, Beijing 100085
China China
Email: caowayne@huawei.com Email: caowayne@huawei.com
Hitoshi Asaeda Hitoshi Asaeda
Graduate School of Media and Governance
Keio University Keio University
5322 Endo, Fujisawa, Kanagawa 252-8520, Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan Japan
Email: asaeda@wide.ad.jp Email: asaeda@wide.ad.jp
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf this standard. Please address the information to the IETF at
ipr@ietf.org. 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 Acknowledgment
The author would like to thank magma and mboned mailing lists for Funding for the RFC Editor function is provided by the IETF
discussion and contribution for the ideas. Administrative Support Activity (IASA).
 End of changes. 88 change blocks. 
295 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/