< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/