draft-ietf-mboned-lightweight-igmpv3-mldv2-06.txt   rfc5790.txt 
MBONED Working Group H. Liu Internet Engineering Task Force (IETF) H. Liu
Internet-Draft W. Cao Request for Comments: 5790 W. Cao
Intended status: Standards Track Huawei Technologies Category: Standards Track Huawei Technologies
Expires: April 17, 2010 H. Asaeda ISSN: 2070-1721 H. Asaeda
Keio University Keio University
October 14, 2009 February 2010
Lightweight IGMPv3 and MLDv2 Protocols
draft-ietf-mboned-lightweight-igmpv3-mldv2-06
Status of this Memo Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
Multicast Listener Discovery Version 2 (MLDv2) Protocols
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
Task Force (IETF), its areas, and its working groups. Note that IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
other groups may also distribute working documents as Internet- IGMPv3 and MLDv2. The interoperability with the full versions and
Drafts. the previous versions of IGMP and MLD is also taken into account.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 17, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5790.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document describes lightweight IGMPv3 and MLDv2 protocols (LW- This document may contain material from IETF Documents or IETF
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of Contributions published or made publicly available before November
IGMPv3 and MLDv2. The interoperability with the full versions and 10, 2008. The person(s) controlling the copyright in some of this
the previous versions of IGMP and MLD is also taken into account. material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................4
3. Simplification Method Overview . . . . . . . . . . . . . . . . 7 3. Simplification Method Overview ..................................4
3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 7 3.1. Behavior of Group Members ..................................5
3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7 3.2. Behavior of Multicast Routers ..............................5
4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9 4. LW-IGMPv3 Protocol for Group Members ............................6
4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9 4.1. Query and Report Messages ..................................6
4.2. Action on Change of Interface State . . . . . . . . . . . 9 4.2. Action on Change of Interface State ........................6
4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10 4.3. Action on Reception of a Query .............................7
4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10 4.4. LW-IGMPv3 Group Record Types ...............................7
5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 5. LW-IGMPv3 Protocol for Multicast Routers ........................9
5.1. Group Timers and Source Timers in the Lightweight 5.1. Group Timers and Source Timers in the Lightweight Version ..9
Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Source-Specific Forwarding Rules ..........................10
5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 5.3. Reception of Current-State Records ........................10
5.3. Reception of Current-State Records . . . . . . . . . . . . 13 5.4. Reception of Source-List-Change and
5.4. Reception of Source-List-Change and Filter-Mode-Change Filter-Mode-Change Records ................................12
Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Interoperability ...............................................13
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16 6.1.1. Behavior of Group Members ..........................13
6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 16 6.1.2. Behavior of Multicast Routers ......................13
6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 16 6.2. Interoperation with IGMPv1/IGMPv2 .........................14
6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 6.2.1. Behavior of Group Members ..........................14
6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 6.2.2. Behavior of Multicast Routers ......................14
6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 6.3. Interoperation with MLDv1 .................................15
6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 17 7. Implementation Considerations ..................................15
7. Implementation Considerations . . . . . . . . . . . . . . . . 19 7.1. Implementation of Source-Specific Multicast ...............15
7.1. Implementation of Source-Specific Multicast . . . . . . . 19 7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19 8. Security Considerations ........................................16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements ...............................................16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. References ....................................................16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References .....................................16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References ...................................17
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 supported 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 learn sources which are of interest or which are multicast router to learn sources that are of interest or that are
of not interested for a particular multicast address. This not of interest for a particular multicast address. This information
information is used during forwarding of multicast data packets. is used during forwarding of multicast data packets.
INCLUDE and EXCLUDE filter-modes are introduced to support the source INCLUDE and EXCLUDE filter-modes are introduced to support the 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
to maintain the forwarding state of desired groups and sources under to maintain the forwarding state of desired groups and sources under
certain filter modes. When a group report arrives or a certain timer certain filter-modes. When a group report arrives or a certain timer
expires, a multicast router may update the desired or undesired expires, a multicast router may update the desired or undesired
source lists, reset related timer values, change filter mode, or source-lists, reset related timer values, change filter-mode, or
trigger group queries. With all of the above factors correlating trigger group queries. With all of the above factors correlating
with each other, the determination rules become relatively complex, with each other, the determination rules become relatively complex,
as the interface states could be frequently changed. as the interface states could be frequently changed.
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 explicitly refuses
refuse traffic from some sources in a group, when other users in the traffic from some sources in a group, when other users in the same
same shared network have an interest in these sources, the shared network have an interest in these sources, the corresponding
corresponding multicast traffic is forwarded to the network. It is multicast traffic will still be forwarded to the network. It is
generally unnecessary to support the filtering function that blocks generally unnecessary to support the filtering function that blocks
sources. 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).
LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2. LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
These protocols support both ASM and SSM communications without a They support both Any-Source Multicast (ASM) and SSM communications
filtering function that blocks sources. Not only are they compatible without a filtering function that blocks sources. Not only are they
with the standard IGMPv3 and MLDv2, but also the protocol operations compatible with the standard IGMPv3 and MLDv2, but also the protocol
made by hosts and routers or switches (performing IGMPv3/MLDv2 operations made by hosts and routers (or switches performing IGMPv3/
snooping) are simplified to reduce the complicated operations. Since MLDv2 snooping) are simplified to reduce the complicated operations.
LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2, Since LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and
hosts or routers that have implemented the full version do not need MLDv2, hosts or routers that have implemented the full version do not
to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 need to implement or modify anything to cooperate with LW-IGMPv3/
hosts or routers. LW-MLDv2 hosts or routers.
2. Terminology 2. Terminology
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].
In addition, the following terms are used in this document. In addition, the following terms are used in this document.
(*,G) join: (*,G) join:
An operation triggered by a host that wants to join the group G. In An operation triggered by a host that wants to join a group G. In
this case, the host receives from all sources sending to group G. this case, the host receives from all sources sending to group G.
This is typical in the ASM communication. This is typical in ASM communication.
(S,G) join: (S,G) join:
An operation triggered by a host that wants to join the group G, with An operation triggered by a host that wants to join a group G,
specifying desired source S. In this case, the host receives only specifying a desired source S. In this case, the host receives
from source S sending to group G. traffic only from source S sending to group G.
INCLUDE (S,G) join: INCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under An operation triggered by a host that wants to join a group G under
INCLUDE filter-mode, with specifying desired source S. The same INCLUDE filter-mode, specifying a desired source S. Same meaning as
meaning of (S,G) join. (S,G) join.
EXCLUDE (*,G) join: EXCLUDE (*,G) join:
An operation triggered by a host that wants to join a group G under An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode. The same meaning of (*,G) join. EXCLUDE filter-mode. Same meaning as (*,G) join.
EXCLUDE (S,G) join: EXCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode, with specifying undesired source S. This EXCLUDE filter-mode, specifying an undesired source S. This
operation is not supported by LW-IGMPv3/LW-MLDv2. operation is not supported by LW-IGMPv3/LW-MLDv2.
3. Simplification Method Overview 3. Simplification Method Overview
The principle is to simplify the host and router's behavior as much The principle is to simplify the host's and router's behavior as much
as possible to improve efficiency, while guaranteeing as possible to improve efficiency, while guaranteeing
interoperability with the full versions, and introducing no side interoperability with the full versions, and introducing no side
effects on applications. 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.
3.1. Behavior of Group Members 3.1. Behavior of Group Members
In LW-IGMPv3, the same service interface model as that of IGMPv3 is LW-IGMPv3 inherits the service interface model of IGMPv3.
inherited:
IPMulticastListen ( socket, interface, multicast-address, IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list ) filter-mode, source-list )
In the lightweight protocol, INCLUDE mode on the host part has the In the lightweight protocol, INCLUDE mode on the host part has the
same usage with the full version for INCLUDE (S,G) join, while same usage as the full version for INCLUDE (S,G) join, while EXCLUDE
EXCLUDE mode on the host part is preserved only for excluding null mode on the host part is preserved only for excluding null source-
source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/ lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/MLDv1.
MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is The detailed host operation of LW-IGMPv3/LW-MLDv2 is described in
described in Section 4. Section 4.
3.2. Behavior of Multicast Routers 3.2. Behavior of Multicast Routers
In IGMPv3, router filter-mode is defined to optimize the state In IGMPv3, router filter-mode is defined to optimize the state
description of a group membership [2][3]. As a rule, once a member description of a group membership [2]. As a rule, once a member
report is in EXCLUDE mode, the router filter-mode for the group will report is in EXCLUDE mode, the router filter-mode for the group will
be set to EXCLUDE. When all systems cease sending EXCLUDE mode be set to EXCLUDE. When all systems cease sending EXCLUDE mode
reports, the filter-mode for that group may transit back to INCLUDE reports, the filter-mode for that group may transit back to INCLUDE
mode. Group timer is used to identify such transition. mode. The group timer is used to identify such a transition.
In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can
request an EXCLUDE (*,G) join, which can be interpreted by the router request an EXCLUDE (*,G) join, which can be interpreted by the router
as a request to include all sources. Without the more general form as a request to include all sources. Without the more general form
of EXCLUDE requests, it is unnecessary for the router to maintain the of EXCLUDE requests, it is unnecessary for the router to maintain the
EXCLUDE filter-mode, and the state model for multicast router can be EXCLUDE filter-mode, and the state model for multicast routers 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 a (*,G) join. Its basic Here a group timer is kept to represent a (*,G) join. Its basic
behavior is: when a router receives a (*,G) join, it will set its behavior is: when a router receives a (*,G) join, it will set 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
previously received source records. When the group timer expires, previously received source records. When the group timer expires,
the router may change to the reception for the listed sources. The the router may change to reception of the listed sources only. The
definition of the source record is the same as that of full version. definition of the source record is the same as in the 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. The detailed operation of router operation is described in behavior. The details of router operation are described in
Section 5. Section 5.
4. LW-IGMPv3 Protocol for Group Members 4. LW-IGMPv3 Protocol for Group Members
4.1. Query and Report Messages 4.1. Query and Report Messages
LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, LW-IGMPv3 uses the same two sets of messages, Query and Report
being the same as the full version protocols. There is no difference messages, as the full version protocols. There is no difference
between the definition and usage of the Query message. But the between the definition and usage of the Query message. But the
report types in lightweight protocols are reduced because an report types in lightweight protocols are reduced because an
operation that triggers EXCLUDE (S,G) join is omitted. operation that triggers EXCLUDE (S,G) join is omitted.
There are three Group Record Types defined in the full IGMPv3: There are three Group Record Types defined in the full IGMPv3: the
Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) Current-State Record denoted by MODE_IS_INCLUDE (referred to as
or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by IS_IN) or MODE_IS_EXCLUDE (IS_EX), the Filter-Mode-Change Record
CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and denoted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE
Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or (TO_EX), and the Source-List-Change Record denoted by
BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the action on change ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3
of interface state and reception of a Query, but IS_IN and IS_EX inherits the actions on change of interface state and on reception of
record types are eliminated and Current-State Records are noted by a query, but the IS_IN and IS_EX record types are eliminated and
other records. The following sections explain the details. Current-State Records are replaced by other records. The following
sections explain the details.
4.2. 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 for the computation are the same as for the
computation, in the lightweight version host, the interface state full version, in a 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 4.4): (Group Record Types are described in Section 4.4):
Old State New State State-Change Record Sent Old State New State State-Change Report 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)
As in the full version, to cover the possibility of the State-Change As in the full version, to cover the possibility of the State-Change
Report being missed by one or more multicast routers, it is Report being missed by one or more multicast routers, it is
retransmitted [Robustness Variable]-1 more times, at intervals chosen retransmitted [Robustness Variable]-1 more times, at intervals chosen
at random from the range (0, [Unsolicited Report Interval]). (These at random from the range (0, [Unsolicited Report Interval]). (These
values are defined in [2][3].) values are defined in [2][3].)
4.3. Action on Reception of a Query 4.3. Action on Reception of a Query
As in the full version, when a lightweight version host receives a As in the full version, when a lightweight version host receives a
Query, it does not respond immediately. Instead, it delays its query, it does not respond immediately. Instead, it delays its
response by a random amount of time, bounded by the Max Resp Time response by a random amount of time, bounded by the Max Resp Time
value derived from the Max Resp Code in the received Query message value derived from the Max Resp Code in the received Query message
[2][3]. The system may receive a variety of Queries on different [2][3]. The system may receive a variety of queries on different
interfaces and of different kinds (e.g., General Queries, Group- interfaces and of different kinds (e.g., General Queries, Group-
Specific Queries, and Group-and-Source-Specific Queries), each of Specific Queries, and Group-and-Source-Specific Queries), each of
which may require its own delayed response. which may require its own delayed 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 the full version's rules that are used to LW-IGMPv3 inherits the full version's rules that are used to
determine if a Report needs to be scheduled. The difference is determine if a report needs to be scheduled. The difference is
regarding the simplification of EXCLUDE filter-mode and the type of regarding the simplification of EXCLUDE filter-mode and the type of
Report as detailed in Section 4.4. report as detailed in Section 4.4.
4.4. LW-IGMPv3 Group Record Types 4.4. LW-IGMPv3 Group Record Types
Among Group Record Types defined in the full IGMPv3, several record Among the Group Record Types defined in the full IGMPv3, several
types are not used in LW-IGMPv3 as some of the processes related to record types are not used in LW-IGMPv3 as some of the processes
the filter mode change to the EXCLUDE mode are eliminated and some of related to the filter-mode change to the EXCLUDE mode are eliminated
the report messages are converged with a record having null source and some of the Report messages are converged into a record having a
address list. All of the record types of report messages used by the null source address list. All of the record types of Report messages
full and lightweight version protocols are shown as follows: used by the 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
skipping to change at page 11, line 27 skipping to change at page 8, line 27
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 a null source address list. For instance, IS_EX({}) means
report whose record type is IS_EX with null source address list. a report whose record type is IS_EX with a 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({}) receives a Report message containing either IS_EX({}) or TO_EX({})
record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) record types. Therefore, LW-IGMPv3 integrates the IS_EX({})
operation with 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 an LW-IGMPv3 host needs to make a query response for the state
INCLUDE (x,G) join, it makes a response whose message type is of 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 exactly the
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 An LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN and TO_EX
used the following situation: the host first launches an application records are used for example in the following situation: the host
(AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the first launches an application (AP1) that requests INCLUDE (x,G) join,
host launches another application (AP2) that joins (*,G), and it and sends ALLOW(x). Then the host launches another application (AP2)
sends TO_EX({}). In this condition, when AP2 terminates but AP1 that joins (*,G), and it sends TO_EX({}). In this condition, when
keeps working on the lightweight version host, the host sends a AP2 terminates but AP1 keeps working on the lightweight version host,
report with TO_IN(x) record type for [Robustness Variable] times. the host sends a report with TO_IN(x) record type for [Robustness
Variable] times.
Although an LW-IGMPv3 host adopts the four message types (ALLOW,
BLOCK, TO_IN, and TO_EX) for simplification, using IS_EX({}) and
IS_IN(x) (respectively, instead of TO_EX({}) and ALLOW(x)) in
response to queries is not inhibited. This will not introduce the
interoperation problem because the router process is, respectively,
the same for the mentioned two message set, as long as the router
implementation follows the rules given by full IGMPv3.
5. 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 in 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.
5.1. Group Timers and Source Timers in the Lightweight Version 5.1. Group Timers and Source Timers in the Lightweight Version
In lightweight and full IGMPv3 routers, a source timer is kept for In lightweight and full IGMPv3 routers, a source timer is kept for
each source record and it is updated when the source is present in a each source record and it is updated when the source is present in a
received report. It indicates the validity of the sources and needs received report. It indicates the validity of the source and needs
to be referred when the router takes its forwarding decision. to be referred to when the router 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
redefined in the lightweight protocols to identify the non-source- redefined in the lightweight protocols to identify the non-source-
specific receiving states maintaining for (*,G) join. Once a group specific receiving state maintained for (*,G) join. Once a group
record of TO_EX({}) is received, the group timer is set to represent record of TO_EX({}) is received, the group timer is set to represent
this (*,G) group join. The expiration of the group timer indicates this (*,G) group join. The expiration of the group timer indicates
that there are no more listeners on the attached network for this that there are no more listeners on the attached network for this
(*,G) group. Then if at this moment there are unexpired sources (*,G) group. Then if at this moment there are unexpired sources
(whose source timers are greater than zero), the router will change (whose source timers are greater than zero), the router will change
to receiving traffic for those sources. The role of the group timer to receiving traffic for those sources only. The role of the group
can be summarized as follows: 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 differences compared to 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.
5.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, based on the router filter-mode and source timer. 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 is
LW-IGMPv3 to the routing protocols is summarized as follows: summarized as follows:
Group Timer Source Timer Action Group Timer Source Timer Action
------------ ------------------ ----------------------- ------------ ------------------ -----------------------
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 S_TIMER == 0 Suggest stopping 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 forwarding
traffic from the source traffic from 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
5.3. Reception of Current-State Records 5.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 (when G_Timer==0 and For source-specific group reception state (when G_Timer == 0 and
S_Timer > 0), the source list contains sources whose traffic will be S_Timer > 0), the source-list contains sources whose traffic will be
forwarded by the router, while in non-source-specific group reception forwarded by the router, while in non-source-specific group reception
(when G_Timer>0), the source list remembers the valid sources to (when G_Timer > 0), the source-list remembers the valid sources to
receive traffic from after toggling to source-specific reception receive traffic from after toggling to source-specific reception
state. state.
Although the LW-IGMPv3 host only sends a subset of the message of Although the LW-IGMPv3 host only sends a subset of the messages of
that of the full version, the LW-IGMPv3 router should be able to the full version, the LW-IGMPv3 router should be able to process as
process as much messages as possible to be compatible with the full many messages as possible to be compatible with the full version
version host. Note that if the report type is IS_EX(x) with non- host. Note that if the report type is IS_EX(x) with a non-empty
empty source-list, the router will treat it as the same type of source-list, the router will treat it as the same type of report with
report with empty source list. The following table describes the an empty source-list. The following table describes the action taken
action taken by a multicast router after receiving Current-State by a multicast router after receiving Current-State Records. The
Records. The notations have the same meaning as that in the full notations have the same meaning as those in the full IGMPv3 protocol.
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
The above table could be further simplified for the processes that The above table could be further simplified since the processes are
are completely same for the two values of the G_Timer: exactly the 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 a
State Record is simple: when a router receives an IS_IN report, it Current-State Record is simple: when a router receives an IS_IN
appends the reported source addresses to the previous source list report, it appends the reported source addresses to the previous
with their source timers set to GMI. Upon receiving an IS_EX({}) source-list with their source timers set to GMI. Upon receiving an
report, the router sets the non-source-specific receiving states by IS_EX({}) report, the router sets the non-source-specific receiving
resetting the group timer value and keeps the previous source list states by resetting the group timer value and keeps the previous
without modification. source-list without modification.
5.4. Reception of Source-List-Change and Filter-Mode-Change Records 5.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. Note that if the report type is be no longer forwarded to a group. Note that if the report type is
TO_EX(x) with non-empty source-list, the router will treat it as the TO_EX(x) with a non-empty source-list, the router will treat it as
same type of report with empty source list. The table below the same type of report with an empty source-list. The table below
describes the state change and the actions that should be taken. describes the 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)
skipping to change at page 15, line 33 skipping to change at page 13, line 6
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)
G_Timer > 0 A TO_EX({}) A G_Timer=GMI G_Timer > 0 A TO_EX({}) A G_Timer=GMI
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)
skipping to change at page 16, line 14 skipping to change at page 13, line 29
6. Interoperability 6. Interoperability
LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and 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 routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts
and routers must interoperate gracefully with hosts and routers and routers must interoperate gracefully with hosts and routers
running IGMPv1/v2 or MLDv1. running IGMPv1/v2 or MLDv1.
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 6.1. Interoperation with the Full Version of IGMPv3/MLDv2
LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format LW-IGMPv3/LW-MLDv2 do not introduce any change on the message formats
of the group query and report messages the full version protocols of the group Query and Report messages that the full version
use. protocols use.
6.1.1. Behavior of Group Members 6.1.1. Behavior of Group Members
A LW-IGMPv3 host's compatibility mode is determined from the Host An LW-IGMPv3 host's compatibility mode is determined from the Host
Compatibility Mode variable which can be in one of three states: Compatibility Mode variable, which can be in one of three states:
IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its
interface as LW-IGMPv3, its Host Compatibility Mode of that interface interface as LW-IGMPv3, its Host Compatibility Mode of that interface
is set to IGMPv3, and the host sends a subset of IGMPv3 report is set to IGMPv3, and the host sends a subset of IGMPv3 Report
messages, which can be recognized by a multicast router running the messages, which can be recognized by a multicast router running the
full or the lightweight IGMPv3 protocol on the same LAN. full or the lightweight IGMPv3 protocol on the same LAN.
6.1.2. Behavior of Multicast Routers 6.1.2. Behavior of Multicast Routers
A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and An LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x)
TO_EX(x) records that are used by the full version. When a LW- and TO_EX(x) reports that are used by the full version. When an LW-
IGMPv3/LW-MLDv2 router receives these report messages from the full IGMPv3/LW-MLDv2 router receives these Report messages from full
version host, it MUST translate them internally to IS_EX({}) and version hosts, it MUST translate them internally to IS_EX({}) and
TO_EX({}) respectively and behaves accordingly. TO_EX({}) respectively and behave accordingly.
6.2. Interoperation with IGMPv1/IGMPv2 6.2. Interoperation with IGMPv1/IGMPv2
Since the lightweight protocols can be treated as the parallel Since the lightweight protocols can be treated as a parallel version
version of full version of IGMPv3/MLDv2, its compatibility principle of the full version of IGMPv3/MLDv2, its compatibility principle and
and method with the older version are generally the same as that of method with the older version are generally the same as that of full
full IGMPv3/MLDv2. IGMPv3/MLDv2.
6.2.1. Behavior of Group Members 6.2.1. Behavior of Group Members
The Host Compatibility Mode of an interface is set to IGMPv2 and its The Host Compatibility Mode of an interface is set to IGMPv2 and its
IGMPv2 Querier Present timer is set to Older Version Querier Present IGMPv2 Querier Present timer is set to Older Version Querier Present
Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is Timeout seconds (defined in [2]) whenever an IGMPv2 General Query 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 its IGMPv1 Querier Present timer is interface is set to IGMPv1 and its IGMPv1 Querier Present timer is
set to Older Version Querier Present Timeout seconds whenever an set to Older Version Querier Present Timeout seconds whenever an
IGMPv1 Membership Query is received on that interface. IGMPv1 Membership Query is received on that interface.
In the presence of older version group members, LW-IGMPv3 hosts may In the presence of older version group members, LW-IGMPv3 hosts may
allow its report message to be suppressed by either an IGMPv1 or allow its Report message to be suppressed by either an IGMPv1 or
IGMPv2 membership report. However, because the transmission of IGMPv2 membership report. However, because the transmission of
IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
as a potential protection mechanism, the choice to enable or disable as a potential protection mechanism, the choice to enable or disable
the use of backward compatibility may be configurable. the use of backward compatibility may be configurable.
6.2.2. Behavior of Multicast Routers 6.2.2. Behavior of Multicast Routers
The behavior of a LW-IGMPv3 router when placed on a network where The behavior of an LW-IGMPv3 router when placed on a network where
there are routers that have not been upgraded to IGMPv3, is there are routers that have not been upgraded to IGMPv3 is exactly
completely the same with a full IGMPv3 router in this situation [2]. the same as for a full IGMPv3 router in this situation [2].
A full IGMPv3 router uses Group Compatibility Mode (whose value is A full IGMPv3 router uses Group Compatibility Mode (whose value is
either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate
which version of IGMP protocol it behaves for the group. This value which version of IGMP protocol it applies to the group. This value
is set according to the version of the received IGMP report. When is set according to the version of the received IGMP reports. When
Group Compatibility Mode is IGMPv3, the lightweight router acts with Group Compatibility Mode is IGMPv3, the lightweight router performs
LW-IGMPv3 protocol for that group. the LW-IGMPv3 protocol for that group.
When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits
this compatibility mechanism with the following rules: this compatibility mechanism with the following rules:
IGMP Message LW-IGMPv3 Equivalent IGMP Message LW-IGMPv3 Equivalent
-------------- -------------------- -------------- --------------------
v2 Report TO_EX({}) v2 Report TO_EX({})
v2 Leave TO_IN({}) v2 Leave TO_IN({})
When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router When Group Compatibility Mode is IGMPv1, an LW-IGMPv3 router
internally translates the following IGMPv1 and IGMPv2 messages for internally translates the following IGMPv1 and IGMPv2 messages for
that group to their LW-IGMPv3 equivalents: that group to their LW-IGMPv3 equivalents:
IGMP Message LW-IGMPv3 Equivalent IGMP Message LW-IGMPv3 Equivalent
-------------- -------------------- -------------- --------------------
v1 Report TO_EX({}) v1 Report TO_EX({})
v2 Report TO_EX({}) v2 Report TO_EX({})
6.3. Interoperation with MLDv1 6.3. Interoperation with MLDv1
LW-MLDv2 hosts and routers MUST interoperate with the hosts and LW-MLDv2 hosts and routers MUST interoperate with hosts and routers
routers running MLDv1. The method is the same as described in running MLDv1. The method is the same as described in Section 6.2.
Section 6.2. The difference is that when a LW-MLDv2 router has a The difference is that when an LW-MLDv2 router has a MLDv1 listener
MLDv1 listener on its network, it translates the following MLDv1 on its network, it translates the following MLDv1 messages to their
messages to their LW-MLDv2 equivalents: LW-MLDv2 equivalents:
MLDv1 Message LW-MLDv2 Equivalent MLDv1 Message LW-MLDv2 Equivalent
------------- ------------------- ------------- -------------------
Report TO_EX({}) Report TO_EX({})
Done TO_IN({}) Done TO_IN({})
7. Implementation Considerations 7. Implementation Considerations
The lightweight protocols require no additional procedure on the The lightweight protocols require no additional procedure for 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/MLDv2 (snooping) and multicast routing protocols may run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be
be greatly decreased. greatly decreased.
In the following sections, the implementation related aspects are
described for the lightweight version protocols.
7.1. Implementation of Source-Specific Multicast 7.1. Implementation of Source-Specific Multicast
[8] illustrates the requirements of implementation of Source-Specific [8] specifies the requirements for the implementation of Source-
Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The
protocol follows the same rule given in [8] except the changing of lightweight protocol follows the same rules as given in [8] except
the message types due to the simplification. for the change of the message types due to the simplification.
A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., An LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e.,
TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for the application TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for applications whose
whose multicast address is in the SSM address range. The upstream multicast addresses are in the SSM address range. An upstream LW-
LW-IGMPv3/LW-MLDv2 router will ignore the these messages and may log IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state and MAY
an error on reception of them. Other types of messages should be log an error on reception of them as described in [7].
processed as [8] describes.
7.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 [9] defines the following Multicast Source Filter (MSF) APIs: (1)
API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-
API, and (4) Protocol-Independent Advanced MSF API. Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF
APIs.
According to the MSF APIs definition, a LW-IGMPv3 host should According to the MSF API definition, an LW-IGMPv3 host should
implement either IPv4 Basic MSF API or Protocol-Independent Basic MSF implement either the IPv4 Basic MSF API or the Protocol-Independent
API, and a LW-MLDv2 host should implement Protocol-Independent Basic Basic MSF API, and an LW-MLDv2 host should implement the Protocol-
MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and
Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2 Protocol-Independent Advanced MSF API, are optional to implement in
host. an LW-IGMPv3/LW-MLDv2 host.
8. 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.
9. Acknowledgements 9. Acknowledgements
The authors would like to appreciate MBONED and MAGMA working group The authors would like to thank MBONED and MAGMA working group
members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark
Fine, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang
Gong Xiangyang for their valuable comments and suggestions on this Wendong, and Gong Xiangyang for their valuable suggestions and
document. comments on this document.
10. References 10. References
10.1. Normative References 10.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", BCP 14, 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.
[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [4] Deering, S., "Host extensions for IP multicasting", STD 5,
August 1989. RFC 1112, August 1989.
[5] Fenner, W., "Internet Group Management Protocol, Version 2", [5] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997. RFC 2236, November 1997.
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
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.
skipping to change at page 23, line 14 skipping to change at page 17, line 31
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.
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
Keio University Keio University
Graduate School of Media and Governance Graduate School of Media and Governance
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Email: asaeda@wide.ad.jp EMail: asaeda@wide.ad.jp
 End of changes. 110 change blocks. 
290 lines changed or deleted 291 lines changed or added

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