draft-ietf-mboned-lightweight-igmpv3-mldv2-01.txt   draft-ietf-mboned-lightweight-igmpv3-mldv2-02.txt 
MBONED Working Group H. Liu MBONED Working Group H. Liu
Internet-Draft W. Cao Internet-Draft W. Cao
Expires: December 31, 2007 Huawei Technologies Co., Ltd. Expires: May 22, 2008 Huawei Technologies Co., Ltd.
H. Asaeda H. Asaeda
Keio University Keio University
June 29, 2007 November 19, 2007
Lightweight IGMPv3 and MLDv2 Protocols Lightweight IGMPv3 and MLDv2 Protocols
draft-ietf-mboned-lightweight-igmpv3-mldv2-01 draft-ietf-mboned-lightweight-igmpv3-mldv2-02
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2007. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
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 [1]. this document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Simplification Method Overview . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Behavior of Group Members . . . . . . . . . . . . . . . . 6 3. Simplification Method Overview . . . . . . . . . . . . . . . . 7
2.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 6 3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 7
3. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 8 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7
3.1. Action on Change of Interface State . . . . . . . . . . . 8 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9
3.2. Action on Reception of a Query . . . . . . . . . . . . . . 9 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9
3.3. Applicable Group Record Types . . . . . . . . . . . . . . 10 4.2. Action on Change of Interface State . . . . . . . . . . . 9
4. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10
4.1. Group Timers and Source Timers in the Lightweight 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10
5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12
5.1. Group Timers and Source Timers in the Lightweight
Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13
4.3. Reception of Current-State Records . . . . . . . . . . . . 13 5.3. Reception of LW-IGMPv3 Group Records . . . . . . . . . . . 13
4.4. Reception of Source-List-Change and Filter-Mode-Change 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16
Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16
5.1. Interoperation with the Full Version of IGMPv3 . . . . . . 16 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16
5.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17
5.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 18
5.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 7. Implementation Considerations . . . . . . . . . . . . . . . . 19
6. Implementation Considerations . . . . . . . . . . . . . . . . 18 7.1. Implementation of Source-Specific Multicast . . . . . . . 19
6.1. Implementation of Source-Specific Multicast . . . . . . . 18 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19
6.2. Implementation of Multicast Source Filter (MSF) APIs . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
IGMP version 3 [2] and MLD version 2 [3] implement source filtering IGMP version 3 [2] and MLD version 2 [3] implement source filtering
capabilities that are not suported by their earlier versions, IGMPv1 capabilities that are not supported by their earlier versions, IGMPv1
[4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can [4], IGMPv2 [5] and MLDv1 [6]. An IGMPv3 or MLDv2 capable host can
tell its upstream router which group it would like to join by tell its upstream router which group it would like to join by
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 learn sources which are of interest or which are
neighboring systems, for packets sent to any particular multicast of not interested for a particular multicast address. This formation
address. is used during forwarding of multicast data packets.
The INCLUDE and EXCLUDE filter-modes are introduced to support the INCLUDE and EXCLUDE filter-modes are introduced to support the source
source filtering function. If a host wants to receive from specific filtering function. If a host wants to receive from specific
sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to
INCLUDE. If the host does not want to receive from some sources, it INCLUDE. If the host does not want to receive from some sources, it
sends a report with filter-mode set to EXCLUDE. A source list for sends a report with filter-mode set to EXCLUDE. A source list for
the given sources shall be included in the report message. the given sources 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 timers and source timers are used group and source addresses. Group timers and source timers are used
skipping to change at page 4, line 46 skipping to change at page 4, line 46
The multicast filter-mode improves the ability of the multicast The multicast filter-mode improves the ability of the multicast
receiver to express its desires. It is useful to support Source- receiver to express its desires. It is useful to support Source-
Specific Multicast (SSM) [7] by specifying interesting source Specific Multicast (SSM) [7] by specifying interesting source
addresses with INCLUDE mode. However, practical applications do not addresses with INCLUDE mode. However, practical applications do not
use EXCLUDE mode to block sources very often, because a user or use EXCLUDE mode to block sources very often, because a user or
application usually wants to specify desired source addresses, not application usually wants to specify desired source addresses, not
undesired source addresses. Even if a user wants to explicitly undesired source addresses. Even if a user wants to explicitly
refuse traffic from some sources in a group, when other users in the refuse traffic from some sources in a group, when other users in the
same shared network have an interest in these sources, the same shared network have an interest in these sources, the
corresponding multicast traffic is forwarded to the network. corresponding multicast traffic is forwarded to the network. It is
generally unnecessary to support the filtering function that blocks
sources.
This document proposes simplified versions of IGMPv3 and MLDv2, named This document proposes simplified versions of IGMPv3 and MLDv2, named
Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2), Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2).
in which EXCLUDE filter-mode is eliminated. Not only are LW-IGMPv3 LW-IGMPv3 and LW-MLDv2 support both ASM and SSM communications
and LW-MLDv2 compatible with the standard IGMPv3 and MLDv2, but also without a filtering function that blocks sources. Not only are they
the protocol operations made by data receiver hosts and routers or compatible with the standard IGMPv3 and MLDv2, but also the protocol
switches (performing IGMPv3/MLDv2 snooping) are simplified in the operations made by hosts and routers or switches (performing IGMPv3/
lightweight protocol, and complicated operations are hence MLDv2 snooping) are simplified to reduce the complicated operations.
effectively reduced. Since LW-IGMPv3 and LW-MLDv2 are fully Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full
compatible with the full version of these protocols (i.e., the version of these protocols (i.e., the standard IGMPv3 and MLDv2),
standard IGMPv3 and MLDv2), hosts or routers that have implemented hosts or routers that have implemented the full version do not need
the full version do not need to implement or modify anything to to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
cooperate with LW-IGMPv3/LW-MLDv2 hosts or routers. hosts or routers.
2. Simplification Method Overview 2. Terminology
The principle is to simplify the host and router parts as much as Following notations are used in several places in this specification.
possible to improve efficiency, while guaranteeing interoperability
with the full versions, and introducing no side effects on (*,G) join:
applications. An operation triggered by a host that wants to join the group G. In
this case, the host receives from all sources sending to group G.
This is typical in the ASM communication.
(S,G) join:
An operation triggered by a host that wants to join the group G, with
specifying desired source S. In this case, the host receives only
from source S sending to group G.
INCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under
INCLUDE filter-mode, with specifying desired source S. The same
meaning of (S,G) join.
EXCLUDE (*,G) join:
An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode. The same meaning of (*,G) join.
EXCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode, with specifying undesired source S. This
operation is not supported by LW-IGMPv3/LW-MLDv2.
3. Simplification Method Overview
The principle is to simplify the host and router's behavior as much
as possible to improve efficiency, while guaranteeing
interoperability with the full versions, and introducing no side
effects on 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 this document inherits the same source filtering mechanism, but this document
additionally shows MLDv2's unique specifications when needed. additionally shows MLDv2's unique specifications when needed.
2.1. Behavior of Group Members 3.1. Behavior of Group Members
In LW-IGMPv3, the same service interface model as that of IGMPv3 is In LW-IGMPv3, the same service interface model as that of IGMPv3 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, INCLUDE mode on the host part has the
preserved only for EXCLUDE (*,G) join, which denotes a non-source- same usage with the full version for INCLUDE (S,G) join, while
specific group report (as known as (*,G) join) and is equivalent to EXCLUDE mode on the host part is preserved only for excluding null
the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/
detailed host operation of LW-IGMPv3/LW-MLDv2 is described in MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is
Section 4. described in Section 4.
2.2. Behavior of Multicast Routers 3.2. Behavior of Multicast Routers
Router filter-mode is defined to optimize the state description of a Router filter-mode is defined to optimize the state description of a
group [2]. As a rule, once a member report is in EXCLUDE mode, the group membership [2][3]. As a rule, once a member report is in
router filter-mode for the group will be set to EXCLUDE. When all EXCLUDE mode, the router filter-mode for the group will be set to
systems cease sending EXCLUDE mode reports, the filter-mode for that EXCLUDE. When all systems cease sending EXCLUDE mode reports, the
group may transit back to INCLUDE mode. Group timer is used to filter-mode for that group may transit back to INCLUDE mode. Group
identify such transition. timer is used to identify such transition.
In LW-IGMPv3, hosts primarily send INCLUDE requests. The only In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can
exception is EXLUDE (*,G) join, which can be interpreted by the request an EXLUDE (*,G) join, which can be interpreted by the router
router as a request to include all sources. Without the more general as a request to include all sources. Without the more general form
form of EXCLUDE requests, it is unnecessary for the router to of EXCLUDE requests, it is unnecessary for the router to maintain the
maintain the EXCLUDE filter-mode, and the state model for multicast EXCLUDE filter-mode, and the state model for multicast router can be
router can be simplified as: simplified as:
(multicast address, group timer, (source records)) (multicast address, group timer, (source records))
Here a group timer is kept to represent (*,G) group join. Its basic Here a group timer is kept to represent a (*,G) join. Its basic
behavior is: when a router receives a (*,G) group join, it will set behavior is: when a router receives a (*,G) join, it will set its
its group timer and keep the source list for sources specified in the group timer and keep the source list for sources specified in the
source records. When the group timer expires, the router may change previously received source records. When the group timer expires,
to the reception for the listed sources. The definition of the the router may change to the reception for the listed sources. The
source record is the same as that of full version. 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. The detailed operation of router operation is described in
the timers. The detailed operation of router operation is described Section 5.
in Section 4.
3. LW-IGMPv3 Protocol for Group Members 4. LW-IGMPv3 Protocol for Group Members
4.1. Query and Report Messages
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. There is no difference
message types and corresponding group records are inherited from the between the definition and usage of the Query message. But the
full version protocols, an operation that triggers EXCLUDE (S,G) join report types in lightweight protocols are reduced because an
is omitted and the corresponding record types of the Report are operation that triggers EXCLUDE (S,G) join is omitted.
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). LW-IGMPv3 inherits the action on change
of interface state and reception of a Query, but IS_IN and IS_EX
record types are eliminated and Current-State Records are noted by
other records. The following sections explain the details.
3.1. Action on Change of Interface State 4.2. Action on Change of Interface State
When the state of an interface of a group member host is changed, a When the state of an interface of a group member host is changed, a
State-Change Report for that interface is immediately transmitted State-Change Report for that interface is immediately transmitted
from that interface. The type and contents of the Group Record(s) in from that interface. The type and contents of the Group Record(s) in
that Report are determined by comparing the filter mode and source that Report are determined by comparing the filter mode and source
list 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 4.4):
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 () TO_EX() INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE () EXCLUDE () TO_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
[2][3].) [2][3].)
In the full version of IGMPv3, as was done with the first report, the 4.3. Action on Reception of a Query
interface state for the affected group before and after the latest
change is compared, and the report records expressing the difference
are built and merged with the contents of the pending report, to
create the new State-Change report. However, for the LW-IGMPv3 host,
this merge operation is optional. If the LW-IGMPv3 host does not
merge with the contents of the pending report, it transmits each
report sequentially. Doing so can greatly simplified the operation
for scheduling the reports.
3.2. Action on Reception of a Query
When a 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 [2][3]. The system may receive a Code in the received Query message [2][3]. The system may receive a
variety of Queries on different interfaces and of different kinds variety of Queries on different interfaces and of different kinds
(e.g., General Queries, Group-Specific Queries, and Group-and-Source- (e.g., General Queries, Group-Specific Queries, and Group-and-Source-
Specific Queries), each of which may require its own delayed Specific Queries), each of which may require its own delayed
response. response.
skipping to change at page 9, line 36 skipping to change at page 10, line 30
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 the full version's rules that are used to
Report needs to be scheduled from the full version. The difference determine if a Report needs to be scheduled. The difference is
is regarding the simplification of EXCLUDE filter-mode and the type regarding the simplification of EXCLUDE filter-mode and the type of
of Report to schedule as detailed in Section 3.3. Report as detailed in Section 4.4.
While it is optional that a LW-IGMPv3 host merges with the contents
of the pending report for unsolicited report (i.e., State-Change
report) as mentioned in the previous section, if the received Query
is a Group-and-Source-Specific Query and there is a pending response
for this group with a non-empty source-list, then the group source
list is augmented to contain the list of sources in the new Query and
a single response is scheduled using the group timer as with the full
version host. The new response is then scheduled to be sent at the
earlier of the remaining time for the pending report and the selected
delay.
3.3. Applicable Group Record Types 4.4. LW-IGMPv3 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() TO_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() TO_EX() (*,G) join TO_EX({}) TO_EX({}) (*,G) join
where "x" represents a non-null source address list and "()" where "x" represents a non-null source address list and "({})"
represents null source address list. For instance, IS_EX() means a represents null source address list. For instance, IS_EX({}) means a
report whose record type is IS_EX with null source address list. report whose record type is IS_EX with null source address list.
"N/A" represents not applicable (or no use) because the corresponding "N/A" represents not applicable (or no use) because the corresponding
operation should 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 a non-null source LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source
address list. 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 IS_EX() or TO_EX() record receives a report message containing either IS_EX({}) or TO_EX({})
types. Therefore, LW-IGMPv3 integrates the IS_EX() operation with record types. Therefore, LW-IGMPv3 integrates the IS_EX({})
the TO_EX() operation. operation with 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, it makes a response whose message type is INCLUDE (x,G) join, it makes a response whose message type is
expressed with ALLOW(x), instead of using the IS_IN record type. expressed with ALLOW(x), instead of using the IS_IN record type.
Because the router's processing of the two messages is completely Because the router's processing of the two messages is completely
same, the 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 the following situation: the host first launches an application used the following situation: the host first launches an application
(AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the
host launches another application (AP2) that joins (*,G), and it host launches another application (AP2) that joins (*,G), and it
sends TO_EX(). In this condition, when AP2 terminates but AP1 keeps sends TO_EX(). In this condition, when AP2 terminates but AP1 keeps
working on the lightweight version host, the host sends a report with working on the lightweight version host, the host sends a report with
TO_IN(x) record type for [Robustness Variable] times. TO_IN(x) record type for [Robustness Variable] times.
4. LW-IGMPv3 Protocol for Multicast Routers 5. LW-IGMPv3 Protocol for Multicast Routers
The major difference between the full and lightweight version The major difference between the full and lightweight version
protocols on the router part is that for the lightweight version protocols on the router part is that for the lightweight version
filter-mode is discarded and the function of the group timer is filter-mode is discarded and the function of the group timer is
redefined. The states maintained by the lightweight router are redefined. The states maintained by the lightweight router are
reduced and the protocol operation is greatly simplified. reduced and the protocol operation is greatly simplified.
4.1. Group Timers and Source Timers in the Lightweight Version 5.1. Group Timers and Source Timers in the Lightweight Version
A source timer is kept for each source record and it is updated when A source timer is kept for each source record and it is updated 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 for The group timer being used in the full version of IGMPv3 for
transitioning the router's filter-mode from EXCLUDE to INCLUDE, is transitioning the router's filter-mode from EXCLUDE to INCLUDE, is
now redefined to identify the non-source-specific receiving states redefined in the lightweight protocols to identify the non-source-
maintaining for (*,G) join. Once a group record of IS_EX() is specific receiving states maintaining for (*,G) join. Once a group
received, the group timer is used to represent this (*,G) group join. record of TO_EX() is received, the group timer is set to represent
The expiration of the group timer indicates that there are no this (*,G) group join. The expiration of the group timer indicates
listeners on the attached network for this (*,G) group. If there are that there are no more listeners on the attached network for this
unexpired sources (whose source timers are greater than zero), the (*,G) group. Then if at this moment there are unexpired sources
router will change to receiving traffic for those sources. The role (whose source timers are greater than zero), the router will change
of the group timer can be summarized as follows: to receiving traffic for those sources. The role 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,
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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 for indicating undesired sources. In the lightweight expires for indicating undesired sources. In the lightweight
version, since there is no need to keep such records for blocking version, since there is no need to keep such records for blocking
specific sources, if a source timer expires, its source record should specific sources, if a source timer expires, its source record should
be deleted immediately, not waiting for the time-out of the group be deleted immediately, not waiting for the time-out of the group
timer. timer.
4.2. Source-Specific Forwarding Rules 5.2. Source-Specific Forwarding Rules
A full version multicast router needs to consult IGMPv3 state A full version multicast router needs to consult IGMPv3 state
information when it makes decisions on forwarding a datagram from a information when it makes decisions on forwarding a datagram from a
source or its upstream router to its attached network, based on the source or its upstream router to its attached network, based on the
router filter-mode and source timer. In LW-IGMPv3, because of the router filter-mode and source timer. In LW-IGMPv3, because of the
absence of the router filter-mode, the group timer and source timer absence of the router filter-mode, the group timer and source timer
could be used for such decisions. The forwarding suggestion made by could be used for such decisions. The forwarding suggestion made by
LW-IGMPv3 to the routing protocols is summarized as follows: LW-IGMPv3 to the routing protocols is summarized as follows:
Group Timer Source Timer Action Group Timer Source Timer Action
skipping to change at page 13, line 38 skipping to change at page 13, line 38
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 forwarding G_Timer > 0 S_TIMER >= 0 Suggest forwarding
traffic from source traffic from source
G_Timer > 0 No Source Elements Suggest forwarding G_Timer > 0 No Source Elements Suggest forwarding
traffic from source traffic from source
4.3. Reception of Current-State Records 5.3. Reception of LW-IGMPv3 Group Records
When receiving Current-State Records, the LW-IGMPv3 router resets its
group or source timers and updates its source list within the group.
For source-specific group reception state (when G_Timer==0), the
source list contains sources whose traffic will be forwarded by the
router, while in non-source-specific group reception (when
G_Timer>0), the source list remembers the valid sources to receive
traffic from after toggling to source-specific reception state.
Although the Lightweight host only sends a subset of the message of
that of the full version, the LW-router should be able to process as
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
Source 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() A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX() A G_Timer=GMI
The above table could be further simplified for the processes that
are completely same for the two values of the G_Timer:
Old New
Source Source
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI On receiving LW-IGMPv3 group records, the LW-IGMPv3 router must act
upon these records and possible change their own states to reflect
the new desired membership state of the network.
A IS_EX() A G_Timer=GMI Lightweight routers query sources that are requested to be no longer
forwarded to a group. When a router queries or receives a query for
a specific set of sources, it lowers its source timers for those
sources to a small interval of Last Member Query Time seconds. If
group records are received in response to the queries which express
interest in receiving traffic from the queried sources, the
corresponding timers are updated.
Without EXCLUDE filter-mode, a router's process on receiving Current- Similarly, when a router queries a specific group, it lowers its
State Record is simple: when a router receives an IS_IN report, it group timer for that group to a small interval of Last Member Query
appends the reported source addresses to the previous source list Time seconds. If TO_EX({}) group records are received within the
with their source timers set to GMI. Upon receiving an IS_EX() interval, the group timer for the group is updated and the suggestion
report, the router sets the non-source-specific receiving states by to the routing protocol to forward the group stands without any
resetting the group timer value and keeps the previous source list interruption.
without modification.
4.4. Reception of Source-List-Change and Filter-Mode-Change Records During a query period (i.e., Last Member Query Time seconds), the
IGMP component in the router continues to suggest to the routing
protocol that it forwards traffic from the groups or sources that it
is querying. It is not until after Last Member Query Time seconds
without receiving a record expressing interest in the queried group
or sources that the router may prune the group or sources from the
network.
On receiving Source-List-Change and Filter-Mode-Change Records, the The following table describes the changes in group state and the
LW-IGMPv3 router needs to reset its group and source timers, update action(s) taken when receiving LW-IGMPV3 Group Record. This table
its source list within the group, or trigger group queries. The also describes the queries which are sent by the Querier when a
queries are sent by the router for the sources that are requested to particular report is received. The notation in the table has the
be no longer forwarded to a group. The table below describes the same meaning as the full version defines [2][3]:
state change and the actions that should be taken.
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 ALLOW(B) A+B (B)=GMI 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 BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B) 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 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: G_Timer >= 0 A TO_EX({}) A (B)=GMI
Old New
Source Source
List Report Rec'd List Actions
------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI In order to maintain protocol robustness, queries sent by actions in
Send Q(G,A-B) the table need to be transmitted [Last Member Query Count] times,
If G_Timer>0 Send Q(G) once every [Last Member Query Interval] (These values are defined in
[2][3]).
In this table, TO_EX() report is not included because the processing If while scheduling new queries, there are already pending queries to
is exactly the same as that of IS_EX(), as described in the previous be retransmitted for the same group, the new and pending queries have
section. Section 5.1 gives the lightweight routers's transformation to be merged. In addition, received host reports for a group with
behavior between the two messages. pending queries may affect the contents of those queries. The
process of building and maintaining the state of pending queries is
described in [2][3].
5. Interoperability The method which a lightweight router uses to build and send queries,
and the actions the router should take on receiving Queries from
other routers are completely the same as that of full version. The
detailed description is described in [2][3].
LW-IGMPv3/LW-MLDv2 hosts and routers should interoperate gracefully 6. Interoperability
with the full version protocols [2][3]. Also, LW-IGMPv3/LW-MLDv2
hosts and routers should interoperate gracefully with hosts and
routers running IGMPv1/v2 or MLDv1.
5.1. Interoperation with the Full Version of IGMPv3 LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and
routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts
and routers must interoperate gracefully with hosts and routers
running IGMPv1/v2 or MLDv1.
LW-IGMPv3 does not introduce any change on the message format of the 6.1. Interoperation with the Full Version of IGMPv3/MLDv2
group query and report messages the full version protocols use. With
the elimination of the EXLCLUDE filter mode, the LW-IGMPv3 group
member sends a subset of IGMPv3 report messages, which can be
recognized by a multicast router running the full or the lightweight
IGMPv3 protocol on the same LAN.
A LW-IGMPv3 router does not process directly IS_EX(x) and TO_EX(x) LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format
records that are used by the full IGMPv3. When a LW-IGMPv3 router of the group query and report messages the full version protocols
receives these report messages from the full version host, it use. The LW-IGMPv3 group member sends a subset of IGMPv3 report
translates them to IS_EX() records and behaves accordingly. All messages, which can be recognized by a multicast router running the
possible record types are compared as follows: full or the lightweight IGMPv3 protocol on the same LAN.
IGMPv3 Report LW-IGMPv3 Equivalent A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_IN(x),
------------- -------------------- IS_EX(x) and TO_EX(x) (except for TO_EX({})) records that are used by
the full version. When a LW-IGMPv3/LW-MLDv2 router receives these
report messages from the full version host, it MUST translate them
internally to the defined records and behaves accordingly. All
possible record types are defined as follows:
IS_IN(x) IS_IN(x) IGMPv3/MLDv2 Report LW-IGMPv3/LW-MLDv2 Equivalent
------------------- -----------------------------
IS_EX(x) IS_EX() IS_IN(x) ALLOW(x)
TO_IN(x) TO_IN(x) IS_EX(x) TO_EX({})
TO_EX(x) IS_EX() TO_EX(x) IS_EX()
ALLOW(x) ALLOW(x) 6.2. Interoperation with IGMPv1/IGMPv2
BLOCK(x) BLOCK(x)
5.2. Interoperation with IGMPv1/IGMPv2
The LW-IGMPv3 protocol basically adopts the same Host/Group
Compatibility Mode and keeps Querier Present timers for IGMPv1 and
IGMPv2. Their definition and processing is the same as that of
IGMPv3.
5.2.1. Behavior of Group Members 6.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 its IGMPv2 Querier Present timer is set to Older Version Querier
Timeout second (defined in [2]) whenever an IGMPv2 General Query is Present Timeout seconds (defined in [2]) whenever an IGMPv2 General
received on that interface. The Host Compatibility Mode of an Query is received on that interface. The Host Compatibility Mode of
interface is set to IGMPv1 and IGMPv1 Querier Present is set to Older an interface is set to IGMPv1 and its IGMPv1 Querier Present timer is
Version Querier Present Timeout second whenever an IGMPv1 Membership set to Older Version Querier Present Timeout seconds whenever an
Query is received on that interface. Based on the Host Compatibility IGMPv1 Membership Query is received on that interface. Based on the
Mode variable, a host acts using the IGMPv3, IGMPv2, or IGMPv1 Host Compatibility Mode variable, a host acts using the IGMPv3,
protocol on that interface. IGMPv2, or IGMPv1 protocol on that interface.
While above manner is inherited from the definition of [2], LW-IGMPv3 In the presence of older version group members, LW-IGMPv3 hosts may
may enable to configure the Host Compatibility Mode variable by other allow its report message to be suppressed by either an IGMPv1 or
means: when a LW-IGMPv3 host is placed on a link where there are IGMPv2 membership report. However, because the transmission of
IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message to be IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
suppressed by an IGMPv1 or IGMPv2 report message. as a potential protection mechanism, the choice to enable or disable
the use of backward compatibility may be configurable.
5.2.2. Behavior of Multicast Routers 6.2.2. Behavior of Multicast Routers
If a LW-IGMPv3 router is on a network where at least one router 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 running IGMPv1 or IGMPv2 protocols, it is required that the lowest
version of querier must be used. This can be administratively version of Querier must be used. This can be administratively
assured by supporting IGMPv1, IGMPv2 or IGMPv3 compatibility mode. assured by supporting IGMPv1, IGMPv2 or IGMPv3 compatibility mode.
An LW-IGMPv3 router may be placed on a network where there are hosts If a router is not explicitly configured to use IGMPv1 or IGMPv2 and
that have not been upgraded to IGMPv3. In order to be compatible hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a
with the older version, the lightweight router should keep a Group warning. These warnings MUST be rate-limited. When in IGMPv1 mode,
compatibility mode for each group record, and IGMPv1 and IGMPv2 Host routers MUST send periodic IGMPv1 Queries and MUST ignore Leave Group
present timers are kept to switch gracefully between different messages. They SHOULD also warn about receiving an IGMPv2 or IGMPv3
versions of IGMP. query (such warnings MUST be rate-limited). When in IGMPv2 mode,
routers MUST send periodic IGMPv2 Queries, and SHOULD also warn about
receiving an IGMPv3 query (such warnings MUST be rate-limited).
When Group Compatibility mode is IGMPv2 or IGMPv1, a LW-IGMPv3 router If an LW-IGMPv3 router is placed on a network where there are hosts
translates the following IGMPv2 or IGMPv1 messages for that group to that have not been upgraded to IGMPv3, it MUST be able to operate in
version 1 or version 2 compatibility mode. The router keeps a
compatibility mode, an IGMPv1 Host Present Timer and an IGMPv2 Host
Present Timer (as defined in [2][3]) for each group record. The
IGMPv1 Host Present timer is set to Older Version Host Present
Timeout seconds whenever an IGMPv1 Membership Report is received.
The IGMPv2 Host Present timer is set to Older Version Host Present
Timeout seconds whenever an IGMPv2 Membership Report is received.
The Group Compatibility Mode of a group record changes whenever an
older version report (than the current compatibility mode) is heard
or when certain timer conditions occur. When the IGMPv1 Host Present
timer expires, the LW-IGMPv3 router switches to Group Compatibility
mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it
does not have a running IGMPv2 Host Present timer then it switches to
Group Compatibility of IGMPv3. When the IGMPv2 Host Present timer
expires and the IGMPv1 Host Present timer is not running, a router
switches to Group Compatibility mode of IGMPv3. Note that when a
group switches back to IGMPv3 mode, it takes some time to regain
source-specific state information.
When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router
internally translates the following IGMPv2 messages for that group to
their LW-IGMPv3 equivalents: their LW-IGMPv3 equivalents:
IGMP Message LW-IGMPv3 Equivalent IGMPv2 Message LW-IGMPv3 Equivalent
------------- -------------------- -------------- --------------------
v1 Report IS_EX() v2 Report TO_EX({})
v2 Report IS_EX() v2 Leave TO_IN({})
v2 Leave TO_IN() When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router
internally translates the following IGMPv1 and IGMPv2 messages for
that group to their IGMPv3 equivalents:
6. Implementation Considerations IGMPv1 Message LW-IGMPv3 Equivalent
-------------- --------------------
The lightweight protocols requires no additional procedure on the v1 Report TO_EX({})
6.3. Interoperation with MLDv1
The MLDv2 hosts and routers MUST interoperate with the hosts and
routers running MLDv1. The method is the same as described in
Section 6.2. The difference is that when a MLDv2 router has a MLDv1
listener on its network, it translates the following MLDv1 messages
to their MLDv2 equivalents:
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
Done TO_IN({})
7. Implementation Considerations
The lightweight protocols require 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 may be running IGMPv3/MLDv2 (snooping) and multicast routing protocols may
greatly decreased. be greatly decreased.
In the following sections, the implementation related aspects 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 7.1. Implementation of Source-Specific Multicast
[8] illustrates the requirements of implementation of Source-Specific [8] illustrates the requirements of implementation of Source-Specific
Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight
protocol does not impose any bad influences on an SSM application. protocol does not impose any bad influences on an SSM application.
The requirements of LW-IGMPv3/LW-MLDv2 for supporting SSM are The requirements of LW-IGMPv3/LW-MLDv2 for supporting 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 invoke a (*,G) join, i.e.,
i.e., IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the TO_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 (*,G) join with an SSM group address should indicate
should indicate an error to the application. The SSM-aware router an error to the application. The SSM-aware router will ignore
will ignore IS_EX() reports with SSM addresses. Other types of TO_EX({}) reports with SSM addresses. Other types of Reports should
Reports should be processed normally. be processed normally.
6.2. Implementation of Multicast Source Filter (MSF) APIs 7.2. Implementation of Multicast Source Filter (MSF) APIs
Multicast Source Filter (MSF) APIs [9] 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 8. Security Considerations
The security considerations are the same as that of the full version The security considerations are the same as that of the full version
of IGMPv3/MLDv2. of IGMPv3/MLDv2.
8. References 9. References
8.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
skipping to change at page 20, line 36 skipping to change at page 21, line 36
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006. RFC 4607, August 2006.
[8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener Management Protocol Version 3 (IGMPv3) and Multicast 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.
8.2. Informative References 9.2. Informative References
[9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, Extensions for Multicast Source Filters", RFC 3678,
January 2004. January 2004.
Authors' Addresses 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.
 End of changes. 84 change blocks. 
293 lines changed or deleted 314 lines changed or added

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