draft-ietf-pim-explicit-tracking-12.txt   draft-ietf-pim-explicit-tracking-13.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Experimental October 19, 2015 Intended status: Experimental November 1, 2015
Expires: April 21, 2016 Expires: May 4, 2016
IGMP/MLD-Based Explicit Membership Tracking Function for Multicast IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
Routers Routers
draft-ietf-pim-explicit-tracking-12 draft-ietf-pim-explicit-tracking-13
Abstract Abstract
This document describes the IGMP/MLD-based explicit membership This document describes the IGMP/MLD-based explicit membership
tracking function for multicast routers and IGMP/MLD proxy devices tracking function for multicast routers and IGMP/MLD proxy devices
supporting IGMPv3/MLDv2. The explicit membership tracking function supporting IGMPv3/MLDv2. The explicit membership tracking function
contributes to saving network resources and shortening leave latency. contributes to saving network resources and shortening leave latency.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 21, 2016. This Internet-Draft will expire on May 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation and Experimentation . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Membership State Information . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 5
5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6
6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7
7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8
8. Compatibility with Older Version Protocols . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 9
9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 8 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4
and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for
IPv6 are the standard protocols used by member hosts and multicast IPv6 are the standard protocols used by member hosts and multicast
routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and
LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2.
When a host starts/finishes listening to particular multicast When a host starts/finishes listening to particular multicast
skipping to change at page 3, line 16 skipping to change at page 3, line 17
being lost and the membership state information being outdated in the being lost and the membership state information being outdated in the
router. router.
IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
provide the ability to keep track of the downstream (adjacent) provide the ability to keep track of the downstream (adjacent)
multicast membership state in multicast routers, yet the multicast membership state in multicast routers, yet the
specifications are not clearly given. This document describes the specifications are not clearly given. This document describes the
"IGMP/MLD-based explicit member tracking function" for multicast "IGMP/MLD-based explicit member tracking function" for multicast
routers and a way for routers to implement the function. By enabling routers and a way for routers to implement the function. By enabling
this explicit tracking function, routers can keep track of the this explicit tracking function, routers can keep track of the
downstream multicast membership state. downstream multicast membership state. The explicit tracking
function contributes to saving network resources and shortening leave
latency.
The explicit tracking function does not change message formats used
by IGMPv3 [2], MLDv2 [3], and their lightweight version protocols
[4]; nor does it change a multicast data sender's and receiver's
behavior.
1.1. Motivation and Experimentation
This document specifies an experimental extension to IGMPv3/MLDv2. This document specifies an experimental extension to IGMPv3/MLDv2.
It makes some fundamental changes to how IGMPv3/MLDv2 works in that It makes some fundamental changes to how IGMPv3/MLDv2 works in that
membership state does not require periodic updates, and it partly membership state does not require periodic updates, and it partly
turns IGMPv3/MLDv2 into a hard-state protocol. Also, a mechanism turns IGMPv3/MLDv2 into a hard-state protocol. Also, a mechanism
called "specific query suppression" with a robust link state is a new called "specific query suppression" with a robust link state is a new
concept. It does not make the router send any specific query concept. It does not make the router send any specific query
message(s) and immediately leave the group or sources when the sole message(s) and immediately leave the group or sources when the sole
member has left according to its membership state information. It is member has left according to its membership state information.
likely that experiences from early implementations and deployments
will lead to at least minor changes in the protocol. Once there is
some deployment experience, making this a Standards Track protocol
should be considered. Experiments using this protocol extension only
require support by pairs of multicast routers on a LAN, and need not
be constrained to isolated networks.
This document describes the risk of having wrong membership state as The explicit tracking function does not change the reliability of the
well. The explicit tracking function does not change the reliability message transmission. The list of tracked member hosts may be
of the message transmission. The list of tracked member hosts may be
outdated in the router because of host departure from the network outdated in the router because of host departure from the network
without sending State-Change Report messages or loss of such messages without sending State-Change Report messages or loss of such messages
due to network congestion. This document guides for setting up due to network congestion. This document describes the risk of
appropriate values or mechanisms used with the explicit tracking having wrong membership state and guides for setting up appropriate
function in routers. values or mechanisms used with the explicit tracking function in
routers.
The explicit tracking function potentially requires a large amount of The explicit tracking function potentially requires a large amount of
memory so that routers keep all membership states. Particularly when memory so that routers keep all membership states. Particularly when
a router needs to maintain a large number of member hosts, this a router needs to maintain a large number of member hosts, this
resource requirement might be sensitive. As the security resource requirement might be sensitive. As the security
consideration, this document describes that operators may decide to consideration, this document describes that operators may decide to
disable this function when their routers have insufficient memory disable this function when their routers have insufficient memory
resources, despite the benefits. resources, despite the benefits.
The explicit tracking function does not change message formats used It is likely that experiences from early implementations and
by IGMPv3 [2], MLDv2 [3], and their lightweight version protocols deployments will lead to at least minor changes in the protocol. Any
experiments using this protocol extension are encouraged. Reports
from such experiments planned with pre-specified objectives and
scenarios are particularly encouraged. Results from such
experiments, documenting the following, are of particular importance:
[4]; nor does it change a multicast data sender's and receiver's o Operation in networks that contain both routers implementing this
behavior. extension, and routers implementing only [2][3][4], in particular
are there any unexpected interactions that can break the network?
o Operation in networks that contain both routers implementing this
extension, and routers implementing older versions of IGMP or MLD,
IGMPv1 [5], IGMPv2 [6], or MLDv1 [7].
o Operation in networks with dynamic topology changes.
o Operation in networks with invalid or outdated membership states.
o Network performance, including leave latency and packet delivery
results.
o Resource requirements observed from running the protocol,
including processing, storage, and bandwidth.
o Any other implementation issues.
Once there is some deployment experience, making this a Standards
Track protocol should be considered.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Membership State Information 3. Membership State Information
A router enabling the explicit tracking function maintains the A router enabling the explicit tracking function maintains the
skipping to change at page 9, line 50 skipping to change at page 10, line 33
tracking function may limit a total amount of membership information tracking function may limit a total amount of membership information
the router can store, or may rate-limit State-Change Report messages the router can store, or may rate-limit State-Change Report messages
per host. When the router enables rate-limiting per host, the router per host. When the router enables rate-limiting per host, the router
MAY ignore the received State-Change Report messages to minimize the MAY ignore the received State-Change Report messages to minimize the
processing overhead or prevent DoS attacks. The rate limit is left processing overhead or prevent DoS attacks. The rate limit is left
to the router's implementation. to the router's implementation.
12. Acknowledgements 12. Acknowledgements
Luis M. Contreras, Toerless Eckert, Adrian Farrel, Sergio Luis M. Contreras, Toerless Eckert, Adrian Farrel, Sergio
Figueiredo, Bharat Joshi, Nicolai Leymann, Magnus Nystrom, Stig Figueiredo, Bharat Joshi, Nicolai Leymann, Magnus Nystrom, Alvaro
Venaas, and others provided many constructive and insightful Retana, Stig Venaas, and others provided many constructive and
comments. insightful comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate [1] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
 End of changes. 15 change blocks. 
32 lines changed or deleted 60 lines changed or added

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