<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" consensus="true" docName="draft-irtf-icnrg-ccninfo-15" indexInclude="true" ipr="trust200902" number="9344" prepTime="2023-02-16T15:17:51" scripts="Common,Latin" sortRefs="true" submissionType="IRTF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccninfo-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9344" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="CCNinfo">CCNinfo: Discovering Content and Network Information in Content-Centric Networks</title>
    <seriesInfo name="RFC" value="9344" stream="IRTF"/>
    <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
      <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
      <address>
        <postal>
          <street>4-2-1 Nukui-Kitamachi, Koganei</street>
          <code>184-8795</code>
          <region>Tokyo</region>
          <country>Japan</country>
        </postal>
        <email>asaeda@nict.go.jp</email>
      </address>
    </author>
    <author initials="A" surname="Ooka" fullname="Atsushi Ooka">
      <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
      <address>
        <postal>
          <street>4-2-1 Nukui-Kitamachi, Koganei</street>
          <code>184-8795</code>
          <region>Tokyo</region>
          <country>Japan</country>
        </postal>
        <email>a-ooka@nict.go.jp</email>
      </address>
    </author>
    <author initials="X" surname="Shao" fullname="Xun Shao">
      <organization showOnFrontPage="true">Toyohashi University of Technology</organization>
      <address>
        <postal>
          <street>1-1 Hibarigaoka Tempaku-cho, Toyohashi</street>
          <region>Aichi</region>
          <code>441-8580</code>
          <country>Japan</country>
        </postal>
        <email>shao.xun.ls@tut.jp</email>
      </address>
    </author>
    <date month="02" year="2023"/>
    <workgroup>Information-Centric Networking</workgroup>
    <keyword>ICN</keyword>
    <keyword>CCNx</keyword>
    <keyword>NDN</keyword>
    <keyword>CCNinfo</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
   This document describes a mechanism named "CCNinfo" that discovers
   information about the network topology and in-network cache in
   Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN
   routing path information per name prefix, 2) the Round-Trip Time
   (RTT) between the content forwarder and the consumer, and 3) the states
   of in-network cache per name prefix. CCNinfo is useful to understand
   and debug the behavior of testbed networks and other experimental
   deployments of CCN systems.</t>
      <t indent="0" pn="section-abstract-2">
   This document is a product of the IRTF Information-Centric Networking
   Research Group (ICNRG). This document represents the consensus view of
   ICNRG and has been reviewed extensively by several members of the ICN
   community and the RG. The authors and RG
   chairs approve of the contents.  The document is sponsored under the IRTF,
   is not issued by the IETF, and is not an IETF standard. This is an
   experimental protocol and the specification may change in the future.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation. 
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Research
            Task Force (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the
            Information-Centric Networking Research Group of the Internet Research Task Force
            (IRTF).  Documents approved for publication by the IRSG are not
            candidates for any level of Internet Standard; see Section 2 of RFC
            7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9344" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-as-an-experimental-">CCNinfo as an Experimental Tool</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions">Definitions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-message-formats">CCNinfo Message Formats</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-message">Request Message</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-header-block-and-re">Request Header Block and Request Block</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derivedContent="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-report-block-tlv">Report Block TLV</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.3.1"><xref derivedContent="3.1.3" format="counter" sectionFormat="of" target="section-3.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-name-specification">Content Name Specification</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-message">Reply Message</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-block-tlv">Reply Block TLV</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2.1.2">
                      <li pn="section-toc.1-1.3.2.2.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.3.2.2.2.1.2.1.1"><xref derivedContent="3.2.1.1" format="counter" sectionFormat="of" target="section-3.2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-sub-block-tlv">Reply Sub-Block TLV</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-user-behavior">CCNinfo User Behavior</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-ccninfo-request">Sending CCNinfo Request</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-path-information">Routing Path Information</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-in-network-cache-informatio">In-Network Cache Information</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-ccninfo-reply">Receiving CCNinfo Reply</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-router-behavior">Router Behavior</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-user-and-neighbor-verificat">User and Neighbor Verification</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-ccninfo-request">Receiving CCNinfo Request</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-ccninfo-request">Forwarding CCNinfo Request</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-regular-request">Regular Request</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-discovery-request">Full Discovery Request</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-ccninfo-reply">Sending CCNinfo Reply</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-ccninfo-reply">Forwarding CCNinfo Reply</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pit-entry-management-for-mu">PIT Entry Management for Multipath Support</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-termination">CCNinfo Termination</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-arriving-at-first-hop-route">Arriving at First-Hop Router</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-arriving-at-router-having-c">Arriving at Router Having Cache</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-arriving-at-last-router">Arriving at Last Router</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-invalid-request">Invalid Request</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-route">No Route</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-information">No Information</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-space">No Space</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.8">
                <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fatal-error">Fatal Error</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.9">
                <t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent="6.9" format="counter" sectionFormat="of" target="section-6.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-reply-timeout">CCNinfo Reply Timeout</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.10">
                <t indent="0" pn="section-toc.1-1.6.2.10.1"><xref derivedContent="6.10" format="counter" sectionFormat="of" target="section-6.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-non-supported-node">Non-Supported Node</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.11">
                <t indent="0" pn="section-toc.1-1.6.2.11.1"><xref derivedContent="6.11" format="counter" sectionFormat="of" target="section-6.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-administratively-prohibited">Administratively Prohibited</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-configurations">Configurations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-reply-timeout-2">CCNinfo Reply Timeout</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hoplimit-in-fixed-header">HopLimit in Fixed Header</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-control">Access Control</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-diagnosis-and-analysis">Diagnosis and Analysis</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-number-of-hops-and-rtt">Number of Hops and RTT</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-caching-router-identificati">Caching Router Identification</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ttl-or-hop-limit">TTL or Hop Limit</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-time-delay">Time Delay</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-stretch">Path Stretch</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cache-hit-probability">Cache Hit Probability</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-type-registry">Packet Type Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-top-level-type-registry">Top-Level Type Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hop-by-hop-type-registry">Hop-by-Hop Type Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-type-registry">Message Type Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.5">
                <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reply-type-registry">Reply Type Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-based-information-pr">Policy-Based Information Provisioning for Request</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-filtering-ccninfo-users-loc">Filtering CCNinfo Users Located in Invalid Networks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-topology-discovery">Topology Discovery</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-characteristics-of-content">Characteristics of Content</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-computational-attacks">Computational Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.6">
                <t indent="0" pn="section-toc.1-1.10.2.6.1"><xref derivedContent="10.6" format="counter" sectionFormat="of" target="section-10.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-longer-or-shorter-ccninfo-r">Longer or Shorter CCNinfo Reply Timeout</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.7">
                <t indent="0" pn="section-toc.1-1.10.2.7.1"><xref derivedContent="10.7" format="counter" sectionFormat="of" target="section-10.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-limiting-request-rates">Limiting Request Rates</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.8">
                <t indent="0" pn="section-toc.1-1.10.2.8.1"><xref derivedContent="10.8" format="counter" sectionFormat="of" target="section-10.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-limiting-reply-rates">Limiting Reply Rates</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.9">
                <t indent="0" pn="section-toc.1-1.10.2.9.1"><xref derivedContent="10.9" format="counter" sectionFormat="of" target="section-10.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-adjacency-verification">Adjacency Verification</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ccninfo-command-and-options">ccninfo Command and Options</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec.intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">In Content-Centric Networks (CCNs), publishers provide the content through the network, and receivers retrieve it by name. In this network architecture, routers forward content requests through their Forwarding Information Bases (FIBs), which are populated by name-based routing protocols. CCN also enables receivers to retrieve content from an in-network cache.</t>
      <t indent="0" pn="section-1-2">In CCN, while consumers do not generally need to know the content forwarder that is transmitting the content to them, the operators and developers may want to identify the content forwarder and observe the routing path information per name prefix for troubleshooting or investigating the network conditions.</t>
      <t indent="0" pn="section-1-3">IP traceroute
      is a useful tool for discovering the routing conditions in IP networks because it provides intermediate router addresses along the path between the source and the destination, and the Round-Trip Time (RTT) for the path. However, this IP-based network tool cannot trace the name prefix paths used in CCN.
      Moreover, such IP-based network tools do not obtain the states of the in-network cache to be discovered.</t>
      <t indent="0" pn="section-1-4">Contrace <xref target="Contrace" format="default" sectionFormat="of" derivedContent="Contrace"/> enables end users (i.e., consumers) to investigate path and in-network cache conditions in CCN. Contrace is implemented as an external daemon process running over TCP/IP that can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the caching information on the forwarding daemon. This solution is flexible, but it requires defining the common APIs used for global deployment in TCP/IP networks. ICN (Information-Centric Networking) ping <xref target="ICN-PING" format="default" sectionFormat="of" derivedContent="ICN-PING"/> and traceroute <xref target="I-D.irtf-icnrg-icntraceroute" format="default" sectionFormat="of" derivedContent="ICN-TRACEROUTE"/> are lightweight operational tools that enable a user to explore the path(s) that reach a publisher or a cache storing the named content. ICN ping and traceroute, however, do not expose detailed information about the forwarders deployed by a network operator.</t>
      <t indent="0" pn="section-1-5">This document describes the specifications of "CCNinfo", an active networking tool for discovering the path and content-caching information in CCN.
      CCNinfo defines the protocol messages to investigate path and in-network cache conditions in CCN. It is embedded in the CCNx forwarding process and can facilitate with non-IP networks as with the basic CCN concept.</t>
      <t indent="0" pn="section-1-6">The two message types, Request and Reply messages, are encoded in the CCNx TLV format <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/>. The Request-and-Reply message flow, walking up the tree from a consumer toward a publisher, is similar to the behavior of the IP multicast traceroute facility <xref target="RFC8487" format="default" sectionFormat="of" derivedContent="RFC8487"/>.</t>
      <t indent="0" pn="section-1-7">CCNinfo facilitates the tracing of a routing path and provides 1) the RTT between the content forwarder (i.e., caching router or first-hop router) and consumer, 2) the states of the in-network cache per name prefix, and 3) the routing path information per name prefix.</t>
      <t indent="0" pn="section-1-8">In addition, CCNinfo identifies the states of the cache, such as the metrics for Content Store (CS) in the content forwarder as follows: 1) size of cached Content Objects, 2) number of cached Content Objects, 3) number of accesses (i.e., received Interests) per content, and 4) elapsed cache time and remaining cache lifetime of content.</t>
      <t indent="0" pn="section-1-9">CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. When the Request messages are forwarded to multiple routers, the different Reply messages are forwarded from different routers or publishers.</t>
      <t indent="0" pn="section-1-10">Furthermore, CCNinfo implements policy-based information provisioning that enables administrators to "hide" secure or private information but does not disrupt message forwarding. This policy-based information provisioning reduces the deployment barrier faced by operators in installing and running CCNinfo on their routers.</t>
      <t indent="0" pn="section-1-11">The document represents the consensus of the Information-Centric Networking Research Group (ICNRG). This document was read and reviewed by the active research group members. It is not an IETF product and is not a standard.</t>
      <section anchor="sec.intro.exp" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-ccninfo-as-an-experimental-">CCNinfo as an Experimental Tool</name>
        <t indent="0" pn="section-1.1-1">In order to carry out meaningful experimentation with CCNx protocols, comprehensive instrumentation and management information is needed to take measurements and explore both the performance and robustness characteristics of the protocols and of the applications using them. CCNinfo's primary goal is to gather and report this information. As experience is gained with both the CCNx protocols and CCNinfo itself, we can refine the instrumentation capabilities and discover what additional capabilities might be needed in CCNinfo and conversely which features wind up not being of sufficient value to justify the implementation complexity and execution overhead.</t>
        <t indent="0" pn="section-1.1-2">CCNinfo is intended as a comprehensive experimental tool for CCNx-based networks. It provides a wealth of information from forwarders, including on-path in-network cache conditions as well as forwarding path instrumentation of multiple paths toward content forwarders. As an experimental capability that exposes detailed information about the forwarders deployed by a network operator, CCNinfo employs more granular authorization policies than those required of ICN ping or ICN traceroute.</t>
        <t indent="0" pn="section-1.1-3">CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.g., consumer, initiates a CCNinfo Request message when they want to obtain routing path and cache information. When an adjacent neighbor router receives the Request message, it examines its own cache information. If the router does not cache the specified content, it inserts its Report block into the hop-by-hop header of the Request message and forwards the message to its upstream neighbor router(s) decided by its FIB. In <xref target="fig_request" format="default" sectionFormat="of" derivedContent="Figure 1"/>, CCNinfo user and routers (Routers A, B, C) insert their own Report blocks into the Request message and forward the message toward the content forwarder.</t>
        <figure anchor="fig_request" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-request-message-invoked-by-">Request Message Invoked by the CCNinfo User and Forwarded by Routers</name>
          <artwork align="center" name="" type="" alt="" pn="section-1.1-4.1">
       1. Request    2. Request    3. Request
          (U)           (U+A)         (U+A+B)
         +----+        +----+        +----+
         |    |        |    |        |    |
         |    v        |    v        |    v
