rfc9508v4.txt		rfc9508.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Research Task Force (IRTF) S. Mastorakis		Internet Research Task Force (IRTF) S. Mastorakis
	Request for Comments: 9508 University of Notre Dame		Request for Comments: 9508 University of Notre Dame
	Category: Experimental D. Oran		Category: Experimental D. Oran
	ISSN: 2070-1721 Network Systems Research and Design		ISSN: 2070-1721 Network Systems Research and Design
	J. Gibson		J. Gibson
	Unaffiliated		Unaffiliated
	I. Moiseenko		I. Moiseenko
	Apple Inc.		Apple Inc.
	R. Droms		R. Droms
	Unaffiliated		Unaffiliated
	February 2024		March 2024
	Information-Centric Networking (ICN) Ping Protocol Specification		Information-Centric Networking (ICN) Ping Protocol Specification
	Abstract		Abstract
	This document presents the design of an Information-Centric		This document presents the design of an Information-Centric
	Networking (ICN) Ping protocol. It includes the operations of both		Networking (ICN) Ping protocol. It includes the operations of both
	the client and the forwarder.		the client and the forwarder.
	This document is a product of the Information-Centric Networking		This document is a product of the Information-Centric Networking
	skipping to change at line 270 ¶		skipping to change at line 270 ¶
	to distinguish a ping from a normal Interest, while diverging as		to distinguish a ping from a normal Interest, while diverging as
	little as possible from the forwarding behavior for an Interest		little as possible from the forwarding behavior for an Interest
	packet. In the same way, the encoding of a Ping Echo Reply should		packet. In the same way, the encoding of a Ping Echo Reply should
	minimize any processing differences from those employed for a data		minimize any processing differences from those employed for a data
	packet by the forwarders.		packet by the forwarders.
	The ping protocol should also enable relatively robust RTT		The ping protocol should also enable relatively robust RTT
	measurements. To this end, it is valuable to have a mechanism to		measurements. To this end, it is valuable to have a mechanism to
	steer consecutive Ping Echo Requests for the same name towards an		steer consecutive Ping Echo Requests for the same name towards an
	individual path. Such a capability was initially published in		individual path. Such a capability was initially published in
	[PATHSTEERING] and has been specified for CCNx and NDN in [RFCYYYY].		[PATHSTEERING] and has been specified for CCNx and NDN in [RFC9531].
	In the case of Ping Echo Requests for the same name from different		In the case of Ping Echo Requests for the same name from different
	sources, it is also important to have a mechanism to avoid those		sources, it is also important to have a mechanism to avoid those
	requests being aggregated in the PIT. To this end, we need some		requests being aggregated in the PIT. To this end, we need some
	encoding in the Ping Echo Requests to make each request for a common		encoding in the Ping Echo Requests to make each request for a common
	name unique, hence avoiding PIT aggregation and further enabling the		name unique, hence avoiding PIT aggregation and further enabling the
	exact match of a response with a particular ping packet. However,		exact match of a response with a particular ping packet. However,
	avoiding PIT aggregation could lead to PIT DoS attacks.		avoiding PIT aggregation could lead to PIT DoS attacks.
	4. ICN Ping Echo CCNx Packet Formats		4. ICN Ping Echo CCNx Packet Formats
	skipping to change at line 324 ¶		skipping to change at line 324 ¶
	type field is _PT_ECHO_REQUEST_. See Section 9 for the value		type field is _PT_ECHO_REQUEST_. See Section 9 for the value
	assignment.		assignment.
	Compared to the typical format of a CCNx packet header [RFC8609],		Compared to the typical format of a CCNx packet header [RFC8609],
	there is a new optional fixed header added to the packet header:		there is a new optional fixed header added to the packet header:
	* A Path Steering hop-by-hop header TLV, which is constructed hop by		* A Path Steering hop-by-hop header TLV, which is constructed hop by
	hop in the Ping Echo Reply and included in the Ping Echo Request		hop in the Ping Echo Reply and included in the Ping Echo Request
	to steer consecutive requests expressed by a client towards a		to steer consecutive requests expressed by a client towards a
	common forwarding path or different forwarding paths. The Path		common forwarding path or different forwarding paths. The Path
	Label TLV is specified in [RFCYYYY].		Label TLV is specified in [RFC9531].
	The message format of an Echo Request is presented below:		The message format of an Echo Request is presented below:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| | |		| | |
	| MessageType = 0x05 | MessageLength |		| MessageType = 0x05 | MessageLength |
	| | |		| | |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| |		| |
	skipping to change at line 396 ¶		skipping to change at line 396 ¶
	| |		| |
	| Echo Reply Message TLVs |		| Echo Reply Message TLVs |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 4: Echo Reply CCNx Packet Format		Figure 4: Echo Reply CCNx Packet Format
	The header of an Echo Reply consists of the header fields of a CCNx		The header of an Echo Reply consists of the header fields of a CCNx
	Content Object and a hop-by-hop Path Label TLV. The value of the		Content Object and a hop-by-hop Path Label TLV. The value of the
	packet type field is PT_ECHO_REPLY. See Section 9 for the value		packet type field is PT_ECHO_REPLY. See Section 9 for the value
	assignment. The Path Label header TLV (Section 3.1 of [RFCYYYY]) is		assignment. The Path Label header TLV (Section 3.1 of [RFC9531]) is
	as defined for the Echo Request packet.		as defined for the Echo Request packet.
	A Ping Echo Reply message is of type T_OBJECT and contains a Name TLV		A Ping Echo Reply message is of type T_OBJECT and contains a Name TLV
	(name of the corresponding Echo Request), a PayloadType TLV, and an		(name of the corresponding Echo Request), a PayloadType TLV, and an
	ExpiryTime TLV with a value of 0 to indicate that Echo Replies must		ExpiryTime TLV with a value of 0 to indicate that Echo Replies must
	not be returned from network caches.		not be returned from network caches.
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| | |		| | |
	skipping to change at line 502 ¶		skipping to change at line 502 ¶
	Nonce		Nonce
	ApplicationParameters?		ApplicationParameters?
	Figure 7: Echo Request NDN Packet Format		Figure 7: Echo Request NDN Packet Format
	The name field of an Echo Request consists of the name prefix to be		The name field of an Echo Request consists of the name prefix to be
	pinged, a nonce value (it can be the value of the Nonce field), and		pinged, a nonce value (it can be the value of the Nonce field), and
	the suffix "ping" to denote that this Interest is a ping request		the suffix "ping" to denote that this Interest is a ping request
	(added as a KeywordNameComponent [NDNTLV]). When the		(added as a KeywordNameComponent [NDNTLV]). When the
	"ApplicationParameters" element is present, a		"ApplicationParameters" element is present, a
	parametersSha256DigestComponent (Section 6) is added as the last name		ParametersSha256DigestComponent (Section 6) is added as the last name
	segment.		segment.
	An Echo Request MAY carry a Path Label TLV in the NDN Link Adaptation		An Echo Request MAY carry a Path Label TLV in the NDN Link Adaptation
	Protocol [NDNLPv2] as specified in [RFCYYYY].		Protocol [NDNLPv2] as specified in [RFC9531].
	Since the NDN packet format does not provide a mechanism to prevent		Since the NDN packet format does not provide a mechanism to prevent
	the network from caching specific data packets, we use the		the network from caching specific data packets, we use the
	MustBeFresh TLV for Echo Requests (in combination with a		MustBeFresh TLV for Echo Requests (in combination with a
	FreshnessPeriod TLV with a value of 1 for Echo Replies) to avoid		FreshnessPeriod TLV with a value of 1 for Echo Replies) to avoid
	fetching cached Echo Replies with an expired freshness period		fetching cached Echo Replies with an expired freshness period
	[REALTIME].		[REALTIME].
	5.2. ICN Ping Echo Reply NDN Packet Format		5.2. ICN Ping Echo Reply NDN Packet Format
	skipping to change at line 529 ¶		skipping to change at line 529 ¶
	EchoReply = DATA-TLV TLV-LENGTH		EchoReply = DATA-TLV TLV-LENGTH
	Name		Name
	MetaInfo		MetaInfo
	Content		Content
	Signature		Signature
	Figure 8: Echo Reply NDN Packet Format		Figure 8: Echo Reply NDN Packet Format
	An Echo Reply MAY carry a Path Label TLV in the NDN Link Adaptation		An Echo Reply MAY carry a Path Label TLV in the NDN Link Adaptation
	Protocol [NDNLPv2] as specified in [RFCYYYY], since it might be		Protocol [NDNLPv2] as specified in [RFC9531], since it might be
	modified in a hop-by-hop fashion by the forwarders along the reverse		modified in a hop-by-hop fashion by the forwarders along the reverse
	path.		path.
	The name of an Echo Reply is the name of the corresponding Echo		The name of an Echo Reply is the name of the corresponding Echo
	Request while the format of the MetaInfo field is as follows:		Request while the format of the MetaInfo field is as follows:
	MetaInfo = META-INFO-TYPE TLV-LENGTH		MetaInfo = META-INFO-TYPE TLV-LENGTH
	ContentType		ContentType
	FreshnessPeriod		FreshnessPeriod
	skipping to change at line 774 ¶		skipping to change at line 774 ¶
	DOI 10.17487/RFC8793, June 2020,		DOI 10.17487/RFC8793, June 2020,
	<https://www.rfc-editor.org/info/rfc8793>.		<https://www.rfc-editor.org/info/rfc8793>.
	10.2. Informative References		10.2. Informative References
	[NDNLPv2] NDN team, "NDNLPv2: Named Data Networking Link Adaptation		[NDNLPv2] NDN team, "NDNLPv2: Named Data Networking Link Adaptation
	Protocol v2", February 2023, <https://redmine.named-		Protocol v2", February 2023, <https://redmine.named-
	data.net/projects/nfd/wiki/NDNLPv2>.		data.net/projects/nfd/wiki/NDNLPv2>.
	[NDNTLV] NDN project team, "NDN Packet Format Specification",		[NDNTLV] NDN project team, "NDN Packet Format Specification",
	September 2023,		February 2024,
	<https://named-data.net/doc/NDN-packet-spec/current/>.		<https://named-data.net/doc/NDN-packet-spec/current/>.
	[PATHSTEERING]		[PATHSTEERING]
	Moiseenko, I. and D. Oran, "Path switching in content		Moiseenko, I. and D. Oran, "Path switching in content
	centric and named data networks", ICN '17: Proceedings of		centric and named data networks", ICN '17: Proceedings of
	the 4th ACM Conference on Information-Centric Networking,		the 4th ACM Conference on Information-Centric Networking,
	pp. 66-76, DOI 10.1145/3125719.3125721, September 2017,		pp. 66-76, DOI 10.1145/3125719.3125721, September 2017,
	<https://dl.acm.org/doi/10.1145/3125719.3125721>.		<https://dl.acm.org/doi/10.1145/3125719.3125721>.
	[REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang,		[REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang,
	skipping to change at line 805 ¶		skipping to change at line 805 ¶
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC9344] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering		[RFC9344] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
	Content and Network Information in Content-Centric		Content and Network Information in Content-Centric
	Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023,		Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023,
	<https://www.rfc-editor.org/info/rfc9344>.		<https://www.rfc-editor.org/info/rfc9344>.
	[RFCYYYY] Moiseenko, I. and D. Oran, "Path Steering in CCNx and		[RFC9531] Moiseenko, I. and D. Oran, "Path Steering in Content-
	NDN", RFC YYYY, DOI 10.17487/RFCYYYY, February 2024,		Centric Networking (CCNx) and Named Data Networking
	<https://www.rfc-editor.org/info/rfcYYYY>.		(NDN)", RFC 9531, DOI 10.17487/RFC9531, March 2024,
			<https://www.rfc-editor.org/info/rfc9531>.
	[SNAMP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang,		[SNAMP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang,
	"SNAMP: Secure namespace mapping to scale NDN forwarding",		"SNAMP: Secure namespace mapping to scale NDN forwarding",
	2015 IEEE Conference on Computer Communications Workshops		2015 IEEE Conference on Computer Communications Workshops
	(INFOCOM WKSHPS), Hong Kong, China, pp. 281-286,		(INFOCOM WKSHPS), Hong Kong, China, pp. 281-286,
	DOI 10.1109/INFCOMW.2015.7179398, April 2015,		DOI 10.1109/INFCOMW.2015.7179398, April 2015,
	<https://ieeexplore.ieee.org/abstract/document/7179398>.		<https://ieeexplore.ieee.org/abstract/document/7179398>.
	Appendix A. Ping Client Application (Consumer) Operation		Appendix A. Ping Client Application (Consumer) Operation
End of changes. 9 change blocks.
	11 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.