draft-ietf-pim-explicit-tracking-11.txt   draft-ietf-pim-explicit-tracking-12.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track March 9, 2015 Intended status: Experimental October 19, 2015
Expires: September 10, 2015 Expires: April 21, 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-11 draft-ietf-pim-explicit-tracking-12
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 September 10, 2015. This Internet-Draft will expire on April 21, 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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Membership State Information . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
4. Specific Query Suppression . . . . . . . . . . . . . . . . . 5 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . 7
8. Compatibility with Older Version Protocols . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 8
9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 8 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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 is important for the scalability of This document specifies an experimental extension to IGMPv3/MLDv2.
multicast networks, and might be widely implemented in modern It makes some fundamental changes to how IGMPv3/MLDv2 works in that
multicast routers. However, it could seriously break IGMP/MLD membership state does not require periodic updates, and it partly
communications if not implemented or configured correctly. For turns IGMPv3/MLDv2 into a hard-state protocol. Also, a mechanism
example, the explicit tracking function is useful for shortening called "specific query suppression" with a robust link state is a new
leave latency, while wrong implementations or configurations in concept. It does not make the router send any specific query
routers on a LAN may not work properly that the operators expect.
This document aims to get the explicit tracking function correctly.
Regarding the way for shortening leave latency, it specifies the way
to do it by tuning the values used by IGMPv3 [2], MLDv2 [3], and
their lightweight version protocols [4], or by enabling the mechanism
called "specific query suppression" with a robust link state. The
latter mechanism 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. member has left according to its membership state information. It is
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 This document describes the risk of having wrong membership state as
well. The explicit tracking function does not change the reliability well. The explicit tracking function does not change the reliability
of the 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 guides for setting up
appropriate values or mechanisms used with the explicit tracking appropriate values or mechanisms used with the explicit tracking
function in routers. function in routers.
skipping to change at page 5, line 36 skipping to change at page 5, line 30
query suppression". With the specific query suppression, regardless query suppression". With the specific query suppression, regardless
of the LMQC/LLQC values, if the router receives one or more replies of the LMQC/LLQC values, if the router receives one or more replies
from the downstream member(s), it SHOULD stop (i.e., cancel) from the downstream member(s), it SHOULD stop (i.e., cancel)
retransmitting the specific query message(s) for the specified source retransmitting the specific query message(s) for the specified source
and/or group. It reduces the number of Group-Specific or Group-and- and/or group. It reduces the number of Group-Specific or Group-and-
Source Specific Query messages transmitted from a router, and in turn Source Specific Query messages transmitted from a router, and in turn
reduces the number of Current-State Report messages transmitted from reduces the number of Current-State Report messages transmitted from
member hosts. This contributes to saving network resources. member hosts. This contributes to saving network resources.
The specific query suppression MAY define an option called "robust The specific query suppression MAY define an option called "robust
link state". A router enabling the specific query suppression with a link state". If an operator is confident that the link is stable and
robust link state does not send any specific query message(s) and robust enough and thus the tracked membership state information is
immediately leave the group or sources when the sole member has left perfectly synchronized with the current (actual) member hosts, s/he
according to its membership state information. The specific query can enable the specific query suppression with a robust link state.
suppression with a robust link state hence does not rely on LMQC/LLQC A router enabling the specific query suppression with a robust link
and LMQI/LLQI values. This contributes to shortening leave latency state does not send any specific query message(s) and immediately
described in Section 5. However, this behavior requires that the leave the group or sources when the sole member has left according to
router perfectly tracks all member hosts. (See a risk of wrong its membership state information. The specific query suppression
membership expectation described in Section 6.) with a robust link state hence does not rely on LMQC/LLQC and LMQI/
LLQI values. This contributes to shortening leave latency described
in Section 5. However, this behavior requires that the router
perfectly tracks all member hosts. (See a risk of wrong membership
expectation described in Section 6.)
Note that the default behavior of the router that supports the Note that the default behavior of the router that supports the
explicit tracking function SHOULD disable this specific query explicit tracking function SHOULD disable this specific query
suppression, in order to avoid the risk caused by the wrong suppression, in order to avoid the risk caused by the wrong
membership expectation or by the case in which multiple multicast membership expectation or by the case in which multiple multicast
routers exist on a LAN and the querier router is not the forwarder routers exist on a LAN and the querier router is not the forwarder
router. The former case is described in Section 6. For the latter router. The former case is described in Section 6. For the latter
case, when the querier suppresses the specific query message case, when the querier suppresses the specific query message
transmission, and expects that the State-Change Report sender is not transmission, and expects that the State-Change Report sender is not
the sole member of the channel, it does not send the specific query. the sole member of the channel, it does not send the specific query.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
[3] Vida, R. and L. Costa, "Multicast Listener Discovery [3] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010. February 2010.
13.2. Informative References 13.2. Informative References
[5] Deering, S., "Host Extensions for IP Multicasting", RFC [5] Deering, S., "Host Extensions for IP Multicasting",
1112, August 1989. RFC 1112, August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version [6] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast [7] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[8] Fenner, B., He, H., Haberman, B., and H. Sandick, [8] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
 End of changes. 8 change blocks. 
31 lines changed or deleted 33 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/