+--------+    +--------+    +--------+    +--------+    +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
|  user  |    |   A    |    |   B    |    |   C    |    |         |
+--------+    +--------+    +--------+    +--------+    +---------+
                                     \
                                      \          +-------+
                            3. Request \         | Cache |
                               (U+A+B)  \ +---------+    |
                                         v| Caching |----+
                                          |  router |
                                          +---------+
</artwork>
        </figure>
        <t indent="0" pn="section-1.1-5">When the Request message reaches the content forwarder, the content forwarder forms the Reply message; it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message. The Reply message is then forwarded back toward the user in a hop-by-hop manner along the Pending Interest Table (PIT) entries. In <xref target="fig_reply" format="default" sectionFormat="of" derivedContent="Figure 2"/>, each router (Routers C, B, and A) forwards the Reply message along its PIT entry, and finally, the CCNinfo user receives a Reply message from Router C, which is the first-hop router for the publisher. Another Reply message from the caching router (i.e., Reply(C)) is discarded at Router B if the other Reply message (i.e., Reply(P)) was already forwarded by Router B.</t>
        <figure anchor="fig_reply" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-reply-messages-forwarded-by">Reply Messages Forwarded by Routers, and One Reply Message is Received by the CCNinfo User</name>
          <artwork align="center" name="" type="" alt="" pn="section-1.1-6.1">
       3. Reply(P)   2. Reply(P)   1. Reply(P)
         +----+        +----+        +----+
         |    |        |    |        |    |
         v    |        v    |        v    |
+--------+    +--------+    +--------+    +--------+    +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
|  user  |    |   A    |    |   B    |    |   C    |    |         |
+--------+    +--------+    +--------+    +--------+    +---------+
                                     ^
                                      \          +-------+
                           1. Reply(C) \         | Cache |
                                        \ +---------+    |
                                         \| Caching |----+
                                          |  router |
                                          +---------+
</artwork>
        </figure>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-definitions">Definitions</name>
        <t indent="0" pn="section-2.1-1">This document follows the basic terminologies and definitions described in <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/>. Although CCNinfo requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-2.1-2">
          <dt pn="section-2.1-2.1">Scheme name:</dt>
          <dd pn="section-2.1-2.2">
	    A scheme name indicates a URI and protocol. This document only considers "ccnx:/" as the scheme name.
	  </dd>
          <dt pn="section-2.1-2.3">Prefix name:</dt>
          <dd pn="section-2.1-2.4">
	    A prefix name, which is defined in <xref target="RFC8569" format="default" sectionFormat="of" derivedContent="RFC8569"/>, is a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name.
	  </dd>
          <dt pn="section-2.1-2.5">Exact name:</dt>
          <dd pn="section-2.1-2.6">
	    An exact name, which is defined in <xref target="RFC8569" format="default" sectionFormat="of" derivedContent="RFC8569"/>, is one that uniquely identifies the name of a Content Object.
	  </dd>
          <dt pn="section-2.1-2.7">Node:</dt>
          <dd pn="section-2.1-2.8">
	    A node within a CCN network can fulfill the role of a data publisher, a data consumer, and/or a forwarder for Interest and Content Object, as described in <xref target="RFC8793" format="default" sectionFormat="of" derivedContent="RFC8793"/>.
	  </dd>
          <dt pn="section-2.1-2.9">Consumer:</dt>
          <dd pn="section-2.1-2.10">
	    A node that requests Content Objects by generating and sending out Interests. It is the same definition of ICN Consumer, as given in <xref target="RFC8793" format="default" sectionFormat="of" derivedContent="RFC8793"/>.
	  </dd>
          <dt pn="section-2.1-2.11">Publisher:</dt>
          <dd pn="section-2.1-2.12">
	    A node that creates Content Objects and makes them available for retrieval. It is the same definition of ICN Producer, as given in <xref target="RFC8793" format="default" sectionFormat="of" derivedContent="RFC8793"/>.
	  </dd>
          <dt pn="section-2.1-2.13">Router:</dt>
          <dd pn="section-2.1-2.14">
	    A node that implements stateful forwarding in the path between consumer and publisher.
	  </dd>
          <dt pn="section-2.1-2.15">Caching router:</dt>
          <dd pn="section-2.1-2.16">
	    A node that temporarily stores and potentially carries Interests or Content Objects before forwarding it to the next node.
	  </dd>
          <dt pn="section-2.1-2.17">Content forwarder:</dt>
          <dd pn="section-2.1-2.18">
	    A content forwarder is either a caching router or a first-hop router that forwards Content Objects to consumers.
	  </dd>
          <dt pn="section-2.1-2.19">CCNinfo user:</dt>
          <dd pn="section-2.1-2.20">
	    A node that initiates the CCNinfo Request, which is either a consumer or a router that invokes the CCNinfo user program with the name prefix of the content. The CCNinfo user program, such as "ccninfo" command described in <xref target="sec.command" format="default" sectionFormat="of" derivedContent="Appendix A"/> or other similar commands, initiates the Request message to obtain routing path and cache information. 
	  </dd>
          <dt pn="section-2.1-2.21">Incoming face:</dt>
          <dd pn="section-2.1-2.22">
	    The face on which data are expected to arrive from the specified name prefix.
	  </dd>
          <dt pn="section-2.1-2.23">Outgoing face:</dt>
          <dd pn="section-2.1-2.24">
	    The face to which data from the publisher or router are expected to transmit for the specified name prefix. It is also the face on which the Request messages is received.
	  </dd>
          <dt pn="section-2.1-2.25">Upstream router:</dt>
          <dd pn="section-2.1-2.26">
	    The router that connects to an Incoming face of a router.
	  </dd>
          <dt pn="section-2.1-2.27">Downstream router:</dt>
          <dd pn="section-2.1-2.28">
	    The router that connects to an Outgoing face of a router.
	  </dd>
          <dt pn="section-2.1-2.29">First-hop router (FHR):</dt>
          <dd pn="section-2.1-2.30">
	    The router that matches a FIB entry with an Outgoing face referring to a local application or a publisher.
	  </dd>
          <dt pn="section-2.1-2.31">Last-hop router (LHR):</dt>
          <dd pn="section-2.1-2.32">
	    The router that is directly connected to a consumer.
	  </dd>
        </dl>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-ccninfo-message-formats">CCNinfo Message Formats</name>
      <t indent="0" pn="section-3-1">CCNinfo Request and Reply messages are encoded in the CCNx TLV format (see <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/> and <xref target="CCNx_Hdr" format="default" sectionFormat="of" derivedContent="Figure 3"/>). The Request message consists of a fixed header, Request block TLV (<xref target="Req_block" format="default" sectionFormat="of" derivedContent="Figure 5"/>), and Report block TLV(s) (<xref target="Rpt_block" format="default" sectionFormat="of" derivedContent="Figure 7"/>). The Reply message consists of a fixed header, Request block TLV, Report block TLV(s), Reply block TLV (<xref target="Reply_block" format="default" sectionFormat="of" derivedContent="Figure 9"/>), and Reply sub-block TLV(s) (<xref target="Reply_subblock" format="default" sectionFormat="of" derivedContent="Figure 10"/>).</t>
      <figure anchor="CCNx_Hdr" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-packet-format">Packet Format <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></name>
        <artwork align="center" name="" type="" alt="" pn="section-3-2.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|    Version    |  PacketType   |         PacketLength          |
+---------------+---------------+---------------+---------------+
|           PacketType specific fields          | HeaderLength  |
+---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs                               /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs                                            /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV                         /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required)  /
+---------------+---------------+---------------+---------------+
</artwork>
      </figure>
      <t indent="0" pn="section-3-3">The PacketType values in the fixed header shown in <xref target="CCNx_Hdr" format="default" sectionFormat="of" derivedContent="Figure 3"/> are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY (see <xref target="Type_val" format="default" sectionFormat="of" derivedContent="Table 1"/>). CCNinfo Request and Reply messages are forwarded in a hop-by-hop manner. When the Request message reaches the content forwarder, the content forwarder turns it into a Reply message by changing the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards it back toward the node that initiated the Request message.</t>
      <table anchor="Type_val" align="center" pn="table-1">
        <name slugifiedName="name-ccnx-packet-types">CCNx Packet Types</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x00</td>
            <td align="left" colspan="1" rowspan="1">PT_INTEREST <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x01</td>
            <td align="left" colspan="1" rowspan="1">PT_CONTENT <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x02</td>
            <td align="left" colspan="1" rowspan="1">PT_RETURN <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x03</td>
            <td align="left" colspan="1" rowspan="1">PT_CCNINFO_REQUEST</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x04</td>
            <td align="left" colspan="1" rowspan="1">PT_CCNINFO_REPLY</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-3-5">Following a fixed header, there can be a sequence of optional hop-by-hop header TLV(s) for a Request message. In the case of a Request message, it is followed by a sequence of Report blocks, each from a router on the path toward the publisher or caching router.</t>
      <t indent="0" pn="section-3-6">At the beginning of PacketPayload TLVs, a top-level TLV type, T_DISCOVERY (<xref target="Top-level_Type" format="default" sectionFormat="of" derivedContent="Table 2"/>), exists at the outermost level of a CCNx protocol message. This TLV indicates that the Name segment TLV(s) and Reply block TLV(s) would follow in the Request or Reply message.</t>
      <table anchor="Top-level_Type" align="center" pn="table-2">
        <name slugifiedName="name-ccnx-top-level-types">CCNx Top-Level Types</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0000</td>
            <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0001</td>
            <td align="left" colspan="1" rowspan="1">T_INTEREST <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0002</td>
            <td align="left" colspan="1" rowspan="1">T_OBJECT <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0003</td>
            <td align="left" colspan="1" rowspan="1">T_VALIDATION_ALG <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0004</td>
            <td align="left" colspan="1" rowspan="1">T_VALIDATION_PAYLOAD <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0x0005</td>
            <td align="left" colspan="1" rowspan="1">T_DISCOVERY</td>
          </tr>
        </tbody>
      </table>
      <section anchor="sec.request" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-request-message">Request Message</name>
        <t indent="0" pn="section-3.1-1">When a CCNinfo user initiates a discovery request (e.g., via the ccninfo command described in <xref target="sec.command" format="default" sectionFormat="of" derivedContent="Appendix A"/>), a CCNinfo Request message is created and forwarded to its upstream router through the Incoming face(s) determined by its FIB.</t>
        <t indent="0" pn="section-3.1-2">The Request message format is shown in <xref target="Req_message" format="default" sectionFormat="of" derivedContent="Figure 4"/>. It consists of a fixed header, Request header block TLV (<xref target="Req_block" format="default" sectionFormat="of" derivedContent="Figure 5"/>), Report block TLV(s) (<xref target="Rpt_block" format="default" sectionFormat="of" derivedContent="Figure 7"/>), Name TLV, and Request block TLV. Request header block TLV and Report block TLV(s) are contained in the hop-by-hop header, as those might change from hop to hop.
Request block TLV is encoded in the PacketPayload TLV by content forwarder as the protocol message itself.
The PacketType value of the Request message is PT_CCNINFO_REQUEST (<xref target="Type_val" format="default" sectionFormat="of" derivedContent="Table 1"/>). The Type value of the CCNx Top-Level type is T_DISCOVERY (<xref target="Top-level_Type" format="default" sectionFormat="of" derivedContent="Table 2"/>).</t>
        <figure anchor="Req_message" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-request-message-2">Request Message</name>
          <artwork align="center" name="" type="" alt="" pn="section-3.1-3.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|    Version    |  PacketType   |         PacketLength          |
