draft-ietf-mboned-lightweight-igmpv3-mldv2-05.txt   draft-ietf-mboned-lightweight-igmpv3-mldv2-06.txt 
MBONED Working Group H. Liu MBONED Working Group H. Liu
Internet-Draft W. Cao Internet-Draft W. Cao
Intended status: BCP Huawei Technologies Co., Ltd. Intended status: Standards Track Huawei Technologies
Expires: November 23, 2009 H. Asaeda Expires: April 17, 2010 H. Asaeda
Keio University Keio University
May 22, 2009 October 14, 2009
Lightweight IGMPv3 and MLDv2 Protocols Lightweight IGMPv3 and MLDv2 Protocols
draft-ietf-mboned-lightweight-igmpv3-mldv2-05 draft-ietf-mboned-lightweight-igmpv3-mldv2-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 November 23, 2009. This Internet-Draft will expire on April 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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
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 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Simplification Method Overview . . . . . . . . . . . . . . . . 8 3. Simplification Method Overview . . . . . . . . . . . . . . . . 7
3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 8 3.1. Behavior of Group Members . . . . . . . . . . . . . . . . 7
3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 8 3.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 7
4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 10 4. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 9
4.1. Query and Report Messages . . . . . . . . . . . . . . . . 10 4.1. Query and Report Messages . . . . . . . . . . . . . . . . 9
4.2. Action on Change of Interface State . . . . . . . . . . . 10 4.2. Action on Change of Interface State . . . . . . . . . . . 9
4.3. Action on Reception of a Query . . . . . . . . . . . . . . 11 4.3. Action on Reception of a Query . . . . . . . . . . . . . . 10
4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 11 4.4. LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10
5. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 Version . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 14 5.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13
5.3. Reception of Current-State Records . . . . . . . . . . . . 14 5.3. Reception of Current-State Records . . . . . . . . . . . . 13
5.4. Reception of Source-List-Change and Filter-Mode-Change 5.4. Reception of Source-List-Change and Filter-Mode-Change
Records . . . . . . . . . . . . . . . . . . . . . . . . . 15 Records . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 17 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 17 6.1. Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16
6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 17 6.1.1. Behavior of Group Members . . . . . . . . . . . . . . 16
6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 6.1.2. Behavior of Multicast Routers . . . . . . . . . . . . 16
6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 17 6.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16
6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 17 6.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16
6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 18 6.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17
6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 18 6.3. Interoperation with MLDv1 . . . . . . . . . . . . . . . . 17
7. Implementation Considerations . . . . . . . . . . . . . . . . 20 7. Implementation Considerations . . . . . . . . . . . . . . . . 19
7.1. Implementation of Source-Specific Multicast . . . . . . . 20 7.1. Implementation of Source-Specific Multicast . . . . . . . 19
7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 20 7.2. Implementation of Multicast Source Filter (MSF) APIs . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 which are of interest or which are
skipping to change at page 5, line 52 skipping to change at page 4, line 52
application usually wants to specify desired source addresses, not application usually wants to specify desired source addresses, not
undesired source addresses. Even if a user wants to explicitly undesired source addresses. Even if a user wants to explicitly
refuse traffic from some sources in a group, when other users in the refuse traffic from some sources in a group, when other users in the
same shared network have an interest in these sources, the same shared network have an interest in these sources, the
corresponding multicast traffic is forwarded to the network. It is corresponding multicast traffic is 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 support both ASM and SSM communications LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
without a filtering function that blocks sources. Not only are they
compatible with the standard IGMPv3 and MLDv2, but also the protocol These protocols support both ASM and SSM communications without a
operations made by hosts and routers or switches (performing IGMPv3/ filtering function that blocks sources. Not only are they compatible
MLDv2 snooping) are simplified to reduce the complicated operations. with the standard IGMPv3 and MLDv2, but also the protocol operations
Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full made by hosts and routers or switches (performing IGMPv3/MLDv2
version of these protocols (i.e., the standard IGMPv3 and MLDv2), snooping) are simplified to reduce the complicated operations. Since
LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2,
hosts or routers that have implemented the full version do not need hosts or routers that have implemented the full version do not need
to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
hosts or routers. hosts or routers.
2. Terminology 2. Terminology
Following notations are used in several places in this specification. 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 [1].
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 the 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 the 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 the group G, with
specifying desired source S. In this case, the host receives only specifying desired source S. In this case, the host receives only
from source S sending to group G. from source S sending to group G.
 End of changes. 10 change blocks. 
51 lines changed or deleted 50 lines changed or added

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