rfc9344xml2.original.xml   rfc9344.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC5378 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5378.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
<!-- used by XSLT processors --> exp" consensus="true" docName="draft-irtf-icnrg-ccninfo-15" number="9344" ipr="t
<!-- For a complete list and description of processing instructions (PIs), rust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4"
please see http://xml.resource.org/authoring/README.html. --> symRefs="true" sortRefs="true" version="3">
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--<?rfc strict="yes" ?>-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-irtf-icnrg-ccninfo-13" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="CCNinfo"> <title abbrev="CCNinfo">
CCNinfo: Discovering Content and Network Information in Content-Centric Ne tworks CCNinfo: Discovering Content and Network Information in Content-Centric Ne tworks
</title> </title>
<seriesInfo name="RFC" value="9344"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"> <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
<organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization> <organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization>
<address> <address>
<postal> <postal>
<code>184-8795</code> <street>4-2-1 Nukui-Kitamachi, Koganei</street>
<street>4-2-1 Nukui-Kitamachi, Koganei</street> <code>184-8795</code>
<code>Tokyo 184-8795</code> <region>Tokyo</region>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>asaeda@nict.go.jp</email> <email>asaeda@nict.go.jp</email>
</address> </address>
</author> </author>
<author initials="A" surname="Ooka" fullname="Atsushi Ooka"> <author initials="A" surname="Ooka" fullname="Atsushi Ooka">
<organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization> <organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization>
<address> <address>
<postal> <postal>
<street>4-2-1 Nukui-Kitamachi, Koganei</street> <street>4-2-1 Nukui-Kitamachi, Koganei</street>
<code>Tokyo 184-8795</code> <code>184-8795</code>
<country>Japan</country> <region>Tokyo</region>
</postal> <country>Japan</country>
<email>a-ooka@nict.go.jp</email> </postal>
<email>a-ooka@nict.go.jp</email>
</address> </address>
</author> </author>
<author initials="X" surname="Shao" fullname="Xun Shao"> <author initials="X" surname="Shao" fullname="Xun Shao">
<organization>Toyohashi University of Technology</organization> <organization>Toyohashi University of Technology</organization>
<address> <address>
<postal> <postal>
<street>1-1 Hibarigaoka Tempaku-cho, Toyohashi</street> <street>1-1 Hibarigaoka Tempaku-cho, Toyohashi</street>
<code>Aichi 441-8580</code> <region>Aichi</region>
<country>Japan</country> <code>441-8580</code>
</postal> <country>Japan</country>
<email>shao.xun.ls@tut.jp</email> </postal>
<email>shao.xun.ls@tut.jp</email>
</address> </address>
</author> </author>
<date year="2023" month="February" />
<date year="2022"/>
<!-- Meta-data Declarations --> <!-- Meta-data Declarations -->
<area>IRTF</area> <workgroup>Information-Centric Networking</workgroup>
<workgroup>ICN Research Group</workgroup>
<keyword>ICN</keyword> <keyword>ICN</keyword>
<keyword>CCNx</keyword> <keyword>CCNx</keyword>
<keyword>NDN</keyword> <keyword>NDN</keyword>
<keyword>CCNinfo</keyword> <keyword>CCNinfo</keyword>
<abstract> <abstract>
<t> <t>
This document describes a mechanism named "CCNinfo" that discovers This document describes a mechanism named "CCNinfo" that discovers
information about the network topology and in-network cache in information about the network topology and in-network cache in
Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN
routing path information per name prefix, 2) the Round-Trip Time routing path information per name prefix, 2) the Round-Trip Time
(RTT) between the content forwarder and consumer, and 3) the states (RTT) between the content forwarder and the consumer, and 3) the states
of in-network cache per name prefix. CCNinfo is useful to understand of in-network cache per name prefix. CCNinfo is useful to understand
and debug the behavior of testbed networks and other experimental and debug the behavior of testbed networks and other experimental
deployments of CCN systems.</t> deployments of CCN systems.</t>
<t> <t>
This document is a product of the IRTF Information-Centric Networking This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). This document represents the consensus view Research Group (ICNRG). This document represents the consensus view of
of ICNRG and has been reviewed extensively by several members of the ICNRG and has been reviewed extensively by several members of the ICN
ICN community and the RG. The authors and RG chairs approve of the community and the RG. The authors and RG
contents. The document is sponsored under the IRTF and is not issued chairs approve of the contents. The document is sponsored under the IRTF,
by the IETF and is not an IETF standard. This is an experimental is not issued by the IETF, and is not an IETF standard. This is an
protocol and the specification may change in the future.</t> experimental protocol and the specification may change in the future.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.intro" title="Introduction"> <section anchor="sec.intro" numbered="true" toc="default">
<name>Introduction</name>
<t>In Content-Centric Networks (CCN), publishers provide the content throu <t>In Content-Centric Networks (CCNs), publishers provide the content thro
gh the network, and receivers retrieve it by name. In this network architecture, ugh the network, and receivers retrieve it by name. In this network architecture
routers forward content requests through their Forwarding Information Bases (FI , routers forward content requests through their Forwarding Information Bases (F
Bs), which are populated by name-based routing protocols. CCN also enables recei IBs), which are populated by name-based routing protocols. CCN also enables rece
vers to retrieve content from an in-network cache.</t> ivers to retrieve content from an in-network cache.</t>
<t>In CCN, while consumers do not generally need to know the content forwa rder 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>In CCN, while consumers do not generally need to know the content forwa rder 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>IP traceroute <t>IP traceroute
<!-- <xref target="refs.traceroute"/>--> is a useful tool for discovering the routing conditions in IP networks bec
is a useful tool for discovering the routing conditions in IP networks bec ause it provides intermediate router addresses along the path between the source
ause 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
and destination and the Round-Trip Time (RTT) for the path. However, this IP-ba IP-based network tool cannot trace the name prefix paths used in CCN.
sed 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-n etwork cache to be discovered.</t> Moreover, such IP-based network tools do not obtain the states of the in-n etwork cache to be discovered.</t>
<t>Contrace <xref target="Contrace" format="default"/> enables end users (
<t>Contrace <xref target="refs.commag" /> enables end users (i.e., consume i.e., consumers) to investigate path and in-network cache conditions in CCN. Con
rs) to investigate path and in-network cache conditions in CCN. Contrace is impl trace is implemented as an external daemon process running over TCP/IP that can
emented as an external daemon process running over TCP/IP that can interact with interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the cac
a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the caching informat hing information on the forwarding daemon. This solution is flexible, but it req
ion on the forwarding daemon. This solution is flexible, but it requires definin uires defining the common APIs used for global deployment in TCP/IP networks. IC
g the common APIs used for global deployment in TCP/IP networks. ICN ping <xref N (Information-Centric Networking) ping <xref target="I-D.irtf-icnrg-icnping" fo
target="refs.icnping" /> and traceroute <xref target="refs.icntrace" /> are ligh rmat="default"/> and traceroute <xref target="I-D.irtf-icnrg-icntraceroute" form
tweight operational tools that enable a user to explore the path(s) that reach a at="default"/> are lightweight operational tools that enable a user to explore t
publisher or a cache storing the named content. ICN ping and traceroute, howeve he path(s) that reach a publisher or a cache storing the named content. ICN ping
r, do not expose detailed information about the forwarders deployed by a network and traceroute, however, do not expose detailed information about the forwarder
operator.</t> s deployed by a network operator.</t>
<t>This document describes the specifications of "CCNinfo", an active netw
<t>This document describes the specifications of "CCNinfo", an active netw orking tool for discovering the path and content-caching information in CCN.
orking tool for discovering the path and content caching information in CCN.
CCNinfo defines the protocol messages to investigate path and in-network c ache conditions in CCN. It is embedded in the CCNx forwarding process and can fa cilitate with non-IP networks as with the basic CCN concept.</t> CCNinfo defines the protocol messages to investigate path and in-network c ache conditions in CCN. It is embedded in the CCNx forwarding process and can fa cilitate with non-IP networks as with the basic CCN concept.</t>
<t>The two message types, Request and Reply messages, are encoded in the C
<t>The two message types, Request and Reply messages, are encoded in the C CNx TLV format <xref target="RFC8609" format="default"/>. The Request-and-Reply
CNx TLV format <xref target="refs.ccnx"/>. The request-reply message flow, walki message flow, walking up the tree from a consumer toward a publisher, is similar
ng up the tree from a consumer toward a publisher, is similar to the behavior of to the behavior of the IP multicast traceroute facility <xref target="RFC8487"
the IP multicast traceroute facility <xref target="refs.mtrace2" />.</t> format="default"/>.</t>
<t>CCNinfo facilitates the tracing of a routing path and provides 1) the R
<t>CCNinfo facilitates the tracing of a routing path and provides: 1) the TT between the content forwarder (i.e., caching router or first-hop router) and
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 rout
consumer, 2) the states of the in-network cache per name prefix, and 3) the rou ing path information per name prefix.</t>
ting path information per name prefix.</t> <t>In addition, CCNinfo identifies the states of the cache, such as the me
trics for Content Store (CS) in the content forwarder as follows: 1) size of cac
<t>In addition, CCNinfo identifies the states of the cache, such as the fo hed Content Objects, 2) number of cached Content Objects, 3) number of accesses
llowing metrics for Content Store (CS) in the content forwarder: 1) size of cach (i.e., received Interests) per content, and 4) elapsed cache time and remaining
ed content objects, 2) number of cached content objects, 3) number of accesses ( cache lifetime of content.</t>
i.e., received Interests) per content, and 4) elapsed cache time and remaining c
ache lifetime of content.</t>
<t>CCNinfo supports multipath forwarding. The Request messages can be forw arded to multiple neighbor routers. When the Request messages are forwarded to m ultiple routers, the different Reply messages are forwarded from different route rs or publishers.</t> <t>CCNinfo supports multipath forwarding. The Request messages can be forw arded to multiple neighbor routers. When the Request messages are forwarded to m ultiple routers, the different Reply messages are forwarded from different route rs or publishers.</t>
<t>Furthermore, CCNinfo implements policy-based information provisioning t hat enables administrators to "hide" secure or private information but does not disrupt message forwarding. This policy-based information provisioning reduces t he deployment barrier faced by operators in installing and running CCNinfo on th eir routers.</t> <t>Furthermore, CCNinfo implements policy-based information provisioning t hat enables administrators to "hide" secure or private information but does not disrupt message forwarding. This policy-based information provisioning reduces t he deployment barrier faced by operators in installing and running CCNinfo on th eir routers.</t>
<t>The document represents the consensus of the Information-Centric Networ king Research Group (ICNRG). This document was read and reviewed by the active r esearch group members. It is not an IETF product and is not a standard.</t> <t>The document represents the consensus of the Information-Centric Networ king Research Group (ICNRG). This document was read and reviewed by the active r esearch group members. It is not an IETF product and is not a standard.</t>
<section anchor="sec.intro.exp" numbered="true" toc="default">
<section anchor="sec.intro.exp" title="CCNinfo as an Experimental Tool"> <name>CCNinfo as an Experimental Tool</name>
<t>In order to carry out meaningful experimentation with CCNx protocols,
<t>In order to carry out meaningful experimentation with CCNx protocols, comprehensive instrumentation and management information is needed to take meas
comprehensive instrumentation and management information is needed to take measu urements and explore both the performance and robustness characteristics of the
rements and explore both the performance and robustness characteristics of the p protocols and of the applications using them. CCNinfo's primary goal is to gathe
rotocols and of the applications using them. CCNinfo's primary goal is to gather r and report this information. As experience is gained with both the CCNx protoc
and report this information. As experience is gained with both the CCNx protoco ols and CCNinfo itself, we can refine the instrumentation capabilities and disco
ls and CCNinfo itself, we can refine the instrumentation capabilities and discov ver what additional capabilities might be needed in CCNinfo and conversely which
er what additional capabilities might be needed in CCNinfo and conversely which features wind up not being of sufficient value to justify the implementation co
features wind up not being of sufficient value to justify the implementation com mplexity and execution overhead.</t>
plexity and execution overhead.</t> <t>CCNinfo is intended as a comprehensive experimental tool for CCNx-bas
ed networks. It provides a wealth of information from forwarders, including on-p
<t>CCNinfo is intended as a comprehensive experimental tool for CCNx-base ath in-network cache conditions as well as forwarding path instrumentation of mu
d networks. It provides a wealth of information from forwarders, including on-pa ltiple paths toward content forwarders. As an experimental capability that expos
th in-network cache conditions as well as forwarding path instrumentation of mul es detailed information about the forwarders deployed by a network operator, CCN
tiple paths toward content forwarders. As an experimental capability that expose info employs more granular authorization policies than those required of ICN pin
s detailed information about the forwarders deployed by a network operator, CCNi g or ICN traceroute.</t>
nfo employs more granular authorization policies than those required of ICN ping <t>CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.
or ICN traceroute.</t> g., consumer, initiates a CCNinfo Request message when they want to obtain routi
ng path and cache information. When an adjacent neighbor router receives the Req
<t>CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.g uest message, it examines its own cache information. If the router does not cach
., consumer, initiates a CCNinfo Request message when s/he wants to obtain routi e the specified content, it inserts its Report block into the hop-by-hop header
ng path and cache information. When an adjacent neighbor router receives the Req of the Request message and forwards the message to its upstream neighbor router(
uest message, it examines its own cache information. If the router does not cach s) decided by its FIB. In <xref target="fig_request" format="default"/>, CCNinfo
e the specified content, it inserts its Report block into the hop-by-hop header user and routers (Routers A, B, C) insert their own Report blocks into the Requ
of the Request message and forwards the message to its upstream neighbor router( est message and forward the message toward the content forwarder.</t>
s) decided by its FIB. In <xref target="fig:request" />, CCNinfo user and router <figure anchor="fig_request">
s (Router A, B, C) insert their own Report blocks into the Request message and f <name>Request Message Invoked by the CCNinfo User and Forwarded by Rou
orward the message toward the content forwarder.</t> ters</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig:request" title="Request message invoked by CCNinfo use
r and forwarded by routers.">
<artwork align="center">
1. Request 2. Request 3. Request 1. Request 2. Request 3. Request
(U) (U+A) (U+A+B) (U) (U+A) (U+A+B)
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | | | | | | | |
| v | v | v | v | v | v
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | | | user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
\ \
\ +-------+ \ +-------+
3. Request \ | Cache | 3. Request \ | Cache |
(U+A+B) \ +---------+ | (U+A+B) \ +---------+ |
v| Caching |----+ v| Caching |----+
| router | | router |
+---------+ +---------+
</artwork> ]]></artwork>
</figure> </figure>
<t>When the Request message reaches the content forwarder, the content f
<t>When the Request message reaches the content forwarder, the content fo orwarder forms the Reply message; it inserts its own Reply block TLV and Reply s
rwarder forms the Reply message; it inserts its own Reply block TLV and Reply su ub-block TLV(s) to the Request message. The Reply message is then forwarded back
b-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) e
toward the user in a hop-by-hop manner along the Pending Interest Table (PIT) en ntries. In <xref target="fig_reply" format="default"/>, each router (Routers C,
tries. In <xref target="fig:reply" />, each router (Router C, B, and A) forwards B, and A) forwards the Reply message along its PIT entry, and finally, the CCNin
the Reply message along its PIT entry and finally, the CCNinfo user receives a fo user receives a Reply message from Router C, which is the first-hop router fo
Reply message from Router C, which is the first-hop router for the Publisher. An r the publisher. Another Reply message from the caching router (i.e., Reply(C))
other Reply message from the Caching router (i.e., Reply(C)) is discarded at Rou is discarded at Router B if the other Reply message (i.e., Reply(P)) was already
ter B if the other Reply message (i.e., Reply(P)) was already forwarded by Route forwarded by Router B.</t>
r B.</t> <figure anchor="fig_reply">
<name>Reply Messages Forwarded by Routers, and One Reply Message is Re
<figure anchor="fig:reply" title="Reply messages forwarded by routers, and ceived by the CCNinfo User</name>
one Reply message is received by CCNinfo user."> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
3. Reply(P) 2. Reply(P) 1. Reply(P) 3. Reply(P) 2. Reply(P) 1. Reply(P)
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | | | | | | | |
v | v | v | v | v | v |
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | | | user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
^ ^
\ +-------+ \ +-------+
1. Reply(C) \ | Cache | 1. Reply(C) \ | Cache |
\ +---------+ | \ +---------+ |
\| Caching |----+ \| Caching |----+
| router | | router |
+---------+ +---------+
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Terminology"> <section numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
this document are to be interpreted as described in BCP 14 (<xref target="refs.R IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
FC2119">RFC2119</xref> and <xref target="refs.RFC8174">RFC8174</xref>) when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<section title="Definitions"> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<t>This document follows the basic terminologies and definitions describe when, and only when, they appear in all capitals, as shown here.
d in <xref target="refs.ccnx"/>. Although CCNinfo requests flow in the opposite </t>
direction to the data flow, we refer to "upstream" and "downstream" with respect <section numbered="true" toc="default">
to data, unless explicitly specified.</t> <name>Definitions</name>
<t>This document follows the basic terminologies and definitions describ
<t> ed in <xref target="RFC8609" format="default"/>. Although CCNinfo requests flow
<list style="hanging"> in the opposite direction to the data flow, we refer to "upstream" and "downstre
<t hangText="Scheme name"> am" with respect to data, unless explicitly specified.</t>
<vspace blankLines="0"/> <dl newline="true" spacing="normal">
It indicates a URI and protocol. This document only considers "ccnx:/ <dt>Scheme name:</dt>
" as the scheme name. <dd>
</t> A scheme name indicates a URI and protocol. This document only consid
ers "ccnx:/" as the scheme name.
<t hangText="Prefix name"> </dd>
<vspace blankLines="0"/> <dt>Prefix name:</dt>
A prefix name, which is defined in <xref target="refs.semantics" />, <dd>
is a name that does not uniquely identify a single content object, but rather a A prefix name, which is defined in <xref target="RFC8569" format="def
namespace or prefix of an existing content object name. ault"/>, is a name that does not uniquely identify a single Content Object, but
</t> rather a namespace or prefix of an existing Content Object name.
</dd>
<t hangText="Exact name"> <dt>Exact name:</dt>
<vspace blankLines="0"/> <dd>
An exact name, which is defined in <xref target="refs.semantics" />, An exact name, which is defined in <xref target="RFC8569" format="def
is one that uniquely identifies the name of a content object. ault"/>, is one that uniquely identifies the name of a Content Object.
</t> </dd>
<dt>Node:</dt>
<t hangText="Node"> <dd>
<vspace blankLines="0"/> A node within a CCN network can fulfill the role of a data publisher,
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 describ
a data consumer, and/or a forwarder for interest and content object as given in ed in <xref target="RFC8793" format="default"/>.
<xref target="refs.term" />. </dd>
</t> <dt>Consumer:</dt>
<dd>
<t hangText="Consumer"> A node that requests Content Objects by generating and sending out In
<vspace blankLines="0"/> terests. It is the same definition of ICN Consumer, as given in <xref target="RF
A node that requests content objects by generating and sending out in C8793" format="default"/>.
terests. It is a same definition of ICN Consumer as given in <xref target="refs. </dd>
term" />. <dt>Publisher:</dt>
</t> <dd>
A node that creates Content Objects and makes them available for retr
<t hangText="Publisher"> ieval. It is the same definition of ICN Producer, as given in <xref target="RFC8
<vspace blankLines="0"/> 793" format="default"/>.
A node that creates content objects and makes them available for retr </dd>
ieval. It is a same definition of ICN Producer as given in <xref target="refs.te <dt>Router:</dt>
rm" />. <dd>
</t>
<t hangText="Router">
<vspace blankLines="0"/>
A node that implements stateful forwarding in the path between consum er and publisher. A node that implements stateful forwarding in the path between consum er and publisher.
</t> </dd>
<dt>Caching router:</dt>
<t hangText="Caching router"> <dd>
<vspace blankLines="0"/> A node that temporarily stores and potentially carries Interests or C
A node that temporarily stores and potentially carries interests or c ontent Objects before forwarding it to the next node.
ontent objects before forwarding it to next node. </dd>
</t> <dt>Content forwarder:</dt>
<dd>
<t hangText="Content forwarder"> A content forwarder is either a caching router or a first-hop router
<vspace blankLines="0"/> that forwards Content Objects to consumers.
It is either a caching router or a first-hop router that forwards con </dd>
tent objects to consumers. <dt>CCNinfo user:</dt>
</t> <dd>
A node that initiates the CCNinfo Request, which is either a consumer
<t hangText="CCNinfo user"> or a router that invokes the CCNinfo user program with the name prefix of the c
<vspace blankLines="0"/> ontent. The CCNinfo user program, such as "ccninfo" command described in <xref t
A node that initiates the CCNinfo Request, which is consumer or route arget="sec.command" format="default"/> or other similar commands, initiates the
r that invokes the CCNinfo user program with the name prefix of the content. The Request message to obtain routing path and cache information.
CCNinfo user program, such as "ccninfo" command described in <xref target="sec. </dd>
command" /> or other similar commands, initiates the Request message to obtain r <dt>Incoming face:</dt>
outing path and cache information. <dd>
</t>
<t hangText="Incoming face">
<vspace blankLines="0"/>
The face on which data are expected to arrive from the specified name prefix. The face on which data are expected to arrive from the specified name prefix.
</t> </dd>
<dt>Outgoing face:</dt>
<t hangText="Outgoing face"> <dd>
<vspace blankLines="0"/> The face to which data from the publisher or router are expected to t
The face to which data from the publisher or router are expected to t ransmit for the specified name prefix. It is also the face on which the Request
ransmit for the specified name prefix. It is also the face on which the Request messages is received.
messages are received. </dd>
</t> <dt>Upstream router:</dt>
<dd>
<t hangText="Upstream router">
<vspace blankLines="0"/>
The router that connects to an Incoming face of a router. The router that connects to an Incoming face of a router.
</t> </dd>
<dt>Downstream router:</dt>
<t hangText="Downstream router"> <dd>
<vspace blankLines="0"/>
The router that connects to an Outgoing face of a router. The router that connects to an Outgoing face of a router.
</t> </dd>
<dt>First-hop router (FHR):</dt>
<t hangText="First-hop router (FHR)"> <dd>
<vspace blankLines="0"/>
The router that matches a FIB entry with an Outgoing face referring t o a local application or a publisher. The router that matches a FIB entry with an Outgoing face referring t o a local application or a publisher.
</t> </dd>
<dt>Last-hop router (LHR):</dt>
<t hangText="Last-hop router (LHR)"> <dd>
<vspace blankLines="0"/>
The router that is directly connected to a consumer. The router that is directly connected to a consumer.
</t> </dd>
</dl>
</list>
</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="CCNinfo Message Formats"> <section numbered="true" toc="default">
<name>CCNinfo Message Formats</name>
<t>CCNinfo Request and Reply messages are encoded in the CCNx TLV format ( <t>CCNinfo Request and Reply messages are encoded in the CCNx TLV format (
<xref target="refs.ccnx"/>, <xref target="CCNx_Hdr" />). The Request message con see <xref target="RFC8609" format="default"/> and <xref target="CCNx_Hdr" format
sists of a fixed header, Request block TLV (<xref target="Req_block" />), and Re ="default"/>). The Request message consists of a fixed header, Request block TLV
port block TLV(s) (<xref target="Rpt_block" />). The Reply message consists of a (<xref target="Req_block" format="default"/>), and Report block TLV(s) (<xref t
fixed header, Request block TLV, Report block TLV(s), Reply block TLV (<xref ta arget="Rpt_block" format="default"/>). The Reply message consists of a fixed hea
rget="Reply_block" />), and Reply sub-block TLV(s) (<xref target="Reply_subblock der, Request block TLV, Report block TLV(s), Reply block TLV (<xref target="Repl
" />).</t> y_block" format="default"/>), and Reply sub-block TLV(s) (<xref target="Reply_su
bblock" format="default"/>).</t>
<figure anchor="CCNx_Hdr" title="Packet format [1]"> <figure anchor="CCNx_Hdr">
<artwork align="center"> <name>Packet Format <xref target="RFC8609" format="default"/></name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength | | PacketType specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs / / Optional Hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ PacketPayload TLVs / / PacketPayload TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV / / Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<t>The PacketType values in the fixed header shown in <xref target="CCNx_H dr" format="default"/> are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY (see <xref ta rget="Type_val" format="default"/>). CCNinfo Request and Reply messages are forw arded in a hop-by-hop manner. When the Request message reaches the content forwa rder, the content forwarder turns it into a Reply message by changing the Type f ield value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and f orwards it back toward the node that initiated the Request message.</t>
<t>The PacketType values in the fixed header shown in <xref target="CCNx_H <table anchor="Type_val">
dr" /> are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (<xref target=" <name>CCNx Packet Types</name>
Type_val" />). CCNinfo Request and Reply messages are forwarded in a hop-by-hop <thead>
manner. When the Request message reaches the content forwarder, the content forw <tr>
arder turns it into a Reply message by changing the Type field value in the fixe <th>Type</th>
d header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards it back toward <th>Name</th>
the node that initiated the Request message.</t> </tr>
</thead>
<figure anchor='Type_val' title="Packet Type Namespace"> <tbody>
<artwork align="center"> <tr>
Code Type name <td>0x00</td>
======== ===================== <td>PT_INTEREST <xref target="RFC8609" format="default"/></td>
%x00 PT_INTEREST [1] </tr>
%x01 PT_CONTENT [1] <tr>
%x02 PT_RETURN [1] <td>0x01</td>
%x03 PT_CCNINFO_REQUEST <td>PT_CONTENT <xref target="RFC8609" format="default"/></td>
%x04 PT_CCNINFO_REPLY </tr>
</artwork> <tr>
</figure> <td>0x02</td>
<td>PT_RETURN <xref target="RFC8609" format="default"/></td>
</tr>
<tr>
<td>0x03</td>
<td>PT_CCNINFO_REQUEST</td>
</tr>
<tr>
<td>0x04</td>
<td>PT_CCNINFO_REPLY</td>
</tr>
</tbody>
</table>
<t>Following a fixed header, there can be a sequence of optional hop-by-ho p header TLV(s) for a Request message. In the case of a Request message, it is f ollowed by a sequence of Report blocks, each from a router on the path toward th e publisher or caching router.</t> <t>Following a fixed header, there can be a sequence of optional hop-by-ho p header TLV(s) for a Request message. In the case of a Request message, it is f ollowed by a sequence of Report blocks, each from a router on the path toward th e publisher or caching router.</t>
<t>At the beginning of PacketPayload TLVs, a top-level TLV type, T_DISCOVE RY (<xref target="Top-level_Type" format="default"/>), exists at the outermost l evel 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>
<t>At the beginning of PacketPayload TLVs, a top-level TLV type, T_DISCOVE <table anchor="Top-level_Type">
RY (<xref target="Top-level_Type" />), exists at the outermost level of a CCNx p <name>CCNx Top-Level Types</name>
rotocol message. This TLV indicates that the Name segment TLV(s) and Reply block <thead>
TLV(s) would follow in the Request or Reply message.</t> <tr>
<th>Type</th>
<figure anchor='Top-level_Type' title="Top-Level Type Namespace"> <th>Name</th>
<artwork align="center"> </tr>
Code Type name </thead>
============= ========================= <tbody>
%x0000 Reserved [1] <tr>
%x0001 T_INTEREST [1] <td>0x0000</td>
%x0002 T_OBJECT [1] <td>Reserved <xref target="RFC8609" format="default"/></td>
%x0003 T_VALIDATION_ALG [1] </tr>
%x0004 T_VALIDATION_PAYLOAD [1] <tr>
%x0005 T_DISCOVERY <td>0x0001</td>
</artwork> <td>T_INTEREST <xref target="RFC8609" format="default"/></td>
</figure> </tr>
<tr>
<!-- XXX The reasons to distinguish or separate PT values; <td>0x0002</td>
o. distinguish normal interest/data forwarding; e.g., no cache, force mult <td>T_OBJECT <xref target="RFC8609" format="default"/></td>
ipath discovery, </tr>
o. easy to filter out invalid ccninfo request or set different access cont <tr>
rol policy --> <td>0x0003</td>
<!-- XXX Why we define the new type value, T_TRACE, and don't use T_INTERE <td>T_VALIDATION_ALG <xref target="RFC8609" format="default"/></td>
ST and T_OBJECT icnping and icntrace do? </tr>
Because it is good to distingush regular Interest/CoB transmission and CCN <tr>
info. CCNinfo requires (1) no cache for reply messages, (2) different PIT operat <td>0x0004</td>
ions especially required for multipath support. For (1), it is possible to do it <td>T_VALIDATION_PAYLOAD <xref target="RFC8609" format="default"/></td>
by setting "cache lifetime = 0", but . And in any case, PT_xxx must be --> </tr>
<tr>
<td>0x0005</td>
<td>T_DISCOVERY</td>
</tr>
</tbody>
</table>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.request" title="Request Message"> <section anchor="sec.request" numbered="true" toc="default">
<name>Request Message</name>
<t>When a CCNinfo user initiates a discovery request (e.g., via the ccnin <t>When a CCNinfo user initiates a discovery request (e.g., via the ccni
fo command described in <xref target="sec.command" />), a CCNinfo Request messag nfo command described in <xref target="sec.command" format="default"/>), a CCNin
e is created and forwarded to its upstream router through the Incoming face(s) d fo Request message is created and forwarded to its upstream router through the I
etermined by its FIB.</t> ncoming face(s) determined by its FIB.</t>
<t>The Request message format is shown in <xref target="Req_message" for
<t>The Request message format is shown in <xref target="Req_message" />. mat="default"/>. It consists of a fixed header, Request header block TLV (<xref
It consists of a fixed header, Request header block TLV (<xref target="Req_block target="Req_block" format="default"/>), Report block TLV(s) (<xref target="Rpt_b
" />), Report block TLV(s) (<xref target="Rpt_block" />), Name TLV, and Request lock" format="default"/>), Name TLV, and Request block TLV. Request header block
block TLV. Request header block TLV and Report block TLV(s) are contained in the TLV and Report block TLV(s) are contained in the hop-by-hop header, as those mi
hop-by-hop header, as those might change from hop to hop. ght change from hop to hop.
Request block TLV is encoded in the PacketPayload TLV by content forwarder as th e protocol message itself. Request block TLV is encoded in the PacketPayload TLV by content forwarder as th e protocol message itself.
The PacketType value of the Request message is PT_CCNINFO_REQUEST (<xref target= The PacketType value of the Request message is PT_CCNINFO_REQUEST (<xref target=
"Type_val" />). The Type value of the Top-Level type namespace is T_DISCOVERY (< "Type_val" format="default"/>). The Type value of the CCNx Top-Level type is T_D
xref target="Top-level_Type" />).</t> ISCOVERY (<xref target="Top-level_Type" format="default"/>).</t>
<figure anchor="Req_message">
<figure anchor="Req_message" title="Request message consists of a fixed h <name>Request Message</name>
eader, Request block TLV, Report block TLV(s), and Name TLV"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
1 2 3 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 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 | | Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength |
+===============+===============+===============+===============+ +===============+===============+===============+===============+
/ Request header block TLV / / Request header block TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Report block TLV 1 / / Report block TLV 1 /
skipping to change at line 416 skipping to change at line 371
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name segment TLVs (name prefix specified by CCNinfo user) / / Name segment TLVs (name prefix specified by CCNinfo user) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Request block TLV / / Request block TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV / / Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<dl>
<t>HopLimit: 8 bits <dt>HopLimit:</dt>
<list> <dd><t>8 bits</t>
<t>HopLimit is a counter that is decremented with each hop whenever a R
equest packet is forwarded. It is specified by the CCNinfo user program. The Hop
Limit value MUST be decremented by 1 prior to forwarding the Request packet. The
packet is discarded if HopLimit is decremented to zero. HopLimit limits the dis
tance that a Request may travel on the network. Only the specified number of hop
s from the CCNinfo user traces the Request. The last router stops the trace and
sends the Reply message back to the CCNinfo user.</t>
</list>
</t>
<t>ReturnCode: 8 bits <t>HopLimit is a counter that is decremented with each hop whenever a
<list> Request packet is forwarded. It is specified by the CCNinfo user program. The Ho
<t>ReturnCode is used for the Reply message. This value is replaced by pLimit value <bcp14>MUST</bcp14> be decremented by 1 prior to forwarding the Req
the content forwarder when the Request message is returned as the Reply message uest packet. The packet is discarded if HopLimit is decremented to zero. HopLimi
(see <xref target="sec.reply" />). Until then, this field MUST be transmitted as t limits the distance that a Request may travel on the network. Only the specifi
zeros and ignored on receipt.</t> ed number of hops from the CCNinfo user traces the Request. The last router stop
</list> s the trace and sends the Reply message back to the CCNinfo user.</t></dd>
</t>
<figure> <dt>ReturnCode:</dt>
<artwork align="center"> <dd><t>8 bits</t>
Value Name Description
%x00 NO_ERROR No error
%x01 WRONG_IF CCNinfo Request arrived on an interface
to which this router would not forward for
the specified name/function toward the
publisher.
%x02 INVALID_REQUEST Invalid CCNinfo Request is received.
%x03 NO_ROUTE This router has no route for the name prefix
and no way to determine a route.
%x04 NO_INFO This router has no cache information for the
specified name prefix.
%x05 NO_SPACE There was not enough room to insert another
Report block in the packet.
%x06 INFO_HIDDEN Information is hidden from this discovery
owing to some policy.
%x0E ADMIN_PROHIB CCNinfo Request is administratively
prohibited.
%x0F UNKNOWN_REQUEST This router does not support/recognize the
Request message.
%x80 FATAL_ERROR In a fatal error, the router may know the
upstream router but cannot forward the
message to it.
</artwork>
<!--0x06 NO_GATEWAY CCNinfo Request arrived on a non-gateway
router.-->
<!--0x82 TOO_MANY_BLOCKS There was too many Report blocks in the
packet.-->
<!-- <postamble>
The 0x80 bit of the ReturnCode is used to indicate a fatal er
ror. A fatal error is one where the router cannot forward the message to the ups
tream router.
</postamble>-->
</figure>
<t>Reserved (MBZ): 8 bits <t>ReturnCode is used for the Reply message. This value is replaced by
<list> the content forwarder when the Request message is returned as the Reply message
<t>The reserved fields in the Value field MUST be transmitted as zeros (see <xref target="sec.reply" format="default"/>). Until then, this field <bcp1
and ignored on receipt.</t> 4>MUST</bcp14> be transmitted as zeros and ignored on receipt.</t>
</list>
</t>
<!-- ======================================================== --> <table>
<name>ReturnCode Used for the Reply Message</name>
<thead>
<tr>
<section anchor="sec.request_blk" title="Request Header Block and Request <th>Value</th>
Block"> <th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x00</td>
<td>NO_ERROR</td>
<td>No error</td>
</tr>
<tr>
<td>0x01</td>
<td>WRONG_IF</td>
<td>CCNinfo Request arrived on an interface to which this router would not forwa
rd for the specified name and/or function toward the publisher.</td>
</tr>
<tr>
<td>0x02</td>
<td>INVALID_REQUEST</td><td>Invalid CCNinfo Request is received.</td>
</tr>
<tr>
<td>0x03</td>
<td>NO_ROUTE </td>
<td>This router has no route for the name prefix and no way to determine a route
.</td>
</tr>
<tr>
<td>0x04</td>
<td>NO_INFO</td>
<td>This router has no cache information for the specified name prefix.</td>
</tr>
<tr>
<td>0x05</td>
<td>NO_SPACE</td>
<td>There was not enough room to insert another Report block in the packet.</td>
</tr>
<tr>
<td>0x06</td>
<td>INFO_HIDDEN</td><td>Information is hidden from this discovery owing to some
policy.</td>
</tr>
<tr>
<td>0x0E</td>
<td>ADMIN_PROHIB</td>
<td>CCNinfo Request is administratively prohibited.</td>
</tr>
<tr>
<td>0x0F</td>
<td>UNKNOWN_REQUEST</td>
<td>This router does not support or recognize the Request message.</td>
</tr>
<tr>
<td>0x80</td>
<td>FATAL_ERROR</td>
<td>In a fatal error, the router may know the upstream router but cannot forward
the message to it.</td>
</tr>
</tbody>
</table>
</dd>
<t>When a CCNinfo user transmits the Request message, s/he MUST insert <dt>Reserved (MBZ):</dt>
her/his Request header block TLV (<xref target="Req_block" />) into the hop-by-h <dd><t>8 bits</t>
op header and Request block TLV (<xref target="Req_nodeblock" />) into the messa <t>The reserved fields in the Value field <bcp14>MUST</bcp14> be transmi
ge before sending it through the Incoming face(s).</t> tted as zeros and ignored on receipt.</t></dd>
</dl>
<!-- ======================================================== -->
<figure anchor='Req_block' title="Request header block TLV (hop-by-hop <section anchor="sec.request_blk" numbered="true" toc="default">
header)"> <name>Request Header Block and Request Block</name>
<artwork align="center"> <t>When a CCNinfo user transmits the Request message, they <bcp14>MUST
</bcp14> insert their Request header block TLV (<xref target="Req_block" format=
"default"/>) into the hop-by-hop header and Request block TLV (<xref target="Req
_nodeblock" format="default"/>) into the message before sending it through the I
ncoming face(s).</t>
<figure anchor="Req_block">
<name>Request Header Block TLV (Hop-by-Hop Header)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Type (=T_DISC_REQHDR) | Length |
+---------------+---------------+-------+-------+-------+-+-+-+-+ +---------------+---------------+-------+-------+-------+-+-+-+-+
| Request ID |SkipHop| Flags |V|F|O|C| | Request ID |SkipHop| Flags |V|F|O|C|
+---------------+---------------+-------+-------+-------+-+-+-+-+ +---------------+---------------+-------+-------+-------+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<figure anchor='Hop-by-hop_Type' title="Hop-by-Hop Type Namespace"> <table anchor="Hop-by-hop_Type">
<artwork align="center"> <name>CCNx Hop-by-Hop Types</name>
Code Type name <thead>
============= ========================= <tr>
%x0000 Reserved [1] <th>Type</th>
%x0001 T_INTLIFE [1] <th>Name</th>
%x0002 T_CACHETIME [1] </tr>
%x0003 T_MSGHASH [1] </thead>
%x0004-%x0007 Reserved [1] <tbody>
%x0008 T_DISC_REQHDR <tr>
%x0009 T_DISC_REPORT <td>0x0000</td>
%x0FFE T_PAD [1] <td>Reserved <xref target="RFC8609" format="default"/></td>
%x0FFF T_ORG [1] </tr><tr>
%x1000-%x1FFF Reserved [1] <td>0x0001</td>
</artwork> <td>T_INTLIFE <xref target="RFC8609" format="default"/></td>
</figure> </tr><tr>
<td>0x0002</td>
<td>T_CACHETIME <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0003</td>
<td>T_MSGHASH <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0004-0x0007</td>
<td>Reserved <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0008</td>
<td>T_DISC_REQHDR</td>
</tr><tr>
<td>0x0009</td>
<td>T_DISC_REPORT</td>
</tr><tr>
<td>0x0FFE</td>
<td>T_PAD <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0FFF</td>
<td>T_ORG <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x1000-0x1FFF</td>
<td>Reserved <xref target="RFC8609" format="default"/></td>
</tr>
</tbody>
</table>
<t>Type: 16 bits <dl>
<list> <dt>Type:</dt>
<t>Format of the Value field. For the type value of the Request block <dd><t>16 bits</t>
TLV MUST be T_DISC_REQHDR.</t>
</list>
</t>
<t>Length: 16 bits <t>Format of the Value field. The type value of the Request header block TLV <b
<list> cp14>MUST</bcp14> be T_DISC_REQHDR.</t></dd>
<t>Length of Value field in octets.
<!-- XXX removed because of no detail discussion about this XXX
Minimum length required is 4 octets (i.e., no Value field). The ma
ximum TLV length is not defined; however the entire CCNinfo packet length should
not exceed the available MTU.-->
</t>
</list>
</t>
<t>Request ID: 16 bits <dt>Length:</dt>
<list> <dd><t>16 bits</t>
<t>This field is used as a unique identifier for the CCNinfo Request
so that the duplicate or delayed Reply messages can be detected.</t>
</list>
</t>
<t>SkipHop (Skip Hop Count): 4 bits <t>Length of the Value field in octets.</t></dd>
<list>
<t>Number of skipped routers for a Request. It is specified by the CC
Ninfo user program. The number of routers corresponding to the value specified i
n this field are skipped and the CCNinfo Request messages are forwarded to the n
ext 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 MUST be lower t
han that of HopLimit at the fixed header.</t>
</list>
</t>
<!-- <t>TimeO: 3 bits <dt>Request ID:</dt>
<list> <dd><t>16 bits</t>
<t>Timeout value (seconds). This Timeout value means a [CCNinfo Reply T <t>This field is used as a unique identifier for the CCNinfo Request so that the
imeout] value (seconds) requested by the CCNinfo user later described in <xref t duplicate or delayed Reply messages can be detected.</t></dd>
arget="sec.timer" />. A CCNinfo user requests routers along the path to keep the
PIT entry for the Request until this timeout value expires. Note that, because
of some security concern (<xref target="sec.timeout" />), a router along the pat
h may configure the shorter timeout value than this requested timeout value. In
that case, the Request may be timed out and the user may not receive the Reply a
s expected.</t>
</list>
</t>-->
<t>Flags: 12 bits <dt>SkipHop (Skip Hop Count):</dt>
<list> <dd><t>4 bits</t>
<t>The Flags field is used to indicate the types of the content or pa
th discoveries. Currently, as shown in <xref target="FlagVal" />, four bits, "C"
, "O", "F", and "V" are assigned, and the other 8 bits are reserved (MBZ) for th
e 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 targe
t="sec.command" />), and the routers that receive the Requests deal with the fla
gs and change the behaviors (see <xref target="sec.router" /> for details). The
Flag values defined in this Flags field correspond to the Reply sub-blocks.</t>
</list>
</t>
<figure anchor='FlagVal' title="Codes and types specified in Flags fiel <t>Number of skipped routers for a Request. It is specified by the C
d"> CNinfo user program. The number of routers corresponding to the value specified
<artwork align="center"> in this field are skipped, and the CCNinfo Request messages are forwarded to the
Flag Value Description next router without the addition of Report blocks; the next upstream router the
C 0 Path discovery (i.e., no cache information retrieved) n starts the trace.
(default) The maximum value of this parameter is 15. This value <bcp14>MUST</bcp14> be low
C 1 Path and cache information retrieval er than that of HopLimit at the fixed header.</t></dd>
O 0 Request to any content forwarder (default)
O 1 Publisher discovery (i.e., only FHR can reply)
F 0 Request based on FIB's forwarding strategy (default)
F 1 Full discovery request. Request to possible multiple
upstream routers specified in FIB simultaneously
V 0 No reply validation (default)
V 1 Reply sender validates Reply message
</artwork>
</figure>
<figure anchor='Req_nodeblock' title="Request block TLV (packet payload <dt>Flags:</dt>
)"> <dd><t>12 bits</t>
<artwork align="center"> <t>The Flags field is used to indicate the types of the content or path discover
ies. Currently, as shown in <xref target="FlagVal" format="default"/>, 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"/>), and the routers that receive the Requ
ests deal with the flags and change the behaviors (see <xref target="sec.router"
format="default"/> for details). The Flag values defined in this Flags field co
rrespond to the Reply sub-blocks.</t>
<table anchor="FlagVal">
<name>Codes and Types Specified in Flags Field</name>
<thead>
<tr>
<th>Flag</th>
<th>Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>C</td>
<td>0</td>
<td>Path discovery (i.e., no cache information retrieved) (default)</td>
</tr><tr>
<td>C</td>
<td>1</td>
<td>Path and cache information retrieval</td>
</tr><tr>
<td>O</td>
<td>0</td>
<td>Request to any content forwarder (default)</td>
</tr><tr>
<td>O</td>
<td>1</td>
<td>Publisher discovery (i.e., only FHR can reply)</td>
</tr><tr>
<td>F</td>
<td>0</td>
<td>Request based on FIB's forwarding strategy (default)</td>
</tr><tr>
<td>F</td>
<td>1</td>
<td>Full discovery request. Request to possible multiple upstream routers specif
ied in FIB simultaneously</td>
</tr><tr>
<td>V</td>
<td>0</td><td>No reply validation (default)</td>
</tr><tr>
<td>V</td>
<td>1</td>
<td>Reply sender validates Reply message</td>
</tr>
</tbody>
</table>
</dd></dl>
<figure anchor="Req_nodeblock">
<name>Request Block TLV (Packet Payload)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Type (=T_DISC_REQ) | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Request Arrival Time | | Request Arrival Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Node Identifier / / Node Identifier /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<table anchor="CCNx_Type">
<name>CCNx Message Types</name>
<thead>
<tr>
<th>Type</th>
<th>Name</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0000</td>
<td>T_NAME <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0001</td>
<td>T_PAYLOAD <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0002</td>
<td>T_KEYIDRESTR <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0003</td>
<td>T_OBJHASHRESTR <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0005</td>
<td>T_PAYLDTYPE <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0006</td>
<td>T_EXPIRY <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0007-0x000C</td>
<td>Reserved <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x000D</td>
<td>T_DISC_REQ</td>
</tr><tr>
<td>0x000E</td>
<td>T_DISC_REPLY</td>
</tr><tr>
<td>0x0FFE</td>
<td>T_PAD <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x0FFF</td>
<td>T_ORG <xref target="RFC8609" format="default"/></td>
</tr><tr>
<td>0x1000-0x1FFF</td>
<td>Reserved <xref target="RFC8609" format="default"/></td>
</tr>
</tbody>
</table>
<figure anchor='CCNx_Type' title="CCNx Message Type Namespace"> <dl>
<artwork align="center"> <dt>Type:</dt>
Code Type name <dd><t>16 bits</t>
============== ===================
%x0000 T_NAME [1]
%x0001 T_PAYLOAD [1]
%x0002 T_KEYIDRESTR [1]
%x0003 T_OBJHASHRESTR [1]
%x0005 T_PAYLDTYPE [1]
%x0006 T_EXPIRY [1]
%x0007 T_DISC_REQ
%x0008 T_DISC_REPLY
%x0009-%x0012 Reserved [1]
%x0FFE T_PAD [1]
%x0FFF T_ORG [1]
%x1000-%x1FFF Reserved [1]
</artwork>
</figure>
<t>Type: 16 bits <t>Format of the Value field. For the Request block TLV, the type va
<list> lue(s) <bcp14>MUST</bcp14> be T_DISC_REQ (see <xref target="CCNx_Type" format="d
<t>Format of the Value field. For the Request block TLV, the type val efault"/>) in the current specification.</t></dd>
ue(s) MUST be T_DISC_REQ (see <xref target="CCNx_Type" />) in the current specif
ication.</t>
</list>
</t>
<t>Length: 16 bits <dt>Length:</dt>
<list> <dd><t>16 bits</t>
<t>Length of Value field in octets.</t> <t>Length of the Value field in octets.</t></dd>
</list>
</t>
<dl newline="true" spacing="normal" indent="3"> <dt>Request Arrival Time:</dt>
<dt>Request Arrival Time: 32 bits</dt> <dd><t>32 bits</t>
<dd>
<!-- <vspace blankLines="1"/>-->
</dd></dl>
<dl newline="false" spacing="normal" indent="3">
<dt/>
<dd>
<t> <t>The Request Arrival Time is a 32-bit NTP timestamp specifying the
The Request Arrival Time is a 32-bit NTP timestamp specifying the
arrival time of the CCNinfo Request message at the router. 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 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 the full 64-bit form, that is, the low 16 bits of the integer part
and the high 16 bits of the fractional part. and the high 16 bits of the fractional part.</t>
</t>
<t>The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp:</t> <t>The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp:</t>
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
request_arrival_time request_arrival_time
= ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125)
]]></artwork> ]]></artwork>
<dl newline="false" spacing="normal" indent="3">
<dt/>
<dd>
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.</dd>
</dl>
<dl newline="false" spacing="normal" indent="3">
<dt/>
<dd>
Note that it is RECOMMENDED 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 consumer.</dd>
</dl>
<t>Node Identifier: variable length <t> The constant 32384 is the number of seconds from Jan 1, 1900 to
<list> Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec &lt;&lt; 7) / 1953125) is
<t>This field specifies the node identifier (e.g., node name or has a reduction of ((tv.tv_nsec / 1000000000) &lt;&lt; 16), where "&lt;&lt;" denotes
h-based self-certifying name <xref target="refs.hopauth" />) or all-zeros if unk a logical left shift.</t>
nown. This document assumes that the Name TLV defined in the CCNx TLV format <xr
ef target="refs.ccnx" /> can be used for this field and the node identifier is s
pecified in it.</t>
</list>
</t>
</section>
<!-- ======================================================== -->
<section anchor="sec.report_blk" title="Report Block TLV"> <t> Note that it is <bcp14>RECOMMENDED</bcp14> for all the routers on the p
ath 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>
<t>A CCNinfo user and each upstream router along the path would insert <dt>Node Identifier:</dt>
their own Report block TLV without changing the Type field of the fixed header o <dd><t>variable length</t>
f the Request message until one of these routers is ready to send a Reply. In th <t>This field specifies the node identifier (e.g., node name or hash
e Report block TLV (<xref target="Rpt_block" />), the Request Arrival Time and N -based self-certifying name <xref target="DCAuth" format="default"/>) or all-zer
ode Identifier MUST be inserted.</t> os if unknown. This document assumes that the Name TLV defined in the CCNx TLV f
ormat <xref target="RFC8609" format="default"/> can be used for this field and t
he node identifier is specified in it.</t></dd>
</dl>
</section>
<!-- ======================================================== -->
<figure anchor='Rpt_block' title="Report block TLV (hop-by-hop header)" <section anchor="sec.report_blk" numbered="true" toc="default">
> <name>Report Block TLV</name>
<artwork align="center"> <t>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 t
he Report block TLV (<xref target="Rpt_block" format="default"/>), the Request A
rrival Time and Node Identifier values <bcp14>MUST</bcp14> be inserted.</t>
<figure anchor="Rpt_block">
<name>Report Block TLV (Hop-by-Hop Header)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Type (=T_DISC_REPORT) | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Request Arrival Time | | Request Arrival Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Node Identifier / / Node Identifier /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<dl>
<t>Type: 16 bits <dt>Type:</dt>
<list> <dd><t>16 bits</t>
<t>Format of the Value field. For the Report block TLV, the type valu <t>Format of the Value field. For the Report block TLV, the type val
e(s) MUST be T_DISC_REPORT in the current specification. For all the available t ue(s) <bcp14>MUST</bcp14> be T_DISC_REPORT in the current specification. For all
ypes for hop-by-hop type namespace, please see <xref target="Hop-by-hop_Type"/>. the available types of the CCNx hop-by-hop types, please see <xref target="Hop-
</t> by-hop_Type" format="default"/>.</t></dd>
</list>
</t>
<t>Length: 16 bits
<list>
<t>Length of Value field in octets.</t>
</list>
</t>
<t>Request Arrival Time: 32 bits
<list>
<t>Same definition as given in <xref target="sec.request_blk" />.</t>
</list>
</t>
<t>Node Identifier: variable length <dt>Length:</dt>
<list> <dd><t>16 bits</t>
<t>Same definition as given in <xref target="sec.request_blk" />.</t>
</list>
</t>
</section> <!-- Report Block --> <t>Length of the Value field in octets.</t></dd>
<section anchor="sec.namespec" title="Content Name Specification"> <dt>Request Arrival Time:</dt>
<dd><t>32 bits</t>
<t>Same definition as given in <xref target="sec.request_blk" format
="default"/>.</t></dd>
<t>Specifications of the Name TLV (whose type value is T_NAME) and the <dt>Node Identifier:</dt>
Name Segment TLVs are described in <xref target="refs.ccnx" />, which are follow <dd><t>variable length</t>
ed by CCNinfo. CCNinfo enables to specification of the content name either with <t>Same definition as given in <xref target="sec.request_blk" format
a prefix name without chunk number (such as "ccnx:/news/today") or an exact name ="default"/>.</t></dd>
(such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix n </dl>
ame, s/he will obtain the summary information of the matched content objects in </section>
the content forwarder. In contrast, when a CCNinfo user specifies an exact name, <!-- Report Block -->
s/he will obtain only about the specified content object in the content forward
er. A CCNinfo Request message MUST NOT be sent only with a scheme name, ccnx:/.
It will be rejected and discarded by routers.</t>
</section> <!-- Name --> <section anchor="sec.namespec" numbered="true" toc="default">
<name>Content Name Specification</name>
<t>Specifications of the Name TLV (whose type value is T_NAME) and the
Name Segment TLVs are described in <xref target="RFC8609" format="default"/>, w
hich is followed by CCNinfo. CCNinfo enables the specification of the content na
me with either a prefix name without chunk number (such as "ccnx:/news/today") o
r an exact name (such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user speci
fies a prefix name, they will obtain the summary information of the matched Cont
ent Objects in the content forwarder. In contrast, when a CCNinfo user specifies
an exact name, they will obtain information only about the specified Content Ob
ject 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 r
outers.</t>
</section>
<!-- Name -->
</section> <!-- Request Message --> </section>
<!-- Request Message -->
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.reply" title="Reply Message"> <section anchor="sec.reply" numbered="true" toc="default">
<name>Reply Message</name>
<t>When a content forwarder receives a CCNinfo Request message from an ap <t>When a content forwarder receives a CCNinfo Request message from an a
propriate adjacent neighbor router, it inserts its own Reply block TLV and Reply ppropriate adjacent neighbor router, it inserts its own Reply block TLV and Repl
sub-block TLV(s) to the Request message and turns the Request into the Reply by y sub-block TLV(s) to the Request message and turns the Request into the Reply b
changing the Type field of the fixed header of the Request message from PT_CCNI y changing the Type field of the fixed header of the Request message from PT_CCN
NFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see <xref target="Reply_mess INFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see <xref target="Reply_mes
age" />) is then forwarded back toward the CCNinfo user in a hop-by-hop manner.< sage" format="default"/>) is then forwarded back toward the CCNinfo user in a ho
/t> p-by-hop manner.</t>
<figure anchor="Reply_message" title="Reply message consists of a fixed h <figure anchor="Reply_message">
eader, Request block TLV, Report block TLV(s), Name TLV, and Reply block/sub-blo <name>Reply Message</name>
ck TLV(s)"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
1 2 3 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 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 | | Version | PacketType | PacketLength |
+---------------+---------------+-------------+-+---------------+ +---------------+---------------+-------------+-+---------------+
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength |
+===============+===============+=============+=+===============+ +===============+===============+=============+=+===============+
/ Request header block TLV / / Request header block TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ . / / . /
skipping to change at line 753 skipping to change at line 778
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ . / / . /
/ . / / . /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Reply sub-block TLV k / / Reply sub-block TLV k /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV / / Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<!-- ======================================================== -->
<!-- ======================================================== -->
<section anchor="sec.reply_blk" title="Reply Block TLV">
<t>The Reply block TLV is an envelope for the Reply sub-block TLV(s) (exp
lained from the next section).</t>
<figure anchor="Reply_block" title="Reply block TLV (packet payload)"> <section anchor="sec.reply_blk" numbered="true" toc="default">
<artwork align="center"> <name>Reply Block TLV</name>
<t>The Reply block TLV is an envelope for the Reply sub-block TLV(s) (
explained in the next section).</t>
<figure anchor="Reply_block">
<name>Reply Block TLV (Packet Payload)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Type (=T_DISC_REPLY) | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Request Arrival Time | | Request Arrival Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Node Identifier / / Node Identifier /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<dl>
<t>Type: 16 bits <dt>Type:</dt>
<list> <dd><t>16 bits</t>
<t>Format of the Value field. For the Reply block TLV, the type value M
UST be T_DISC_REPLY shown in <xref target="CCNx_Type" /> in the current specific
ation.</t>
</list>
</t>
<t>Length: 16 bits
<list>
<t>Length of the Value field in octets. This length is the total length
of Reply sub-block(s).</t>
</list>
</t>
<t>Request Arrival Time: 32 bits
<list>
<t>Same definition as given in <xref target="sec.request_blk" />.</t>
</list>
</t>
<t>Node Identifier: variable length
<list>
<t>Same definition as given in <xref target="sec.request_blk" />.</t>
</list>
</t>
<!-- ======================================================== -->
<section anchor="sec.reply_subblk" title="Reply Sub-Block TLV"> <t>Format of the Value field. For the Reply block TLV, the type valu e <bcp14>MUST</bcp14> be T_DISC_REPLY shown in <xref target="CCNx_Type" format=" default"/> in the current specification.</t></dd>
<t>The router on the traced path will add one or multiple Reply sub-blo <dt>Length:</dt>
cks followed by the Reply block TLV before sending the Reply to its neighbor rou <dd><t>16 bits</t>
ter. This section describes the Reply sub-block TLV for informing various cache <t>Length of the Value field in octets. This length is the total len
states and conditions as shown in <xref target="Reply_subblock" />. (Other Reply gth of the Reply sub-block(s).</t>
sub-block TLVs will be discussed in separate document(s).)</t> </dd>
<dt>Request Arrival Time:</dt>
<dd><t>32 bits</t>
<t>Note that some routers may not be capable of reporting the following <t>Same definition as given in <xref target="sec.request_blk" format
values, such as Object Size, Object Count, # Received Interest, First Seqnum, L ="default"/>.</t>
ast Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, shown in <xref target </dd>
="Reply_subblock" />, or do not report these values due to their policy. In that <dt>Node Identifier:</dt>
case, the routers set these fields to a value of all ones (i.e., %xFFFFFFFF). T <dd><t>variable length</t>
he value of each field will be also all-one when the value is equal to or bigger <t>Same definition as given in <xref target="sec.request_blk" format
than the maximum size expressed by the 32-bit field. The CCNinfo user program M ="default"/>.</t>
UST inform that these values are not valid if the fields received are set to the </dd>
value of all ones.</t> </dl>
<!-- ======================================================== -->
<t>If the cache is refreshed after reboot, the value in each field MUST <section anchor="sec.reply_subblk" numbered="true" toc="default">
be refreshed (i.e., MUST be set to 0). If the cache remains after reboot, the v <name>Reply Sub-Block TLV</name>
alue MUST NOT be refreshed (i.e., MUST be reflected as it is).</t> <t>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 cac
he states and conditions as shown in <xref target="Reply_subblock" format="defau
lt"/>. (Other Reply sub-block TLVs will be discussed in separate document(s).)</
t>
<figure anchor="Reply_subblock" title="Reply sub-block TLV for T_DISC_C <t>Note that some routers may not be capable of reporting the follow
ONTENT and T_DISC_CONTENT_PUBLISHER (packet payload)"> ing values: Object Size, Object Count, # Received Interest, First Seqnum, Last S
<artwork align="center"> eqnum, Elapsed Cache Time, and Remain Cache Lifetime (shown in <xref target="Rep
ly_subblock" format="default"/>). Or, some routers do not report these values du
e to their policy. In that case, the routers <bcp14>MUST</bcp14> set these field
s 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 s
ize 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 val
ue of all ones.</t>
<t>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">
<name>Reply Sub-Block TLV for T_DISC_CONTENT and T_DISC_CONTENT_PU
BLISHER (Packet Payload)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
1 2 3 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 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 | | Type | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Object Size | | Object Size |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Object Count | | Object Count |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| # Received Interest | | # Received Interest |
skipping to change at line 835 skipping to change at line 853
| Last Seqnum | | Last Seqnum |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Elapsed Cache Time | | Elapsed Cache Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Remain Cache Lifetime | | Remain Cache Lifetime |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name Segment TLVs / / Name Segment TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
</artwork> ]]></artwork>
</figure> </figure>
<table anchor="Sub_Type">
<figure anchor='Sub_Type' title="CCNinfo Reply Type Namespace"> <name>CCNx Reply Types</name>
<artwork align="center"> <thead>
Code Type name <tr>
============= =========================== <th>Type</th>
%x0000 T_DISC_CONTENT <th>Name</th>
%x0001 T_DISC_CONTENT_PUBLISHER </tr>
%x0FFF T_ORG </thead>
%x1000-%x1FFF Reserved (Experimental Use) <tbody>
</artwork> <tr>
</figure> <td>0x0000</td>
<td>T_DISC_CONTENT</td>
<t>Type: 16 bits </tr><tr>
<list> <td>0x0001</td>
<t>Format of the Value field. For the Reply sub-block TLV, the type v <td>T_DISC_CONTENT_PUBLISHER</td>
alue MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER defined in the CC </tr><tr>
Ninfo Reply Type Namespace (<xref target="Sub_Type" />). T_DISC_CONTENT is speci <td>0x0FFF</td>
fied when the cache information is replied from a caching router. T_DISC_CONTENT <td>T_ORG</td>
_PUBLISHER is specified when the content information is replied from a FHR attac </tr><tr>
hed to a publisher.</t> <td>0x1000-0x1FFF</td>
</list> <td>Reserved for Experimental Use</td>
</t> </tr>
</tbody>
<t>Length: 16 bits
<list>
<t>Length of the Value field in octets.</t>
</list>
</t>
<t>Object Size: 32 bits
<list>
<t>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 fiel
d is approximately 4.29 TB.
</t>
</list>
</t>
<t>Object Count: 32 bits
<list>
<t>The number of the unexpired content objects. Note that the maximum
count expressed by the 32-bit field is approximately 4.29 billion.</t>
</list>
</t>
<t># Received Interest: 32 bits
<list>
<!-- <t>The number of the received Interest messages to retrieve the content
(not content objects).</t>-->
<t>The total number of the received Interest messages to retrieve the
cached content objects.</t>
</list>
</t>
<t>First Seqnum: 32 bits
<list>
<t>The first sequential number of the unexpired content objects.</t>
</list>
</t>
<t>Last Seqnum: 32 bits
<list>
<t>The last sequential number of the unexpired content objects. The Fir
st Seqnum and Last Seqnum do not guarantee the consecutiveness of the cached con
tent objects; however, knowing these values may help in the analysis of consecut
ive or discontinuous chunks such as <xref target="refs.acur" />.</t>
</list>
</t>
<t>Elapsed Cache Time: 32 bits
<list>
<t>The elapsed time (seconds) after the oldest content object of the co
ntent is cached.</t>
</list>
</t>
<!-- XXXXX cache life time is per content? or per content object? If the latter
one, this is wrong. -->
<t>Remain Cache Lifetime: 32 bits </table>
<list>
<t>The lifetime (seconds) of a content object, which is lastly cached.
<!--The shortest lifetime among the cached content objects. The content object i
s removed after this timeout period. -->
</t>
</list>
</t>
</section> <!-- Reply Sub-Block --> <dl>
</section> <!-- Reply Block --> <dt>Type:</dt>
<dd><t>16 bits</t>
</section> <!-- Reply Message --> <t>Format of the Value field. For the Reply sub-block TLV, the typ e 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"/>).
</section> <!-- CCNinfo Message Formats --> T_DISC_CONTENT is specified when a content forwarder replies with the cache inf ormation. T_DISC_CONTENT_PUBLISHER is specified when a FHR attached to a publish er replies with the original content information.</t></dd>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <dt>Length:</dt>
<dd><t>16 bits</t>
<section anchor="sec.user" title="CCNinfo User Behavior"> <t>Length of the Value field in octets.</t>
</dd>
<dt>Object Size:</dt>
<dd><t>32 bits</t>
<t>The total size (KB) of the unexpired Content Objects. Values le
ss than 1 KB are truncated. Note that the maximum size expressed by the 32-bit f
ield is approximately 4.29 TB.
</t>
</dd>
<dt>Object Count:</dt>
<dd><t>32 bits</t>
<t>The number of the unexpired Content Objects. Note that the maxi
mum count expressed by the 32-bit field is approximately 4.29 billion.</t></dd>
<!-- ========================================================== --> <dt># Received Interest:</dt>
<dd><t>32 bits</t>
<section title="Sending CCNinfo Request"> <t>The total number of the received Interest messages to retrieve the
cached Content Objects.</t>
</dd>
<dt>First Seqnum:</dt>
<dd><t>32 bits</t>
<t>A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) <t>The first sequential number of the unexpired Content Objects.</
that initiates a CCNinfo Request message and sends it to the user's adjacent nei t>
ghbor router(s) of interest. The user later obtains both the routing path inform </dd>
ation and in-network cache information in the single Reply.</t> <dt>Last Seqnum:</dt>
<dd><t>32 bits</t>
<t>When the CCNinfo user program initiates a Request message, it MUST ins ert the necessary values, i.e., the "Request ID" and the "Node Identifier", in t he Request block. The Request ID MUST be unique for the CCNinfo user until s/he receives the corresponding Reply message(s) or the Request is timed out.</t> <t>The last sequential number of the unexpired Content Objects. Th e First Seqnum and Last Seqnum do not guarantee the consecutiveness of the cache d Content Objects; however, knowing these values may help in the analysis of con secutive or discontinuous chunks such as <xref target="CONSEC-CACHING" format="d efault"/>.</t></dd>
<t>Owing to some policies, a router may want to validate the CCNinfo Requ <dt>Elapsed Cache Time:</dt>
ests using the CCNx ValidationPayload TLV (whether it accepts the Request or not <dd><t>32 bits</t>
) especially when the router receives the "full discovery request" (see <xref ta
rget="sec.forward.full-request" />). Accordingly, the CCNinfo user program MAY r
equire validating the Request message and appending the user's signature into th
e CCNx ValidationPayload TLV. The router then forwards the Request message. If t
he router does not approve the Request, it rejects the Request message as descri
bed in <xref target="sec.admin_prohibit" />.</t>
<!-- XXX or silently discards the Request??? -->
<t>After the CCNinfo user program sends the Request message, until the Re <t>The elapsed time (seconds) after the oldest Content Object of t
ply is timed out or the expected numbers of Replies or a Reply message with a no he content is cached.</t>
n-zero ReturnCode in the fixed header is received, the CCNinfo user program MUST </dd>
keep the following information: HopLimit, specified in the fixed header, Reques
t ID, Flags, Node Identifier, and Request Arrival Time, specified in the Request
block.</t>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <dt>Remain Cache Lifetime:</dt>
<dd><t>32 bits</t>
<section anchor="sec.usr.path" title="Routing Path Information"> <t>The lifetime (seconds) of a Content Object, which is lastly cac
hed.
</t>
</dd>
</dl>
</section>
<!-- Reply Sub-Block -->
<t>A CCNinfo user can send a CCNinfo Request for investigating the rout ing path information for the specified named content. Using the Request, a legit imate user can obtain 1) the node identifiers of the intermediate routers, 2) no de identifier of the content forwarder, 3) number of hops between the content fo rwarder and consumer, and 4) RTT between the content forwarder and consumer, per name prefix. This CCNinfo Request is terminated when it reaches the content for warder.</t>
</section> </section>
<!-- Reply Block -->
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> </section>
<!-- Reply Message -->
<section anchor="sec.usr.cache" title="In-Network Cache Information">
<t>A CCNinfo user can send a CCNinfo Request for investigating in-netwo </section>
rk cache information. Using the Request, a legitimate user can obtain 1) the siz <!-- CCNinfo Message Formats -->
e of cached content objects, 2) number of cached content objects, 3) number of a
ccesses (i.e., received Interests) per content, and 4) lifetime and expiration t
ime of the cached content objects, for Content Store (CS) in the content forward
er, unless the content forwarder is capable of reporting them (see <xref target=
"sec.reply_subblk" />). This CCNinfo Request is terminated when it reaches the c
ontent forwarder.</t>
</section>
</section> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.user" numbered="true" toc="default">
<name>CCNinfo User Behavior</name>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.receiving_reply" title="Receiving CCNinfo Reply"> <section numbered="true" toc="default">
<name>Sending CCNinfo Request</name>
<t>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 ne
ighbor router(s) of interest. The user later obtains both the routing path infor
mation and in-network cache information in the single Reply.</t>
<t>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 I
dentifier", in the Request block. The Request ID <bcp14>MUST</bcp14> be unique f
or the CCNinfo user until they receive the corresponding Reply message(s) or the
Request is timed out.</t>
<t>Owing to some policies, a router may want to validate the CCNinfo Req
uests using the CCNx ValidationPayload TLV (whether it accepts the Request or no
t) especially when the router receives the "full discovery request" (see <xref t
arget="sec.forward.full-request" format="default"/>). Accordingly, the CCNinfo u
ser program <bcp14>MAY</bcp14> require validating the Request message and append
ing the user's signature into the CCNx ValidationPayload TLV. The router then fo
rwards the Request message. If the router does not approve the Request, it rejec
ts the Request message as described in <xref target="sec.admin_prohibit" format=
"default"/>.</t>
<t>A CCNinfo user program will receive one or multiple CCNinfo Reply mess <t>After the CCNinfo user program sends the Request message, until the
ages from the adjacent neighbor router(s). When the program receives the Reply, Reply is timed out or the expected numbers of Replies or a Reply
it MUST compare the kept Request ID and Node Identifier to identify the Request message with a non-zero ReturnCode in the fixed header is received,
and Reply pair. the CCNinfo user program <bcp14>MUST</bcp14> keep the following information:
If they do not match, the Reply message MUST be silently discarded.</t> 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>
<t>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 M UST be silently ignored.</t> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<t>After the CCNinfo user has determined that s/he has traced the whole p <section anchor="sec.usr.path" numbered="true" toc="default">
ath or the maximum path that s/he can be expected to, s/he might collect statist <name>Routing Path Information</name>
ics by waiting for a timeout. Useful statistics provided by CCNinfo are stated i <t>A CCNinfo user can send a CCNinfo Request for investigating the rou
n <xref target="sec.diag"/>.</t> ting path information for the specified named content. Using the Request, a legi
timate user can obtain 1) the node identifiers of the intermediate routers, 2) t
he node identifier of the content forwarder, 3) the number of hops between the c
ontent 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 re
aches the content forwarder.</t>
</section>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec.usr.cache" numbered="true" toc="default">
<name>In-Network Cache Information</name>
<t>A CCNinfo user can send a CCNinfo Request for investigating in-netw
ork cache information. Using the Request, a legitimate user can obtain 1) the si
ze of cached Content Objects, 2) the number of cached Content Objects, 3) the nu
mber 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 co
ntent forwarder, unless the content forwarder is capable of reporting them (see
<xref target="sec.reply_subblk" format="default"/>). This CCNinfo Request is ter
minated when it reaches the content forwarder.</t>
</section>
</section> </section>
<!-- ========================================================== -->
<section anchor="sec.receiving_reply" numbered="true" toc="default">
<name>Receiving CCNinfo Reply</name>
<t>A CCNinfo user program will receive one or multiple CCNinfo Reply mes
sages 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 t
o identify the Request and Reply pair.
If they do not match, the Reply message <bcp14>MUST</bcp14> be silently d
iscarded.</t>
<t>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>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 stati
stics by waiting for a timeout. Useful statistics provided by CCNinfo are stated
in <xref target="sec.diag" format="default"/>.</t>
</section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.router" title="Router Behavior"> <section anchor="sec.router" numbered="true" toc="default">
<name>Router Behavior</name>
<!-- ========================================================== --> <!-- ========================================================== -->
<section title="User and Neighbor Verification"> <section numbered="true" toc="default">
<t>Upon receiving a CCNinfo Request message, a router MAY examine whether <name>User and Neighbor Verification</name>
a valid CCNinfo user has sent the message. If the router recognizes that the Re <t>Upon receiving a CCNinfo Request message, a router <bcp14>MAY</bcp14>
quest sender's signature specified in the Request is invalid, it SHOULD terminat examine whether a valid CCNinfo user has sent the message. If the router recogn
e the Request, as defined in <xref target="sec.terminate.invalid" />.</t> izes that the Request sender's signature specified in the Request is invalid, it
<t>Upon receiving a CCNinfo Request/Reply message, a router MAY examine w <bcp14>SHOULD</bcp14> terminate the Request, as defined in <xref target="sec.te
hether the message comes from a valid adjacent neighbor node. If the router reco rminate.invalid" format="default"/>.</t>
gnizes that the Request/Reply sender is invalid, it SHOULD silently ignore the R <t>Upon receiving a CCNinfo Request or Reply message, a router <bcp14>MA
equest/Reply message, as specified in <xref target="sec.adjacency" />.</t> Y</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
<!-- The router next examines the number of Report blocks. If the number of >SHOULD</bcp14> silently ignore the message, as specified in <xref target="sec.a
Report blocks is equal or more than the value of the "HopLimit" in the fixed hea djacency" format="default"/>.</t>
der, the Request MUST be silently ignored.-->
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.receive.req" title="Receiving CCNinfo Request"> <section anchor="sec.receive.req" numbered="true" toc="default">
<name>Receiving CCNinfo Request</name>
<t>After a router accepts the CCNinfo Request message, it performs the fo <t>After a router accepts the CCNinfo Request message, it performs the f
llowing steps.</t> ollowing steps.</t>
<ol spacing="normal" type="1"><li>The value of "HopLimit" in the fixed h
<t><list style='numbers'> eader and the value of "SkipHop (Skip Hop Count)" in the Request block are count
<t>The value of "HopLimit" in the fixed header and that of "SkipHop (Sk ers that are decremented with each hop. If the HopLimit value is zero, the route
ip Hop Count)" in the Request block are counters that are decremented with each r terminates the Request, as defined in <xref target="sec.terminate.no_route" fo
hop. If the HopLimit value is zero, the router terminates the Request, as define rmat="default"/>. If the SkipHop value is equal to or more than the HopLimit val
d in <xref target="sec.terminate.no_route" />. If the SkipHop value is equal to ue, the router terminates the Request, as defined in <xref target="sec.terminate
or more than the HopLimit value, the router terminates the Request, as defined i .invalid" format="default"/>; otherwise, until the SkipHop value becomes zero, t
n <xref target="sec.terminate.invalid" />. Otherwise, until the SkipHop value be he router forwards the Request message to the upstream router(s) without adding
comes zero, the router forwards the Request message to the upstream router(s) wi its own Report block and without replying to the Request. If the router does not
thout adding its own Report block and without replying to the Request. If the ro know the upstream router(s) regarding the specified name prefix, it terminates
uter does not know the upstream router(s) regarding the specified name prefix, i the Request, as defined in <xref target="sec.terminate.no_route" format="default
t terminates the Request, as defined in <xref target="sec.terminate.no_route" /> "/>. It should be noted that the Request messages are terminated at the FHR; the
. It should be noted that the Request messages are terminated at the FHR; theref refore, although the maximum value for the HopLimit is 255 and that for SkipHop
ore, although the maximum value for the HopLimit is 255 and that for SkipHop is is 15, if the Request messages reach the FHR before the HopLimit or SkipHop valu
15, if the Request messages reach the FHR before the HopLimit or SkipHop value b e becomes 0, the FHR silently discards the Request message and the Request is ti
ecomes 0, the FHR silently discards the Request message and the Request is timed med out.</li>
out.</t> <li>The router examines the Flags field (specified in <xref target="Fl
agVal" format="default"/>) in the Request block of the received CCNinfo Request.
<t>The router examines the Flags field (specified in <xref target="Flag If the "C" flag is not set, it is categorized as the "routing path information
Val" />) in the Request block of the received CCNinfo Request. If the "C" flag i discovery". If the "C" flag is set, it is the "cache information discovery". If
s not set, it is categorized as the "routing path information discovery". If the the "O" flag is set, it is the "publisher discovery".</li>
"C" flag is set, it is the "cache information discovery". If the "O" flag is se <li>If the Request is either "cache information discovery" or "routing
t, it is the "publisher discovery".</t> 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 bloc
<t>If the Request is either "cache information discovery" or "routing p k and sub-block(s). If the router cannot insert its own Reply block or sub-block
ath information discovery", the router examines its FIB and CS. If the router ca (s) because of no space, it terminates the Request, as specified in <xref target
ches the specified content, it sends the Reply message with its own Reply block ="sec.terminate.no_space" format="default"/>.
and sub-block(s). If the router cannot insert its own Reply block or sub-block(s If the router does not cache the specified content but knows the upstre
) because of no space, it terminates the Request, as specified in <xref target=" am neighbor router(s) for the specified name prefix, it creates the PIT entry, i
sec.terminate.no_space" />. nserts its own Report block in the hop-by-hop header, and forwards the Request t
If the router does not cache the specified content but knows the upstre o the upstream neighbor(s). If the router cannot insert its own Report block bec
am neighbor router(s) for the specified name prefix, it creates the PIT entry, a ause of no space, or if the router does not cache the specified content and does
nd inserts its own Report block in the hop-by-hop header and forwards the Reques not know the upstream neighbor router(s) for the specified name prefix, it term
t to the upstream neighbor(s). If the router cannot insert its own Report block inates the Request, as defined in <xref target="sec.terminate.no_route" format="
because of no space, or if the router does not cache the specified content and d default"/>.</li>
oes not know the upstream neighbor router(s) for the specified name prefix, it t <li>If the Request is the "publisher discovery", the router examines w
erminates the Request, as defined in <xref target="sec.terminate.no_route" />.</ hether it is the FHR for the requested content. If the router is the FHR, it sen
t> ds the Reply message with its own Report block and sub-blocks (in the case of ca
che information discovery) or the Reply message with its own Report block withou
<t>If the Request is the "publisher discovery", the router examines whe t adding any Reply sub-blocks (in the case of routing path information discovery
ther it is the FHR for the requested content. If the router is the FHR, it sends ). If the router is not the FHR but knows the upstream neighbor router(s) for th
the Reply message with its own Report block and sub-blocks (in the case of cach e specified name prefix, it creates the PIT entry, inserts its own Report block,
e information discovery) or the Reply message with its own Report block without and forwards the Request to the upstream neighbor(s). If the router cannot inse
adding any Reply sub-blocks (in the case of routing path information discovery). rt its own Report block in the hop-by-hop header because of no space, it termina
If the router is not the FHR but knows the upstream neighbor router(s) for the tes the Request, as specified in <xref target="sec.terminate.no_space" format="d
specified name prefix, it creates the PIT entry, and inserts its own Report bloc efault"/>. If the router is not the FHR and does not know the upstream neighbor
k and forwards the Request to the upstream neighbor(s). If the router cannot ins router(s) for the specified name prefix, it terminates the Request, as defined i
ert its own Report block in the hop-by-hop header because of no space, it termin n <xref target="sec.terminate.no_route" format="default"/>. Note that in Cefore
ates the Request, as specified in <xref target="sec.terminate.no_space" />. If t <xref target="Cefore-site" format="default"/>, there is an API by which a publis
he router is not the FHR and does not know the upstream neighbor router(s) for t her informs the application prefix to the FHR, and the FHR registers it into the
he specified name prefix, it terminates the Request, as defined in <xref target= FIB. The prefix entry then can be statically configured on other routers or ann
"sec.terminate.no_route" />. Note that in Cefore <xref target="refs.cefore" />, ounced by a routing protocol.</li>
there is an API by which a publisher informs the application prefix to the FHR a </ol>
nd the FHR registers it into the FIB. The prefix entry then can be statically co
nfigured on other routers or announced by a routing protocol.</t>
</list></t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.forward.request" title="Forwarding CCNinfo Request"> <section anchor="sec.forward.request" numbered="true" toc="default">
<name>Forwarding CCNinfo Request</name>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<section anchor="sec.forward.regular" title="Regular Request">
<t>When a router decides to forward a Request message with its Report b
lock to its upstream router(s), it specifies the Request Arrival Time and Node I
dentifier in the Report block of the Request message. The router then forwards t
he Request message upstream toward the publisher or caching router based on the
FIB entry like the ordinary Interest-Data exchanges in CCN.</t>
<t>When the router forwards the Request message, it MUST record the F f <section anchor="sec.forward.regular" numbered="true" toc="default">
lag and Request ID in the Request block of the Request message and exploiting pa <name>Regular Request</name>
th labels (specified in <xref target="sec.intro" />) at the corresponding PIT en <t>When a router decides to forward a Request message with its Report
try. 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 fo
rwards 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>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 a
nd exploiting path labels (specified in <xref target="sec.intro" format="default
"/>) at the corresponding PIT entry.
The router can later check the PIT entry to correctly forward the Reply message(s) back.</t> The router can later check the PIT entry to correctly forward the Reply message(s) back.</t>
<t>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 I
nterest messages to multiple neighbor routers, it may delay or prioritize to sen
d the message to the upstream routers. The CCNinfo Request, as the default, comp
lies 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 a
s a Content Object.</t>
</section>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<t>CCNinfo supports multipath forwarding. The Request messages can be f <section anchor="sec.forward.full-request" numbered="true" toc="default">
orwarded to multiple neighbor routers. <name>Full Discovery Request</name>
<!-- XXX accept strategy, no SHOULD XXX --> <t>There may be a case wherein a CCNinfo user wants to discover all po
Some routers may have a strategy for multipath forwarding; when a router sends I ssible forwarding paths and content forwarders based on the routers' FIBs. The "
nterest messages to multiple neighbor routers, it may delay or prioritize to sen full discovery request" enables this functionality.
d the message to the upstream routers. The CCNinfo Request, as the default, comp If a CCNinfo user sets the F flag in the Request block of the Request mes
lies with such strategies; a CCNinfo user could trace the actual forwarding path sage (as seen in <xref target="FlagVal" format="default"/>) to request the full
based on the forwarding strategy and will receive a single Reply message such a discovery, the upstream routers simultaneously forward the Requests to all multi
s a content object.</t> ple upstream routers based on the FIBs. Then, the CCNinfo user can trace all pos
sible forwarding paths. As seen in <xref target="fig_reply_force" format="defaul
</section> t"/>, each router forwards the Reply message along its PIT entry, and finally, t
he 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">
<section anchor="sec.forward.full-request" title="Full Discovery Request" <name>Full Discovery Request: Reply Messages Forwarded by the Publis
> her and Routers</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<t>There may be a case wherein a CCNinfo user wants to discover all pos
sible forwarding paths and content forwarders based on the routers' FIBs. The "f
ull discovery request" enables this functionality.
If a CCNinfo user sets the F flag in the Request block of the Request mes
sage (as seen in <xref target="FlagVal" />) to request the full discovery, the u
pstream routers simultaneously forward the Requests to all multiple upstream rou
ters based on the FIBs. Then, the CCNinfo user can trace all possible forwarding
paths. As seen in <xref target="fig:reply_force" />, each router forwards the R
eply message along its PIT entry and finally, the CCNinfo user receives two Repl
y messages: one from the FHR (Router C) and the other from the Caching router.</
t>
<figure anchor="fig:reply_force" title="Full discovery request. Reply m
essages forwarded by publisher and routers.">
<artwork align="center">
3. Reply(C) 2. Reply(C) 3. Reply(C) 2. Reply(C)
3. Reply(P) 2. Reply(P) 1. Reply(P) 3. Reply(P) 2. Reply(P) 1. Reply(P)
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | | | | | | | |
v | v | v | v | v | v |
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | | | user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+
^ ^
\ +-------+ \ +-------+
1. Reply(C) \ | Cache | 1. Reply(C) \ | Cache |
\ +---------+ | \ +---------+ |
\| Caching |----+ \| Caching |----+
| router | | router |
+---------+ +---------+
</artwork> ]]></artwork>
</figure> </figure>
<t>To receive different Reply messages forwarded from different router
<t>To receive different Reply messages forwarded from different routers s, the PIT entries initiated by CCNinfo remain until the configured CCNinfo Repl
, the PIT entries initiated by CCNinfo remain until the configured CCNinfo Reply y Timeout (<xref target="sec.timer" format="default"/>) is expired. In other wor
Timeout (<xref target="sec.timer" />) is expired. In other words, unlike the or ds, unlike the ordinary Interest-Data exchanges in CCN, if routers that accept t
dinary Interest-Data exchanges in CCN, if routers that accept the full discovery he full discovery request receive the full discovery request, the routers <bcp14
request receive the full discovery request, the routers SHOULD NOT remove the P >SHOULD NOT</bcp14> remove the PIT entry created by the full discovery request u
IT entry created by the full discovery request until the CCNinfo Reply Timeout v ntil the CCNinfo Reply Timeout value expires.</t>
alue expires.</t> <t>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 i
<t>Note that the full discovery request is an OPTIONAL implementation o mplemented on a router, it may not accept the full discovery request from non-va
f CCNinfo; it may not be implemented on routers. Even if it is implemented on a lidated CCNinfo users or routers or because of its policy. If a router does not
router, it may not accept the full discovery request from non-validated CCNinfo accept the full discovery request, it rejects the full discovery request as desc
users or routers or because of its policy. If a router does not accept the full ribed in <xref target="sec.admin_prohibit" format="default"/>. Routers that enab
discovery request, it rejects the full discovery request as described in <xref t le the full discovery request <bcp14>MAY</bcp14> rate-limit Replies, as describe
arget="sec.admin_prohibit" />. Routers that enable the full discovery request MA d in <xref target="sec.rate_limit.reply" format="default"/> as well.</t>
Y rate-limit Replies, as described in <xref target="sec.rate_limit.reply" /> as </section>
well.</t>
</section>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.send.reply" title="Sending CCNinfo Reply"> <section anchor="sec.send.reply" numbered="true" toc="default">
<name>Sending CCNinfo Reply</name>
<t>If there is a caching router or FHR for the specified content within t <t>If there is a caching router or FHR for the specified content within
he specified hop count along the path, the caching router or FHR sends back the 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> Reply message toward the CCNinfo user and terminates the Request.</t>
<t>When a router decides to send a Reply message to its downstream neigh
<t>When a router decides to send a Reply message to its downstream neighb bor router or the CCNinfo user with a NO_ERROR return code, it inserts a Report
or router or the CCNinfo user with NO_ERROR return code, it inserts a Report blo block with the Request Arrival Time and Node Identifier values to the Request me
ck with the Request Arrival Time and Node Identifier to the Request message. The ssage. Then, the router inserts the corresponding Reply sub-block(s) (<xref targ
n, the router inserts the corresponding Reply sub-block(s) (<xref target="Reply_ et="Reply_subblock" format="default"/>) to the payload. The router finally chang
subblock" />) to the payload. The router finally changes the Type field in the f es the Type field in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPL
ixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message Y and forwards the message back as the Reply toward the CCNinfo user in a hop-by
back as the Reply toward the CCNinfo user in a hop-by-hop manner.</t> -hop manner.</t>
<!-- <t>The total number of the traced routers SHOULD be the sum of the Report
blocks in the Request (including the one just added), even though there may be
the Request blocks with null Node Identifier because of some administrative poli
cy (see <xref target="sec.policy" />).
The router that creates the Reply message SHOULD examine the number of the locat
ed Report block TLVs and compare it with the HopCount field value in the Request
block TLV in the Reply message.</t>
<t>When a router decides to send the Reply message for the Request for th
e cache or routing path information discovery, it forms the Reply message includ
ing a Reply block and a Reply sub-block and various cache information. After th
e router puts the NO_ERROR return code in the fixed header, it sends the Reply b
ack toward the CCNinfo user.</t>-->
<t>If a router cannot continue the Request, the router MUST put an approp
riate ReturnCode in the Request message, change the Type field value in the fixe
d header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY, and forward the Reply mess
age back toward the CCNinfo user to terminate the Request (see <xref target="sec
.terminate" />).</t>
<t>If a router cannot continue the Request, the router <bcp14>MUST</bcp1 4> put an appropriate ReturnCode in the Request message, change the Type field v alue in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY, and forwar d the Reply message back toward the CCNinfo user to terminate the Request (see < xref target="sec.terminate" format="default"/>).</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section title="Forwarding CCNinfo Reply"> <section numbered="true" toc="default">
<name>Forwarding CCNinfo Reply</name>
<t>When a router receives a CCNinfo Reply whose Request ID and Node Ident <t>When a router receives a CCNinfo Reply whose Request ID and Node Iden
ifier match those in the PIT entry, sent from a valid adjacent neighbor router, tifier values match those in the PIT entry, which is sent from a valid adjacent
it forwards the CCNinfo Reply back toward the CCNinfo user. If the router does n neighbor router, it forwards the CCNinfo Reply back toward the CCNinfo user. If
ot receive the corresponding Reply within the [CCNinfo Reply Timeout] period, th the router does not receive the corresponding Reply within the [CCNinfo Reply Ti
en it removes the corresponding PIT entry and terminates the trace.</t> meout] period, then it removes the corresponding PIT entry and terminates the tr
ace.</t>
<t>The Flags field in the Request block TLV is used to indicate whether t <t>The Flags field in the Request block TLV is used to indicate whether
he router keeps the PIT entry during the CCNinfo Reply Timeout even after one or the router keeps the PIT entry during the CCNinfo Reply Timeout even after one o
more corresponding Reply messages are forwarded. When the CCNinfo user does not r more corresponding Reply messages are forwarded. When the CCNinfo user does no
set the F flag (i.e., "0"), the intermediate routers immediately remove the PIT t set the F flag (i.e., "0"), the intermediate routers immediately remove the PI
entry whenever they forward the corresponding Reply message. When the CCNinfo u T entry whenever they forward the corresponding Reply message. When the CCNinfo
ser sets the F flag (i.e., "1"), which means the CCNinfo user chooses the "full 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" />), the interme discovery request" (see <xref target="sec.forward.full-request" format="default
diate routers keep the PIT entry within the [CCNinfo Reply Timeout] period. Afte "/>), the intermediate routers keep the PIT entry within the [CCNinfo Reply Time
r this timeout, the PIT entry is removed.</t> out] period. After this timeout, the PIT entry is removed.</t>
<t>CCNinfo Replies <bcp14>MUST NOT</bcp14> be cached in routers upon the
<t>CCNinfo Replies MUST NOT be cached in routers upon the transmission of transmission of Reply messages.</t>
Reply messages.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section title="PIT Entry Management for Multipath Support"> <section numbered="true" toc="default">
<t>Within a network with multipath condition, there is a case (<xref targ <name>PIT Entry Management for Multipath Support</name>
et="fig:multi-replies" />) wherein a single CCNinfo Request is split into multip <t>Within a network with a multipath condition, there is a case (<xref t
le Requests (e.g., at Router A), which are injected into a single router (Router arget="fig_multi-replies" format="default"/>) wherein a single CCNinfo Request i
D). In this case, multiple Replies with the same Request ID and Node Identifier s split into multiple Requests (e.g., at Router A), which are injected into a si
including different Report blocks are received by the router (Router D).</t> ngle router (Router D). In this case, multiple Replies with the same Request ID
and Node Identifier values, including different Report blocks, are received by t
he router (Router D).</t>
<figure anchor="fig:multi-replies" title=""> <figure anchor="fig_multi-replies">
<artwork align="center"> <name>An Example of Multipath Network Topology</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+--------+ +--------+
| Router | | Router |
| B | | B |
+--------+ +--------+
/ \ / \
/ \ / \
+--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router | | Router | ... |Publisher| | CCNinfo|----| Router | | Router | ... |Publisher|
| user | | A | | D | | | | user | | A | | D | | |
+--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +---------+
\ / \ /
\ / \ /
+--------+ +--------+
| Router | | Router |
| C | | C |
+--------+ +--------+
</artwork> ]]></artwork>
</figure> </figure>
<t>To recognize different CCNinfo Reply messages, the routers <bcp14>MUS
<t>To recognize different CCNinfo Reply messages, the routers MUST distin T</bcp14> distinguish the PIT entries by the Request ID and exploiting path labe
guish the PIT entries by the Request ID and exploiting path labels, which could ls, which could be a hash value of the concatenation information of the cumulate
be a hash value of the concatenation information of the cumulate Node Identifier node identifiers in the hop-by-hop header and the specified content name. For e
s in the hop-by-hop header and the specified content name. For example, when Rou xample, when Router D in <xref target="fig_multi-replies" format="default"/> rec
ter D in <xref target="fig:multi-replies" /> receives a CCNinfo Request from Rou eives a CCNinfo Request from Router B, its PIT includes the Request ID and value
ter B, its PIT includes the Request ID and value such as H((Router_A|Router_B)|c such as H((Router_A|Router_B)|content_name), where "H" indicates some hash func
ontent_name), where "H" indicates some hash function and "|" indicates concatena tion and "|" indicates concatenation. When Router D receives a CCNinfo Request f
tion. When Router D receives a CCNinfo Request from Router C, its PIT includes t rom Router C, its PIT includes the same Request ID and value of H((Router_A|Rout
he same Request ID and value of H((Router_A|Router_C)|content_name). Two differe er_C)|content_name). Two different Replies are later received on Router D, and e
nt Replies are later received on Router D and each Reply is appropriately forwar ach Reply is appropriately forwarded to Router B and Router C, respectively.
ded 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 eith er from Router B or Router C as Router A removes the corresponding PIT entry aft er it forwards the first Reply.</t> 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 eith er from Router B or Router C as Router A removes the corresponding PIT entry aft er it forwards the first Reply.</t>
<t>To avoid routing loops, when a router seeks the cumulate node identif
<t>To avoid routing loops, when a router seeks the cumulate Node Identifi iers of the Report blocks in the hop-by-hop header, it <bcp14>MUST</bcp14> exami
ers of the Report blocks in the hop-by-hop header, it MUST examine whether its o ne whether its own node identifier is not previously inserted. If a router detec
wn Node Identifier is not previously inserted. If a router detects its own Node ts its own node identifier in the hop-by-hop header, the router inserts its Repo
Identifier in the hop-by-hop header, the router inserts its Report block and ter rt block and terminates the Request as will be described in <xref target="sec.te
minates the Request as will be described in <xref target="sec.terminate.fatal" / rminate.fatal" format="default"/>.</t>
>.</t>
<!-- <t>CCNinfo Requests SHOULD NOT result in PIT aggregation in routers du
ring the Request message transmission.</t> XXX No more needed because of unique
PIT entry given by hash value. -->
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.terminate" title="CCNinfo Termination"> <section anchor="sec.terminate" numbered="true" toc="default">
<name>CCNinfo Termination</name>
<t>When performing a hop-by-hop trace, it is necessary to determine when t o stop the trace. There are several cases when an intermediate router might retu rn a Reply before a Request reaches the caching router or the FHR.</t> <t>When performing a hop-by-hop trace, it is necessary to determine when t o stop the trace. There are several cases when an intermediate router might retu rn a Reply before a Request reaches the caching router or the FHR.</t>
<section numbered="true" toc="default">
<section title="Arriving at First-hop Router"> <name>Arriving at First-Hop Router</name>
<t>A CCNinfo Request can be determined to have arrived at the FHR. To ens <t>A CCNinfo Request can be determined to have arrived at the FHR. To en
ure that a router recognizes that it is the FHR for the specified content, it ne sure that a router recognizes that it is the FHR for the specified content, it n
eds to have a FIB entry (or attach) to the corresponding publisher or the conten eeds to have a FIB entry (or to attach) to the corresponding publisher or the co
t.</t> ntent.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Arriving at Router Having Cache"> <name>Arriving at Router Having Cache</name>
<t>A CCNinfo Request can be determined to have arrived at the router havi <t>A CCNinfo Request can be determined to have arrived at the router hav
ng the specified content cache within the specified HopLimit.</t> ing the specified content cache within the specified HopLimit.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Arriving at Last Router</name>
<section title="Arriving at Last Router"> <t>A CCNinfo Request can be determined to have arrived at the last route
<t>A CCNinfo Request can be determined to have arrived at the last router r of the specified HopLimit. If the last router does not have the corresponding
of the specified HopLimit. If the last router does not have the corresponding c cache, it <bcp14>MUST</bcp14> insert its Report block and send the Reply message
ache, it MUST insert its Report block and send the Reply message with NO_INFO re with a NO_INFO return code without appending any Reply block or sub-block TLVs.
turn code without appending any Reply (sub-)block TLVs.</t> </t>
</section> </section>
<section anchor="sec.terminate.invalid" numbered="true" toc="default">
<section anchor="sec.terminate.invalid" title="Invalid Request"> <name>Invalid Request</name>
<t>If the router does not validate the Request or the Reply even it is re <t>If the router does not validate the Request or the Reply even it is r
quired, the router MUST note a ReturnCode of INVALID_REQUEST in the fixed header equired, the router <bcp14>MUST</bcp14> note a ReturnCode of INVALID_REQUEST in
of the message, insert its Report block, and forward the message as the Reply b the fixed header of the message, insert its Report block, and forward the messag
ack to the CCNinfo user. The router MAY, however, randomly ignore the received i e as the Reply back to the CCNinfo user. The router <bcp14>MAY</bcp14>, however,
nvalid messages. (See <xref target="sec.rate_limit.request" />.)</t> randomly ignore the received invalid messages. (See <xref target="sec.rate_limi
t.request" format="default"/>.)</t>
</section> </section>
<section anchor="sec.terminate.no_route" numbered="true" toc="default">
<section anchor="sec.terminate.no_route" title="No Route"> <name>No Route</name>
<t>If the router cannot determine the routing paths or neighbor routers f <t>If the router cannot determine the routing paths or neighbor routers
or the specified name prefix within the specified HopLimit, for the specified name prefix within the specified HopLimit,
it MUST note a ReturnCode of NO_ROUTE in the fixed header of the message, it <bcp14>MUST</bcp14> note a ReturnCode of NO_ROUTE in the fixed header
insert its Report block, and forward the message as the Reply back to the CCNin of the message, insert its Report block, and forward the message as the Reply ba
fo user.</t> ck to the CCNinfo user.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="No Information"> <name>No Information</name>
<t>If the router does not have any information about the specified name p <t>If the router does not have any information about the specified name
refix within the specified HopLimit, prefix within the specified HopLimit,
it MUST note a ReturnCode of NO_INFO in the fixed header of the message, it <bcp14>MUST</bcp14> note a ReturnCode of NO_INFO in the fixed header o
insert its Report block, and forward the message as the Reply back to the CCNinf f the message, insert its Report block, and forward the message as the Reply bac
o user.</t> k to the CCNinfo user.</t>
</section> </section>
<section anchor="sec.terminate.no_space" numbered="true" toc="default">
<section anchor="sec.terminate.no_space" title="No Space"> <name>No Space</name>
<t>If appending the Report block or the Reply (sub-)block would make the <t>If appending the Report block, the Reply block, or Reply sub-block wo
hop-by-hop header longer than 247 bytes or the Request packet longer than the MT uld make the hop-by-hop header longer than 247 bytes or the Request packet longe
U of the Incoming face, r than the MTU of the Incoming face, the router <bcp14>MUST</bcp14> note a Retur
<!-- or longer than 1280 bytes (in the case of IPv6 as the payload <xref targe nCode of NO_SPACE in the fixed header of the message and forward the message as
t="refs.IPv6"/>),--> the Reply back to the CCNinfo user.</t>
the router MUST 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>
<section anchor="sec.terminate.fatal" numbered="true" toc="default">
<section anchor="sec.terminate.fatal" title="Fatal Error"> <name>Fatal Error</name>
<t>If a CCNinfo Request has encountered a fatal error, <t>If a CCNinfo Request has encountered a fatal error,
the router MUST note a ReturnCode of FATAL_ERROR in the fixed header of t the router <bcp14>MUST</bcp14> note a ReturnCode of FATAL_ERROR in the fi
he message and forward the message as the Reply back to the CCNinfo user. This m xed header of the message and forward the message as the Reply back to the CCNin
ay happen, for example, when the router detects some routing loop in the Request fo user. This may happen, for example, when the router detects some routing loop
blocks (see <xref target="sec.intro" />). The fatal error can be encoded with a in the Request blocks (see <xref target="sec.intro" format="default"/>). The fa
nother error: if a router detects routing loop but cannot insert its Report bloc tal error can be encoded with another error: if a router detects routing loop bu
k, it MUST note NO_SPACE and FATAL_ERROR ReturnCodes (i.e., %x85) in the fixed h t cannot insert its Report block, it <bcp14>MUST</bcp14> note NO_SPACE and FATAL
eader and forward the message back to the CCNinfo user.</t> _ERROR ReturnCodes (i.e., 0x85) in the fixed header and forward the message back
to the CCNinfo user.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="CCNinfo Reply Timeout"> <name>CCNinfo Reply Timeout</name>
<t>If a router receives the Request or Reply message that expires its own <t>If a router receives the Request or Reply message that expires its ow
[CCNinfo Reply Timeout] value (<xref target="sec.timer"/>), the router will sil n [CCNinfo Reply Timeout] value (<xref target="sec.timer" format="default"/>), t
ently discard the Request or Reply message.</t> he router will silently discard the Request or Reply message.</t>
</section> </section>
<section anchor="sec.nonsupport" numbered="true" toc="default">
<section anchor="sec.nonsupport" title="Non-Supported Node"> <name>Non-Supported Node</name>
<t>Cases will arise in which a router or a FHR along the path does not su <t>Cases will arise in which a router or a FHR along the path does not s
pport CCNinfo. In such cases, a CCNinfo user and routers that forward the CCNinf upport CCNinfo. In such cases, a CCNinfo user and routers that forward the CCNin
o Request will time out the CCNinfo request.</t> fo Request will time out the CCNinfo request.</t>
<!--a downstream router that supports ccninfo will reply to the ccninfo user wit
h a message indicating that the upstream router does not support ccninfo. XXXX h
ow to detect non-supported router???-->
</section> </section>
<section anchor="sec.admin_prohibit" numbered="true" toc="default">
<section anchor="sec.admin_prohibit" title="Administratively Prohibited"> <name>Administratively Prohibited</name>
<t>If CCNinfo is administratively prohibited, the router rejects the Requ <t>If CCNinfo is administratively prohibited, the router rejects the Req
est message and MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB. uest message and <bcp14>MUST</bcp14> send the CCNinfo Reply with the ReturnCode
The router MAY, however, randomly ignore the Request messages to be rejected (s of ADMIN_PROHIB. The router <bcp14>MAY</bcp14>, however, randomly ignore the Req
ee <xref target="sec.rate_limit.request" />).</t> uest messages to be rejected (see <xref target="sec.rate_limit.request" format="
default"/>).</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.config" title="Configurations"> <section anchor="sec.config" numbered="true" toc="default">
<name>Configurations</name>
<section anchor="sec.timer" title="CCNinfo Reply Timeout"> <section anchor="sec.timer" numbered="true" toc="default">
<t>The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply. <name>CCNinfo Reply Timeout</name>
The value for a router can be statically configured by the router's administrat <t>The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply
ors/operators. The default value is 3 (seconds). The [CCNinfo Reply Timeout] val . The value for a router can be statically configured by the router's administra
ue SHOULD NOT be larger than 4 (seconds) and SHOULD NOT be lower than 2 (seconds tors and/or operators. The default value is 3 (seconds). The [CCNinfo Reply Time
).</t> out] value <bcp14>SHOULD NOT</bcp14> be larger than 4 (seconds) and <bcp14>SHOUL
D NOT</bcp14> be lower than 2 (seconds).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="HopLimit in Fixed Header"> <name>HopLimit in Fixed Header</name>
<t>If a CCNinfo user does not specify the HopLimit value in the fixed hea <t>If a CCNinfo user does not specify the HopLimit value in the fixed he
der for a Request message as the HopLimit, the HopLimit is set to 32. Note that ader 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 0 HopLimit is an invalid Request; hence, the router in this case follows the wa
defined in <xref target="sec.terminate.invalid" />.</t> y defined in <xref target="sec.terminate.invalid" format="default"/>.</t>
</section> </section>
<section anchor="sec.acl.config" numbered="true" toc="default">
<section anchor="sec.acl.config" title="Access Control"> <name>Access Control</name>
<t>A router MAY configure the valid or invalid networks to enable an acce <t>A router <bcp14>MAY</bcp14> configure the valid or invalid networks t
ss control. The access control MAY be defined per name prefix, such as "who can o enable an access control. The access control <bcp14>MAY</bcp14> be defined per
retrieve which name prefix" (see <xref target="sec.acl" />).</t> name prefix, such as "who can retrieve which name prefix" (see <xref target="se
c.acl" format="default"/>).</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.diag" title="Diagnosis and Analysis"> <section anchor="sec.diag" numbered="true" toc="default">
<name>Diagnosis and Analysis</name>
<section title="Number of Hops and RTT"> <section numbered="true" toc="default">
<t>A CCNinfo Request message is forwarded in a hop-by-hop manner and each <name>Number of Hops and RTT</name>
forwarding router appends its own Report block. We can then verify the number o <t>A CCNinfo Request message is forwarded in a hop-by-hop manner and eac
f hops to reach the content forwarder or publisher and the RTT between the conte h forwarding router appends its own Report block. We can then verify the number
nt forwarder or publisher.</t> of hops to reach the content forwarder or publisher and the RTT between the cont
ent forwarder or publisher.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Caching Router Identification"> <name>Caching Router Identification</name>
<t>While some routers may hide their node identifiers with all-zeros in t <t>While some routers may hide their node identifiers with all-zeros in
he Report blocks (as seen in <xref target="sec.policy" />), the routers in the p the Report blocks (as seen in <xref target="sec.policy" format="default"/>), the
ath from the CCNinfo user to the content forwarder can be identified.</t> routers in the path from the CCNinfo user to the content forwarder can be ident
ified.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="TTL or Hop Limit"> <name>TTL or Hop Limit</name>
<t>By taking the HopLimit from the content forwarder and <t>By taking the HopLimit from the content forwarder and
forwarding the TTL threshold over all hops, it is possible to 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> discover the TTL or hop limit required for the content forwarder to reach the CCNinfo user.</t>
</section> </section>
<section anchor="sec.delay" numbered="true" toc="default">
<section anchor="sec.delay" title="Time Delay"> <name>Time Delay</name>
<t>If the routers have synchronized clocks, it is possible to estimate th <t>If the routers have synchronized clocks, it is possible to estimate t
e propagation and queuing delays from the differences between the timestamps at he propagation and queuing delays from the differences between the timestamps at
the successive hops. However, this delay includes the control processing overhea the successive hops. However, this delay includes the control processing overhe
d; therefore, it is not necessarily indicative of the delay that would be experi ad; therefore, it is not necessarily indicative of the delay that would be exper
enced by the data traffic.</t> ienced by the data traffic.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Path Stretch"> <name>Path Stretch</name>
<t>By obtaining the path stretch "d / P", where "d" is the hop count of t <t>By obtaining the path stretch "d / P", where "d" is the hop count of
he data and "P" is the hop count from the consumer to the publisher, we can meas the data and "P" is the hop count from the consumer to the publisher, we can mea
ure the improvements in path stretch in various cases, such as in different cach sure the improvements in path stretch in various cases, such as in different cac
ing and routing algorithms. We can then facilitate the investigation of the perf hing and routing algorithms. We can then facilitate the investigation of the per
ormance of the protocol.</t> formance of the protocol.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Cache Hit Probability"> <name>Cache Hit Probability</name>
<t>CCNinfo can show the number of received interests per cache or chunk o <t>CCNinfo can show the number of received Interests per cache or chunk
n a router. Accordingly, CCNinfo measures the content popularity (i.e., the numb on a router. Accordingly, CCNinfo measures the content popularity (i.e., the num
er of accesses for each content/cache), thereby enabling the investigation of th ber of accesses for each content and/or cache), thereby enabling the investigati
e routing/caching strategy in networks.</t> on of the routing/caching strategy in networks.</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.iana" title="IANA Considerations"> <section anchor="sec.iana" numbered="true" toc="default">
<!-- <t>New assignments can only be made via a Standards Action as specifie <name>IANA Considerations</name>
d in <xref target="refs.IANA" />. This document does not intend to be the standa <t>This section details each kind of CCNx protocol value that has been reg
rd document. However, the new assignments such as the ReturnCode and various typ istered. As per <xref target="RFC8126" format="default"/>, four assignments have
e values will be considered when this specification becomes the RFC.</t>--> been made in existing registries, and a new Reply Type registry has been create
<t>This section details each kind of CCNx protocol value that can be regis d in the "Content-Centric Networking (CCNx)" registry group.</t>
tered. As per <xref target="refs.IANA" />, this section makes assignments in fou <section anchor="sec.iana.pt" numbered="true" toc="default">
r existing registries and creates a new Reply Type registry in the "Content-Cent <name>Packet Type Registry</name>
ric Networking (CCNx)" registry group. The registration procedure is "RFC Requir <t>As shown in <xref target="Type_val" format="default"/>, CCNinfo defin
ed", which requires only that this document be published as an RFC.</t> es two packet types, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose values are 0
x03 and 0x04, respectively.</t>
<section anchor="sec.iana.pt" title="Packet Type Registry">
<t>As shown in <xref target='Type_val' />, CCNinfo defines two packet typ
es, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose suggested values are %x03 and
%x04, respectively.</t>
</section> </section>
<section anchor="sec.iana.tlt" numbered="true" toc="default">
<section anchor="sec.iana.tlt" title="Top-Level Type Registry"> <name>Top-Level Type Registry</name>
<t>As shown in <xref target='Top-level_Type' />, CCNinfo defines one top- <t>As shown in <xref target="Top-level_Type" format="default"/>, CCNinfo
level type, T_DISCOVERY, whose suggested value is %x0005.</t> defines one top-level type, T_DISCOVERY, whose value is 0x0005.</t>
</section> </section>
<section anchor="sec.iana.hbh" numbered="true" toc="default">
<section anchor="sec.iana.hbh" title="Hop-by-Hop Type Registry"> <name>Hop-by-Hop Type Registry</name>
<t>As shown in <xref target='Hop-by-hop_Type' />, CCNinfo defines two hop <t>As shown in <xref target="Hop-by-hop_Type" format="default"/>, CCNinf
-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose suggested values are %x000 o defines two hop-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose values ar
8 and %x0009, respectively.</t> e 0x0008 and 0x0009, respectively.</t>
</section> </section>
<section anchor="sec.iana.msg" numbered="true" toc="default">
<section anchor="sec.iana.msg" title="Message Type Registry"> <name>Message Type Registry</name>
<t>As shown in <xref target='CCNx_Type' />, CCNinfo defines two message t <t>As shown in <xref target="CCNx_Type" format="default"/>, CCNinfo defi
ypes, T_DISC_REQ and T_DISC_REPLY, whose suggested values are %x0007 and %x0008, nes two message types, T_DISC_REQ and T_DISC_REPLY, whose values are 0x000D and
respectively.</t> 0x000E, respectively.</t>
</section> </section>
<section anchor="sec.iana.reply" title="Reply Type Registry"> <section anchor="sec.iana.reply" numbered="true" toc="default">
<t>IANA has created the "CCNx Reply Types" registry and allocated the rep <name>Reply Type Registry</name>
ly types. The Type value is 2 octets. The range is %x0000-%xFFFF. As shown in <x <t>IANA has created the "CCNx Reply Types" registry and allocated the re
ref target='Sub_Type' />, CCNinfo defines three reply types, T_DISC_CONTENT, T_D ply types. The registration procedure is "RFC Required" <xref target="RFC8126"/>
ISC_CONTENT_PUBLISHER, and T_ORG, whose suggested values are %x0000, %x0001, and . The Type value is 2 octets. The range is 0x0000-0xFFFF. As shown in <xref tar
%x0FFF, respectively.</t> get="Sub_Type" format="default"/>, CCNinfo defines three reply types, T_DISC_CON
TENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose values are 0x0000, 0x0001, and
0x0FFF, respectively.</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.sec" title="Security Considerations"> <section anchor="sec.sec" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This section addresses some of the security considerations.</t> <t>This section addresses some of the security considerations.</t>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.policy" title="Policy-Based Information Provisioning <section anchor="sec.policy" numbered="true" toc="default">
for Request"> <name>Policy-Based Information Provisioning for Request</name>
<t>Although CCNinfo gives excellent troubleshooting cues, some network a
<t>Although CCNinfo gives excellent troubleshooting cues, some network ad dministrators or operators may not want to disclose everything about their netwo
ministrators or operators may not want to disclose everything about their networ rk to the public or may wish to securely transmit private information to specifi
k to the public or may wish to securely transmit private information to specific c members of their networks. CCNinfo provides policy-based information provision
members of their networks. CCNinfo provides policy-based information provisioni ing, thereby allowing network administrators to specify their response policy fo
ng, thereby allowing network administrators to specify their response policy for r each router.</t>
each router.</t> <t>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
<t>The access policy regarding "who is allowed to retrieve" and/or "what of access policy, routers with the specified content <bcp14>MAY</bcp14> examine
kind of cache information" can be defined for each router. For the former type o the signature enclosed in the Request message and decide whether they should not
f access policy, routers with the specified content MAY examine the signature en ify the content information in the Reply. If the routers decide to not notify th
closed in the Request message and decide whether they should notify the content e content information, they <bcp14>MUST</bcp14> send the CCNinfo Reply with the
information in the Reply. If the routers decide to not notify the content inform ReturnCode of ADMIN_PROHIB without appending any Reply block or sub-block TLVs.
ation, they MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB with
out appending any Reply (sub-)block TLVs.
For the latter type of policy, the permission, whether (1) All (all cache inform ation is disclosed), (2) Partial (cache information with a particular name prefi x can (or cannot) be disclosed), or (3) Deny (no cache information is disclosed) , is defined at the routers.</t> For the latter type of policy, the permission, whether (1) All (all cache inform ation is disclosed), (2) Partial (cache information with a particular name prefi x can (or cannot) be disclosed), or (3) Deny (no cache information is disclosed) , is defined at the routers.</t>
<t>In contrast, we entail that each router does not disrupt the forwardi
<t>In contrast, we entail that each router does not disrupt the forwardin ng of CCNinfo Request and Reply messages. When a Request message is received, th
g of CCNinfo Request and Reply messages. When a Request message is received, the e router <bcp14>SHOULD</bcp14> insert the Report block if the ReturnCode is NO_E
router SHOULD insert the Report block if the ReturnCode is NO_ERROR. Here, acco RROR. Here, according to the policy configuration, the Node Identifier field in
rding to the policy configuration, the Node Identifier field in the Report block the Report block <bcp14>MAY</bcp14> be null (i.e., all-zeros), but the Request A
MAY be null (i.e., all-zeros), but the Request Arrival Time field SHOULD NOT be rrival Time field <bcp14>SHOULD NOT</bcp14> be null. Finally, the router <bcp14>
null. Finally, the router SHOULD forward the Request message to the upstream ro SHOULD</bcp14> forward the Request message to the upstream router toward the con
uter toward the content forwarder if the ReturnCode is kept with NO_ERROR.</t> tent forwarder if the ReturnCode is kept with NO_ERROR.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.acl" title="Filtering CCNinfo Users Located in Invali <section anchor="sec.acl" numbered="true" toc="default">
d Networks"> <name>Filtering CCNinfo Users Located in Invalid Networks</name>
<t>A router MAY support an access control mechanism to filter out Request <t>A router <bcp14>MAY</bcp14> support an access control mechanism to fi
s from invalid CCNinfo users. To accomplish this, invalid networks (or domains) lter out Requests from invalid CCNinfo users. To accomplish this, invalid networ
could, for example, be configured via a list of allowed/disallowed networks (as ks (or domains) could, for example, be configured via a list of allowed or disal
observed in <xref target="sec.acl.config" />). If a Request is received from a d lowed networks (as observed in <xref target="sec.acl.config" format="default"/>)
isallowed network (according to the Node Identifier in the Request block), the R . If a Request is received from a disallowed network (according to the node iden
equest MUST NOT be processed and the Reply with the ReturnCode of INFO_HIDDEN SH tifier in the Request block), the Request <bcp14>MUST NOT</bcp14> be processed a
OULD be used to note that. The router MAY, however, perform rate limited logging nd the Reply with the ReturnCode of INFO_HIDDEN <bcp14>SHOULD</bcp14> be used to
of such events.</t> note that. The router <bcp14>MAY</bcp14>, however, perform rate-limited logging
of such events.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section title="Topology Discovery"> <section numbered="true" toc="default">
<t>CCNinfo can be used to discover actively used topologies. If a network <name>Topology Discovery</name>
topology is not disclosed, CCNinfo Requests SHOULD be restricted at the border <t>CCNinfo can be used to discover actively used topologies. If a networ
of the domain using the ADMIN_PROHIB return code.</t> k topology is not disclosed, CCNinfo Requests <bcp14>SHOULD</bcp14> be restricte
d at the border of the domain using the ADMIN_PROHIB return code.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section title="Characteristics of Content"> <section numbered="true" toc="default">
<t>CCNinfo can be used to discover the type of content being sent by publ <name>Characteristics of Content</name>
ishers. If this information is a secret, CCNinfo Requests SHOULD be restricted a <t>CCNinfo can be used to discover the type of content being sent by pub
t the border of the domain, using the ADMIN_PROHIB return code.</t> lishers. 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>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.compute" title="Computational Attacks"> <section anchor="sec.compute" numbered="true" toc="default">
<t>CCNinfo may impose heavy tasks at content forwarders because it makes <name>Computational Attacks</name>
content forwarders seek their internal cache states reported in the Reply messag <t>CCNinfo may impose heavy tasks at content forwarders because it makes
es whenever they form the Reply messages. The current CCNinfo specification allo content forwarders seek their internal cache states reported in the Reply messa
ws to return null values for several fields, such as First/Last Seqnum or Elapse ges whenever they form the Reply messages. The current CCNinfo specification all
d Cache Time fields in the Reply sub-block. As mentioned in <xref target="sec.re ows to return null values for several fields, such as First/Last Seqnum or Elaps
ply_subblk" />, these values MAY be null. This means that the content forwarder ed Cache Time fields in the Reply sub-block. As mentioned in <xref target="sec.r
can not only hide these values owing to privacy/security policies, but also skip eply_subblk" format="default"/>, these values <bcp14>MAY</bcp14> be null. This m
the implementations of the complex functions to report these values.</t> eans that the content forwarder cannot only hide these values owing to privacy a
nd security policies but also skip the implementations of the complex functions
to report these values.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.timeout" title="Longer or Shorter CCNinfo Reply Timeo <section anchor="sec.timeout" numbered="true" toc="default">
ut"> <name>Longer or Shorter CCNinfo Reply Timeout</name>
<t>Routers can configure CCNinfo Reply Timeout (<xref target="sec.timer" <t>Routers can configure CCNinfo Reply Timeout (<xref target="sec.timer"
/>), which is the allowable timeout value to keep the PIT entry. If routers conf format="default"/>), which is the allowable timeout value to keep the PIT entry
igure a longer timeout value, there may be an attractive attack vector against t . If routers configure a longer timeout value, there may be an attractive attack
he PIT memory. Moreover, especially when the full discovery request option (<xre vector against the PIT memory. Moreover, especially when the full discovery req
f target="sec.forward.request" />) is specified for the CCNinfo Request, several uest option (<xref target="sec.forward.request" format="default"/>) is specified
Reply messages may be returned and cause a response storm. (See <xref target="s for the CCNinfo Request, several Reply messages may be returned and cause a res
ec.rate_limit.reply" /> for rate-limiting to avoid the storm). ponse storm. (See <xref target="sec.rate_limit.reply" format="default"/> for rat
To avoid DoS attacks, routers MAY configure the timeout value, which is s e-limiting to avoid the storm).
horter than the user-configured CCNinfo timeout value. However, if it is too sho To avoid DoS attacks, routers <bcp14>MAY</bcp14> configure the timeout va
rt, the Request may be timed out and the CCNinfo user does not receive all Repli lue, which is shorter than the user-configured CCNinfo timeout value. However, i
es; s/he only retrieves the partial path information (i.e., information about a f it is too short, the Request may be timed out and the CCNinfo user does not re
part of the tree).</t> ceive all Replies; they only retrieve the partial path information (i.e., inform
ation about a part of the tree).</t>
<t>There may be a way to enable incremental exploration (i.e., to explore <t>There may be a way to enable incremental exploration (i.e., to explor
the part of the tree that was not explored by the previous operation); however, e 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> , discussing such mechanisms is out of scope of this document.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.rate_limit.request" title="Limiting Request Rates"> <section anchor="sec.rate_limit.request" numbered="true" toc="default">
<t>A router MAY rate-limit CCNinfo Requests by ignoring some of the conse <name>Limiting Request Rates</name>
cutive messages. The router MAY randomly ignore the received messages to minimiz <t>A router <bcp14>MAY</bcp14> rate-limit CCNinfo Requests by ignoring s
e the processing overhead, i.e., to keep fairness in processing requests, or pre ome of the consecutive messages. The router <bcp14>MAY</bcp14> randomly ignore t
vent traffic amplification. In such a case, no error message is returned. The ra he received messages to minimize the processing overhead, i.e., to keep fairness
te limit function is left to the router's implementation.</t> 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 imple
mentation.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.rate_limit.reply" title="Limiting Reply Rates"> <section anchor="sec.rate_limit.reply" numbered="true" toc="default">
<t>CCNinfo supporting multipath forwarding may result in one Request retu <name>Limiting Reply Rates</name>
rning multiple Reply messages. To prevent abuse, the routers in the traced path <t>CCNinfo supporting multipath forwarding may result in one Request ret
MAY need to rate-limit the Replies. In such a case, no error message is returned urning multiple Reply messages. To prevent abuse, the routers in the traced path
. The rate limit function is left to the router's implementation.</t> <bcp14>MAY</bcp14> need to rate-limit the Replies. In such a case, no error mes
sage is returned. The rate limit function is left to the router's implementation
.</t>
</section> </section>
<!-- ========================================================== --> <!-- ========================================================== -->
<section anchor="sec.adjacency" title="Adjacency Verification"> <section anchor="sec.adjacency" numbered="true" toc="default">
<t>It is assumed that the CCNinfo Request and Reply messages are forwarde <name>Adjacency Verification</name>
d by adjacent neighbor nodes or routers. The CCNx message format or semantics do <t>It is assumed that the CCNinfo Request and Reply messages are forward
not define a secure way to verify the node/router adjacency, while HopAuth <xre ed by adjacent neighbor nodes or routers. The CCNx message format or semantics d
f target="refs.hopauth" /> provides a possible method for an adjacency verificat o not define a secure way to verify the node and/or router adjacency, while a ho
ion and defines the corresponding message format for adjacency verification as w p-by-hop authentication such as <xref target="DCAuth" format="default"/> provide
ell as the router behaviors. CCNinfo MAY use a similar method for node adjacency s a possible method for an adjacency verification and defines the corresponding
verification. message format for adjacency verification as well as the router behaviors. CCNin
</t> fo <bcp14>MAY</bcp14> use a similar method for node adjacency verification.
</t>
</section> </section>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Acknowledgements">
<t>The authors would like to thank Jerome Francois, Erik Kline, Spyridon M
astorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry Turletti for th
eir valuable comments and suggestions on this document.</t>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
</middle> </middle>
<!-- *****BACK MATTER ***** --> <!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <displayreference target="I-D.irtf-icnrg-icnping" to="ICN-PING" />
<reference anchor="refs.ccnx"> <displayreference target="I-D.irtf-icnrg-icntraceroute" to="ICN-TRACEROUTE" />
<front>
<title>CCNx Messages in TLV Format</title>
<author initials="M" surname="Mosko"/>
<author initials="I" surname="Solis"/>
<author initials="C" surname="Wood"/>
<date month="July" year="2019"/>
</front>
<seriesInfo name="RFC" value="8609"/>
</reference>
<reference anchor="refs.semantics">
<front>
<title>CCNx Semantics</title>
<author initials="M" surname="Mosko"/>
<author initials="I" surname="Solis"/>
<author initials="C" surname="Wood"/>
<date month="July" year="2019"/>
</front>
<seriesInfo name="RFC" value="8569"/>
</reference>
<reference anchor="refs.RFC2119" target='https://www.rfc-editor.org/info/r
fc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organiza
tion /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used t
o signify the requirements in the specification. These words are often capitali
zed. This document defines these words as they should be interpreted in IETF doc
uments. This document specifies an Internet Best Current Practices for the Inte
rnet Community, and requests discussion and suggestions for improvements.</t></a
bstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="refs.RFC8174" target='https://www.rfc-editor.org/info/r
fc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title
>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization
/></author>
<date year='2017' month='May' />
</front>
</reference>
<reference anchor='refs.IANA' target='https://www.rfc-editor.org/info/rfc <references>
8126'> <name>References</name>
<front> <references>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</t <name>Normative References</name>
itle>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organizati
on /></author>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization
/></author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organizati
on /></author>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that us
e constants to identify various protocol parameters. To ensure that the values
in these fields do not have conflicting uses and to promote interoperability, th
eir allocations are often coordinated by a central record keeper. For IETF prot
ocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t
><t>To make assignments in a given registry prudently, guidance describing the c
onditions under which new values should be assigned, as well as when and how mod
ifications to existing values can be made, is needed. This document defines a f
ramework 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>This is the third edition of this document; it obsoletes RFC 5226.</t></a
bstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.86
09.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.85
69.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"/>
<references title="Informative References"> </references>
<references>
<name>Informative References</name>
<reference anchor="refs.term"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.87
<front> 93.xml"/>
<title>Information-Centric Networking (ICN): Content-Centric Networking
(CCNx) and Named Data Networking (NDN) Terminology</title>
<author initials="C" surname="Wood"/>
<author initials="A" surname="Afanasyev"/>
<author initials="L" surname="Zhang"/>
<author initials="D" surname="Oran"/>
<author initials="C" surname="Tschudin"/>
<date month="June" year="2020"/>
</front>
<seriesInfo name="RFC" value="8793"/>
</reference>
<reference anchor="refs.commag"> <reference anchor="Contrace">
<front> <front>
<title>Contrace: A Tool for Measuring and Tracing Content-Centric Netwo <title>Contrace: A tool for measuring and tracing content-centric ne
rks</title> tworks</title>
<author initials="H" surname="Asaeda"/> <author initials="H" surname="Asaeda"/>
<author initials="K" surname="Matsuzono"/> <author initials="K" surname="Matsuzono"/>
<author initials="T" surname="Turletti"/> <author initials="T" surname="Turletti"/>
<date month="March" year="2015"/> <date month="March" year="2015"/>
</front> </front>
<seriesInfo name="IEEE Communications Magazine," value="Vol.53, No.3, pp. <seriesInfo name="DOI" value="10.1109/MCOM.2015.7060502"/>
182-188"/> <refcontent>IEEE Communications Magazine, Vol. 53, No. 3, pp. 182-188<
</reference> /refcontent>
</reference>
<reference anchor="refs.icnping"> <!-- [I-D.irtf-icnrg-icnping] IESG state I-D Exists as of 1/31/23-->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-ic
<title>ICN Ping Protocol Specification</title> nrg-icnping.xml"/>
<author initials="S" surname="Mastorakis"/>
<author initials="J" surname="Gibson"/>
<author initials="I" surname="Moiseenko"/>
<author initials="R" surname="Droms"/>
<author initials="D" surname="Oran"/>
<date month="May" year="2022"/>
</front>
<seriesInfo name="draft-irtf-icnrg-icnping-06" value="(work in progress)"
/>
</reference>
<reference anchor="refs.icntrace"> <!-- [I-D.irtf-icnrg-icntraceroute] IESG state I-D Exists as of 1/31/23-->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-ic
<title>ICN Traceroute Protocol Specification</title> nrg-icntraceroute.xml"/>
<author initials="S" surname="Mastorakis"/>
<author initials="J" surname="Gibson"/>
<author initials="I" surname="Moiseenko"/>
<author initials="R" surname="Droms"/>
<author initials="D" surname="Oran"/>
<date month="May" year="2022"/>
</front>
<seriesInfo name="draft-irtf-icnrg-icntraceroute-06" value="(work in prog
ress)"/>
</reference>
<reference anchor="refs.mtrace2"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8487.
<front> xml"/>
<title>Mtrace Version 2: Traceroute Facility for IP Multicast</title>
<author initials="H" surname="Asaeda"/>
<author initials="K" surname="Mayer"/>
<author initials="W" surname="Lee"/>
<date month="October" year="2018"/>
</front>
<seriesInfo name="RFC" value="8487"/>
</reference>
<!-- <reference anchor="refs.dcauth"> <reference anchor="DCAuth">
<front> <front>
<title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Da ta Retrieval</title> <title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Da ta Retrieval</title>
<author initials="R" surname="Li"/> <author initials="R" surname="Li"/>
<author initials="H" surname="Asaeda"/> <author initials="H" surname="Asaeda"/>
<author initials="J" surname="Wu"/> <author initials="J" surname="Wu"/>
<date month="October" year="2018"/> <date month="October" year="2018"/>
</front> </front>
<seriesInfo name="IEEE Transactions on Network Science and Engineering (T <seriesInfo name="DOI" value="10.1109/TNSE.2018.2872049"/>
NSE)" value=""/> <refcontent>IEEE Transactions on Network Science and Engineering, Vol. 7
</reference>--> , No. 1, pp. 15-27</refcontent>
</reference>
<reference anchor="refs.hopauth">
<front>
<title>Hop-by-Hop Authentication in Content-Centric Networking/Named Da
ta Networking</title>
<author initials="R" surname="Li"/>
<author initials="H" surname="Asaeda"/>
<date month="February" year="2020"/>
</front>
<seriesInfo name="draft-li-icnrg-hopauth-02" value="(work in progress)"/>
</reference>
<reference anchor="refs.acur"> <!-- [I-D.li-icnrg-hopauth] IESG state Expired -->
<front>
<title>Consecutive Caching and Adaptive Retrieval for In-Network Big Da
ta 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="Proc. IEEE ICC," value="Kansas City, USA"/>
</reference>
<reference anchor="refs.ieice"> <!--<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.li-
<front> icnrg-hopauth.xml"/> [HA] replaced by above journal as hopauth is expired and no
<title>Cefore: Software Platform Enabling Content-Centric Networking an t maintained.-->
d 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="IEICE Transaction on Communications," value="Vol.E102-B
, No.9, pp.1792-1803"/>
</reference>
<reference anchor="refs.cefore" target="https://cefore.net/"> <reference anchor="CONSEC-CACHING">
<front> <front>
<title>Cefore Home Page</title> <title>Consecutive Caching and Adaptive Retrieval for In-Network Big
<author /> Data Sharing</title>
<date /> <author initials="R" surname="Li"/>
</front> <author initials="K" surname="Matsuzono"/>
</reference> <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>
<!--<xi:include <reference anchor="Cefore">
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <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>
<referencegroup anchor="STD78" target="https://www.rfc-editor.org/info/std <reference anchor="Cefore-site" target="https://cefore.net/">
78"> <front>
<xi:include <title>Cefore</title>
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5343.xml"/> <author/>
<xi:include <date/>
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5590.xml"/> </front>
<xi:include </reference>
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5591.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6353.xml"/>
</referencegroup>-->
</references> </references>
</references>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.command" title="ccninfo Command and Options"> <section anchor="sec.command" numbered="true" toc="default">
<name>ccninfo Command and Options</name>
<t> <t>
CCNinfo is implemented in Cefore <xref target="refs.ieice" format="default"/> CCNinfo is implemented in Cefore <xref target="Cefore" format="default"/> <xr
<xref target="refs.cefore" format="default"/>. The command invoked by the CCNinf ef target="Cefore-site" format="default"/>. The command invoked by the CCNinfo u
o user (e.g., consumer) is named "ccninfo". The ccninfo command sends the Reques ser (e.g., consumer) is named "ccninfo". The ccninfo command sends the Request m
t message and receives the Reply message(s). There are several options that can essage and receives the Reply message(s). There are several options that can be
be specified with ccninfo, while the content name prefix (e.g., ccnx:/news/today specified with ccninfo, while the content name prefix (e.g., ccnx:/news/today) i
) is the mandatory parameter.</t> s the mandatory parameter.</t>
<t>The usage of ccninfo command is as follows:</t> <t>The usage of the ccninfo command is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count]
algo] name_prefix [-v algorithm] name_prefix
]]></artwork> ]]></artwork>
<dl newline="true" spacing="normal" indent="3"> <dl newline="true" spacing="normal" indent="3">
<dt>name_prefix</dt> <dt>name_prefix:</dt>
<dd> <dd>
Prefix name of content (e.g., ccnx:/news/today) or exact name of 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 content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants
to trace.</dd> to trace.</dd>
</dl> <dt>c option:</dt>
<dl newline="true" spacing="normal" indent="3">
<dt>c option</dt>
<dd> <dd>
This option can be specified if a CCNinfo user needs the cache This option can be specified if a CCNinfo user needs the cache
information as well as the routing path information for the information as well as the routing path information for the
specified content/cache and RTT between the CCNinfo user and specified content/cache and RTT between the CCNinfo user and
content forwarder. content forwarder.
</dd> </dd>
<dt>f option:</dt>
<dt>f option</dt>
<dd> <dd>
This option enables the "full discovery request"; routers send This option enables the "full discovery request"; routers send
CCNinfo Requests to multiple upstream faces based on their FIBs CCNinfo Requests to multiple upstream faces based on their FIBs
simultaneously. The CCNinfo user can then trace all possible simultaneously. The CCNinfo user can then trace all possible
forwarding paths. forwarding paths.
</dd> </dd>
<dt>o option:</dt>
<dt>o option</dt> <dd>
<dd> This option enables the tracing of the path to the content publisher.
This option enables to trace the path to the content publisher.
Each router along the path to the publisher inserts each Report Each router along the path to the publisher inserts each Report
block and forwards the Request message. It does not send Reply block and forwards the Request message. It does not send Reply
even if it caches the specified content. FHR that attaches the even if it caches the specified content. FHR that attaches the
publisher (who has the complete set of content and is not a publisher (who has the complete set of content and is not a
caching router) sends the Reply message. caching router) sends the Reply message.
</dd> </dd>
<dt>V option:</dt>
<dt>V option</dt>
<dd> <dd>
This option requests the Reply sender to validate the Reply This option requests the Reply sender to validate the Reply
message with the Reply sender's signature. The Reply message will message with the Reply sender's signature. The Reply message will
then include the CCNx ValidationPayload TLV. The validation then include the CCNx ValidationPayload TLV. The validation
algorithm is selected by the Reply sender. algorithm is selected by the Reply sender.
</dd> </dd>
<dt>r option:</dt>
<dt>r option</dt>
<dd> <dd>
Number of traced routers. This value is set in the "HopLimit" The number of traced routers. This value is set in the "HopLimit"
field located in the fixed header of the Request. For example, field located in the fixed header of the Request. For example,
when the CCNinfo user invokes the CCNinfo command with this when the CCNinfo user invokes the ccninfo command with this
option, such as "-r 3", only three routers along the path examine option, such as "-r 3", only three routers along the path examine
their path and cache information. their path and cache information.
</dd> </dd>
<dt>s option:</dt>
<dt>s option</dt>
<dd> <dd>
Number of skipped routers. This value is set in the "SkipHop" The number of skipped routers. This value is set in the "SkipHop"
field located in the Request block TLV. For example, when the field located in the Request block TLV. For example, when the CCNinfo
CCNinfo user invokes the CCNinfo command with this option, such as user invokes the ccninfo command with this option, such as "-s 3",
"-s 3", three upstream routers along the path only forward the three upstream routers along the path only forward the Request message
Request message but do not append their Report blocks in the hop- but do not append their Report blocks in the hop-by-hop header and do
by-hop header and do not send Reply messages despite having the not send Reply messages despite having the corresponding cache.
corresponding cache.
</dd> </dd>
<dt>v option:</dt>
<dt>v option</dt>
<dd> <dd>
This option enables the CCNinfo user to validate the Request This option enables the CCNinfo user to validate the Request
message with his/her signature. The Request message will include message with their signature. The Request message will include
the CCNx ValidationPayload TLV. The validation algorithm is the CCNx ValidationPayload TLV. The validation algorithm is
specified by the CCNinfo user. specified by the CCNinfo user.
</dd> </dd>
</dl> </dl>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- <section anchor="sec.history" title="Change History"> <section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Jérôme François"/>,
<contact fullname="Erik Kline"/>, <contact fullname="Spyridon Mastorakis"/>, <co
ntact fullname="Paulo Mendes"/>, <contact fullname="Ilya Moiseenko"/>, <contact
fullname="David Oran"/>, and <contact fullname="Thierry Turletti"/> for their va
luable comments and suggestions on this document.</t>
</section>
<t>-00: This document was created based on the previous "Contrace" documen </back>
t whose initial version had been published on October 31, 2016.</t>
<t>-01: Lots of bug fixes from -00.</t>
</section>--> <!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
CCNinfo command vs. ccninfo command ([HA] Done with ccninfo command)
Request and Reply vs. request-reply vs. Request/Reply ([HA] Done.)
caching router vs. Caching router ([HA] Done except Figs.1 and 2 and their expla
nation)
interests vs. Interests ([HA] Done with Interest except a few general "interest"
)
node identifier vs. Node Identifier ([HA] Done with Node Identifier (as the fiel
d name) and node identifier (as the general term))
-->
</back>
</rfc> </rfc>
 End of changes. 246 change blocks. 
1689 lines changed or deleted 1509 lines changed or added

This html diff was produced by rfcdiff 1.48.