+---------------+---------------+---------------+---------------+
|    HopLimit   |   ReturnCode  | Reserved(MBZ) | HeaderLength  |
+===============+===============+===============+===============+
/                    Request header block TLV                   /
+---------------+---------------+---------------+---------------+
/                      Report block TLV 1                       /
+---------------+---------------+---------------+---------------+
/                      Report block TLV 2                       /
+---------------+---------------+---------------+---------------+
/                               .                               /
/                               .                               /
+---------------+---------------+---------------+---------------+
/                      Report block TLV n                       /
+===============+===============+===============+===============+
|      Type (=T_DISCOVERY)      |         MessageLength         |
+---------------+---------------+---------------+---------------+
|            T_NAME             |             Length            |
+---------------+---------------+---------------+---------------+
/   Name segment TLVs (name prefix specified by CCNinfo user)   /
+---------------+---------------+---------------+---------------+
/                       Request block TLV                       /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV                         /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required)  /
+---------------+---------------+---------------+---------------+
</artwork>
        </figure>
        <dl indent="3" newline="false" spacing="normal" pn="section-3.1-4">
          <dt pn="section-3.1-4.1">HopLimit:</dt>
          <dd pn="section-3.1-4.2">
            <t indent="0" pn="section-3.1-4.2.1">8 bits</t>
            <t indent="0" pn="section-3.1-4.2.2">HopLimit is a counter that is decremented with each hop whenever a Request packet is forwarded. It is specified by the CCNinfo user program. The HopLimit value <bcp14>MUST</bcp14> be decremented by 1 prior to forwarding the Request packet. The packet is discarded if HopLimit is decremented to zero. HopLimit limits the distance that a Request may travel on the network. Only the specified number of hops from the CCNinfo user traces the Request. The last router stops the trace and sends the Reply message back to the CCNinfo user.</t>
          </dd>
          <dt pn="section-3.1-4.3">ReturnCode:</dt>
          <dd pn="section-3.1-4.4">
            <t indent="0" pn="section-3.1-4.4.1">8 bits</t>
            <t indent="0" pn="section-3.1-4.4.2">ReturnCode is used for the Reply message. This value is replaced by the content forwarder when the Request message is returned as the Reply message (see <xref target="sec.reply" format="default" sectionFormat="of" derivedContent="Section 3.2"/>). Until then, this field <bcp14>MUST</bcp14> be transmitted as zeros and ignored on receipt.</t>
            <table align="center" pn="table-3">
              <name slugifiedName="name-returncode-used-for-the-rep">ReturnCode Used for the Reply Message</name>
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">Value</th>
                  <th align="left" colspan="1" rowspan="1">Name</th>
                  <th align="left" colspan="1" rowspan="1">Description</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x00</td>
                  <td align="left" colspan="1" rowspan="1">NO_ERROR</td>
                  <td align="left" colspan="1" rowspan="1">No error</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x01</td>
                  <td align="left" colspan="1" rowspan="1">WRONG_IF</td>
                  <td align="left" colspan="1" rowspan="1">CCNinfo Request arrived on an interface to which this router would not forward for the specified name and/or function toward the publisher.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x02</td>
                  <td align="left" colspan="1" rowspan="1">INVALID_REQUEST</td>
                  <td align="left" colspan="1" rowspan="1">Invalid CCNinfo Request is received.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x03</td>
                  <td align="left" colspan="1" rowspan="1">NO_ROUTE </td>
                  <td align="left" colspan="1" rowspan="1">This router has no route for the name prefix and no way to determine a route.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x04</td>
                  <td align="left" colspan="1" rowspan="1">NO_INFO</td>
                  <td align="left" colspan="1" rowspan="1">This router has no cache information for the specified name prefix.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x05</td>
                  <td align="left" colspan="1" rowspan="1">NO_SPACE</td>
                  <td align="left" colspan="1" rowspan="1">There was not enough room to insert another Report block in the packet.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x06</td>
                  <td align="left" colspan="1" rowspan="1">INFO_HIDDEN</td>
                  <td align="left" colspan="1" rowspan="1">Information is hidden from this discovery owing to some policy.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x0E</td>
                  <td align="left" colspan="1" rowspan="1">ADMIN_PROHIB</td>
                  <td align="left" colspan="1" rowspan="1">CCNinfo Request is administratively prohibited.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x0F</td>
                  <td align="left" colspan="1" rowspan="1">UNKNOWN_REQUEST</td>
                  <td align="left" colspan="1" rowspan="1">This router does not support or recognize the Request message.</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x80</td>
                  <td align="left" colspan="1" rowspan="1">FATAL_ERROR</td>
                  <td align="left" colspan="1" rowspan="1">In a fatal error, the router may know the upstream router but cannot forward the message to it.</td>
                </tr>
              </tbody>
            </table>
          </dd>
          <dt pn="section-3.1-4.5">Reserved (MBZ):</dt>
          <dd pn="section-3.1-4.6">
            <t indent="0" pn="section-3.1-4.6.1">8 bits</t>
            <t indent="0" pn="section-3.1-4.6.2">The reserved fields in the Value field <bcp14>MUST</bcp14> be transmitted as zeros and ignored on receipt.</t>
          </dd>
        </dl>
        <section anchor="sec.request_blk" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.1">
          <name slugifiedName="name-request-header-block-and-re">Request Header Block and Request Block</name>
          <t indent="0" pn="section-3.1.1-1">When a CCNinfo user transmits the Request message, they <bcp14>MUST</bcp14> insert their Request header block TLV (<xref target="Req_block" format="default" sectionFormat="of" derivedContent="Figure 5"/>) into the hop-by-hop header and Request block TLV (<xref target="Req_nodeblock" format="default" sectionFormat="of" derivedContent="Figure 6"/>) into the message before sending it through the Incoming face(s).</t>
          <figure anchor="Req_block" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-request-header-block-tlv-ho">Request Header Block TLV (Hop-by-Hop Header)</name>
            <artwork align="center" name="" type="" alt="" pn="section-3.1.1-2.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|     Type (=T_DISC_REQHDR)     |             Length            |
+---------------+---------------+-------+-------+-------+-+-+-+-+
|           Request ID          |SkipHop|      Flags    |V|F|O|C|
+---------------+---------------+-------+-------+-------+-+-+-+-+
</artwork>
          </figure>
          <table anchor="Hop-by-hop_Type" align="center" pn="table-4">
            <name slugifiedName="name-ccnx-hop-by-hop-types">CCNx Hop-by-Hop Types</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Name</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0000</td>
                <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0001</td>
                <td align="left" colspan="1" rowspan="1">T_INTLIFE <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0002</td>
                <td align="left" colspan="1" rowspan="1">T_CACHETIME <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0003</td>
                <td align="left" colspan="1" rowspan="1">T_MSGHASH <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0004-0x0007</td>
                <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0008</td>
                <td align="left" colspan="1" rowspan="1">T_DISC_REQHDR</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0009</td>
                <td align="left" colspan="1" rowspan="1">T_DISC_REPORT</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0FFE</td>
                <td align="left" colspan="1" rowspan="1">T_PAD <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0FFF</td>
                <td align="left" colspan="1" rowspan="1">T_ORG <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x1000-0x1FFF</td>
                <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
            </tbody>
          </table>
          <dl indent="3" newline="false" spacing="normal" pn="section-3.1.1-4">
            <dt pn="section-3.1.1-4.1">Type:</dt>
            <dd pn="section-3.1.1-4.2">
              <t indent="0" pn="section-3.1.1-4.2.1">16 bits</t>
              <t indent="0" pn="section-3.1.1-4.2.2">Format of the Value field. The type value of the Request header block TLV <bcp14>MUST</bcp14> be T_DISC_REQHDR.</t>
            </dd>
            <dt pn="section-3.1.1-4.3">Length:</dt>
            <dd pn="section-3.1.1-4.4">
              <t indent="0" pn="section-3.1.1-4.4.1">16 bits</t>
              <t indent="0" pn="section-3.1.1-4.4.2">Length of the Value field in octets.</t>
            </dd>
            <dt pn="section-3.1.1-4.5">Request ID:</dt>
            <dd pn="section-3.1.1-4.6">
              <t indent="0" pn="section-3.1.1-4.6.1">16 bits</t>
              <t indent="0" pn="section-3.1.1-4.6.2">This field is used as a unique identifier for the CCNinfo Request so that the duplicate or delayed Reply messages can be detected.</t>
            </dd>
            <dt pn="section-3.1.1-4.7">SkipHop (Skip Hop Count):</dt>
            <dd pn="section-3.1.1-4.8">
              <t indent="0" pn="section-3.1.1-4.8.1">4 bits</t>
              <t indent="0" pn="section-3.1.1-4.8.2">Number of skipped routers for a Request. It is specified by the CCNinfo user program. The number of routers corresponding to the value specified in this field are skipped, and the CCNinfo Request messages are forwarded to the next router without the addition of Report blocks; the next upstream router then starts the trace.
The maximum value of this parameter is 15. This value <bcp14>MUST</bcp14> be lower than that of HopLimit at the fixed header.</t>
            </dd>
            <dt pn="section-3.1.1-4.9">Flags:</dt>
            <dd pn="section-3.1.1-4.10">
              <t indent="0" pn="section-3.1.1-4.10.1">12 bits</t>
              <t indent="0" pn="section-3.1.1-4.10.2">The Flags field is used to indicate the types of the content or path discoveries. Currently, as shown in <xref target="FlagVal" format="default" sectionFormat="of" derivedContent="Table 5"/>, four bits ("C", "O", "F", and "V") are assigned, and the other 8 bits are reserved (MBZ) for the future use. Each flag can be mutually specified with other flags. These flags are set by the CCNinfo user program when they initiate Requests (see <xref target="sec.command" format="default" sectionFormat="of" derivedContent="Appendix A"/>), and the routers that receive the Requests deal with the flags and change the behaviors (see <xref target="sec.router" format="default" sectionFormat="of" derivedContent="Section 5"/> for details). The Flag values defined in this Flags field correspond to the Reply sub-blocks.</t>
              <table anchor="FlagVal" align="center" pn="table-5">
                <name slugifiedName="name-codes-and-types-specified-i">Codes and Types Specified in Flags Field</name>
                <thead>
                  <tr>
                    <th align="left" colspan="1" rowspan="1">Flag</th>
                    <th align="left" colspan="1" rowspan="1">Value</th>
                    <th align="left" colspan="1" rowspan="1">Description</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">C</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">Path discovery (i.e., no cache information retrieved) (default)</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">C</td>
                    <td align="left" colspan="1" rowspan="1">1</td>
                    <td align="left" colspan="1" rowspan="1">Path and cache information retrieval</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">O</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">Request to any content forwarder (default)</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">O</td>
                    <td align="left" colspan="1" rowspan="1">1</td>
                    <td align="left" colspan="1" rowspan="1">Publisher discovery (i.e., only FHR can reply)</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">F</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">Request based on FIB's forwarding strategy (default)</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">F</td>
                    <td align="left" colspan="1" rowspan="1">1</td>
                    <td align="left" colspan="1" rowspan="1">Full discovery request. Request to possible multiple upstream routers specified in FIB simultaneously</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">V</td>
                    <td align="left" colspan="1" rowspan="1">0</td>
                    <td align="left" colspan="1" rowspan="1">No reply validation (default)</td>
                  </tr>
                  <tr>
                    <td align="left" colspan="1" rowspan="1">V</td>
                    <td align="left" colspan="1" rowspan="1">1</td>
                    <td align="left" colspan="1" rowspan="1">Reply sender validates Reply message</td>
                  </tr>
                </tbody>
              </table>
            </dd>
          </dl>
          <figure anchor="Req_nodeblock" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-request-block-tlv-packet-pa">Request Block TLV (Packet Payload)</name>
            <artwork align="center" name="" type="" alt="" pn="section-3.1.1-5.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|       Type (=T_DISC_REQ)      |             Length            |
+---------------+---------------+---------------+---------------+
|                     Request Arrival Time                      |
+---------------+---------------+---------------+---------------+
/                        Node Identifier                        /
+---------------+---------------+---------------+---------------+
</artwork>
          </figure>
          <table anchor="CCNx_Type" align="center" pn="table-6">
            <name slugifiedName="name-ccnx-message-types">CCNx Message Types</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Name</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0000</td>
                <td align="left" colspan="1" rowspan="1">T_NAME <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0001</td>
                <td align="left" colspan="1" rowspan="1">T_PAYLOAD <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0002</td>
                <td align="left" colspan="1" rowspan="1">T_KEYIDRESTR <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0003</td>
                <td align="left" colspan="1" rowspan="1">T_OBJHASHRESTR <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0005</td>
                <td align="left" colspan="1" rowspan="1">T_PAYLDTYPE <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0006</td>
                <td align="left" colspan="1" rowspan="1">T_EXPIRY <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0007-0x000C</td>
                <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x000D</td>
                <td align="left" colspan="1" rowspan="1">T_DISC_REQ</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x000E</td>
                <td align="left" colspan="1" rowspan="1">T_DISC_REPLY</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0FFE</td>
                <td align="left" colspan="1" rowspan="1">T_PAD <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x0FFF</td>
                <td align="left" colspan="1" rowspan="1">T_ORG <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">0x1000-0x1FFF</td>
                <td align="left" colspan="1" rowspan="1">Reserved <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/></td>
              </tr>
            </tbody>
          </table>
          <dl indent="3" newline="false" spacing="normal" pn="section-3.1.1-7">
            <dt pn="section-3.1.1-7.1">Type:</dt>
            <dd pn="section-3.1.1-7.2">
              <t indent="0" pn="section-3.1.1-7.2.1">16 bits</t>
              <t indent="0" pn="section-3.1.1-7.2.2">Format of the Value field. For the Request block TLV, the type value(s) <bcp14>MUST</bcp14> be T_DISC_REQ (see <xref target="CCNx_Type" format="default" sectionFormat="of" derivedContent="Table 6"/>) in the current specification.</t>
            </dd>
            <dt pn="section-3.1.1-7.3">Length:</dt>
            <dd pn="section-3.1.1-7.4">
              <t indent="0" pn="section-3.1.1-7.4.1">16 bits</t>
              <t indent="0" pn="section-3.1.1-7.4.2">Length of the Value field in octets.</t>
            </dd>
            <dt pn="section-3.1.1-7.5">Request Arrival Time:</dt>
            <dd pn="section-3.1.1-7.6">
              <t indent="0" pn="section-3.1.1-7.6.1">32 bits</t>
              <t indent="0" pn="section-3.1.1-7.6.2">The Request Arrival Time is a 32-bit NTP timestamp specifying the
      arrival time of the CCNinfo Request message at the router.  The
      32-bit form of an NTP timestamp consists of the middle 32 bits of
      the full 64-bit form, that is, the low 16 bits of the integer part
	    and the high 16 bits of the fractional part.</t>
              <t indent="0" pn="section-3.1.1-7.6.3">The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp:</t>
              <artwork name="" type="" align="left" alt="" pn="section-3.1.1-7.6.4">
