wdiff draft-liu-magma-igmpv3-mldv2-lite-01.txt draft-liu-magma-igmpv3-mldv2-lite-02.txt

MAGMA Hui Working Group H. Liu
Internet Draft wei cao
Internet-Draft W. Cao
Expires: December 2006 April, 2007 Huawei Technologies Co.,Ltd.
June 26, Co., Ltd.
H. Asaeda
Keio University
October 14, 2006

Simplifying Process for IGMPv3 and MLDv2 Protocols
draft-liu-magma-igmpv3-mldv2-lite-01.txt
<draft-liu-magma-igmpv3-mldv2-lite-02.txt>

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html

This Internet-Draft will expire on December 26, 2006.

Abstract

This document suggests a simplifying implementation for proposes simplified IGMPv3 and MLDv2 protocols, which is
are called IGMPv3-lite or and MLDv2-lite. The interoperability with
other versions of IGMP and MLD is also considered.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-
2119[KEYWORDS]. RFC 2119
[KEYWORDS].

Table of Contents

1. Introduction................................................2 Introduction ................................................... 2
2. Simplification Method overview...............................3 Overview ................................. 3
2.1. Behavior of Group Members...............................4 Members ................................. 3
2.2. Behavior of Multicast Routers...........................4 Routers ............................. 4
3. IGMPv3-lite protocol Protocol for Group Members.......................5 Members ......................... 4
3.1. Group Record Types......................................5
3.2. Action on Change of Interface State.....................5 State ....................... 5
3.2. Action on Reception of a Query ............................ 5
3.3. Group Record Types ........................................ 6
4. IGMPv3-lite protocol Protocol for Multicast Routers...................5 Routers ..................... 7
4.1. Group timers Timers and source timers Source Timers in lite version...........5 the Lite Version ........ 8
4.2. Source-Specific Forwarding Rules........................6 Rules .......................... 9
4.3. Reception of Current-State Records......................6 Records ........................ 9
4.4. Reception of Source-List-Change and
Filter-Mode-Change
Records.....................................................7 Records ............................... 10
5. Interoperability............................................8 Interoperability .............................................. 11
5.1. Interoperation with IGMPv1/IGMPv2.......................9 IGMPv1/IGMPv2 ........................ 11
5.2. Interoperation with full IGMPv3.........................9 the Full Version of IGMPv3 ........... 12
6. Affects to other protocols..................................10 Implementation Considerations ................................. 12
6.1. Implementation of Source-Specific Multicast .............. 12
6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 13
7. Security Considerations.....................................10 Considerations ....................................... 13
8. References.................................................10
Author's Addressess...........................................10 Normative References .......................................... 13
9. Informative References ........................................ 13
Intellectual Property Statement................................10 Statement .................................. 14
Disclaimer of Validity........................................11 Validity ........................................... 14
Copyright Statement...........................................11
Acknowledgment................................................11 Statement .............................................. 15
Acknowledgment ................................................... 15

1. Introduction

The purpose of this draft is to suggest the simplification of

IGMPv3 [IGMPv3] and MLDv2 [MLDv2] protocols.

IGMPv3 and MLDv2 implement source filtering
capability compared to their earlier versions IGMPv2 and MLDv1, i.e.,
the end host not only tells which group it would like to join, but
also specifies which sources it does or does not intend to receive
multicast traffic from. Filter-modes are defined for the end hosts
and router parts of the protocols respectively.

If a receiver on a host wants to receive from specific sources, it'll
send it sends
an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. On the
other hand if the host does not need want to receive from some sources,
the filter-mode of it
sends the report should be with filter-mode set to EXCLUDE. A source list for
the given sources shall be included in the report message.

Filter mode

INCLUDE and EXCLUDE filter modes are also defined in the a multicast
router to process the IGMPv3 or MLDv2 reports appropriately. And
group reports. Group timer and source
timer are maintained. The used to maintain forwarding state of desired group and
source. A multicast router decides its filter-mode, type type, and value
of the timers and forwarding methods according to the specific rules
when a group report message arrives or timer expires, and the expires. The router then
has to switch its filter-mode under certain conditions. All above
factors correlated with each other, while the determination rule is
relatively complex as the receiving state changes. could be frequently
changed.

