draft-ietf-mboned-lightweight-igmpv3-mldv2-02.txt   draft-ietf-mboned-lightweight-igmpv3-mldv2-03.txt 
MBONED Working Group H. Liu MBONED Working Group H. Liu
Internet-Draft W. Cao Internet-Draft W. Cao
Expires: May 22, 2008 Huawei Technologies Co., Ltd. Expires: December 7, 2008 Huawei Technologies Co., Ltd.
H. Asaeda H. Asaeda
Keio University Keio University
November 19, 2007 June 5, 2008
Lightweight IGMPv3 and MLDv2 Protocols Lightweight IGMPv3 and MLDv2 Protocols
draft-ietf-mboned-lightweight-igmpv3-mldv2-02 draft-ietf-mboned-lightweight-igmpv3-mldv2-03
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 May 22, 2008. This Internet-Draft will expire on December 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes lightweight IGMPv3 and MLDv2 protocols (LW- This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
IGMPv3 and MLDv2. The interoperability with the full versions and IGMPv3 and MLDv2. The interoperability with the full versions and
the previous versions of IGMP and MLD is also taken into account. the previous versions of IGMP and MLD is also taken into account.
Conventions used in this document Conventions used in this document
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7
4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9
4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9
4.2. Action on Change of Interface State . . . . . . . . . . . 9 4.2. Action on Change of Interface State . . . . . . . . . . . 9
4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10
4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10
5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12
5.1. Group Timers and Source Timers in the Lightweight 5.1. Group Timers and Source Timers in the Lightweight
Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13
5.3. Reception of LW-IGMPv3 Group Records . . . . . . . . . . . 13 5.3. Reception of Current-State Records . . . . . . . . . . . . 13
5.4. Reception of Source-List-Change and Filter-Mode-Change
Records . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16
6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 16
6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 16
6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16
6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16
6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17
6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 18 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 17
7. Implementation Considerations . . . . . . . . . . . . . . . . 19 7. Implementation Considerations . . . . . . . . . . . . . . . . 19
7.1. Implementation of Source-Specific Multicast . . . . . . . 19 7.1. Implementation of Source-Specific Multicast . . . . . . . 19
7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 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 which are of interest or which are
of not interested for a particular multicast address. This formation of not interested for a particular multicast address. This
is used during forwarding of multicast data packets. information 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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 with the full version for INCLUDE (S,G) join, while
EXCLUDE mode on the host part is preserved only for excluding null EXCLUDE mode on the host part is preserved only for excluding null
source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/ source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/
MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is
described in Section 4. described in Section 4.
3.2. Behavior of Multicast Routers 3.2. Behavior of Multicast Routers
Router filter-mode is defined to optimize the state description of a In IGMPv3, router filter-mode is defined to optimize the state
group membership [2][3]. As a rule, once a member report is in description of a group membership [2][3]. As a rule, once a member
EXCLUDE mode, the router filter-mode for the group will be set to report is in EXCLUDE mode, the router filter-mode for the group will
EXCLUDE. When all systems cease sending EXCLUDE mode reports, the be set to EXCLUDE. When all systems cease sending EXCLUDE mode
filter-mode for that group may transit back to INCLUDE mode. Group reports, the filter-mode for that group may transit back to INCLUDE
timer is used to identify such transition. mode. Group timer is used to identify such 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 EXLUDE (*,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 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 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
skipping to change at page 9, line 49 skipping to change at page 9, line 49
----------- ----------- ------------------------ ----------- ----------- ------------------------
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 As in the full version, to cover the possibility of the State-Change
one or more multicast routers, it is retransmitted [Robustness Report being missed by one or more multicast routers, it is
Variable]-1 more times, at intervals chosen at random from the range retransmitted [Robustness Variable]-1 more times, at intervals chosen
(0, [Unsolicited Report Interval]). (These values are defined in at random from the range (0, [Unsolicited Report Interval]). (These
[2][3].) values are defined in [2][3].)
4.3. Action on Reception of a Query 4.3. Action on Reception of a Query
When a lightweight version host receives a Query, it does not respond As in the full version, when a lightweight version host receives a
immediately. Instead, it delays its response by a random amount of Query, it does not respond immediately. Instead, it delays its
time, bounded by the Max Resp Time value derived from the Max Resp response by a random amount of time, bounded by the Max Resp Time
Code in the received Query message [2][3]. The system may receive a value derived from the Max Resp Code in the received Query message
variety of Queries on different interfaces and of different kinds [2][3]. The system may receive a variety of Queries on different
(e.g., General Queries, Group-Specific Queries, and Group-and-Source- interfaces and of different kinds (e.g., General Queries, Group-
Specific Queries), each of which may require its own delayed Specific Queries, and Group-and-Source-Specific Queries), each of
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.
skipping to change at page 11, line 6 skipping to change at page 11, line 6
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 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
skipping to change at page 11, line 48 skipping to change at page 11, line 48
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
working on the lightweight version host, the host sends a report with keeps working on the lightweight version host, the host sends a
TO_IN(x) record type for [Robustness Variable] times. report with TO_IN(x) record type for [Robustness Variable] times.
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 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.
5.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 In lightweight and full IGMPv3 routers, a source timer is kept for
the source is present in a received report. It indicates the each source record and it is updated when the source is present in a
validity of the sources and needs to be referred when the router received report. It indicates the validity of the sources and needs
takes its forwarding decision. to be referred 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 states maintaining 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. The role of the group timer
can be summarized as follows: can be summarized as follows:
Group Timer Value Actions/Comments Group Timer Value Actions/Comments
------------------ -------------------------------------- ------------------ --------------------------------------
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
5.3. Reception of LW-IGMPv3 Group Records 5.3. Reception of Current-State Records
On receiving LW-IGMPv3 group records, the LW-IGMPv3 router must act When receiving Current-State Records, the LW-IGMPv3 router resets its
upon these records and possible change their own states to reflect group or source timers and updates its source list within the group.
the new desired membership state of the network. 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.
Lightweight routers query sources that are requested to be no longer Although the LW-IGMPv3 host only sends a subset of the message of
forwarded to a group. When a router queries or receives a query for that of the full version, the LW-IGMPv3 router should be able to
a specific set of sources, it lowers its source timers for those process as much messages as possible to be compatible with the full
sources to a small interval of Last Member Query Time seconds. If version host. Note that if the report type is IS_EX(x) with non-
group records are received in response to the queries which express empty source-list, the router will treat it as the same type of
interest in receiving traffic from the queried sources, the report with empty source list. The following table describes the
corresponding timers are updated. action taken by a multicast router after receiving Current-State
Records. The notations have the same meaning as that in the full
IGMPv3 protocol.
Similarly, when a router queries a specific group, it lowers its Old New
group timer for that group to a small interval of Last Member Query Source Source
Time seconds. If TO_EX({}) group records are received within the Group Timer List Report Rec'd List Actions
interval, the group timer for the group is updated and the suggestion ------------ ------ ------------ ------ -----------
to the routing protocol to forward the group stands without any
interruption.
During a query period (i.e., Last Member Query Time seconds), the G_Timer == 0 A IS_IN(B) A+B (B)=GMI
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.
The following table describes the changes in group state and the G_Timer == 0 A IS_EX({}) A G_Timer=GMI
action(s) taken when receiving LW-IGMPV3 Group Record. This table
also describes the queries which are sent by the Querier when a G_Timer > 0 A IS_IN(B) A+B (B)=GMI
particular report is received. The notation in the table has the
same meaning as the full version defines [2][3]: 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
A IS_EX({}) A G_Timer=GMI
Without EXCLUDE filter-mode, a router's process on receiving Current-
State Record is simple: when a router receives an IS_IN report, it
appends the reported source addresses to the previous source list
with their source timers set to GMI. Upon receiving an IS_EX({})
report, the router sets the non-source-specific receiving states by
resetting the group timer value and keeps the previous source list
without modification.
5.4. Reception of Source-List-Change and Filter-Mode-Change Records
On receiving Source-List-Change and Filter-Mode-Change Records, the
LW-IGMPv3 router needs to reset its group and source timers, update
its source list within the group, or trigger group queries. The
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
TO_EX(x) with non-empty source-list, the router will treat it as the
same type of report with empty source list. The table below
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)
G_Timer == 0 A TO_EX({}) A G_Timer=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 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)
Send Q(G) Send Q(G)
G_Timer >= 0 A TO_EX({}) A (B)=GMI G_Timer > 0 A TO_EX({}) A G_Timer=GMI
In order to maintain protocol robustness, queries sent by actions in The table could be further simplified by merging duplicate lines:
the table need to be transmitted [Last Member Query Count] times,
once every [Last Member Query Interval] (These values are defined in
[2][3]).
If while scheduling new queries, there are already pending queries to Old New
be retransmitted for the same group, the new and pending queries have Source Source
to be merged. In addition, received host reports for a group with List Report Rec'd List Actions
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].
The method which a lightweight router uses to build and send queries, A ALLOW(B) A+B (B)=GMI
and the actions the router should take on receiving Queries from
other routers are completely the same as that of full version. The A BLOCK(B) A Send Q(G,A*B)
detailed description is described in [2][3].
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_EX({}) A G_Timer=GMI
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 format
of the group query and report messages the full version protocols of the group query and report messages the full version protocols
use. The LW-IGMPv3 group member sends a subset of IGMPv3 report use.
messages, which can be recognized by a multicast router running the
full or the lightweight IGMPv3 protocol on the same LAN.
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:
IGMPv3/MLDv2 Report LW-IGMPv3/LW-MLDv2 Equivalent 6.1.1. Behavior of Group Members
------------------- -----------------------------
IS_IN(x) ALLOW(x) A LW-IGMPv3 host's compatibility mode is determined from the Host
Compatibility Mode variable which can be in one of three states:
IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its
interface as LW-IGMPv3, its Host Compatibility Mode of that interface
is set to IGMPv3, and the host 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. The
lightweight host's processing rule in presence of older version
Queriers should be the same as that of full IGMPv3.
IS_EX(x) TO_EX({}) 6.1.2. Behavior of Multicast Routers
TO_EX(x) IS_EX() A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and
TO_EX(x) 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 IS_EX({}) and
TO_EX({}) respectively and behaves accordingly.
6.2. Interoperation with IGMPv1/IGMPv2 6.2. Interoperation with IGMPv1/IGMPv2
Since the lightweight protocols can be treated as the parallel
version of full version of IGMPv3/MLDv2, its compatibility principle
and method with the older version are generally the same as that of
full IGMPv3/MLDv2.
6.2.1. Behavior of Group Members 6.2.1. Behavior of Group Members
A host's compatibility mode is determined from the Host Compatibility The Host Compatibility Mode of an interface is set to IGMPv2 and its
Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv2 Querier Present timer is set to Older Version Querier Present
IGMPv3. The Host Compatibility Mode of an interface is set to IGMPv2 Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is
and its IGMPv2 Querier Present timer is set to Older Version Querier received on that interface. The Host Compatibility Mode of an
Present Timeout seconds (defined in [2]) whenever an IGMPv2 General interface is set to IGMPv1 and its IGMPv1 Querier Present timer is
Query is received on that interface. The Host Compatibility Mode of
an 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. Based on the IGMPv1 Membership Query is received on that interface.
Host Compatibility Mode variable, a host acts using the IGMPv3,
IGMPv2, or IGMPv1 protocol 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
If a LW-IGMPv3 router is on a network where at least one router The behavior of a LW-IGMPv3 router when placed on a network where
running IGMPv1 or IGMPv2 protocols, it is required that the lowest there are routers that have not been upgraded to IGMPv3, is
version of Querier must be used. This can be administratively completely the same with a full IGMPv3 router in this situation [2].
assured by supporting IGMPv1, IGMPv2 or IGMPv3 compatibility mode.
If a router is not explicitly configured to use IGMPv1 or IGMPv2 and
hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a
warning. These warnings MUST be rate-limited. When in IGMPv1 mode,
routers MUST send periodic IGMPv1 Queries and MUST ignore Leave Group
messages. They SHOULD also warn about receiving an IGMPv2 or IGMPv3
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).
If an LW-IGMPv3 router is placed on a network where there are hosts
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 A full IGMPv3 router uses Group Compatibility Mode (whose value is
older version report (than the current compatibility mode) is heard either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate
or when certain timer conditions occur. When the IGMPv1 Host Present which version of IGMP protocol it behaves for the group. This value
timer expires, the LW-IGMPv3 router switches to Group Compatibility is set according to the version of the received IGMP report. When
mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it Group Compatibility Mode is IGMPv3, the lightweight router acts with
does not have a running IGMPv2 Host Present timer then it switches to LW-IGMPv3 protocol for that group.
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 When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits
internally translates the following IGMPv2 messages for that group to this compatibility mechanism with the following rules:
their LW-IGMPv3 equivalents:
IGMPv2 Message LW-IGMPv3 Equivalent IGMPv2 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, a LW-IGMPv3 router
internally translates the following IGMPv1 and IGMPv2 messages for internally translates the following IGMPv1 and IGMPv2 messages for
skipping to change at page 19, line 25 skipping to change at page 19, line 25
described for the lightweight version protocols. 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] 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 invoke a (*,G) join, i.e., A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e.,
TO_EX({}), and IGMPv2 Leave and MLDv1 Done messages for the TO_EX({})) and IGMPv2 Leave and MLDv1 Done messages (i.e., TO_IN({}))
application whose multicast address is in the SSM address range. The for the application whose multicast address is in the SSM address
reception of a (*,G) join with an SSM group address should indicate range. The reception of a (*,G) join with an SSM group address
an error to the application. The SSM-aware router will ignore should indicate an error to the application. The SSM-aware router
TO_EX({}) reports with SSM addresses. Other types of Reports should will ignore TO_EX({}) reports with SSM addresses. Other types of
be processed normally. Reports should be processed normally.
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 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 either IPv4 Basic MSF API or Protocol-Independent Basic MSF
Basic MSF API, and a LW-MLDv2 host should implement Protocol- API, and a LW-MLDv2 host should implement Protocol-Independent Basic
Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent
Protocol-Independent Advanced MSF API, are optional to implement in Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2
LW-IGMPv3/LW-MLDv2 host. 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. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 21, line 23 skipping to change at page 21, line 23
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", RFC 1112,
August 1989. August 1989.
[5] Fenner, W., "Internet Group Management Protocol, Version 2", [5] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2373, July 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.
[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
skipping to change at page 23, line 7 skipping to change at page 23, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 23, line 44 skipping to change at line 804
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 45 change blocks. 
163 lines changed or deleted 174 lines changed or added

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