request_arrival_time
= ((tv.tv_sec + 32384) &lt;&lt; 16) + ((tv.tv_nsec &lt;&lt; 7) / 1953125)
</artwork>
              <t indent="0" pn="section-3.1.1-7.6.5"> The constant 32384 is the number of seconds from Jan 1, 1900 to
      Jan 1, 1970 truncated to 16 bits.  ((tv.tv_nsec &lt;&lt; 7) / 1953125) is a reduction of ((tv.tv_nsec / 1000000000) &lt;&lt; 16), where "&lt;&lt;" denotes a logical left shift.</t>
              <t indent="0" pn="section-3.1.1-7.6.6"> Note that it is <bcp14>RECOMMENDED</bcp14> for all the routers on the path to
      have synchronized clocks to measure one-way latency per hop;
      however, even if they do not have synchronized clocks, CCNinfo
      measures the RTT between the content forwarder and the consumer.</t>
            </dd>
            <dt pn="section-3.1.1-7.7">Node Identifier:</dt>
            <dd pn="section-3.1.1-7.8">
              <t indent="0" pn="section-3.1.1-7.8.1">variable length</t>
              <t indent="0" pn="section-3.1.1-7.8.2">This field specifies the node identifier (e.g., node name or hash-based self-certifying name <xref target="DCAuth" format="default" sectionFormat="of" derivedContent="DCAuth"/>) or all-zeros if unknown. This document assumes that the Name TLV defined in the CCNx TLV format <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/> can be used for this field and the node identifier is specified in it.</t>
            </dd>
          </dl>
        </section>
        <section anchor="sec.report_blk" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.2">
          <name slugifiedName="name-report-block-tlv">Report Block TLV</name>
          <t indent="0" pn="section-3.1.2-1">A CCNinfo user and each upstream router along the path would insert their own Report block TLV without changing the Type field of the fixed header of the Request message until one of these routers is ready to send a Reply. In the Report block TLV (<xref target="Rpt_block" format="default" sectionFormat="of" derivedContent="Figure 7"/>), the Request Arrival Time and Node Identifier values <bcp14>MUST</bcp14> be inserted.</t>
          <figure anchor="Rpt_block" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-report-block-tlv-hop-by-hop">Report Block TLV (Hop-by-Hop Header)</name>
            <artwork align="center" name="" type="" alt="" pn="section-3.1.2-2.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|     Type (=T_DISC_REPORT)     |             Length            |
+---------------+---------------+---------------+---------------+
|                     Request Arrival Time                      |
+---------------+---------------+---------------+---------------+
/                        Node Identifier                        /
+---------------+---------------+---------------+---------------+
</artwork>
          </figure>
          <dl indent="3" newline="false" spacing="normal" pn="section-3.1.2-3">
            <dt pn="section-3.1.2-3.1">Type:</dt>
            <dd pn="section-3.1.2-3.2">
              <t indent="0" pn="section-3.1.2-3.2.1">16 bits</t>
              <t indent="0" pn="section-3.1.2-3.2.2">Format of the Value field. For the Report block TLV, the type value(s) <bcp14>MUST</bcp14> be T_DISC_REPORT in the current specification. For all the available types of the CCNx hop-by-hop types, please see <xref target="Hop-by-hop_Type" format="default" sectionFormat="of" derivedContent="Table 4"/>.</t>
            </dd>
            <dt pn="section-3.1.2-3.3">Length:</dt>
            <dd pn="section-3.1.2-3.4">
              <t indent="0" pn="section-3.1.2-3.4.1">16 bits</t>
              <t indent="0" pn="section-3.1.2-3.4.2">Length of the Value field in octets.</t>
            </dd>
            <dt pn="section-3.1.2-3.5">Request Arrival Time:</dt>
            <dd pn="section-3.1.2-3.6">
              <t indent="0" pn="section-3.1.2-3.6.1">32 bits</t>
              <t indent="0" pn="section-3.1.2-3.6.2">Same definition as given in <xref target="sec.request_blk" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>.</t>
            </dd>
            <dt pn="section-3.1.2-3.7">Node Identifier:</dt>
            <dd pn="section-3.1.2-3.8">
              <t indent="0" pn="section-3.1.2-3.8.1">variable length</t>
              <t indent="0" pn="section-3.1.2-3.8.2">Same definition as given in <xref target="sec.request_blk" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>.</t>
            </dd>
          </dl>
        </section>
        <section anchor="sec.namespec" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.3">
          <name slugifiedName="name-content-name-specification">Content Name Specification</name>
          <t indent="0" pn="section-3.1.3-1">Specifications of the Name TLV (whose type value is T_NAME) and the Name Segment TLVs are described in <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/>, which is followed by CCNinfo. CCNinfo enables the specification of the content name with either a prefix name without chunk number (such as "ccnx:/news/today") or an exact name (such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix name, they will obtain the summary information of the matched Content Objects in the content forwarder. In contrast, when a CCNinfo user specifies an exact name, they will obtain information only about the specified Content Object in the content forwarder. A CCNinfo Request message <bcp14>MUST NOT</bcp14> be sent only with a scheme name, ccnx:/. It will be rejected and discarded by routers.</t>
        </section>
      </section>
      <section anchor="sec.reply" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-reply-message">Reply Message</name>
        <t indent="0" pn="section-3.2-1">When a content forwarder receives a CCNinfo Request message from an appropriate adjacent neighbor router, it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message and turns the Request into the Reply by changing the Type field of the fixed header of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see <xref target="Reply_message" format="default" sectionFormat="of" derivedContent="Figure 8"/>) is then forwarded back toward the CCNinfo user in a hop-by-hop manner.</t>
        <figure anchor="Reply_message" align="left" suppress-title="false" pn="figure-8">
          <name slugifiedName="name-reply-message-2">Reply Message</name>
          <artwork align="center" name="" type="" alt="" pn="section-3.2-2.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|    Version    |  PacketType   |         PacketLength          |
+---------------+---------------+-------------+-+---------------+
|    HopLimit   |   ReturnCode  | Reserved(MBZ) | HeaderLength  |
+===============+===============+=============+=+===============+
/                    Request header block TLV                   /
+---------------+---------------+---------------+---------------+
/                               .                               /
/                               .                               /
/                      n Report block TLVs                      /
/                               .                               /
/                               .                               /
+===============+===============+===============+===============+
|      Type (=T_DISCOVERY)      |         MessageLength         |
+---------------+---------------+---------------+---------------+
|            T_NAME             |             Length            |
+---------------+---------------+---------------+---------------+
/   Name segment TLVs (name prefix specified by CCNinfo user)   /
+---------------+---------------+---------------+---------------+
/                       Request block TLV                       /
+---------------+---------------+---------------+---------------+
/                        Reply block TLV                        /
+---------------+---------------+---------------+---------------+
/                     Reply sub-block TLV 1                     /
+---------------+---------------+---------------+---------------+
/                               .                               /
/                               .                               /
+---------------+---------------+---------------+---------------+
/                     Reply sub-block TLV k                     /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV                         /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required)  /
+---------------+---------------+---------------+---------------+
</artwork>
        </figure>
        <section anchor="sec.reply_blk" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-reply-block-tlv">Reply Block TLV</name>
          <t indent="0" pn="section-3.2.1-1">The Reply block TLV is an envelope for the Reply sub-block TLV(s) (explained in the next section).</t>
          <figure anchor="Reply_block" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-reply-block-tlv-packet-payl">Reply Block TLV (Packet Payload)</name>
            <artwork align="center" name="" type="" alt="" pn="section-3.2.1-2.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|      Type (=T_DISC_REPLY)     |             Length            |
+---------------+---------------+---------------+---------------+
|                     Request Arrival Time                      |
+---------------+---------------+---------------+---------------+
/                        Node Identifier                        /
+---------------+---------------+---------------+---------------+
</artwork>
          </figure>
          <dl indent="3" newline="false" spacing="normal" pn="section-3.2.1-3">
            <dt pn="section-3.2.1-3.1">Type:</dt>
            <dd pn="section-3.2.1-3.2">
              <t indent="0" pn="section-3.2.1-3.2.1">16 bits</t>
              <t indent="0" pn="section-3.2.1-3.2.2">Format of the Value field. For the Reply block TLV, the type value <bcp14>MUST</bcp14> be T_DISC_REPLY shown in <xref target="CCNx_Type" format="default" sectionFormat="of" derivedContent="Table 6"/> in the current specification.</t>
            </dd>
            <dt pn="section-3.2.1-3.3">Length:</dt>
            <dd pn="section-3.2.1-3.4">
              <t indent="0" pn="section-3.2.1-3.4.1">16 bits</t>
              <t indent="0" pn="section-3.2.1-3.4.2">Length of the Value field in octets. This length is the total length of the Reply sub-block(s).</t>
            </dd>
            <dt pn="section-3.2.1-3.5">Request Arrival Time:</dt>
            <dd pn="section-3.2.1-3.6">
              <t indent="0" pn="section-3.2.1-3.6.1">32 bits</t>
              <t indent="0" pn="section-3.2.1-3.6.2">Same definition as given in <xref target="sec.request_blk" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>.</t>
            </dd>
            <dt pn="section-3.2.1-3.7">Node Identifier:</dt>
            <dd pn="section-3.2.1-3.8">
              <t indent="0" pn="section-3.2.1-3.8.1">variable length</t>
              <t indent="0" pn="section-3.2.1-3.8.2">Same definition as given in <xref target="sec.request_blk" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>.</t>
            </dd>
          </dl>
          <section anchor="sec.reply_subblk" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1.1">
            <name slugifiedName="name-reply-sub-block-tlv">Reply Sub-Block TLV</name>
            <t indent="0" pn="section-3.2.1.1-1">The router on the traced path will add one or multiple Reply sub-blocks followed by the Reply block TLV before sending the Reply to its neighbor router. This section describes the Reply sub-block TLV for informing various cache states and conditions as shown in <xref target="Reply_subblock" format="default" sectionFormat="of" derivedContent="Figure 10"/>. (Other Reply sub-block TLVs will be discussed in separate document(s).)</t>
            <t indent="0" pn="section-3.2.1.1-2">Note that some routers may not be capable of reporting the following values: Object Size, Object Count, # Received Interest, First Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime (shown in <xref target="Reply_subblock" format="default" sectionFormat="of" derivedContent="Figure 10"/>). Or, some routers do not report these values due to their policy. In that case, the routers <bcp14>MUST</bcp14> set these fields to a value of all ones (i.e., 0xFFFFFFFF). The value of each field <bcp14>MUST</bcp14> be also all-one when the value is equal to or bigger than the maximum size expressed by the 32-bit field. The CCNinfo user program <bcp14>MUST</bcp14> inform that these values are not valid if the fields received are set to the value of all ones.</t>
            <t indent="0" pn="section-3.2.1.1-3">If the cache is refreshed after reboot, the value in each field <bcp14>MUST</bcp14> be refreshed (i.e., <bcp14>MUST</bcp14> be set to 0). If the cache remains after reboot, the value <bcp14>MUST NOT</bcp14> be refreshed (i.e., <bcp14>MUST</bcp14> be reflected as it is).</t>
            <figure anchor="Reply_subblock" align="left" suppress-title="false" pn="figure-10">
              <name slugifiedName="name-reply-sub-block-tlv-for-t_d">Reply Sub-Block TLV for T_DISC_CONTENT and T_DISC_CONTENT_PUBLISHER (Packet Payload)</name>
              <artwork align="center" name="" type="" alt="" pn="section-3.2.1.1-4.1">
                     1                   2                   3
 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