The introduction of multicast filter-mode improves the expressing ability of the
multicast receiver. And it It is very useful in to support of SSM
(which making use of Source-Specific Multicast
(SSM) [SSM] by specifying interesting source addresses with INCLUDE mode). But in
mode. However, practical applications,
EXCLUDE <S,G> mode(which means blocking some sources) is applications do not used use EXCLUDE mode to
block sources so often, because the scenario is rare that a user is unwilling or application usually wants
to specify desired source addresses, not undesired source addresses
to not receive from some sources. them. Even if such application exists, it is
possible that a user wants to explicitly refuse
traffic from some sources in a group, when other users in the same
shared network have interest in these sources. Then sources, the corresponding
multicast traffic has to be forwarded down
either. Then it can not be guaranteed that undesired traffic not
received. Thus in most applications, excluding specific sources does
not seem a useful implementation.

In many applications, it is enough forwarded to implement part of IGMPv3/MLDv2
without EXCLUDE<S,G> mode. Considering the limited effects of EXCLUDE
<S,G> filter-mode, and the complicacy of network after all.

This document aims to propose the operation introduced by
it, it is suggested simplified IGMPv3 and MLDv2
(referred to as IGMPv3-lite and MLDv2-lite) in this draft that the function of which EXCLUDE filter
mode that supports to exclude data come from specified sources is simplified. The protocol operation would be greatly reduced as a
result.

The elimination of the EXCLUDE <S,G> mode does not
eliminated. Not only simplify IGMPv3-lite and MLDv2-lite are compatible with
the
process of IGMPv3/MLDv2 hosts standard IGMPv3 and routers, MLDv2, but also reduces the
complexity protocol operations made
by data receiver hosts and routers or switches (performing
IGMPv3/MLDv2 snooping) are simplified in the lite version protocol
and complicated operations are hence effectively reduced. Since
IGMPv3-lite and MLDv2-lite are fully compatible with the full version
of related these protocols realization on other equipments(e.g.,
switches (i.e. the standard IGMPv3 and MLDv2), hosts or
routers that perform IGMPv3/MLDv2 snooping). have implemented the full version do not need to
implement or modify anything to cooperate with IGMPv3/MLDv2-lite
hosts or routers.

2. Simplification Method overview Overview

The simplifying principle is to simplify the host and router parts as much as
possible to improve efficiency, while guaranteeing the
interoperability with full versions, and introducing no side effects
on the applications.

For convenience, we just mention IGMPv3, because this document mainly discusses IGMPv3 since MLDv2
inherits the same source filtering
mechanism is the same for the two protocols. mechanism, but additionally shows
MLDv2's unique specifications when needed.

2.1. Behavior of Group Members
In this method, we take the IGMPv3-lite, the same service interface model as that of
IGMPv3 [IGMPv3]: [IGMPv3] is inherited:

IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list) source-list )

In the lite version protocol, EXCLUDE mode on the host part is
preserved only for
the expression of non-source-specific group EXCLUDE (*,G) join, which denotes non-source-
specific group report (as known as (*,G) join) and is equivalent to IGMPv2/IGMPv1/MLDv1 join. It is denoted as
EXCLUDE<NULL> in this draft.
the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The
detailed host operation of IGMPv3-
lite IGMPv3/MLDv2-lite is described in section
3.

2.2. Behavior of Multicast Routers

According to [IGMPv3], the filter-mode of the router is defined to
optimize the state description of a group. As a rule, once a member
report is in EXCLUDE mode, the router filter-mode for the group will
be set to EXCLUDE. Otherwise when all systems with a group record in
EXCLUDE mode for that group cease reporting, the router's filter-mode
may transit back to INCLUDE mode. Group timer is used to identify
such transition.

In IGMPv3-lite, member reports carry mainly the INCLUDE mode
information with only one exception for EXCLUDE<NULL>, EXCLUDE (*,G), which can be
interpreted as means
including all sources and can also be interpreted as well. INCLUDE mode.
Without EXCLUDE mode
group report information, it is unnecessary for the
router to maintain the EXCLUDE filter-mode. With INLCUDE filter-mode as a default processing
mode, filter-mode, and the state model for
multicast router can be simplified as:

