Diff: rfc9508v4.txt - rfc9508.txt

	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.