+---------------+---------------+---------------+---------------+
|             Type              |             Length            |
+---------------+---------------+---------------+---------------+
|                          Object Size                          |
+---------------+---------------+---------------+---------------+
|                         Object Count                          |
+---------------+---------------+---------------+---------------+
|                      # Received Interest                      |
+---------------+---------------+---------------+---------------+
|                         First Seqnum                          |
+---------------+---------------+---------------+---------------+
|                          Last Seqnum                          |
+---------------+---------------+---------------+---------------+
|                       Elapsed Cache Time                      |
+---------------+---------------+---------------+---------------+
|                      Remain Cache Lifetime                    |
+---------------+---------------+---------------+---------------+
|            T_NAME             |             Length            |
+---------------+---------------+---------------+---------------+
/                       Name Segment TLVs                       /
+---------------+---------------+---------------+---------------+
</artwork>
            </figure>
            <table anchor="Sub_Type" align="center" pn="table-7">
              <name slugifiedName="name-ccnx-reply-types">CCNx Reply Types</name>
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">Type</th>
                  <th align="left" colspan="1" rowspan="1">Name</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x0000</td>
                  <td align="left" colspan="1" rowspan="1">T_DISC_CONTENT</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x0001</td>
                  <td align="left" colspan="1" rowspan="1">T_DISC_CONTENT_PUBLISHER</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x0FFF</td>
                  <td align="left" colspan="1" rowspan="1">T_ORG</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">0x1000-0x1FFF</td>
                  <td align="left" colspan="1" rowspan="1">Reserved for Experimental Use</td>
                </tr>
              </tbody>
            </table>
            <dl indent="3" newline="false" spacing="normal" pn="section-3.2.1.1-6">
              <dt pn="section-3.2.1.1-6.1">Type:</dt>
              <dd pn="section-3.2.1.1-6.2">
                <t indent="0" pn="section-3.2.1.1-6.2.1">16 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.2.2">Format of the Value field. For the Reply sub-block TLV, the type value <bcp14>MUST</bcp14> be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER defined in the CCNx Reply Types (<xref target="Sub_Type" format="default" sectionFormat="of" derivedContent="Table 7"/>).

 T_DISC_CONTENT is specified when a content forwarder replies with the cache information. T_DISC_CONTENT_PUBLISHER is specified when a FHR attached to a publisher replies with the original content information.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.3">Length:</dt>
              <dd pn="section-3.2.1.1-6.4">
                <t indent="0" pn="section-3.2.1.1-6.4.1">16 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.4.2">Length of the Value field in octets.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.5">Object Size:</dt>
              <dd pn="section-3.2.1.1-6.6">
                <t indent="0" pn="section-3.2.1.1-6.6.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.6.2">The total size (KB) of the unexpired Content Objects. Values less than 1 KB are truncated. Note that the maximum size expressed by the 32-bit field is approximately 4.29 TB.
                </t>
              </dd>
              <dt pn="section-3.2.1.1-6.7">Object Count:</dt>
              <dd pn="section-3.2.1.1-6.8">
                <t indent="0" pn="section-3.2.1.1-6.8.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.8.2">The number of the unexpired Content Objects. Note that the maximum count expressed by the 32-bit field is approximately 4.29 billion.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.9"># Received Interest:</dt>
              <dd pn="section-3.2.1.1-6.10">
                <t indent="0" pn="section-3.2.1.1-6.10.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.10.2">The total number of the received Interest messages to retrieve the cached Content Objects.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.11">First Seqnum:</dt>
              <dd pn="section-3.2.1.1-6.12">
                <t indent="0" pn="section-3.2.1.1-6.12.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.12.2">The first sequential number of the unexpired Content Objects.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.13">Last Seqnum:</dt>
              <dd pn="section-3.2.1.1-6.14">
                <t indent="0" pn="section-3.2.1.1-6.14.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.14.2">The last sequential number of the unexpired Content Objects. The First Seqnum and Last Seqnum do not guarantee the consecutiveness of the cached Content Objects; however, knowing these values may help in the analysis of consecutive or discontinuous chunks such as <xref target="CONSEC-CACHING" format="default" sectionFormat="of" derivedContent="CONSEC-CACHING"/>.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.15">Elapsed Cache Time:</dt>
              <dd pn="section-3.2.1.1-6.16">
                <t indent="0" pn="section-3.2.1.1-6.16.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.16.2">The elapsed time (seconds) after the oldest Content Object of the content is cached.</t>
              </dd>
              <dt pn="section-3.2.1.1-6.17">Remain Cache Lifetime:</dt>
              <dd pn="section-3.2.1.1-6.18">
                <t indent="0" pn="section-3.2.1.1-6.18.1">32 bits</t>
                <t indent="0" pn="section-3.2.1.1-6.18.2">The lifetime (seconds) of a Content Object, which is lastly cached.
</t>
              </dd>
            </dl>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sec.user" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-ccninfo-user-behavior">CCNinfo User Behavior</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-sending-ccninfo-request">Sending CCNinfo Request</name>
        <t indent="0" pn="section-4.1-1">A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) that initiates a CCNinfo Request message and sends it to the user's adjacent neighbor router(s) of interest. The user later obtains both the routing path information and in-network cache information in the single Reply.</t>
        <t indent="0" pn="section-4.1-2">When the CCNinfo user program initiates a Request message, it <bcp14>MUST</bcp14> insert the necessary values, i.e., the "Request ID" and the "Node Identifier", in the Request block. The Request ID <bcp14>MUST</bcp14> be unique for the CCNinfo user until they receive the corresponding Reply message(s) or the Request is timed out.</t>
        <t indent="0" pn="section-4.1-3">Owing to some policies, a router may want to validate the CCNinfo Requests using the CCNx ValidationPayload TLV (whether it accepts the Request or not) especially when the router receives the "full discovery request" (see <xref target="sec.forward.full-request" format="default" sectionFormat="of" derivedContent="Section 5.3.2"/>). Accordingly, the CCNinfo user program <bcp14>MAY</bcp14> require validating the Request message and appending the user's signature into the CCNx ValidationPayload TLV. The router then forwards the Request message. If the router does not approve the Request, it rejects the Request message as described in <xref target="sec.admin_prohibit" format="default" sectionFormat="of" derivedContent="Section 6.11"/>.</t>
        <t indent="0" pn="section-4.1-4">After the CCNinfo user program sends the Request message, until the
   Reply is timed out or the expected numbers of Replies or a Reply
   message with a non-zero ReturnCode in the fixed header is received,
   the CCNinfo user program <bcp14>MUST</bcp14> keep the following information:
   HopLimit (specified in the fixed header), Request ID and Flags
   (specified in the Request header block), and Node Identifier and 
   Request Arrival Time (specified in the Request block).</t>
        <section anchor="sec.usr.path" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-routing-path-information">Routing Path Information</name>
          <t indent="0" pn="section-4.1.1-1">A CCNinfo user can send a CCNinfo Request for investigating the routing path information for the specified named content. Using the Request, a legitimate user can obtain 1) the node identifiers of the intermediate routers, 2) the node identifier of the content forwarder, 3) the number of hops between the content forwarder and the consumer, and 4) the RTT between the content forwarder and the consumer, per name prefix. This CCNinfo Request is terminated when it reaches the content forwarder.</t>
        </section>
        <section anchor="sec.usr.cache" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-in-network-cache-informatio">In-Network Cache Information</name>
          <t indent="0" pn="section-4.1.2-1">A CCNinfo user can send a CCNinfo Request for investigating in-network cache information. Using the Request, a legitimate user can obtain 1) the size of cached Content Objects, 2) the number of cached Content Objects, 3) the number of accesses (i.e., received Interests) per content, and 4) the lifetime and expiration time of the cached Content Objects, for Content Store (CS) in the content forwarder, unless the content forwarder is capable of reporting them (see <xref target="sec.reply_subblk" format="default" sectionFormat="of" derivedContent="Section 3.2.1.1"/>). This CCNinfo Request is terminated when it reaches the content forwarder.</t>
        </section>
      </section>
      <section anchor="sec.receiving_reply" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-receiving-ccninfo-reply">Receiving CCNinfo Reply</name>
        <t indent="0" pn="section-4.2-1">A CCNinfo user program will receive one or multiple CCNinfo Reply messages from the adjacent neighbor router(s). When the program receives the Reply, it <bcp14>MUST</bcp14> compare the kept Request ID and Node Identifier values to identify the Request and Reply pair.
	If they do not match, the Reply message <bcp14>MUST</bcp14> be silently discarded.</t>
        <t indent="0" pn="section-4.2-2">If the number of Report blocks in the received Reply is more than the initial HopLimit value (which was inserted in the original Request), the Reply <bcp14>MUST</bcp14> be silently ignored.</t>
        <t indent="0" pn="section-4.2-3">After the CCNinfo user has determined that they have traced the whole path or the maximum path that they can be expected to, they might collect statistics by waiting for a timeout. Useful statistics provided by CCNinfo are stated in <xref target="sec.diag" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
      </section>
    </section>
    <section anchor="sec.router" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-router-behavior">Router Behavior</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-user-and-neighbor-verificat">User and Neighbor Verification</name>
        <t indent="0" pn="section-5.1-1">Upon receiving a CCNinfo Request message, a router <bcp14>MAY</bcp14> examine whether a valid CCNinfo user has sent the message. If the router recognizes that the Request sender's signature specified in the Request is invalid, it <bcp14>SHOULD</bcp14> terminate the Request, as defined in <xref target="sec.terminate.invalid" format="default" sectionFormat="of" derivedContent="Section 6.4"/>.</t>
        <t indent="0" pn="section-5.1-2">Upon receiving a CCNinfo Request or Reply message, a router <bcp14>MAY</bcp14> examine whether the message comes from a valid adjacent neighbor node. If the router recognizes that the Request or Reply sender is invalid, it <bcp14>SHOULD</bcp14> silently ignore the message, as specified in <xref target="sec.adjacency" format="default" sectionFormat="of" derivedContent="Section 10.9"/>.</t>
      </section>
      <section anchor="sec.receive.req" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-receiving-ccninfo-request">Receiving CCNinfo Request</name>
        <t indent="0" pn="section-5.2-1">After a router accepts the CCNinfo Request message, it performs the following steps.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.2-2"><li pn="section-5.2-2.1" derivedCounter="1.">The value of "HopLimit" in the fixed header and the value of "SkipHop (Skip Hop Count)" in the Request block are counters that are decremented with each hop. If the HopLimit value is zero, the router terminates the Request, as defined in <xref target="sec.terminate.no_route" format="default" sectionFormat="of" derivedContent="Section 6.5"/>. If the SkipHop value is equal to or more than the HopLimit value, the router terminates the Request, as defined in <xref target="sec.terminate.invalid" format="default" sectionFormat="of" derivedContent="Section 6.4"/>; otherwise, until the SkipHop value becomes zero, the router forwards the Request message to the upstream router(s) without adding its own Report block and without replying to the Request. If the router does not know the upstream router(s) regarding the specified name prefix, it terminates the Request, as defined in <xref target="sec.terminate.no_route" format="default" sectionFormat="of" derivedContent="Section 6.5"/>. It should be noted that the Request messages are terminated at the FHR; therefore, although the maximum value for the HopLimit is 255 and that for SkipHop is 15, if the Request messages reach the FHR before the HopLimit or SkipHop value becomes 0, the FHR silently discards the Request message and the Request is timed out.</li>
          <li pn="section-5.2-2.2" derivedCounter="2.">The router examines the Flags field (specified in <xref target="FlagVal" format="default" sectionFormat="of" derivedContent="Table 5"/>) in the Request block of the received CCNinfo Request. If the "C" flag is not set, it is categorized as the "routing path information discovery". If the "C" flag is set, it is the "cache information discovery". If the "O" flag is set, it is the "publisher discovery".</li>
          <li pn="section-5.2-2.3" derivedCounter="3.">If the Request is either "cache information discovery" or "routing path information discovery", the router examines its FIB and CS. If the router caches the specified content, it sends the Reply message with its own Reply block and sub-block(s). If the router cannot insert its own Reply block or sub-block(s) because of no space, it terminates the Request, as specified in <xref target="sec.terminate.no_space" format="default" sectionFormat="of" derivedContent="Section 6.7"/>.
	  If the router does not cache the specified content but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, inserts its own Report block in the hop-by-hop header, and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block because of no space, or if the router does not cache the specified content and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in <xref target="sec.terminate.no_route" format="default" sectionFormat="of" derivedContent="Section 6.5"/>.</li>
          <li pn="section-5.2-2.4" derivedCounter="4.">If the Request is the "publisher discovery", the router examines whether it is the FHR for the requested content. If the router is the FHR, it sends the Reply message with its own Report block and sub-blocks (in the case of cache information discovery) or the Reply message with its own Report block without adding any Reply sub-blocks (in the case of routing path information discovery). If the router is not the FHR but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, inserts its own Report block, and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block in the hop-by-hop header because of no space, it terminates the Request, as specified in <xref target="sec.terminate.no_space" format="default" sectionFormat="of" derivedContent="Section 6.7"/>. If the router is not the FHR and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in <xref target="sec.terminate.no_route" format="default" sectionFormat="of" derivedContent="Section 6.5"/>. Note that in Cefore <xref target="Cefore-site" format="default" sectionFormat="of" derivedContent="Cefore-site"/>, there is an API by which a publisher informs the application prefix to the FHR, and the FHR registers it into the FIB. The prefix entry then can be statically configured on other routers or announced by a routing protocol.</li>
        </ol>
      </section>
      <section anchor="sec.forward.request" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-forwarding-ccninfo-request">Forwarding CCNinfo Request</name>
        <section anchor="sec.forward.regular" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-regular-request">Regular Request</name>
          <t indent="0" pn="section-5.3.1-1">When a router decides to forward a Request message with its Report block to its upstream router(s), it specifies the Request Arrival Time and Node Identifier values in the Report block of the Request message. The router then forwards the Request message upstream toward the publisher or caching router based on the FIB entry like the ordinary Interest-Data exchanges in CCN.</t>
          <t indent="0" pn="section-5.3.1-2">When the router forwards the Request message, it <bcp14>MUST</bcp14> record the F flag and Request ID in the Request block of the Request message and exploiting path labels (specified in <xref target="sec.intro" format="default" sectionFormat="of" derivedContent="Section 1"/>) at the corresponding PIT entry.
	  The router can later check the PIT entry to correctly forward the Reply message(s) back.</t>
          <t indent="0" pn="section-5.3.1-3">CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers.