(multicast address, group timer,(source timer, (source records))

Here group timer is kept to represent ASM group. (*,G) group join. Its basic
behavior is: when a router receives an ASM a (*,G) group join, it will set
its group timer, and the source list for the SSM source-specific group
will be kept. As the group timer expires, the router may change to
the reception for the listed sources.

The elimination of the filter-mode will greatly simplify the router
behavior, e.g. the action on reception of reports and the setting of
the timers. The detailed operation of router operation is described
in section 4.

3. IGMPv3-lite protocol Protocol for Group Members

IGMPv3-lite uses two sets of messages, i.e., Query messages and
Report messages the same as the full version protocols. Although
most of these message types and corresponding group records are
inherited from the full version protocols, an operation that triggers
EXCLUDE (S,G) join is omitted and the corresponding record types of
the Report are modified on the lite version protocols.

3.1. Action on Change of Interface State

When an interface state of a group member host is changed, a State-
Change Report for that interface is immediately transmitted from that
interface. The type and contents of the Group Record(s) in that
Report are determined by comparing the filter mode and source list
for the affected multicast address before and after the change. While
the requirements are the same as the full version for the
computation, in the lite version host, the interface state change
rules are simplified due to the reduction of message types. The
contents of the new transmitted report are calculated as described in
section 3.3.

To cover the possibility of the State-Change Report being missed by
one or more multicast routers, it is retransmitted [Robustness
Variable]-1 more times, at intervals chosen at random from the range
(0, [Unsolicited Report Interval]). (These values are defined in
[IGMPv3, MLDv2].)

In the full version of IGMPv3, as was done with the first report, the
interface state for the affected group before and after the latest
change is compared, and the report records expressing the difference
are built and merged with the contents of the pending report, to
create the new State-Change report. However, it is optional that an
IGMPv3-lite host merges with the contents of the pending report. If
the IGMPv3-lite host does not merge with the contents of the pending
report, it transmits each report sequentially. Doing so can greatly
simplified the operation for scheduling the reports.

3.2. Action on Reception of a Query

When a lite version host receives a Query, it does not respond
immediately. Instead, it delays its 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 [IGMPv3, MLDv2]. The system may
receive a variety of Queries on different interfaces and of different
kinds (e.g., General Queries, Group-Specific Queries, and Group-and-
Source-Specific Queries), each of which may require its own delayed
response.

Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the lite version host must
be able to maintain the following state:

o A timer per interface for scheduling responses to General Queries.

o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.

o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.

IGMPv3-lite inherits most of the rules that are used to determine if
a Report needs to be scheduled from the full version. The different
point is regarding the simplification of EXCLUDE filter-mode and the
type of Report to schedule as detailed in section 3.3.

On the other hand, while it is optional that an IGMPv3-lite host
merges with the contents of the pending report for unsolicited report
(i.e. State-Change report) as mentioned in the previous section, if
the received Query is a Group-and-Source-Specific Query and there is
a pending response for this group with a non-empty source-list, then
the group source list is augmented to contain the list of sources in
the new Query and a single response is scheduled using the group
timer as with the full version host. The new response is then
scheduled to be sent at the earliest of the remaining time for the
pending report and the selected delay.

3.3. Group Record Types

There are three group record types Group Record Types defined in the full IGMPv3:
Current-State Record (taking value of NODE_IS_INCLUDE and
NODE_IS_EXCLUDE), noted by MODE_IS_INCLUDE (referred to as IS_IN)
or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record (CHANGE_TO_INCLUDE_MODE
and CHANGE_TO_EXCLUDE_MODE) noted by
CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and
Source-List-Change Record
(ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES). noted by ALLOW_NEW_SOURCES (ALLOW) or
BLOCK_OLD_SOURCES (BLOCK).

Among these messages, CHANGE_TO_EXCLUDE_MODE is several record types defined in the full IGMPv3
are not used, for used in IGMPv3-lite as some of the
process processes related to it is completely the same as that of
MODE_IS_EXCLUDE. The formats
filter mode change to the EXCLUDE mode are eliminated and some of other five the
report messages are converged with a record having null source
address list. All of the same as
that record types of full IGMPv3. MODE_IS_EXCLUDE is solely report messages used by the
full and lite version protocols are shown as follows:

Full ver. Lite ver. Comments

--------- --------- --------------------------------

IS_EX() IS_EX() Query response for EXCLUDE<NULL>.

3.2. Action on (*,G) join
IS_EX(x) N/A Query response for EX (x,G) join

IS_IN(x) ALLOW(x) Query response for IN (x,G) join

ALLOW(x) ALLOW(x) IN (x,G) join

BLOCK(x) BLOCK(x) IN (x,G) leave

TO_IN(x) TO_IN(x) Change of Interface State

The interface to IN (x,G) join

TO_IN() TO_IN() (*,G) leave

TO_EX(x) N/A Change to EX (x,G) join

TO_EX() IS_EX() (*,G) join

where "x" represents non-null source address list and "()" represents
null source address list. For instance, IS_EX() means a report whose
record type is IS_EX with null source address list. "N/A" represents
not applicable (or no use) because the corresponding operation should
not occur in the lite version protocols.

IGMPv3-lite does not use EXCLUDE filter-mode with non-null source
address list. And a multicast router creates the same state change rules are simplified as when it
receives a report message containing either of IS_EX or TO_EX record
types. Therefore, IGMPv3-lite integrates the elimination TO_EX operation to the
IS_EX operation.

On the other hand, when an IGMPv3-lite version host needs to make a
query response for the state of
EXCLUDE<S,G> mode, which can be expressed by:

Old State New State State-Change Record Sent

--------- --------- ------------------------

INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK(A-B)

INCLUDE (A) EXCLUDE (NULL) IS_EX(NULL) (x,G) join, the host makes
the response whose message type is expressed with ALLOW(x), instead
of using IS_IN record type, for router's processing of the two
messages are completely the same, the IS_IN(x) type is eliminated for
simplification.

An IGMPv3-lite version host does not use EXCLUDE (NULL) mode, while TO_IN
record is used with the following situation; the host firstly
launches an application (AP1) that requests INCLUDE (B) TO_IN(B) (x,G) join, and
it sends ALLOW(x). Then the host launches another application (AP2)
that joins (*,G), and it sends IS_EX(). In this condition, when AP2
terminates but AP1 keeps working on the lite version host, the host
sends a report with TO_IN(x) record type for [Robustness Variable]
times.

4. IGMPv3-lite protocol Protocol for Multicast Routers

4.1. Group timers

The major difference between the full and source timers in lite version

As protocol on
the router is that filter-mode is discarded for the lite version, as
section 2.2 mentioned, it mentioned. Then the IGMP state maintained by the router
for each attached network can be simplified as:

(multicast address, group timer, (source records))

where the source record includes pairs of source address and its
corresponding source timer. The reduction of filtering mode will
change the meaning of the group timer and will simplify the router's
processing.

4.1. Group Timers and Source Timers in the Lite Version

The source timer is possible kept for IGMPv3-lite to discard
filter-mode denotation each source record and it is updated
when the source is present in a received report. It indicates the router.
validity of the sources and needs to be referred when the router
takes its forwarding decision.

The group timer, which being
previously used in full IGMPv3 as a mechanism for
transitioning the router filter-
mode router's filter-mode from EXCLUDE to INCLUDE, now is
now redefined for the transitioning
between identification of the ASM and SSM non-source-specific
receiving state states. Once a group record of IS_EX() is received, the
group timer is used to represent this (*,G) group join. The
expiration of the group timer indicates that there are no listeners
on the router. attached network for this (*,G) group. Then if at this moment
there are unexpired sources (whose source timers are greater than
zero), the router will change to receiving for those sources. The
role of the group timer can be summarized as follows:

Group Timer Value Actions/Comments

------------------ ----------------- --------------------------------------

G_Timer > 0 All members in this group.

G_Timer == 0 No more listeners to this ASM (*,G) group.
If all source timers have expired then
delete group record. If there are
still source record timers running,
use those source records with running
timers as the source record state.

The operation related to the group and source timers is different has some
difference compared to with the full IGMPv3. In the full version, if a
source timer expires under the EXCLUDE router filter-mode, its
corresponding source record is not deleted until the group timer
expires. They are kept for indicating undesired sources. In the lite
version, since there is no need to keep such records for blocking
specific sources, if a source timer expires, its source record should
be deleted immediately, not waiting for the time-out of the group
timer.

4.2. Source-Specific Forwarding Rules

The forwarding rules depend on group and source timer values. Now
they can be expressed suggestion made by igmpv3-lite to the routing
protocols is as follows:

Group Timer Source Timer Action

-----------

------------ ------------------ ---------------------- -----------------------

G_Timer == 0 S_TIMER > 0 Suggest to forward
traffic from source

G_Timer == 0 S_TIMER == 0 Suggest to stop
forwarding traffic from
source and remove
source record. If there
are no more source
records for the group,
delete group record. record

G_Timer == 0 No Source Elements Suggest not to forward
traffic from the source

G_Timer > 0 S_TIMER >= 0 Suggest to forward
traffic from source

G_Timer > 0 No Source Elements Suggest to forward
traffic from source

4.3. Reception of Current-State Records

When receiving Current-State Records, the IGMPv3-lite router needs
reset resets
its group or source timers, timers and update updates its source list within the
group. In SSM For source-specific group (G_Timer==0), reception state(G_Timer==0), the
source list includes sources to be forwarded by the router, while in ASM
non-source-specific group (G_Timer >0) reception(G_Timer>0) the source list
remembers the sources to be forwarded after switching
back toggling to SSM mode. source-
specific reception state.

Old New
Source new Source
Group Timer list List Report Rec'd list List Actions

----------- ------ ------------ ------- ---------

G_Timer==0 -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI

G_Timer==0

G_Timer == 0 A IS_EX(NULL) IS_EX() A G_Timer= GMI G_Timer=GMI

G_Timer >0 > 0 A IS_IN(B) A+B (B)=GMI

G_Timer >0 > 0 A IS_EX(NULL) IS_EX() A G_Timer = GMI G_Timer=GMI

And the above table could be further simplified for the processes are
completely the same for the two values of the G-Timer: G_Timer:

Old New
Source new Source

list
List Report Rec'd list List Actions

------ ------------ ------- --------- ------------

A IS_IN(B) A+B (B)=GMI

A IS_EX(NULL) IS_EX() A G_Timer= GMI G_Timer=GMI

4.4. Reception of Source-List-Change and Filter-Mode-Change Records

On receiving Source-List-Change Records, the IGMPv3-lite router needs
to reset its group and source timers, update its source list within
the group, or trigger group queries.

Old New
Source new Source
Group Timer list List Report Rec'd list List Actions

-----------

------------ ------ ------------ ------- ---------

G_Timer==0 -------------

G_Timer == 0 A ALLOW(B) A+B (B)=GMI

G_Timer==0

G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer==0

G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)

