ICN Traceroute Protocol Specification
draft-irtf-icnrg-icntraceroute-10

"SNAMP: Secure namespace mapping to
              scale NDN forwarding", IEEE Conference on Computer
              Communications Workshops (INFOCOM WKSHPS), 2015.

Appendix A.  Traceroute Client Application (Consumer) Operation

   This section is an informative appendix regarding the proposed
   traceroute client operation.

   The client application is responsible for generating traceroute
   requests for prefixes provided by users.

   The overall process can be iterative: the first traceroute request of
   each session will have a HopLimit of value 1 to reach the first hop
   forwarder, the second of value 2 to reach the second hop forwarder
   and so on and so forth.

   When generating a series of requests for a specific name, the first
   one will typically not include a Path label TLV, since no TLV value
   is known.  After a traceroute reply containing a Path label TLV is
   received, each subsequent request might include the received path

Mastorakis, et al.       Expires 24 January 2024               [Page 18]
Internet-Draft               ICN Traceroute                    July 2023

   steering value in the Path label header TLV to drive the requests
   towards a common path as part of checking the network performance.
   To discover more paths, a client can omit the Path label TLV in
   future requests.  Moreover, for each new traceroute request, the
   client has to generate a new nonce and record the time that the
   request was expressed.  It will also set the lifetime of a request,
   which will have semantics similar to the lifetime of an Interest.

   Moreover, the client application might not wish to receive replies
   due to CS hits.  In CCNx, a mechanism to achieve that would be to use
   a Content Object Hash Restriction TLV with a value of 0 in the
   payload of a traceroute request message.  In NDN, the exclude filter
   selector can be used.

   When it receives a traceroute reply, the client would typically match
   the reply to a sent request and compute the round-trip time of the
   request.  It should parse the Path label value and decode the reply's
   payload to parse the sender's name and signature.  The client should
   verify that both the received message and the forwarder's name have
   been signed by the key of the forwarder, whose name is included in
   the payload of the reply (by fetching this forwarder's public key and
   verifying the contained signature).  In the case that the client
   receives an TrReply Code TLV with a valid value, it can stop sending
   requests with increasing HopLimit values and potentially start a new
   traceroute session.

   In the case that a traceroute reply is not received for a request
   within a certain time interval (lifetime of the request), the client
   should time-out and send a new request with a new nonce value up to a
   maximum number of requests to be sent specified by the user.

Authors' Addresses

   Spyridon Mastorakis
   University of Notre Dame
   South Bend, IN
   United States of America
   Email: smastor2@nd.edu

   Dave Oran
   Network Systems Research and Design
   Cambridge, MA
   United States of America
   Email: daveoran@orandom.net

Mastorakis, et al.       Expires 24 January 2024               [Page 19]
Internet-Draft               ICN Traceroute                    July 2023

   Ilya Moiseenko
   Apple Inc
   Cupertino, CA
   United States of America
   Email: iliamo@mailbox.org

   Jim Gibson
   Unaffiliated
   Belmont, MA
   United States of America
   Email: jcgibson61@gmail.com

   Ralph Droms
   Unaffiliated
   Hopkinton, MA
   United States of America
   Email: rdroms.ietf@gmail.com

Mastorakis, et al.       Expires 24 January 2024               [Page 20]