Some routers may have a strategy for multipath forwarding; when a router sends Interest messages to multiple neighbor routers, it may delay or prioritize to send the message to the upstream routers. The CCNinfo Request, as the default, complies with such strategies; a CCNinfo user could trace the actual forwarding path based on the forwarding strategy and will receive a single Reply message such as a Content Object.</t>
        </section>
        <section anchor="sec.forward.full-request" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-full-discovery-request">Full Discovery Request</name>
          <t indent="0" pn="section-5.3.2-1">There may be a case wherein a CCNinfo user wants to discover all possible forwarding paths and content forwarders based on the routers' FIBs. The "full discovery request" enables this functionality.
	If a CCNinfo user sets the F flag in the Request block of the Request message (as seen in <xref target="FlagVal" format="default" sectionFormat="of" derivedContent="Table 5"/>) to request the full discovery, the upstream routers simultaneously forward the Requests to all multiple upstream routers based on the FIBs. Then, the CCNinfo user can trace all possible forwarding paths. As seen in <xref target="fig_reply_force" format="default" sectionFormat="of" derivedContent="Figure 11"/>, each router forwards the Reply message along its PIT entry, and finally, the CCNinfo user receives two Reply messages: one from the FHR (Router C) and the other from the Caching router.</t>
          <figure anchor="fig_reply_force" align="left" suppress-title="false" pn="figure-11">
            <name slugifiedName="name-full-discovery-request-repl">Full Discovery Request: Reply Messages Forwarded by the Publisher and Routers</name>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.2-2.1">
       3. Reply(C)   2. Reply(C)
       3. Reply(P)   2. Reply(P)   1. Reply(P)
         +----+        +----+        +----+
         |    |        |    |        |    |
         v    |        v    |        v    |
+--------+    +--------+    +--------+    +--------+    +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
|  user  |    |   A    |    |   B    |    |   C    |    |         |
+--------+    +--------+    +--------+    +--------+    +---------+
                                     ^
                                      \          +-------+
                           1. Reply(C) \         | Cache |
                                        \ +---------+    |
                                         \| Caching |----+
                                          |  router |
                                          +---------+
</artwork>
          </figure>
          <t indent="0" pn="section-5.3.2-3">To receive different Reply messages forwarded from different routers, the PIT entries initiated by CCNinfo remain until the configured CCNinfo Reply Timeout (<xref target="sec.timer" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) is expired. In other words, unlike the ordinary Interest-Data exchanges in CCN, if routers that accept the full discovery request receive the full discovery request, the routers <bcp14>SHOULD NOT</bcp14> remove the PIT entry created by the full discovery request until the CCNinfo Reply Timeout value expires.</t>
          <t indent="0" pn="section-5.3.2-4">Note that the full discovery request is an <bcp14>OPTIONAL</bcp14> implementation of CCNinfo; it may not be implemented on routers. Even if it is implemented on a router, it may not accept the full discovery request from non-validated CCNinfo users or routers or because of its policy. If a router does not accept the full discovery request, it rejects the full discovery request as described in <xref target="sec.admin_prohibit" format="default" sectionFormat="of" derivedContent="Section 6.11"/>. Routers that enable the full discovery request <bcp14>MAY</bcp14> rate-limit Replies, as described in <xref target="sec.rate_limit.reply" format="default" sectionFormat="of" derivedContent="Section 10.8"/> as well.</t>
        </section>
      </section>
      <section anchor="sec.send.reply" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-sending-ccninfo-reply">Sending CCNinfo Reply</name>
        <t indent="0" pn="section-5.4-1">If there is a caching router or FHR for the specified content within the specified hop count along the path, the caching router or FHR sends back the Reply message toward the CCNinfo user and terminates the Request.</t>
        <t indent="0" pn="section-5.4-2">When a router decides to send a Reply message to its downstream neighbor router or the CCNinfo user with a NO_ERROR return code, it inserts a Report block with the Request Arrival Time and Node Identifier values to the Request message. Then, the router inserts the corresponding Reply sub-block(s) (<xref target="Reply_subblock" format="default" sectionFormat="of" derivedContent="Figure 10"/>) to the payload. The router finally changes the Type field in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back as the Reply toward the CCNinfo user in a hop-by-hop manner.</t>
        <t indent="0" pn="section-5.4-3">If a router cannot continue the Request, the router <bcp14>MUST</bcp14> put an appropriate ReturnCode in the Request message, change the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY, and forward the Reply message back toward the CCNinfo user to terminate the Request (see <xref target="sec.terminate" format="default" sectionFormat="of" derivedContent="Section 6"/>).</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-forwarding-ccninfo-reply">Forwarding CCNinfo Reply</name>
        <t indent="0" pn="section-5.5-1">When a router receives a CCNinfo Reply whose Request ID and Node Identifier values match those in the PIT entry, which is sent from a valid adjacent neighbor router, it forwards the CCNinfo Reply back toward the CCNinfo user. If the router does not receive the corresponding Reply within the [CCNinfo Reply Timeout] period, then it removes the corresponding PIT entry and terminates the trace.</t>
        <t indent="0" pn="section-5.5-2">The Flags field in the Request block TLV is used to indicate whether the router keeps the PIT entry during the CCNinfo Reply Timeout even after one or more corresponding Reply messages are forwarded. When the CCNinfo user does not set the F flag (i.e., "0"), the intermediate routers immediately remove the PIT entry whenever they forward the corresponding Reply message. When the CCNinfo user sets the F flag (i.e., "1"), which means the CCNinfo user chooses the "full discovery request" (see <xref target="sec.forward.full-request" format="default" sectionFormat="of" derivedContent="Section 5.3.2"/>), the intermediate routers keep the PIT entry within the [CCNinfo Reply Timeout] period. After this timeout, the PIT entry is removed.</t>
        <t indent="0" pn="section-5.5-3">CCNinfo Replies <bcp14>MUST NOT</bcp14> be cached in routers upon the transmission of Reply messages.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-pit-entry-management-for-mu">PIT Entry Management for Multipath Support</name>
        <t indent="0" pn="section-5.6-1">Within a network with a multipath condition, there is a case (<xref target="fig_multi-replies" format="default" sectionFormat="of" derivedContent="Figure 12"/>) wherein a single CCNinfo Request is split into multiple Requests (e.g., at Router A), which are injected into a single router (Router D). In this case, multiple Replies with the same Request ID and Node Identifier values, including different Report blocks, are received by the router (Router D).</t>
        <figure anchor="fig_multi-replies" align="left" suppress-title="false" pn="figure-12">
          <name slugifiedName="name-an-example-of-multipath-net">An Example of Multipath Network Topology</name>
          <artwork align="center" name="" type="" alt="" pn="section-5.6-2.1">
                          +--------+
                          | Router |
                          |   B    |
                          +--------+
                         /          \
                        /            \
+--------+    +--------+              +--------+     +---------+
| CCNinfo|----| Router |              | Router | ... |Publisher|
|  user  |    |   A    |              |   D    |     |         |
+--------+    +--------+              +--------+     +---------+
                        \            /
                         \          /
                          +--------+
                          | Router |
                          |   C    |
                          +--------+