G_Timer >0 > 0 A ALLOW(B) A+B (B)=GMI

G_Timer >0 > 0 A BLOCK(B) A Send Q(G,A*B)

G_Timer >0 > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)

The table could be further simplified by merging duplicate lines:

Old New
Source new Source

list
List Report Rec'd list List Actions

------ ------------ ------- --------- ----------------------

A ALLOW(B) A+B (B)=GMI

A BLOCK(B) A Send Q(G,A*B)

A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)

5. Interoperability

IGMPv3-lite hosts and routers should interoperate gracefully with
IGMPv3/MLDv2-lite hosts and routers should interoperate gracefully
with hosts and routers that running IGMPv1/IGMPv2/IGMPv3. IGMPv1/v2/v3 or MLDv1/v2.

The simplification in IGMPv3-lite introduces no changes on the
message format of the group query and report. The member sends a
subset of IGMPv3 reports, which can be recognized by full IGMPv3
protocols.

The discard of the filter-mode on the router just simplified the
processing inside the router, not influencing the outside behavior of
the protocol.

From above discussion, IGMPv3-lite IGMPv3/MLDv2-lite can be treated as a ''parallel
version''
"parallel version" of the full IGMPv3. IGMPv3/MLDv2. Its interoperability
method with lower versions (i.e. IGMPv1 IGMPv1/v2 and IGMPv2) MLDv1) should be the
same as that of the IGMPv3 and MLDv2.

