< draft-lts-pim-hello-mtu-00.txt		draft-lts-pim-hello-mtu-01.txt >
	PIM Working Group H. Liu		PIM Working Group H. Liu
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track T. Tsou		Intended status: Standards Track T. Tsou
	Expires: September 1, 2012 Huawei Technologies (USA)		Expires: January 14, 2013 Huawei Technologies (USA)
	February 29, 2012		July 13, 2012
	PIM MTU Hello Option for PIM Message Encapsulation		PIM MTU Hello Option for PIM Message Encapsulation
	draft-lts-pim-hello-mtu-00		draft-lts-pim-hello-mtu-01
	Abstract		Abstract
	This memo introduces a new PIM Hello MTU Option which is carried in		This memo introduces a new PIM Hello MTU Option which is carried in
	PIM Hello messages. The MTU option enables interface MTU information		PIM Hello messages. The MTU option enables interface MTU information
	to be exchanged among PIM neighbors, and PIM messages to be		to be exchanged among PIM neighbors, and PIM messages to be
	encapsulated in an efficient and consistent way.		encapsulated in an efficient and consistent way.
	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 1, 2012.		This Internet-Draft will expire on January 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 13 ¶		skipping to change at page 2, line 13 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. MTU Option and its Operation Rule . . . . . . . . . . . . . . . 4		3. MTU Option and its Operation Rule . . . . . . . . . . . . . . . 4
	4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 5		8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	A PIM router often needs to preserve a great many (*,G) or (S,G)		A PIM router often needs to preserve a great many (*,G) or (S,G)
	states to enable traffic forwarding for large scale multicast		multicast forwarding states to enable traffic forwarding for large
	channels. These states are usually set up and kept alive by		scale of multicast channels. These states are usually set up and
	periodical PIM messages (e.g.PIM Join) sent from its downstream		kept alive by each downstream router periodically sending Join
	neighbors. For each periodical assembling of these states into a PIM		Messages carrying its own forwarding states to its upstream neighbor.
	message, multiple packets will possibly be generated due to MTU		For each round of assembling these states into a PIM message,
			multiple segments of packets might be generated due to the MTU
	limitation on the sending PIM interface.		limitation on the sending PIM interface.
	Current implementation uses merely sending link MTU to calculate		Current implementation uses merely sending link MTU to calculate
	maximum PIM packet length without considering the receiving interface		maximum PIM packet length without considering the receiving MTU of
	link MTU of the neighbor. It has some drawbacks because if the MTU		the neighbor(s). It has some drawbacks because if the MTU of the
	of the downstream sending interface is larger than that of the		sending interface is larger than that of the receiving one, PIM
	upstream receiving interface, PIM protocol packets encapsulated		protocol packets encapsulated according to the sending MTU will most
	according to the sending MTU will most possibly be discarded for		possibly be discarded by the receiving router and the forwarding
	exceeding the MTU limitation of the upstream receiving interface.		states cannot be properly established as a result. There are already
	The forwarding states cannot be properly established as a result.		faults being reported caused by inconsistent MTU configuration among
	There are already faults being reported caused by inconsistent MTU		PIM neighbors.
	configuration among PIM neighbors.
	Even though the problem could be resolved by requiring each PIM		Even though the problem could be resolved by requiring each PIM
	downstream interface taking less or equal MTU value than its upstream		downstream interface to take less or equal MTU value than its
	interface, it is inflexible for operation and does not scale because		upstream interface, it is inflexible for operation and does not scale
	the interface or link conditions across the network might be diverse		because the interface or link conditions across the network might be
	in practice. As a remedy, this memo recommends exchanging link MTU		diverse in practice. As a remedy, this memo recommends exchanging
	information among PIM neighbors, and introduces a new PIM MTU Hello		link MTU information among PIM neighbors by using a new Hello MTU
	option. PIM MTU option is carried in periodical PIM Hello messages.		Option. The option is carried in periodical PIM Hello messages for a
	A PIM router uses the option to inform its own receiving link MTU on		router to inform its receiving link MTU parameter on an interface to
	an interface to its neighbor(s). The neighbor(s) will use the MTU		the connected neighbor(s), so that the MTU information could be
	when encapsulating and sending PIM protocol messages to this router.		referenced by the neighbor(s) when they are sending PIM protocol
			messages on this link.
	PIM MTU Option can be applied to all variants of PIM protocols, i.e.,		PIM MTU Option can be applied to all variants of PIM protocols, i.e.,
	PIM-SM, PIM-SSM, PIM-DM, and BIDIR-PIM, on both IPv4 and IPv6 PIM		PIM-SM, PIM-SSM, PIM-DM, and BIDIR-PIM, on both IPv4 and IPv6
	networks. Because MTU issue for unicast Register Message has already		networks. There is an exception for the processing of PIM-SM
	been considered in PIM-SM (4.4.1 in [1]), neighboring MTU is only		Register/Register-Stop Message, which should reference the MTU
	referred when encapsulating PIM messages with multicast destination.		information on the entire path between source DR and RP, as described
			in 4.4.1 of [RFC4601].
	It should be noted that PIM MTU discovery proposed here is different		It should be noted that PIM MTU Option extension is different from
	from multicast PMTU discovery described in RFC1981 [2]. Section 5.2		multicast PMTU discovery mentioned in [RFC1981] . Section 5.2 of
	of RFC1981 requires that an implementation should maintain a single		RFC1981 describes that an implementation could maintain a single PMTU
	PMTU learned across the whole multicast distribution tree. This		learned across the whole multicast distribution tree. This might
	might result in using smaller packets than necessary for a lot of		result in using smaller packets than necessary for a lot of paths.
	paths. And because the end to end paths can be very dynamic this		And because the end to end paths can be very dynamic it could make
	could make the effort too complex. PMTU is used in encapsulating a		the effort too complex. This PMTU is used in encapsulating a
	'multicast data packet' (not a 'PIM protocol packet' as here) to		'multicast data packet' to avoid fragmentation in multicast data
	avoid fragmentation as the packet travels on the paths of the tree.		plane as the packet travels on all paths of the tree. Whereas PIM
	Whereas PIM MTU option works in control plane and has a per-hop		MTU option works in control plane and has a per-hop nature - it only
	nature - it only functions between one-hop PIM neighbors and helps		functions between adjacent one-hop PIM neighbors to guide the sending
	PIM protocols to establish correctly the multicast forwarding states.		of a 'PIM protocol message'.
			The maintenance of MTU in control plane (by PIM Hello MTU Option) and
			data plane (by PMTU) are for different purposes and are run
			independently - the control plane makes sure that forwarding paths
			are setup even there exists asymmetric MTUs on different links, while
			the data plane is to make multicast delivery efficient by avoiding
			fragmenting/reassembling operation, which could be done by means of
			acquiring minimal MTU on all paths, and of applying it in generating
			a data packet on first-hop or head-end. Control plane cannot
			preclude fragmentation, but it is the premise of normal data
			forwarding - even if some data packets exceeding limitation of some
			points of the paths cannot be processed properly, other packets
			meeting the PMTU requirements will be normally forwarded and
			delivered.
	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 [3].		document are to be interpreted as described in [RFC2119].
	3. MTU Option and its Operation Rule		3. MTU Option and its Operation Rule
	To record the minimum sending MTU value on an interface, a new		To record the minimum usable sending MTU value on an interface, a new
	General Purpose non-group-specific state (say Sending MTU state) is		General Purpose non-group-specific state - Sending MTU state is
	introduced in PIM protocols (for General Purpose State referring to		introduced in PIM protocols (for General Purpose State referring to
	4.1.1 of [1] and [4], and 3.1.1 of [5]. It is 32-bit long and is		4.1.1 of [RFC4601] and [RFC3973], and 3.1.1 of [RFC5015]). It is 32-
	unique on an interface even if what is connected is a multi-access		bit long and is unique on an interface whether the link connected is
	network. The initial value of the Sending MTU state should be set to		point-to-point or multi-accessed. The initial value of the Sending
	the outbound MTU, or if unavailable, set to the default MTU of the		MTU state should be set to the outbound MTU of the interface, taking
	interface.		either the configured MTU or the default MTU value (referring to 7.1
			of [RFC1191] for common MTU for different link types).
	When an MTU Hello Option is received from a neighbor, the PIM router		When an MTU Hello Option is received from a neighbor, a PIM router
	parses the MTU value in the option and decides whether or not it		parses the MTU value in the option and decides whether or not it
	should accept the value and should store it in the Sending MTU field.		should accept the value and store it in the Sending MTU field. A
	A router should not accept too small a value to prevent extreme		router should not accept too small a value to prevent extreme
	fragmentation deteriorating the router's performance. If the MTU		fragmentation from deteriorating the router's performance. If the
	value is valid from a legal neighbor, it compares the value with the		MTU value is valid from a legal neighbor, it compares the value with
	MTU value currently stored in the Sending MTU field, and makes the		the MTU value currently stored in the Sending MTU field, and makes
	replacement if the former is less than the latter.		the replacement if the former is less than the latter.
	Unlike other PIM Hello option, MTU Option is not required being		Unlike other PIM Hello option, MTU Option is not required being
	supported simultaneously by all PIM neighbors connecting to a		supported simultaneously by all PIM neighbors connecting to a
	network. An MTU-capable router only considers the MTU of a trusty		network. An MTU-capable router only considers the MTU of a trusty
	neighbor from which a valid MTU option is received. An MTU-capable		neighbor from which a valid MTU option is received. An MTU-capable
	PIM router should use MTU option in its Hello message, and should		PIM router should use MTU option in its Hello message, and should
	keep the Sending MTU state to the initial value if no neighbor		keep the Sending MTU state to the initial value if no neighbor
	reports a valid MTU Option. Finally, an MTU-incapable router should		reports a valid MTU Option. Finally, an MTU-incapable router should
	ignore an MTU option on reception.		ignore an MTU option on reception.
	skipping to change at page 5, line 39 ¶		skipping to change at page 6, line 8 ¶
	6. Security Considerations		6. Security Considerations
	The potential security threat for MTU option should be the denial-		The potential security threat for MTU option should be the denial-
	of-service attack of extremely fragmenting PIM messages, by		of-service attack of extremely fragmenting PIM messages, by
	advertising much smaller MTU value than necessary. A remedy is to		advertising much smaller MTU value than necessary. A remedy is to
	require a PIM router to check the validity of a neighbor's MTU value		require a PIM router to check the validity of a neighbor's MTU value
	before accepting it.		before accepting it.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to acknowledge Hou Yunlong and Mach Chen for		The authors would like to acknowledge Hou Yunlong, Mach Chen, Liu
	their valuable comments on the work.		Yisong, Stig Venaas, Bill Fenner, Dino Farinacci, and Chiranjeevi
			Ramana Rao for their valuable comments and discussions on the work.
	8. Normative References		8. Normative References
	[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol		November 1990.
	Specification (Revised)", RFC 4601, August 2007.
	[2] McCann, J., Deering, S., Mogul, J., and L. Vicisano, "Path MTU		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	Discovery for IP version 6", RFC 1981, August 1996.		for IP version 6", RFC 1981, August 1996.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[4] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent		[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
	Multicast - Dense Mode (PIM-DM): Protocol Specification		Independent Multicast - Dense Mode (PIM-DM): Protocol
	(Revised)", RFC 3973, January 2005.		Specification (Revised)", RFC 3973, January 2005.
	[5] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Bidirectional Protocol Independent Multicast (BIDIR-PIM)",		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	RFC 5015, October 2007.		Protocol Specification (Revised)", RFC 4601, August 2006.
			[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
			"Bidirectional Protocol Independent Multicast (BIDIR-
			PIM)", RFC 5015, October 2007.
	Authors' Addresses		Authors' Addresses
	Liu Hui		Liu Hui
	Huawei Technologies		Huawei Technologies
	Building Q14, No.156, Beiqing Rd.		Building Q14, No.156, Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Phone: 8610-60610012		Phone: 8610-60610012
End of changes. 20 change blocks.
	75 lines changed or deleted		96 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/