</artwork>
        </figure>
        <t indent="0" pn="section-5.6-3">To recognize different CCNinfo Reply messages, the routers <bcp14>MUST</bcp14> distinguish the PIT entries by the Request ID and exploiting path labels, which could be a hash value of the concatenation information of the cumulate node identifiers in the hop-by-hop header and the specified content name. For example, when Router D in <xref target="fig_multi-replies" format="default" sectionFormat="of" derivedContent="Figure 12"/> receives a CCNinfo Request from Router B, its PIT includes the Request ID and value such as H((Router_A|Router_B)|content_name), where "H" indicates some hash function and "|" indicates concatenation. When Router D receives a CCNinfo Request from Router C, its PIT includes the same Request ID and value of H((Router_A|Router_C)|content_name). Two different Replies are later received on Router D, and each Reply is appropriately forwarded to Router B and Router C, respectively.
      Note that two Reply messages coming from Router B and Router C are reached at Router A, but the CCNinfo user can only receive the first Reply message either from Router B or Router C as Router A removes the corresponding PIT entry after it forwards the first Reply.</t>
        <t indent="0" pn="section-5.6-4">To avoid routing loops, when a router seeks the cumulate node identifiers of the Report blocks in the hop-by-hop header, it <bcp14>MUST</bcp14> examine whether its own node identifier is not previously inserted. If a router detects its own node identifier in the hop-by-hop header, the router inserts its Report block and terminates the Request as will be described in <xref target="sec.terminate.fatal" format="default" sectionFormat="of" derivedContent="Section 6.8"/>.</t>
      </section>
    </section>
    <section anchor="sec.terminate" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-ccninfo-termination">CCNinfo Termination</name>
      <t indent="0" pn="section-6-1">When performing a hop-by-hop trace, it is necessary to determine when to stop the trace. There are several cases when an intermediate router might return a Reply before a Request reaches the caching router or the FHR.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-arriving-at-first-hop-route">Arriving at First-Hop Router</name>
        <t indent="0" pn="section-6.1-1">A CCNinfo Request can be determined to have arrived at the FHR. To ensure that a router recognizes that it is the FHR for the specified content, it needs to have a FIB entry (or to attach) to the corresponding publisher or the content.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-arriving-at-router-having-c">Arriving at Router Having Cache</name>
        <t indent="0" pn="section-6.2-1">A CCNinfo Request can be determined to have arrived at the router having the specified content cache within the specified HopLimit.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-arriving-at-last-router">Arriving at Last Router</name>
        <t indent="0" pn="section-6.3-1">A CCNinfo Request can be determined to have arrived at the last router of the specified HopLimit. If the last router does not have the corresponding cache, it <bcp14>MUST</bcp14> insert its Report block and send the Reply message with a NO_INFO return code without appending any Reply block or sub-block TLVs.</t>
      </section>
      <section anchor="sec.terminate.invalid" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-invalid-request">Invalid Request</name>
        <t indent="0" pn="section-6.4-1">If the router does not validate the Request or the Reply even it is required, the router <bcp14>MUST</bcp14> note a ReturnCode of INVALID_REQUEST in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user. The router <bcp14>MAY</bcp14>, however, randomly ignore the received invalid messages. (See <xref target="sec.rate_limit.request" format="default" sectionFormat="of" derivedContent="Section 10.7"/>.)</t>
      </section>
      <section anchor="sec.terminate.no_route" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-no-route">No Route</name>
        <t indent="0" pn="section-6.5-1">If the router cannot determine the routing paths or neighbor routers for the specified name prefix within the specified HopLimit,
	it <bcp14>MUST</bcp14> note a ReturnCode of NO_ROUTE in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-no-information">No Information</name>
        <t indent="0" pn="section-6.6-1">If the router does not have any information about the specified name prefix within the specified HopLimit,
	it <bcp14>MUST</bcp14> note a ReturnCode of NO_INFO in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user.</t>
      </section>
      <section anchor="sec.terminate.no_space" numbered="true" toc="include" removeInRFC="false" pn="section-6.7">
        <name slugifiedName="name-no-space">No Space</name>
        <t indent="0" pn="section-6.7-1">If appending the Report block, the Reply block, or Reply sub-block would make the hop-by-hop header longer than 247 bytes or the Request packet longer than the MTU of the Incoming face, the router <bcp14>MUST</bcp14> note a ReturnCode of NO_SPACE in the fixed header of the message and forward the message as the Reply back to the CCNinfo user.</t>
      </section>
      <section anchor="sec.terminate.fatal" numbered="true" toc="include" removeInRFC="false" pn="section-6.8">
        <name slugifiedName="name-fatal-error">Fatal Error</name>
        <t indent="0" pn="section-6.8-1">If a CCNinfo Request has encountered a fatal error,
	the router <bcp14>MUST</bcp14> note a ReturnCode of FATAL_ERROR in the fixed header of the message and forward the message as the Reply back to the CCNinfo user. This may happen, for example, when the router detects some routing loop in the Request blocks (see <xref target="sec.intro" format="default" sectionFormat="of" derivedContent="Section 1"/>). The fatal error can be encoded with another error: if a router detects routing loop but cannot insert its Report block, it <bcp14>MUST</bcp14> note NO_SPACE and FATAL_ERROR ReturnCodes (i.e., 0x85) in the fixed header and forward the message back to the CCNinfo user.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.9">
        <name slugifiedName="name-ccninfo-reply-timeout">CCNinfo Reply Timeout</name>
        <t indent="0" pn="section-6.9-1">If a router receives the Request or Reply message that expires its own [CCNinfo Reply Timeout] value (<xref target="sec.timer" format="default" sectionFormat="of" derivedContent="Section 7.1"/>), the router will silently discard the Request or Reply message.</t>
      </section>
      <section anchor="sec.nonsupport" numbered="true" toc="include" removeInRFC="false" pn="section-6.10">
        <name slugifiedName="name-non-supported-node">Non-Supported Node</name>
        <t indent="0" pn="section-6.10-1">Cases will arise in which a router or a FHR along the path does not support CCNinfo. In such cases, a CCNinfo user and routers that forward the CCNinfo Request will time out the CCNinfo request.</t>
      </section>
      <section anchor="sec.admin_prohibit" numbered="true" toc="include" removeInRFC="false" pn="section-6.11">
        <name slugifiedName="name-administratively-prohibited">Administratively Prohibited</name>
        <t indent="0" pn="section-6.11-1">If CCNinfo is administratively prohibited, the router rejects the Request message and <bcp14>MUST</bcp14> send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB. The router <bcp14>MAY</bcp14>, however, randomly ignore the Request messages to be rejected (see <xref target="sec.rate_limit.request" format="default" sectionFormat="of" derivedContent="Section 10.7"/>).</t>
      </section>
    </section>
    <section anchor="sec.config" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-configurations">Configurations</name>
      <section anchor="sec.timer" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-ccninfo-reply-timeout-2">CCNinfo Reply Timeout</name>
        <t indent="0" pn="section-7.1-1">The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply. The value for a router can be statically configured by the router's administrators and/or operators. The default value is 3 (seconds). The [CCNinfo Reply Timeout] value <bcp14>SHOULD NOT</bcp14> be larger than 4 (seconds) and <bcp14>SHOULD NOT</bcp14> be lower than 2 (seconds).</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-hoplimit-in-fixed-header">HopLimit in Fixed Header</name>
        <t indent="0" pn="section-7.2-1">If a CCNinfo user does not specify the HopLimit value in the fixed header for a Request message as the HopLimit, the HopLimit is set to 32. Note that 0 HopLimit is an invalid Request; hence, the router in this case follows the way defined in <xref target="sec.terminate.invalid" format="default" sectionFormat="of" derivedContent="Section 6.4"/>.</t>
      </section>
      <section anchor="sec.acl.config" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-access-control">Access Control</name>
        <t indent="0" pn="section-7.3-1">A router <bcp14>MAY</bcp14> configure the valid or invalid networks to enable an access control. The access control <bcp14>MAY</bcp14> be defined per name prefix, such as "who can retrieve which name prefix" (see <xref target="sec.acl" format="default" sectionFormat="of" derivedContent="Section 10.2"/>).</t>
      </section>
    </section>
    <section anchor="sec.diag" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-diagnosis-and-analysis">Diagnosis and Analysis</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-number-of-hops-and-rtt">Number of Hops and RTT</name>
        <t indent="0" pn="section-8.1-1">A CCNinfo Request message is forwarded in a hop-by-hop manner and each forwarding router appends its own Report block. We can then verify the number of hops to reach the content forwarder or publisher and the RTT between the content forwarder or publisher.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-caching-router-identificati">Caching Router Identification</name>
        <t indent="0" pn="section-8.2-1">While some routers may hide their node identifiers with all-zeros in the Report blocks (as seen in <xref target="sec.policy" format="default" sectionFormat="of" derivedContent="Section 10.1"/>), the routers in the path from the CCNinfo user to the content forwarder can be identified.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-ttl-or-hop-limit">TTL or Hop Limit</name>
        <t indent="0" pn="section-8.3-1">By taking the HopLimit from the content forwarder and
	forwarding the TTL threshold over all hops, it is possible to
	discover the TTL or hop limit required for the content forwarder to reach the CCNinfo user.</t>
      </section>
      <section anchor="sec.delay" numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-time-delay">Time Delay</name>
        <t indent="0" pn="section-8.4-1">If the routers have synchronized clocks, it is possible to estimate the propagation and queuing delays from the differences between the timestamps at the successive hops. However, this delay includes the control processing overhead; therefore, it is not necessarily indicative of the delay that would be experienced by the data traffic.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.5">
        <name slugifiedName="name-path-stretch">Path Stretch</name>
        <t indent="0" pn="section-8.5-1">By obtaining the path stretch "d / P", where "d" is the hop count of the data and "P" is the hop count from the consumer to the publisher, we can measure the improvements in path stretch in various cases, such as in different caching and routing algorithms. We can then facilitate the investigation of the performance of the protocol.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.6">
        <name slugifiedName="name-cache-hit-probability">Cache Hit Probability</name>
        <t indent="0" pn="section-8.6-1">CCNinfo can show the number of received Interests per cache or chunk on a router. Accordingly, CCNinfo measures the content popularity (i.e., the number of accesses for each content and/or cache), thereby enabling the investigation of the routing/caching strategy in networks.</t>
      </section>
    </section>
    <section anchor="sec.iana" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This section details each kind of CCNx protocol value that has been registered. As per <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, four assignments have been made in existing registries, and a new Reply Type registry has been created in the "Content-Centric Networking (CCNx)" registry group.</t>
      <section anchor="sec.iana.pt" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-packet-type-registry">Packet Type Registry</name>
        <t indent="0" pn="section-9.1-1">As shown in <xref target="Type_val" format="default" sectionFormat="of" derivedContent="Table 1"/>, CCNinfo defines two packet types, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose values are 0x03 and 0x04, respectively.</t>
      </section>
      <section anchor="sec.iana.tlt" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-top-level-type-registry">Top-Level Type Registry</name>
        <t indent="0" pn="section-9.2-1">As shown in <xref target="Top-level_Type" format="default" sectionFormat="of" derivedContent="Table 2"/>, CCNinfo defines one top-level type, T_DISCOVERY, whose value is 0x0005.</t>
      </section>
      <section anchor="sec.iana.hbh" numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-hop-by-hop-type-registry">Hop-by-Hop Type Registry</name>
        <t indent="0" pn="section-9.3-1">As shown in <xref target="Hop-by-hop_Type" format="default" sectionFormat="of" derivedContent="Table 4"/>, CCNinfo defines two hop-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose values are 0x0008 and 0x0009, respectively.</t>
      </section>
      <section anchor="sec.iana.msg" numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-message-type-registry">Message Type Registry</name>
        <t indent="0" pn="section-9.4-1">As shown in <xref target="CCNx_Type" format="default" sectionFormat="of" derivedContent="Table 6"/>, CCNinfo defines two message types, T_DISC_REQ and T_DISC_REPLY, whose values are 0x000D and 0x000E, respectively.</t>
      </section>
      <section anchor="sec.iana.reply" numbered="true" toc="include" removeInRFC="false" pn="section-9.5">
        <name slugifiedName="name-reply-type-registry">Reply Type Registry</name>
        <t indent="0" pn="section-9.5-1">IANA has created the "CCNx Reply Types" registry and allocated the reply types. The registration procedure is "RFC Required" <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.  The Type value is 2 octets. The range is 0x0000-0xFFFF. As shown in <xref target="Sub_Type" format="default" sectionFormat="of" derivedContent="Table 7"/>, CCNinfo defines three reply types, T_DISC_CONTENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose values are 0x0000, 0x0001, and 0x0FFF, respectively.</t>
      </section>
    </section>
    <section anchor="sec.sec" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">This section addresses some of the security considerations.</t>
      <section anchor="sec.policy" numbered="true" toc="include" removeInRFC="false" pn="section-10.1">
        <name slugifiedName="name-policy-based-information-pr">Policy-Based Information Provisioning for Request</name>
        <t indent="0" pn="section-10.1-1">Although CCNinfo gives excellent troubleshooting cues, some network administrators or operators may not want to disclose everything about their network to the public or may wish to securely transmit private information to specific members of their networks. CCNinfo provides policy-based information provisioning, thereby allowing network administrators to specify their response policy for each router.</t>
        <t indent="0" pn="section-10.1-2">The access policy regarding "who is allowed to retrieve" and/or "what kind of cache information" can be defined for each router. For the former type of access policy, routers with the specified content <bcp14>MAY</bcp14> examine the signature enclosed in the Request message and decide whether they should notify the content information in the Reply. If the routers decide to not notify the content information, they <bcp14>MUST</bcp14> send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without appending any Reply block or sub-block TLVs.