5.1. Interoperation with IGMPv1/IGMPv2

IGMPv3-lite protocol adopts the same Host/Group Compatibility Mode
and keeps Querier Present timers for IGMPv1 and IGMPv2. Their
definition and processing is just the same as [IGMPv3].

When Group Compatibility mode is IGMPv2 or IGMPv1, an IGMPv3-lite
router translates the following IGMPv2 or IGMPv1 messages for that
group to their IGMPv2 or IGMPv1 equivalents, as following:

IGMP Message IGMPv3 lite IGMPv3-lite Equivalent
-------------- ----------------- ----------------------

v1 Report IS_EX(NULL) IS_EX()

v2 Report IS_EX(NULL) IS_EX()

v2 Leave TO_IN(NULL) TO_IN()

5.2. Interoperation with full the Full Version of IGMPv3

If an IGMPv3-lite router receives reports from the full IGMPv3 host,
it should treat the messages as follows:

IGMPv3 Report IGMPv3-lite Equivalent

-------------- ----------------- ----------------------

IS_IN(x) IS_IN(x)

IS_EX(x) IS_EX(NULL) IS_EX()

TO_IN(x) TO_IN(x)

TO_EX(x) IS_EX(NULL) IS_EX()

ALLOW(x) ALLOW(x)

BLOCK(x) BLOCK(x)

