< draft-irtf-icnrg-icnping-03.txt		draft-irtf-icnrg-icnping-04.txt >
	ICNRG S. Mastorakis		ICNRG S. Mastorakis
	Internet-Draft University of Nebraska, Omaha		Internet-Draft University of Nebraska at Omaha
	Intended status: Experimental J. Gibson		Intended status: Experimental J. Gibson
	Expires: 28 April 2022 Cisco Systems		Expires: 7 September 2022 Cisco Systems
	I. Moiseenko		I. Moiseenko
	Apple Inc		Apple Inc
	R. Droms		R. Droms
	Google Inc.		Google Inc.
	D. Oran		D. Oran
	Network Systems Research and Design		Network Systems Research and Design
	25 October 2021		6 March 2022
	ICN Ping Protocol Specification		ICN Ping Protocol Specification
	draft-irtf-icnrg-icnping-03		draft-irtf-icnrg-icnping-04
	Abstract		Abstract
	This document presents the design of an ICN Ping protocol. It		This document presents the design of an ICN Ping protocol. It
	includes the operations of both the client and the forwarder.		includes the operations of both the client and the forwarder.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 28 April 2022.		This Internet-Draft will expire on 7 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background on IP-Based Ping Operation . . . . . . . . . . . . 3		2. Background on IP-Based Ping Operation . . . . . . . . . . . . 3
	3. Ping Functionality Challenges and Opportunities in ICN . . . 4		3. Ping Functionality Challenges and Opportunities in ICN . . . 4
	4. ICN Ping Echo CCNx Packet Formats . . . . . . . . . . . . . . 6		4. ICN Ping Echo CCNx Packet Formats . . . . . . . . . . . . . . 6
	4.1. ICN Ping Echo Request CCNx Packet Format . . . . . . . . 6		4.1. ICN Ping Echo Request CCNx Packet Format . . . . . . . . 6
	4.2. Ping Echo Reply CCNx Packet Format . . . . . . . . . . . 8		4.2. Ping Echo Reply CCNx Packet Format . . . . . . . . . . . 8
	5. ICN Ping Echo NDN Packet Formats . . . . . . . . . . . . . . 12		5. ICN Ping Echo NDN Packet Formats . . . . . . . . . . . . . . 12
	5.1. ICN Ping Echo Request NDN Packet Format . . . . . . . . . 12		5.1. ICN Ping Echo Request NDN Packet Format . . . . . . . . . 12
	5.2. Ping Echo Reply NDN Packet Format . . . . . . . . . . . . 13		5.2. Ping Echo Reply NDN Packet Format . . . . . . . . . . . . 13
	6. Forwarder Handling . . . . . . . . . . . . . . . . . . . . . 14		6. Forwarder Handling . . . . . . . . . . . . . . . . . . . . . 14
	7. Protocol Operation For Locally-Scoped Namespaces . . . . . . 15		7. Protocol Operation For Locally-Scoped Namespaces . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Ping Client Application (Consumer) Operation . . . . 18		Appendix A. Ping Client Application (Consumer) Operation . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Ascertaining data plane reachability to a destination and taking		Ascertaining data plane reachability to a destination and taking
	coarse performance measurements of round trip time are fundamental		coarse performance measurements of round trip time are fundamental
	facilities for network administration and troubleshooting. In IP,		facilities for network administration and troubleshooting. In IP,
	where routing and forwarding are based on IP addresses, ICMP echo and		where routing and forwarding are based on IP addresses, ICMP echo and
	ICMP echo response are the protocol mechanisms used for this purpose,		ICMP echo response are the protocol mechanisms used for this purpose,
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	5.1. ICN Ping Echo Request NDN Packet Format		5.1. ICN Ping Echo Request NDN Packet Format
	An echo request is encoded as an NDN Interest packet. Its format is		An echo request is encoded as an NDN Interest packet. Its format is
	the following:		the following:
	EchoRequest ::= INTEREST-TYPE TLV-LENGTH		EchoRequest ::= INTEREST-TYPE TLV-LENGTH
	Name		Name
	MustBeFresh		MustBeFresh
	Nonce		Nonce
	Parameters?		ApplicationParameters?
	Figure 8: Echo Request NDN Packet Format		Figure 8: 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). When the "ApplicationParameters"
			element is present, a ParametersSha256DigestComponent is added as the
			last name component.
	The "Parameters" field of the Request contains the following		The "ApplicationParameters" field of the Request contains the
	PathSteering TLV:		following PathSteering TLV:
	PathSteering TLV ::= PATHSTEERING-TLV-TYPE TLV-LENGTH BYTE{8}		PathSteering TLV ::= PATHSTEERING-TLV-TYPE TLV-LENGTH 8*OCTET
	Figure 9: PathSteering TLV		Figure 9: PathSteering TLV
	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 selector for echo requests (in combination with a		MustBeFresh element for echo requests (in combination with a
	Freshness Period TLV of value 0 for echo replies) to avoid fetching		Freshness Period TLV of value 0 for echo replies) to avoid fetching
	cached echo replies with an expired freshness period [REALTIME].		cached echo replies with an expired freshness period [REALTIME].
	5.2. Ping Echo Reply NDN Packet Format		5.2. Ping Echo Reply NDN Packet Format
	An echo reply is encoded as an NDN Data packet. Its format is the		An echo reply is encoded as an NDN Data packet. Its format is the
	following:		following:
	EchoReply ::= DATA-TLV TLV-LENGTH		EchoReply ::= DATA-TLV TLV-LENGTH
	PathSteering TLV		Name
	Name		MetaInfo
	MetaInfo		Content
	Content		Signature
	Signature		PathSteering TLV
	Figure 10: Echo Reply NDN Packet Format		Figure 10: Echo Reply NDN Packet Format
	Compared to the format of a regular NDN Data packet, an echo reply		Compared to the format of a regular NDN Data packet, an echo reply
	contains a PathSteering TLV field, which is not included in the		contains a PathSteering TLV field, which is not included in the
	security envelope, since it might be modified in a hop-by-hop fashion		security envelope, since it might be modified in a hop-by-hop fashion
	by the forwarders along the reverse path.		by the forwarders along the reverse 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 the following:		request, while the format of the MetaInfo field is the following:
	MetaInfo ::= META-INFO-TYPE TLV-LENGTH		MetaInfo ::= META-INFO-TYPE TLV-LENGTH
	ContentType		ContentType
	FreshnessPeriod		FreshnessPeriod
	Figure 11: MetaInfo TLV		Figure 11: MetaInfo TLV
	The value of the ContentType TLV is 0. The same applies to the value		The value of the ContentType TLV is 0. The same applies to the value
	of the FreshnessPeriod TLV, so that the replies are treated as stale		of the FreshnessPeriod TLV, so that the replies are treated as stale
	data as soon as they are received by a forwarder.		data as soon as they are received by a forwarder (mentioned for
			completeness, since these are the default values in NDN packet format
			v0.3).
	The content of an echo reply consists of the following 2 TLVs:		The content of an echo reply consists of the following 2 TLVs:
	Sender's name (with a structure similar as an NDN Name TLV) and Echo		Sender's name (with a structure similar as an NDN Name TLV) and Echo
	Reply Code. There is no need to have a separate TLV for the sender's		Reply Code. There is no need to have a separate TLV for the sender's
	signature in the content of the reply, since every NDN data packet		signature in the content of the reply, since every NDN data packet
	carries the signature of the data producer.		carries the signature of the data producer.
	The Echo Reply Code TLV format is the following (with the values		The Echo Reply Code TLV format is the following (with the values
	specified in Section 4.2):		specified in Section 4.2):
	EchoReplyCode ::= ECHOREPLYCODE-TLV-TYPE TLV-LENGTH BYTE{2}		EchoReplyCode ::= ECHOREPLYCODE-TLV-TYPE TLV-LENGTH 2*OCTET
	Figure 12: Echo Reply Code TLV		Figure 12: Echo Reply Code TLV
	6. Forwarder Handling		6. Forwarder Handling
	We present the workflow of the forwarder's operation in Figure 13.		We present the workflow of the forwarder's operation in Figure 13.
	When a forwarder receives an echo request, it first extracts the		When a forwarder receives an echo request, it first extracts the
	message's base name (i.e., the request name with the Nonce name		message's base name (i.e., the request name with the Nonce name
	component excluded and the suffix "ping" in the case of an echo		component excluded as well as the suffix "ping" and the
	request with the NDN packet format).		ParametersSha256DigestComponent in the case of an echo request with
			the NDN packet format).
	In some cases, the forwarder originates an echo reply, sending the		In some cases, the forwarder originates an echo reply, sending the
	reply downstream through the face on which the echo request was		reply downstream through the face on which the echo request was
	received. This echo reply includes the forwarder's own name and		received. This echo reply includes the forwarder's own name and
	signature and the appropriate echo reply code based on the condition		signature and the appropriate echo reply code based on the condition
	that triggered the reply generation. It also includes a pathSteering		that triggered the reply generation. It also includes a pathSteering
	TLV, initially containing a null value (since the echo reply		TLV, initially containing a null value (since the echo reply
	originator did not forward the request and, thus, does not make a		originator did not forward the request and, thus, does not make a
	path choice).		path choice).
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 29 ¶
	<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-		<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
	ccninfo-08>.		ccninfo-08>.
	[I-D.oran-icnrg-pathsteering]		[I-D.oran-icnrg-pathsteering]
	Moiseenko, I. and D. Oran, "Path Steering in CCNx and		Moiseenko, I. and D. Oran, "Path Steering in CCNx and
	NDN", Work in Progress, Internet-Draft, draft-oran-icnrg-		NDN", Work in Progress, Internet-Draft, draft-oran-icnrg-
	pathsteering-04, 25 October 2021,		pathsteering-04, 25 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-oran-icnrg-		<https://datatracker.ietf.org/doc/html/draft-oran-icnrg-
	pathsteering-04>.		pathsteering-04>.
	[NDNTLV] "NDN Packet Format Specification.", in Proceedings of the		[NDNTLV] "NDN Packet Format Specification.", 2016,
	IEEE Conference on Computer Communications Workshops
	(INFOCOM WKSHPS), 2016,
	<http://named-data.net/doc/ndn-tlv/>.		<http://named-data.net/doc/ndn-tlv/>.
	[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", in Proceedings of the		centric and named data networks", in Proceedings of the
	4th ACM Conference on Information-Centric Networking,		4th ACM Conference on Information-Centric Networking,
	2017.		2017.
	[REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang,		[REALTIME] Mastorakis, S., Gusev, P., Afanasyev, A., and L. Zhang,
	"Real-Time Data Retrieval in Named Data Networking", in		"Real-Time Data Retrieval in Named Data Networking", in
	skipping to change at page 19, line 36 ¶		skipping to change at page 19, line 43 ¶
	condition that triggered the generation of the reply.		condition that triggered the generation of the reply.
	In the case that an echo reply is not received for a request within a		In the case that an echo reply is not received for a request within a
	certain time interval (lifetime of the request), the client should		certain time interval (lifetime of the request), the client should
	time-out and send a new request with a new nonce value up to some		time-out and send a new request with a new nonce value up to some
	maximum number of requests to be sent specified by the user.		maximum number of requests to be sent specified by the user.
	Authors' Addresses		Authors' Addresses
	Spyridon Mastorakis		Spyridon Mastorakis
	University of Nebraska, Omaha		University of Nebraska at Omaha
	Omaha, NE		Omaha, NE
	United States of America		United States of America
	Email: smastorakis@unomaha.edu		Email: smastorakis@unomaha.edu
	Jim Gibson		Jim Gibson
	Cisco Systems		Cisco Systems
	Cambridge, MA		Cambridge, MA
	United States of America		United States of America
	Email: gibson@cisco.com		Email: gibson@cisco.com
	Ilya Moiseenko		Ilya Moiseenko
	Apple Inc		Apple Inc
	Cupertino, CA		Cupertino, CA
	United States of America		United States of America
	Email: iliamo@mailbox.org		Email: iliamo@mailbox.org
	Ralph Droms		Ralph Droms
	Google Inc.		Google Inc.
	Cambridge, MA		Cambridge, MA
	United States of America		United States of America
	Email: rdroms.ietf@gmail.com		Email: rdroms.ietf@gmail.com
	Dave Oran		Dave Oran
	Network Systems Research and Design		Network Systems Research and Design
	Cambridge, MA		Cambridge, MA
	United States of America		United States of America
	Email: daveoran@orandom.net		Email: daveoran@orandom.net
End of changes. 26 change blocks.
	35 lines changed or deleted		35 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/