For the latter type of policy, the permission, whether (1) All (all cache information is disclosed), (2) Partial (cache information with a particular name prefix can (or cannot) be disclosed), or (3) Deny (no cache information is disclosed), is defined at the routers.</t>
        <t indent="0" pn="section-10.1-3">In contrast, we entail that each router does not disrupt the forwarding of CCNinfo Request and Reply messages. When a Request message is received, the router <bcp14>SHOULD</bcp14> insert the Report block if the ReturnCode is NO_ERROR. Here, according to the policy configuration, the Node Identifier field in the Report block <bcp14>MAY</bcp14> be null (i.e., all-zeros), but the Request Arrival Time field <bcp14>SHOULD NOT</bcp14> be null. Finally, the router <bcp14>SHOULD</bcp14> forward the Request message to the upstream router toward the content forwarder if the ReturnCode is kept with NO_ERROR.</t>
      </section>
      <section anchor="sec.acl" numbered="true" toc="include" removeInRFC="false" pn="section-10.2">
        <name slugifiedName="name-filtering-ccninfo-users-loc">Filtering CCNinfo Users Located in Invalid Networks</name>
        <t indent="0" pn="section-10.2-1">A router <bcp14>MAY</bcp14> support an access control mechanism to filter out Requests from invalid CCNinfo users. To accomplish this, invalid networks (or domains) could, for example, be configured via a list of allowed or disallowed networks (as observed in <xref target="sec.acl.config" format="default" sectionFormat="of" derivedContent="Section 7.3"/>). If a Request is received from a disallowed network (according to the node identifier in the Request block), the Request <bcp14>MUST NOT</bcp14> be processed and the Reply with the ReturnCode of INFO_HIDDEN <bcp14>SHOULD</bcp14> be used to note that. The router <bcp14>MAY</bcp14>, however, perform rate-limited logging of such events.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.3">
        <name slugifiedName="name-topology-discovery">Topology Discovery</name>
        <t indent="0" pn="section-10.3-1">CCNinfo can be used to discover actively used topologies. If a network topology is not disclosed, CCNinfo Requests <bcp14>SHOULD</bcp14> be restricted at the border of the domain using the ADMIN_PROHIB return code.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-10.4">
        <name slugifiedName="name-characteristics-of-content">Characteristics of Content</name>
        <t indent="0" pn="section-10.4-1">CCNinfo can be used to discover the type of content being sent by publishers. If this information is a secret, CCNinfo Requests <bcp14>SHOULD</bcp14> be restricted at the border of the domain, using the ADMIN_PROHIB return code.</t>
      </section>
      <section anchor="sec.compute" numbered="true" toc="include" removeInRFC="false" pn="section-10.5">
        <name slugifiedName="name-computational-attacks">Computational Attacks</name>
        <t indent="0" pn="section-10.5-1">CCNinfo may impose heavy tasks at content forwarders because it makes content forwarders seek their internal cache states reported in the Reply messages whenever they form the Reply messages. The current CCNinfo specification allows to return null values for several fields, such as First/Last Seqnum or Elapsed Cache Time fields in the Reply sub-block. As mentioned in <xref target="sec.reply_subblk" format="default" sectionFormat="of" derivedContent="Section 3.2.1.1"/>, these values <bcp14>MAY</bcp14> be null. This means that the content forwarder cannot only hide these values owing to privacy and security policies but also skip the implementations of the complex functions to report these values.</t>
      </section>
      <section anchor="sec.timeout" numbered="true" toc="include" removeInRFC="false" pn="section-10.6">
        <name slugifiedName="name-longer-or-shorter-ccninfo-r">Longer or Shorter CCNinfo Reply Timeout</name>
        <t indent="0" pn="section-10.6-1">Routers can configure CCNinfo Reply Timeout (<xref target="sec.timer" format="default" sectionFormat="of" derivedContent="Section 7.1"/>), which is the allowable timeout value to keep the PIT entry. If routers configure a longer timeout value, there may be an attractive attack vector against the PIT memory. Moreover, especially when the full discovery request option (<xref target="sec.forward.request" format="default" sectionFormat="of" derivedContent="Section 5.3"/>) is specified for the CCNinfo Request, several Reply messages may be returned and cause a response storm. (See <xref target="sec.rate_limit.reply" format="default" sectionFormat="of" derivedContent="Section 10.8"/> for rate-limiting to avoid the storm).
	To avoid DoS attacks, routers <bcp14>MAY</bcp14> configure the timeout value, which is shorter than the user-configured CCNinfo timeout value. However, if it is too short, the Request may be timed out and the CCNinfo user does not receive all Replies; they only retrieve the partial path information (i.e., information about a part of the tree).</t>
        <t indent="0" pn="section-10.6-2">There may be a way to enable incremental exploration (i.e., to explore the part of the tree that was not explored by the previous operation); however, discussing such mechanisms is out of scope of this document.</t>
      </section>
      <section anchor="sec.rate_limit.request" numbered="true" toc="include" removeInRFC="false" pn="section-10.7">
        <name slugifiedName="name-limiting-request-rates">Limiting Request Rates</name>
        <t indent="0" pn="section-10.7-1">A router <bcp14>MAY</bcp14> rate-limit CCNinfo Requests by ignoring some of the consecutive messages. The router <bcp14>MAY</bcp14> randomly ignore the received messages to minimize the processing overhead, i.e., to keep fairness in processing requests or to prevent traffic amplification. In such a case, no error message is returned. The rate limit function is left to the router's implementation.</t>
      </section>
      <section anchor="sec.rate_limit.reply" numbered="true" toc="include" removeInRFC="false" pn="section-10.8">
        <name slugifiedName="name-limiting-reply-rates">Limiting Reply Rates</name>
        <t indent="0" pn="section-10.8-1">CCNinfo supporting multipath forwarding may result in one Request returning multiple Reply messages. To prevent abuse, the routers in the traced path <bcp14>MAY</bcp14> need to rate-limit the Replies. In such a case, no error message is returned. The rate limit function is left to the router's implementation.</t>
      </section>
      <section anchor="sec.adjacency" numbered="true" toc="include" removeInRFC="false" pn="section-10.9">
        <name slugifiedName="name-adjacency-verification">Adjacency Verification</name>
        <t indent="0" pn="section-10.9-1">It is assumed that the CCNinfo Request and Reply messages are forwarded by adjacent neighbor nodes or routers. The CCNx message format or semantics do not define a secure way to verify the node and/or router adjacency, while a hop-by-hop authentication such as <xref target="DCAuth" format="default" sectionFormat="of" derivedContent="DCAuth"/> provides a possible method for an adjacency verification and defines the corresponding message format for adjacency verification as well as the router behaviors. CCNinfo <bcp14>MAY</bcp14> use a similar method for node adjacency verification.
        </t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.irtf-icnrg-icntraceroute" to="ICN-TRACEROUTE"/>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8569" target="https://www.rfc-editor.org/info/rfc8569" quoteTitle="true" derivedAnchor="RFC8569">
          <front>
            <title>Content-Centric Networking (CCNx) Semantics</title>
            <author fullname="M. Mosko" initials="M." surname="Mosko"/>
            <author fullname="I. Solis" initials="I." surname="Solis"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.</t>
              <t indent="0">The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.</t>
              <t indent="0">This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8569"/>
          <seriesInfo name="DOI" value="10.17487/RFC8569"/>
        </reference>
        <reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8609" quoteTitle="true" derivedAnchor="RFC8609">
          <front>
            <title>Content-Centric Networking (CCNx) Messages in TLV Format</title>
            <author fullname="M. Mosko" initials="M." surname="Mosko"/>
            <author fullname="I. Solis" initials="I." surname="Solis"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.</t>
              <t indent="0">This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8609"/>
          <seriesInfo name="DOI" value="10.17487/RFC8609"/>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Cefore" quoteTitle="true" target="https://doi.org/10.1587/transcom.2018EII0001" derivedAnchor="Cefore">
          <front>
            <title>Cefore: Software Platform Enabling Content-Centric Networking and Beyond</title>
            <author initials="H" surname="Asaeda"/>
            <author initials="A" surname="Ooka"/>
            <author initials="K" surname="Matsuzono"/>
            <author initials="R" surname="Li"/>
            <date month="September" year="2019"/>
          </front>
          <seriesInfo name="DOI" value="10.1587/transcom.2018EII0001"/>
          <refcontent>IEICE Transaction on Communications, Volume E102-B, Issue 9, pp. 1792-1803</refcontent>
        </reference>
        <reference anchor="Cefore-site" target="https://cefore.net/" quoteTitle="true" derivedAnchor="Cefore-site">
          <front>
            <title>Cefore</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="CONSEC-CACHING" quoteTitle="true" target="https://doi.org/10.1109/ICC.2018.8422233" derivedAnchor="CONSEC-CACHING">
          <front>
            <title>Consecutive Caching and Adaptive Retrieval for In-Network Big Data Sharing</title>
            <author initials="R" surname="Li"/>
            <author initials="K" surname="Matsuzono"/>
            <author initials="H" surname="Asaeda"/>
            <author initials="X" surname="Fu"/>
            <date month="May" year="2018"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/ICC.2018.8422233"/>
          <refcontent>Proc. IEEE ICC, Kansas City, MO, USA</refcontent>
        </reference>
        <reference anchor="Contrace" quoteTitle="true" target="https://doi.org/10.1109/MCOM.2015.7060502" derivedAnchor="Contrace">
          <front>
            <title>Contrace: A tool for measuring and tracing content-centric networks</title>
            <author initials="H" surname="Asaeda"/>
            <author initials="K" surname="Matsuzono"/>
            <author initials="T" surname="Turletti"/>
            <date month="March" year="2015"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/MCOM.2015.7060502"/>
          <refcontent>IEEE Communications Magazine, Vol. 53, No. 3, pp. 182-188</refcontent>
        </reference>
        <reference anchor="DCAuth" quoteTitle="true" target="https://doi.org/10.1109/TNSE.2018.2872049" derivedAnchor="DCAuth">
          <front>
            <title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval</title>
            <author initials="R" surname="Li"/>
            <author initials="H" surname="Asaeda"/>
            <author initials="J" surname="Wu"/>
            <date month="October" year="2018"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/TNSE.2018.2872049"/>
          <refcontent>IEEE Transactions on Network Science and Engineering, Vol. 7, No. 1, pp. 15-27</refcontent>
        </reference>
        <reference anchor="ICN-PING" target="https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icnping-07" quoteTitle="true" derivedAnchor="ICN-PING">
          <front>
            <title>ICN Ping Protocol Specification</title>
            <author fullname="Spyridon Mastorakis" initials="S." surname="Mastorakis">
              <organization showOnFrontPage="true">University of Nebraska at Omaha</organization>
            </author>
            <author fullname="David R. Oran" initials="D." surname="Oran">
              <organization showOnFrontPage="true">Network Systems Research and Design</organization>
            </author>
            <author fullname="Jim Gibson" initials="J." surname="Gibson">
              <organization showOnFrontPage="true">Unaffiliated</organization>
            </author>
            <author fullname="Ilya Moiseenko" initials="I." surname="Moiseenko">
              <organization showOnFrontPage="true">Apple Inc</organization>
            </author>
            <author fullname="Ralph Droms" initials="R." surname="Droms">
              <organization showOnFrontPage="true">Unaffiliated</organization>
            </author>
            <date day="16" month="October" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icnping-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.irtf-icnrg-icntraceroute" target="https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icntraceroute-07" quoteTitle="true" derivedAnchor="ICN-TRACEROUTE">
          <front>
            <title>ICN Traceroute Protocol Specification</title>
            <author initials="S." surname="Mastorakis" fullname="Spyridon Mastorakis">
              <organization showOnFrontPage="true">University of Nebraska at Omaha</organization>
            </author>
            <author initials="D." surname="Oran" fullname="David R. Oran">
              <organization showOnFrontPage="true">Network Systems Research and Design</organization>
            </author>
            <author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
              <organization showOnFrontPage="true">Apple Inc</organization>
            </author>
            <author initials="J." surname="Gibson" fullname="Jim Gibson">
              <organization showOnFrontPage="true">Unaffiliated</organization>
            </author>
            <author initials="R." surname="Droms" fullname="Ralph Droms">
              <organization showOnFrontPage="true">Unaffiliated</organization>
            </author>
            <date month="October" day="16" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icntraceroute-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC8487" target="https://www.rfc-editor.org/info/rfc8487" quoteTitle="true" derivedAnchor="RFC8487">
          <front>
            <title>Mtrace Version 2: Traceroute Facility for IP Multicast</title>
            <author fullname="H. Asaeda" initials="H." surname="Asaeda"/>
            <author fullname="K. Meyer" initials="K." surname="Meyer"/>
            <author fullname="W. Lee" initials="W." role="editor" surname="Lee"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers.  This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8487"/>
          <seriesInfo name="DOI" value="10.17487/RFC8487"/>
        </reference>
        <reference anchor="RFC8793" target="https://www.rfc-editor.org/info/rfc8793" quoteTitle="true" derivedAnchor="RFC8793">
          <front>
            <title>Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology</title>
            <author fullname="B. Wissingh" initials="B." surname="Wissingh"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <author fullname="A. Afanasyev" initials="A." surname="Afanasyev"/>
            <author fullname="L. Zhang" initials="L." surname="Zhang"/>
            <author fullname="D. Oran" initials="D." surname="Oran"/>
            <author fullname="C. Tschudin" initials="C." surname="Tschudin"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses.  Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures.  This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN.  While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8793"/>
          <seriesInfo name="DOI" value="10.17487/RFC8793"/>
        </reference>
      </references>
    </references>
    <section anchor="sec.command" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-ccninfo-command-and-options">ccninfo Command and Options</name>
      <t indent="0" pn="section-appendix.a-1">
   CCNinfo is implemented in Cefore <xref target="Cefore" format="default" sectionFormat="of" derivedContent="Cefore"/> <xref target="Cefore-site" format="default" sectionFormat="of" derivedContent="Cefore-site"/>. The command invoked by the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo command sends the Request message and receives the Reply message(s). There are several options that can be specified with ccninfo, while the content name prefix (e.g., ccnx:/news/today) is the mandatory parameter.</t>
      <t indent="0" pn="section-appendix.a-2">The usage of the ccninfo command is as follows:</t>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.a-3">
ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count]
   [-v algorithm] name_prefix
</artwork>
      <dl newline="true" spacing="normal" indent="3" pn="section-appendix.a-4">
        <dt pn="section-appendix.a-4.1">name_prefix:</dt>
        <dd pn="section-appendix.a-4.2">
      The prefix name of content (e.g., ccnx:/news/today) or exact name of
      content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants
      to trace.</dd>
        <dt pn="section-appendix.a-4.3">c option:</dt>
        <dd pn="section-appendix.a-4.4">
	This option can be specified if a CCNinfo user needs the cache
      information as well as the routing path information for the
      specified content/cache and RTT between the CCNinfo user and
      content forwarder.
	</dd>
        <dt pn="section-appendix.a-4.5">f option:</dt>
        <dd pn="section-appendix.a-4.6">
	This option enables the "full discovery request"; routers send
      CCNinfo Requests to multiple upstream faces based on their FIBs
      simultaneously.  The CCNinfo user can then trace all possible
      forwarding paths.
	</dd>
        <dt pn="section-appendix.a-4.7">o option:</dt>
        <dd pn="section-appendix.a-4.8">
      This option enables the tracing of the path to the content publisher.
      Each router along the path to the publisher inserts each Report
      block and forwards the Request message.  It does not send Reply
      even if it caches the specified content.  FHR that attaches the
      publisher (who has the complete set of content and is not a
      caching router) sends the Reply message.
        </dd>
        <dt pn="section-appendix.a-4.9">V option:</dt>
        <dd pn="section-appendix.a-4.10">
	This option requests the Reply sender to validate the Reply
      message with the Reply sender's signature.  The Reply message will
      then include the CCNx ValidationPayload TLV.  The validation
      algorithm is selected by the Reply sender.
	</dd>
        <dt pn="section-appendix.a-4.11">r option:</dt>
        <dd pn="section-appendix.a-4.12">
	The number of traced routers.  This value is set in the "HopLimit"
      field located in the fixed header of the Request.  For example,
      when the CCNinfo user invokes the ccninfo command with this
      option, such as "-r 3", only three routers along the path examine
      their path and cache information.
	</dd>
        <dt pn="section-appendix.a-4.13">s option:</dt>
        <dd pn="section-appendix.a-4.14">
	The number of skipped routers.  This value is set in the "SkipHop"
	field located in the Request block TLV.  For example, when the CCNinfo
	user invokes the ccninfo command with this option, such as "-s 3",
	three upstream routers along the path only forward the Request message
	but do not append their Report blocks in the hop-by-hop header and do
	not send Reply messages despite having the corresponding cache.
	</dd>
        <dt pn="section-appendix.a-4.15">v option:</dt>
        <dd pn="section-appendix.a-4.16">
	This option enables the CCNinfo user to validate the Request
      message with their signature.  The Request message will include
      the CCNx ValidationPayload TLV.  The validation algorithm is
      specified by the CCNinfo user.
	</dd>
      </dl>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">The authors would like to thank <contact fullname="Jérôme François"/>, <contact fullname="Erik Kline"/>, <contact fullname="Spyridon Mastorakis"/>, <contact fullname="Paulo Mendes"/>, <contact fullname="Ilya Moiseenko"/>, <contact fullname="David Oran"/>, and <contact fullname="Thierry Turletti"/> for their valuable comments and suggestions on this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
        <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
        <address>
          <postal>
            <street>4-2-1 Nukui-Kitamachi, Koganei</street>
            <code>184-8795</code>
            <region>Tokyo</region>
            <country>Japan</country>
          </postal>
          <email>asaeda@nict.go.jp</email>
        </address>
      </author>
      <author initials="A" surname="Ooka" fullname="Atsushi Ooka">
        <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
        <address>
          <postal>
            <street>4-2-1 Nukui-Kitamachi, Koganei</street>
            <code>184-8795</code>
            <region>Tokyo</region>
            <country>Japan</country>
          </postal>
          <email>a-ooka@nict.go.jp</email>
        </address>
      </author>
      <author initials="X" surname="Shao" fullname="Xun Shao">
        <organization showOnFrontPage="true">Toyohashi University of Technology</organization>
        <address>
          <postal>
            <street>1-1 Hibarigaoka Tempaku-cho, Toyohashi</street>
            <region>Aichi</region>
            <code>441-8580</code>
            <country>Japan</country>
          </postal>
          <email>shao.xun.ls@tut.jp</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