6. Affects to other protocols Implementation Considerations

The simplified protocols put no additional burden on the
implementation of other related protocols, e.g. IGMP/MLD snooping,
multicast routing protocol and operation of application sockets. On
the other hand, the processing load loads on the switches and routers that
running IGMPv3 (snooping) and multicast routing protocols will be
greatly decreased.

In the following sections, the protocols related to the
implementation of IGMPv3/MLDv2 are restated for the lite version.

6.1. Implementation of Source-Specific Multicast

RFC [IGMP-SSM] illustrates the requirements of implementation of
Source-Specific Multicast on IGMPv3/MLDv2 hosts and routers. The lite
protocol does not impose any bad influences on SSM application. The
requirements of IGMPV3/MLDv2-lite for support of SSM are illustrated
below.

For an SSM-aware host, the application should not send a non-source-
specific join, i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages
for the SSM address. The reception of a non-source-specific join with
an SSM group address should indicate an error to the application. The
SSM-aware router will ignore IS_EX() reports with SSM addresses.
Other types of Reports should be processed normally.

6.2. Implementation of Multicast Source Filter (MSF) APIs

Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF
API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF
API, and (4) Protocol-Independent Advanced MSF API.

According to the MSF APIs definition, an IGMPv3-lite version host
should implement IPv4 Basic MSF API and an MLDv2-lite version host
should implement Protocol-Independent Basic MSF API. Other APIs, IPv4
Advanced MSF API and Protocol-Independent Advanced MSF API, are
optional to implement in IGMPv3/MLDv2-lite version host.

7. Security Considerations

The security consideration is the same as that of the original full version of
IGMPv3/MLDv2.

8 Normative References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate
requirement levels," RFC 2119, March 1997.

9 Informative References

[SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP,"
RFC 4607, August 2006.

[IGMPv3] Cain, B.,"Internet Group Management Protocol, Version3",
RFC3376, Version3," RFC
3376, October 2002.

[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version
2 (MLDv2) for IPv6", RFC3810, IPv6," RFC 3810, June 2004.

[IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific
Multicast," RFC 4604, August 2006.

[MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface
Extensions for Multicast Source Filters," RFC 3678, January 2004.

Author's Addressess

Hui Liu
Huawei Technologies Co., Ltd
Email: Liuhui47967@huawei.com

Wei Cao
Huawei Technologies Co., Ltd
Email: caowayne@huawei.com

Hitoshi Asaeda
Keio University
Email: asaeda@wide.ad.jp

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf
ipr@ietf.org.

Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

Acknowledgment

The author would like to thank magma and mboned mailing lists for
discussion and contribution for the ideas.