< draft-irtf-icnrg-ccninfo-09.txt   draft-irtf-icnrg-ccninfo-10.txt >
ICN Research Group H. Asaeda ICN Research Group H. Asaeda
Internet-Draft A. Ooka Internet-Draft A. Ooka
Intended status: Experimental NICT Intended status: Experimental NICT
Expires: August 14, 2022 X. Shao Expires: October 27, 2022 X. Shao
Kitami Institute of Technology Kitami Institute of Technology
February 10, 2022 April 25, 2022
CCNinfo: Discovering Content and Network Information in Content-Centric CCNinfo: Discovering Content and Network Information in Content-Centric
Networks Networks
draft-irtf-icnrg-ccninfo-09 draft-irtf-icnrg-ccninfo-10
Abstract Abstract
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 (CCN). 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 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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2022. This Internet-Draft will expire on October 27, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 6 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 8 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9
3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 9 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Request Header Block and Request Block . . . . . . . 11 3.1.1. Request Header Block and Request Block . . . . . . . 12
3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 15 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16
3.1.3. Content Name Specification . . . . . . . . . . . . . 16 3.1.3. Content Name Specification . . . . . . . . . . . . . 17
3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 17 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18
3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 18 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19
4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 21 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22
4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 21 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22
4.1.1. Routing Path Information . . . . . . . . . . . . . . 21 4.1.1. Routing Path Information . . . . . . . . . . . . . . 22
4.1.2. In-Network Cache Information . . . . . . . . . . . . 21 4.1.2. In-Network Cache Information . . . . . . . . . . . . 22
4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 22 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23
5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. User and Neighbor Verification . . . . . . . . . . . . . 22 5.1. User and Neighbor Verification . . . . . . . . . . . . . 23
5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 22 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 23
5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 24 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25
5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 24 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25
5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 24 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 25
5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 25 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 26
5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 26 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27
5.6. PIT Entry Management for Multipath Support . . . . . . . 26 5.6. PIT Entry Management for Multipath Support . . . . . . . 27
6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 28 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 29
6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 28 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 29
6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 28 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 29
6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 28 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 29
6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 28 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 29
6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 28 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6. No Information . . . . . . . . . . . . . . . . . . . . . 28 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 30
6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 29 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 30
6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 29 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 30
6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 29 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30
6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 29 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 30
6.11. Administratively Prohibited . . . . . . . . . . . . . . . 29 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 30
7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 29 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31
7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 30 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 31
7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 30 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 31
8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 30 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 31
8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 30 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 31
8.2. Caching Router Identification . . . . . . . . . . . . . . 30 8.2. Caching Router Identification . . . . . . . . . . . . . . 31
8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 30 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 31
8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32
8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 31 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 32
8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 31 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Policy-Based Information Provisioning for Request . . . 31 10.1. Policy-Based Information Provisioning for Request . . . 32
10.2. Filtering CCNinfo Users Located in Invalid Networks . . 32 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 33
10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33
10.4. Characteristics of Content . . . . . . . . . . . . . . . 32 10.4. Characteristics of Content . . . . . . . . . . . . . . . 33
10.5. Computational Attacks . . . . . . . . . . . . . . . . . 32 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 34
10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 33 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 34
10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 33 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 34
10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 33 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34
10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 33 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. ccninfo Command and Options . . . . . . . . . . . . 35 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
In Content-Centric Networks (CCN), publishers provide the content In Content-Centric Networks (CCN), publishers provide the content
through the network, and receivers retrieve it by name. In this through the network, and receivers retrieve it by name. In this
network architecture, routers forward content requests through their network architecture, routers forward content requests through their
Forwarding Information Bases (FIBs), which are populated by name- Forwarding Information Bases (FIBs), which are populated by name-
based routing protocols. CCN also enables receivers to retrieve based routing protocols. CCN also enables receivers to retrieve
content from an in-network cache. content from an in-network cache.
skipping to change at page 4, line 15 skipping to change at page 4, line 15
investigating the network conditions. investigating the network conditions.
IP traceroute is a useful tool for discovering the routing conditions IP traceroute is a useful tool for discovering the routing conditions
in IP networks because it provides intermediate router addresses in IP networks because it provides intermediate router addresses
along the path between the source and destination and the Round-Trip along the path between the source and destination and the Round-Trip
Time (RTT) for the path. However, this IP-based network tool cannot Time (RTT) for the path. However, this IP-based network tool cannot
trace the name prefix paths used in CCN. Moreover, such IP-based trace the name prefix paths used in CCN. Moreover, such IP-based
network tools do not obtain the states of the in-network cache to be network tools do not obtain the states of the in-network cache to be
discovered. discovered.
Contrace [6] enables end users (i.e., consumers) to investigate path Contrace [7] enables end users (i.e., consumers) to investigate path
and in-network cache conditions in CCN. Contrace is implemented as and in-network cache conditions in CCN. Contrace is implemented as
an external daemon process running over TCP/IP that can interact with an external daemon process running over TCP/IP that can interact with
a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the
caching information on the forwarding daemon. This solution is caching information on the forwarding daemon. This solution is
flexible, but it requires TCP/IP networks and defining the common flexible, but it requires TCP/IP networks and defining the common
APIs for the global deployment. ICN ping [7] and traceroute [8] are APIs for the global deployment. ICN ping [8] and traceroute [9] are
lightweight operational tools that enable a user to explore the lightweight operational tools that enable a user to explore the
path(s) that reach a publisher or a cache storing the named content. path(s) that reach a publisher or a cache storing the named content.
ICN ping and traceroute, however, do not exposes detailed information ICN ping and traceroute, however, do not exposes detailed information
about the forwarders deployed by a network operator. about the forwarders deployed by a network operator.
This document describes the specifications of "CCNinfo", an active This document describes the specifications of "CCNinfo", an active
networking tool for discovering the path and content caching networking tool for discovering the path and content caching
information in CCN. CCNinfo defines the protocol messages to information in CCN. CCNinfo defines the protocol messages to
investigate path and in-network cache conditions in CCN. It is investigate path and in-network cache conditions in CCN. It is
embedded in the CCNx forwarding process and can facilitate with non- embedded in the CCNx forwarding process and can facilitate with non-
IP networks as with the basic CCN concept. IP networks as with the basic CCN concept.
The two message types, Request and Reply messages, are encoded in the The two message types, Request and Reply messages, are encoded in the
CCNx TLV format [1]. The request-reply message flow, walking up the CCNx TLV format [1]. The request-reply message flow, walking up the
tree from a consumer toward a publisher, is similar to the behavior tree from a consumer toward a publisher, is similar to the behavior
of the IP multicast traceroute facility [9]. of the IP multicast traceroute facility [10].
CCNinfo facilitates the tracing of a routing path and provides: 1) CCNinfo facilitates the tracing of a routing path and provides: 1)
the RTT between the content forwarder (i.e., the caching or first-hop the RTT between the content forwarder (i.e., caching router or first-
router) and consumer, 2) the states of the in-network cache per name hop router) and consumer, 2) the states of the in-network cache per
prefix, and 3) the routing path information per name prefix. name prefix, and 3) the routing path information per name prefix.
In addition, CCNinfo identifies the states of the cache, such as the In addition, CCNinfo identifies the states of the cache, such as the
following metrics for Content Store (CS) in the content forwarder: 1) following metrics for Content Store (CS) in the content forwarder: 1)
size of cached content objects, 2) number of cached content objects, size of cached content objects, 2) number of cached content objects,
3) number of accesses (i.e., received Interests) per content, and 4) 3) number of accesses (i.e., received Interests) per content, and 4)
elapsed cache time and remaining cache lifetime of content. elapsed cache time and remaining cache lifetime of content.
CCNinfo supports multipath forwarding. The Request messages can be
forwarded to multiple neighbor routers. When the Request messages
are forwarded to multiple routers, the different Reply messages are
forwarded from different routers or publishers.
Furthermore, CCNinfo implements policy-based information provisioning
that enables administrators to "hide" secure or private information
but does not disrupt message forwarding. This policy-based
information provisioning reduces the deployment barrier faced by
operators in installing and running CCNinfo on their routers.
1.1. CCNinfo as an Experimental Tool
In order to carry out meaningful experimentation with CCNx protocols,
comprehensive instrumentation and management information is needed to
take measurements and explore both the performance and robustness
characteristics of the protocols and of the applications using them.
CCNinfo's primary goal is to gather and report this information. As
experience is gained with both the CCNx protocols and CCNinfo itself,
we can refine the instrumentation capabilities and discover what
additional capabilities might be needed in CCNinfo and conversely
which features wind up not being of sufficient value to justify the
implementation complexity and execution overhead.
CCNinfo is intended as a comprehensive experimental tool for CCNx-
based networks. It provides a wealth of information from forwarders,
including on-path in-network cache conditions as well as forwarding
path instrumentation of multiple paths toward content forwarders. As
an experimental capability that exposes detailed information about
the forwarders deployed by a network operator, CCNinfo employs more
granular authorization policies than those required of ICN ping or
ICN traceroute.
CCNinfo uses two message types: Request and Reply. A CCNinfo user,
e.g., consumer, initiates a CCNinfo Request message when s/he wants
to obtain routing path and cache information. When an adjacent
neighbor router receives the Request message, it examines own cache
information. If the router does not cache the specified content, it
inserts its Report block into the hop-by-hop header of the Request
message and forwards the message to its upstream neighbor router(s)
decided by its FIB. In Figure 1, CCNinfo user and routers (Router A,
B, C) insert their own Report blocks into the Request message and
forward the message toward the content forwarder.
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 |
+---------+ +---------+
Figure 1: Request messages forwarded by consumer and routers. Figure 1: Request message invoked by CCNinfo user and forwarded by
CCNinfo user and routers (i.e., Router A, B, C) insert their own routers.
Report blocks into the Request message and forward the message toward
the content forwarder (i.e., caching router and publisher). When the Request message reaches the content forwarder, the content
forwarder forms the Reply message; it inserts its own Reply block TLV
and Reply sub-block TLV(s) to the Request message. The Reply message
is then forwarded back toward the user in a hop-by-hop manner along
the PIT entries. In Figure 2, each router (Router C, B, and A)
forwards the Reply message along its PIT entry and finally, the
CCNinfo user receives a Reply message from Router C, which is the
first-hop router for the Publisher. Another Reply message from the
Caching router (i.e., Reply(C)) is discarded at Router B if the other
Reply message (i.e., Reply(P)) was already forwarded by Router B.
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 |
+---------+ +---------+
Figure 2: Default behavior. Reply messages forwarded by routers. Figure 2: Reply messages forwarded by routers, and one Reply message
Each router forwards the Reply message along its PIT entry and is received by CCNinfo user.
finally, the CCNinfo user receives a Reply message from Router C,
which is the first-hop router for the Publisher. Another Reply
message from the Caching router (i.e., Reply(C)) is discarded at
Router B when the other Reply message (i.e., Reply(P)) was already
forwarded by Router B.
CCNinfo supports multipath forwarding. The Request messages can be
forwarded to multiple neighbor routers. When the Request messages
are forwarded to multiple routers, the different Reply messages are
forwarded from different routers or publishers.
Furthermore, CCNinfo implements policy-based information provisioning
that enables administrators to "hide" secure or private information
but does not disrupt message forwarding. This policy-based
information provisioning reduces the deployment barrier faced by
operators in installing and running CCNinfo on their routers.
1.1. CCNinfo as an Experimental Tool
CCNinfo is intended as a comprehensive experimental tool for CCN
networks. It provides a wealth of information from CCN forwarders,
including on-path in-network cache conditions as well as forwarding
path instrumentation of multiple paths toward content forwarders. As
an experimental capability that exposes detailed information about
the forwarders deployed by a network operator, CCNinfo employs more
granular authorization policies than those required of ICN ping or
ICN traceroute.
Usually, the CCNinfo user (e.g., consumer) invokes the CCNinfo user
program (such as "ccninfo" command described in Appendix A) with the
name prefix of the content. The user program initiates the Request
message (described in Section 3.1) to obtain routing path and cache
information. When an appropriate adjacent neighbor router receives
the Request message, it retrieves own cache information. If the
router is not the content forwarder for the specified name prefix, it
inserts its Report block (described in Section 3.1.2) into the
Request message and forwards it to its upstream neighbor router(s)
decided by its FIB.
The Request message is forwarded by routers toward the content
publisher and the Report record is inserted by each intermediate
router. When the Request message reaches the content forwarder
(i.e., a router that can forward the specified content), the content
forwarder forms the Reply message (described in Section 3.2) and
sends it to the downstream neighbor router. The Reply message is
forwarded back toward the user in a hop-by-hop manner (along the PIT
entries).
In order to carry out meaningful experimentation with CCNx protocols,
comprehensive instrumentation and management information is needed to
take measurements and explore both the performance and robustness
characteristics of the protocols and of the applications using them.
CCNinfo's primary goal is to gather and report this information. As
experience is gained with both the CCNx protocols and CCNinfo itself,
we can refine the instrumentation capabilities and discover what
additional capabilities might be needed in CCNinfo and conversely
which features wind up not being of sufficient value to justify the
implementation complexity and execution overhead.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in
all capitals, as shown here. all capitals, as shown here.
2.1. Definitions 2.1. Definitions
This document follows the basic terminologies and definitions This document follows the basic terminologies and definitions
described in [1]. Although CCNinfo requests flow in the opposite described in [1]. Although CCNinfo requests flow in the opposite
direction to the data flow, we refer to "upstream" and "downstream" direction to the data flow, we refer to "upstream" and "downstream"
with respect to data, unless explicitly specified. with respect to data, unless explicitly specified.
Router
It is a router that facilitates CCN-based content retrieval in the
path between the consumer and publisher.
Scheme name Scheme name
It indicates a URI and protocol. This document only considers It indicates a URI and protocol. This document only considers
"ccnx:/" as the scheme name. "ccnx:/" as the scheme name.
Prefix name Prefix name
A prefix name, which is defined in [2], is a name that does not A prefix name, which is defined in [2], is a name that does not
uniquely identify a single content object, but rather a namespace uniquely identify a single content object, but rather a namespace
or prefix of an existing content object name. or prefix of an existing content object name.
Exact name Exact name
An exact name, which is defined in [2], is one that uniquely An exact name, which is defined in [2], is one that uniquely
identifies the name of a content object. identifies the name of a content object.
Node Node
It is a router, publisher, or consumer. 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 given in [6].
Consumer
A node that requests content objects by generating and sending out
interests. It is a same definition of ICN Consumer as given in
[6].
Publisher
A node that creates content objects and makes them available for
retrieval. It is a same definition of ICN Producer as given in
[6].
Router
A node that implements stateful forwarding in the path between
consumer and publisher.
Caching router
A node that temporarily stores and potentially carries interests
or content objects before forwarding it to next node.
Content forwarder Content forwarder
It is either a caching router or a first-hop router that forwards It is either a caching router or a first-hop router that forwards
content objects to consumers. content objects to consumers.
CCNinfo user CCNinfo user
It is a node that initiates the CCNinfo Request, which is usually A node that initiates the CCNinfo Request, which is consumer or
invoked by the user program (described in Appendix A) or other router that invokes the CCNinfo user program with the name prefix
similar commands. of the content. The CCNinfo user program, such as "ccninfo"
command described in Appendix A or other similar commands,
initiates the Request message to obtain routing path and cache
information.
Incoming face Incoming face
The face on which data are expected to arrive from the specified The face on which data are expected to arrive from the specified
name prefix. name prefix.
Outgoing face Outgoing face
The face to which data from the publisher or router are expected The face to which data from the publisher or router are expected
to transmit for the specified name prefix. It is also the face on to transmit for the specified name prefix. It is also the face on
which the Request messages are received. which the Request messages are received.
skipping to change at page 8, line 27 skipping to change at page 9, line 14
First-hop router (FHR) First-hop router (FHR)
The router that matches a FIB entry with an Outgoing face The router that matches a FIB entry with an Outgoing face
referring to a local application or a publisher. referring to a local application or a publisher.
Last-hop router (LHR) Last-hop router (LHR)
The router that is directly connected to a consumer. The router that is directly connected to a consumer.
3. CCNinfo Message Formats 3. CCNinfo Message Formats
CCNinfo uses two message types: Request and Reply. Both messages are CCNinfo Request and Reply messages are encoded in the CCNx TLV format
encoded in the CCNx TLV format ([1], Figure 3). The Request message ([1], Figure 3). The Request message consists of a fixed header,
consists of a fixed header, Request block TLV (Figure 7), and Report Request block TLV (Figure 7), and Report block TLV(s) (Figure 12).
block TLV(s) (Figure 12). The Reply message consists of a fixed The Reply message consists of a fixed header, Request block TLV,
header, Request block TLV, Report block TLV(s), and Reply block/sub- Report block TLV(s), Reply block TLV (Figure 14), and Reply sub-block
block TLV(s) (Figure 14). TLV(s) (Figure 15).
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) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 3: Packet format [1] Figure 3: Packet format [1]
The Request and Reply Type values in the fixed header are The PacketType values in the fixed header shown in Figure 3 are
PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4).
These messages are forwarded in a hop-by-hop manner. When the CCNinfo Request and Reply messages are forwarded in a hop-by-hop
Request message reaches the content forwarder, the content forwarder manner. When the Request message reaches the content forwarder, the
turns it into a Reply message by changing the Type field value in the content forwarder turns it into a Reply message by changing the Type
fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards field value in the fixed header from PT_CCNINFO_REQUEST to
it back toward the node that initiated the Request message. PT_CCNINFO_REPLY and forwards it back toward the node that initiated
the Request message.
Code Type name Code Type name
======== ===================== ======== =====================
%x00 PT_INTEREST [1] %x00 PT_INTEREST [1]
%x01 PT_CONTENT [1] %x01 PT_CONTENT [1]
%x02 PT_RETURN [1] %x02 PT_RETURN [1]
%x03 PT_CCNINFO_REQUEST %x03 PT_CCNINFO_REQUEST
%x04 PT_CCNINFO_REPLY %x04 PT_CCNINFO_REPLY
Figure 4: Packet Type Namespace Figure 4: Packet Type Namespace
The CCNinfo Request and Reply messages MUST begin with a fixed header Following a fixed header, there can be a sequence of optional hop-by-
with either a Request or Reply type value to specify whether it is a hop header TLV(s) for a Request message. In the case of a Request
Request message or Reply message. Following a fixed header, there message, it is followed by a sequence of Report blocks, each from a
can be a sequence of optional hop-by-hop header TLV(s) for a Request router on the path toward the publisher or caching router.
message. In the case of a Request message, it is followed by a
sequence of Report blocks, each from a router on the path toward the
publisher or caching router.
At the beginning of PacketPayload TLVs, a top-level TLV type, At the beginning of PacketPayload TLVs, a top-level TLV type,
T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx
protocol message. This TLV indicates that the Name segment TLV(s) protocol message. This TLV indicates that the Name segment TLV(s)
and Reply block TLV(s) would follow in the Request or Reply message. and Reply block TLV(s) would follow in the Request or Reply message.
Code Type name Code Type name
============= ========================= ============= =========================
%x0000 Reserved [1] %x0000 Reserved [1]
%x0001 T_INTEREST [1] %x0001 T_INTEREST [1]
skipping to change at page 10, line 7 skipping to change at page 10, line 45
3.1. Request Message 3.1. Request Message
When a CCNinfo user initiates a discovery request (e.g., via the When a CCNinfo user initiates a discovery request (e.g., via the
ccninfo command described in Appendix A), a CCNinfo Request message ccninfo command described in Appendix A), a CCNinfo Request message
is created and forwarded to its upstream router through the Incoming is created and forwarded to its upstream router through the Incoming
face(s) determined by its FIB. face(s) determined by its FIB.
The Request message format is shown in Figure 6. It consists of a The Request message format is shown in Figure 6. It consists of a
fixed header, Request header block TLV (Figure 7), Report block fixed header, Request header block TLV (Figure 7), Report block
TLV(s) (Figure 12), Name TLV, and Request block TLV. The Type value TLV(s) (Figure 12), Name TLV, and Request block TLV. Request header
of the Top-Level type namespace is T_DISCOVERY (Figure 5). The Type block TLV and Report block TLV(s) are contained in the hop-by-hop
value for the Report message is PT_CCNINFO_REQUEST. header, as those might change from hop to hop. Request block TLV is
encoded in the PacketPayload TLV by content forwarder as the protocol
message itself. The PacketType value of the Request message is
PT_CCNINFO_REQUEST (Figure 4). The Type value of the Top-Level type
namespace is T_DISCOVERY (Figure 5).
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 page 11, line 47 skipping to change at page 12, line 42
Reserved (MBZ): 8 bits Reserved (MBZ): 8 bits
The reserved fields in the Value field MUST be transmitted as The reserved fields in the Value field MUST be transmitted as
zeros and ignored on receipt. zeros and ignored on receipt.
3.1.1. Request Header Block and Request Block 3.1.1. Request Header Block and Request Block
When a CCNinfo user transmits the Request message, s/he MUST insert When a CCNinfo user transmits the Request message, s/he MUST insert
her/his Request header block TLV (Figure 7) into the hop-by-hop her/his Request header block TLV (Figure 7) into the hop-by-hop
header and Request block TLV (Figure 7) into the message before header and Request block TLV (Figure 10) into the message before
sending it through the Incoming face(s). sending it through the Incoming face(s).
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|
+---------------+---------------+-------+-------+-------+-+-+-+-+ +---------------+---------------+-------+-------+-------+-+-+-+-+
skipping to change at page 12, line 47 skipping to change at page 13, line 47
Length of Value field in octets. Length of Value field in octets.
Request ID: 16 bits Request ID: 16 bits
This field is used as a unique identifier for the CCNinfo Request This field is used as a unique identifier for the CCNinfo Request
so that the duplicate or delayed Reply messages can be detected. so that the duplicate or delayed Reply messages can be detected.
SkipHop (Skip Hop Count): 4 bits SkipHop (Skip Hop Count): 4 bits
Number of skipped routers for a Request. It is specified by the Number of skipped routers for a Request. It is specified by the
CCNinfo user program. Routers corresponding to the value CCNinfo user program. The number of routers corresponding to the
specified in this field are skipped and the CCNinfo Request value specified in this field are skipped and the CCNinfo Request
messages are forwarded to the next router without the addition of messages are forwarded to the next router without the addition of
Report blocks; the next upstream router then starts the trace. Report blocks; the next upstream router then starts the trace.
The maximum value of this parameter is 15. This value MUST be The maximum value of this parameter is 15. This value MUST be
lower than that of HopLimit at the fixed header. lower than that of HopLimit at the fixed header.
Flags: 12 bits Flags: 12 bits
The Flags field is used to indicate the types of the content or The Flags field is used to indicate the types of the content or
path discoveries. Currently, as shown in Figure 9, four bits, path discoveries. Currently, as shown in Figure 9, four bits,
"C", "O", "F", and "V" are assigned, and the other 8 bits are "C", "O", "F", and "V" are assigned, and the other 8 bits are
skipping to change at page 13, line 21 skipping to change at page 14, line 21
specified with other flags. These flags are set by the CCNinfo specified with other flags. These flags are set by the CCNinfo
user program when they initiate Requests (see Appendix A), and the user program when they initiate Requests (see Appendix A), and the
routers that receive the Requests deal with the flags and change routers that receive the Requests deal with the flags and change
the behaviors (see Section 5 for details). The Flag values the behaviors (see Section 5 for details). The Flag values
defined in this Flags field correspond to the Reply sub-blocks. defined in this Flags field correspond to the Reply sub-blocks.
Flag Value Description Flag Value Description
----- ----- ----------------------------------------------------- ----- ----- -----------------------------------------------------
C 0 Path discovery (i.e., no cache information retrieved) C 0 Path discovery (i.e., no cache information retrieved)
(default) (default)
C 1 Cache information retrieval C 1 Path and cache information retrieval
O 0 Request to any content forwarder (default) O 0 Request to any content forwarder (default)
O 1 Publisher discovery (i.e., only FHR can reply) O 1 Publisher discovery (i.e., only FHR can reply)
F 0 Request based on FIB's strategy (default) F 0 Request based on FIB's forwarding strategy (default)
F 1 Full discovery request. Request to possible multiple F 1 Full discovery request. Request to possible multiple
upstream routers specified in FIB simultaneously upstream routers specified in FIB simultaneously
V 0 No reply validation (default) V 0 No reply validation (default)
V 1 Reply sender validates Reply message V 1 Reply sender validates Reply message
Figure 9: Codes and types specified in Flags field Figure 9: Codes and types specified in Flags field
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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 14, line 34 skipping to change at page 15, line 34
value(s) MUST be T_DISC_REQ (see Figure 11) in the current value(s) MUST be T_DISC_REQ (see Figure 11) in the current
specification. specification.
Length: 16 bits Length: 16 bits
Length of Value field in octets. Length of Value field in octets.
Request Arrival Time: 32 bits Request Arrival Time: 32 bits
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 packet at a specific router. arrival time of the CCNinfo Request message at the router. The
The 32-bit form of an NTP timestamp consists of the middle 32 bits 32-bit form of an NTP timestamp consists of the middle 32 bits of
of the full 64-bit form; that is, the low 16 bits of the integer the full 64-bit form; that is, the low 16 bits of the integer part
part and the high 16 bits of the fractional part. and the high 16 bits of the fractional part.
The following formula converts from a timespec (fractional part in The following formula converts from a timespec (fractional part in
nanoseconds) to a 32-bit NTP timestamp: nanoseconds) to a 32-bit NTP timestamp:
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)
The constant 32384 is the number of seconds from Jan 1, 1900 to The constant 32384 is the number of seconds from Jan 1, 1900 to
Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125)
is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<"
denotes a logical left shift. denotes a logical left shift.
Note that it is RECOMMENDED for all the routers on the path to Note that it is RECOMMENDED for all the routers on the path to
have synchronized clocks to measure one-way latency per hop; have synchronized clocks to measure one-way latency per hop;
however, even if they do not have synchronized clocks, CCNinfo however, even if they do not have synchronized clocks, CCNinfo
measures the RTT between the content forwarder and consumer. measures the RTT between the content forwarder and consumer.
Node Identifier: variable length Node Identifier: variable length
This field specifies the node identifier (e.g., node name or hash- This field specifies the node identifier (e.g., node name or hash-
based self-certifying name [10]) or all-zeros if unknown. This based self-certifying name [11]) or all-zeros if unknown. This
document assumes that the Name TLV defined in the CCNx TLV format document assumes that the Name TLV defined in the CCNx TLV format
[1] can be used for this field and the node identifier is [1] can be used for this field and the node identifier is
specified in it. specified in it.
3.1.2. Report Block TLV 3.1.2. Report Block TLV
A CCNinfo user and each upstream router along the path would insert A CCNinfo user and each upstream router along the path would insert
their own Report block TLV without changing the Type field of the their own Report block TLV without changing the Type field of the
fixed header of the Request message until one of these routers is fixed header of the Request message until one of these routers is
ready to send a Reply. In the Report block TLV (Figure 12), the ready to send a Reply. In the Report block TLV (Figure 12), the
skipping to change at page 20, line 41 skipping to change at page 21, line 41
First Seqnum: 32 bits First Seqnum: 32 bits
The first sequential number of the unexpired content objects. The first sequential number of the unexpired content objects.
Last Seqnum: 32 bits Last Seqnum: 32 bits
The last sequential number of the unexpired content objects. The The last sequential number of the unexpired content objects. The
First Seqnum and Last Seqnum do not guarantee the consecutiveness First Seqnum and Last Seqnum do not guarantee the consecutiveness
of the cached content objects; however, knowing these values may of the cached content objects; however, knowing these values may
help in the analysis of consecutive or discontinuous chunks such help in the analysis of consecutive or discontinuous chunks such
as [11]. as [12].
Elapsed Cache Time: 32 bits Elapsed Cache Time: 32 bits
The elapsed time (seconds) after the oldest content object of the The elapsed time (seconds) after the oldest content object of the
content is cached. content is cached.
Remain Cache Lifetime: 32 bits Remain Cache Lifetime: 32 bits
The lifetime (seconds) of a content object, which is lastly The lifetime (seconds) of a content object, which is lastly
cached. cached.
skipping to change at page 23, line 31 skipping to change at page 24, line 31
flag is not set, it is categorized as the "routing path flag is not set, it is categorized as the "routing path
information discovery". If the "C" flag is set, it is the "cache information discovery". If the "C" flag is set, it is the "cache
information discovery". If the "O" flag is set, it is the information discovery". If the "O" flag is set, it is the
"publisher discovery". "publisher discovery".
3. If the Request is either "cache information discovery" or 3. If the Request is either "cache information discovery" or
"routing path information discovery", the router examines its FIB "routing path information discovery", the router examines its FIB
and CS. If the router caches the specified content, it sends the and CS. If the router caches the specified content, it sends the
Reply message with its own Reply block and sub-block(s). If the Reply message with its own Reply block and sub-block(s). If the
router cannot insert its own Reply block or sub-block(s) because router cannot insert its own Reply block or sub-block(s) because
of no space, it it terminates the Request, as specified in of no space, it terminates the Request, as specified in
Section 6.7. If the router does not cache the specified content Section 6.7. If the router does not cache the specified content
but knows the upstream neighbor router(s) for the specified name but knows the upstream neighbor router(s) for the specified name
prefix, it creates the PIT entry, and inserts its own Report prefix, it creates the PIT entry, and inserts its own Report
block in the hop-by-hop header and forwards the Request to the block in the hop-by-hop header and forwards the Request to the
upstream neighbor(s). If the router cannot insert its own Report upstream neighbor(s). If the router cannot insert its own Report
block because of no space, or if the router does not cache the block because of no space, or if the router does not cache the
specified content and does not know the upstream neighbor specified content and does not know the upstream neighbor
router(s) for the specified name prefix, it terminates the router(s) for the specified name prefix, it terminates the
Request, as defined in Section 6.5. Request, as defined in Section 6.5.
skipping to change at page 24, line 5 skipping to change at page 25, line 5
whether it is the FHR for the requested content. If the router whether it is the FHR for the requested content. If the router
is the FHR, it sends the Reply message with its own Report block is the FHR, it sends the Reply message with its own Report block
and sub-blocks (in the case of cache information discovery) or and sub-blocks (in the case of cache information discovery) or
the Reply message with its own Report block without adding any the Reply message with its own Report block without adding any
Reply sub-blocks (in the case of routing path information Reply sub-blocks (in the case of routing path information
discovery). If the router is not the FHR but knows the upstream discovery). If the router is not the FHR but knows the upstream
neighbor router(s) for the specified name prefix, it creates the neighbor router(s) for the specified name prefix, it creates the
PIT entry, and inserts its own Report block and forwards the PIT entry, and inserts its own Report block and forwards the
Request to the upstream neighbor(s). If the router cannot insert Request to the upstream neighbor(s). If the router cannot insert
its own Report block in the hop-by-hop header because of no its own Report block in the hop-by-hop header because of no
space, it it terminates the Request, as specified in Section 6.7. space, it terminates the Request, as specified in Section 6.7.
If the router is not the FHR and does not know the upstream If the router is not the FHR and does not know the upstream
neighbor router(s) for the specified name prefix, it terminates neighbor router(s) for the specified name prefix, it terminates
the Request, as defined in Section 6.5. Note that in Cefore the Request, as defined in Section 6.5. Note that in Cefore
[13], there is an API by which a publisher informs the [14], there is an API by which a publisher informs the
application prefix to the FHR and the FHR registers it into the application prefix to the FHR and the FHR registers it into the
FIB. The prefix entry then can be statically configured on other FIB. The prefix entry then can be statically configured on other
routers or announced by a routing protocol. routers or announced by a routing protocol.
5.3. Forwarding CCNinfo Request 5.3. Forwarding CCNinfo Request
5.3.1. Regular Request 5.3.1. Regular Request
When a router decides to forward a Request message with its Report When a router decides to forward a Request message with its Report
block to its upstream router(s), it specifies the Request Arrival block to its upstream router(s), it specifies the Request Arrival
skipping to change at page 28, line 34 skipping to change at page 29, line 34
6.3. Arriving at Last Router 6.3. Arriving at Last Router
A CCNinfo Request can be determined to have arrived at the last A CCNinfo Request can be determined to have arrived at the last
router of the specified HopLimit. If the last router does not have router of the specified HopLimit. If the last router does not have
the corresponding cache, it MUST insert its Report block and send the the corresponding cache, it MUST insert its Report block and send the
Reply message with NO_INFO return code without appending any Reply Reply message with NO_INFO return code without appending any Reply
(sub-)block TLVs. (sub-)block TLVs.
6.4. Invalid Request 6.4. Invalid Request
If the router does not validate the Request or the Reply, the router If the router does not validate the Request or the Reply even it is
MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the required, the router MUST note a ReturnCode of INVALID_REQUEST in the
message, insert its Report block, and forward the message as the fixed header of the message, insert its Report block, and forward the
Reply back to the CCNinfo user. The router MAY, however, randomly message as the Reply back to the CCNinfo user. The router MAY,
ignore the received invalid messages. (See Section 10.7.) however, randomly ignore the received invalid messages. (See
Section 10.7.)
6.5. No Route 6.5. No Route
If the router cannot determine the routing paths or neighbor routers If the router cannot determine the routing paths or neighbor routers
for the specified name prefix within the specified HopLimit, it MUST for the specified name prefix within the specified HopLimit, it MUST
note a ReturnCode of NO_ROUTE in the fixed header of the message, note a ReturnCode of NO_ROUTE in the fixed header of the message,
insert its Report block, and forward the message as the Reply back to insert its Report block, and forward the message as the Reply back to
the CCNinfo user. the CCNinfo user.
6.6. No Information 6.6. No Information
skipping to change at page 33, line 51 skipping to change at page 35, line 10
returning multiple Reply messages. To prevent abuse, the routers in returning multiple Reply messages. To prevent abuse, the routers in
the traced path MAY need to rate-limit the Replies. In such a case, the traced path MAY need to rate-limit the Replies. In such a case,
no error message is returned. The rate limit function is left to the no error message is returned. The rate limit function is left to the
router's implementation. router's implementation.
10.9. Adjacency Verification 10.9. Adjacency Verification
It is assumed that the CCNinfo Request and Reply messages are It is assumed that the CCNinfo Request and Reply messages are
forwarded by adjacent neighbor nodes or routers. The CCNx message forwarded by adjacent neighbor nodes or routers. The CCNx message
format or semantics do not define a secure way to verify the node/ format or semantics do not define a secure way to verify the node/
router adjacency, while HopAuth [10] provides a possible method for router adjacency, while HopAuth [11] provides a possible method for
an adjacency verification and defines the corresponding message an adjacency verification and defines the corresponding message
format for adjacency verification as well as the router behaviors. format for adjacency verification as well as the router behaviors.
CCNinfo MAY use a similar method for node adjacency verification. CCNinfo MAY use a similar method for node adjacency verification.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Spyridon Mastorakis, Paulo Mendes, The authors would like to thank Spyridon Mastorakis, Paulo Mendes,
Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable
comments and suggestions on this document. comments and suggestions on this document.
skipping to change at page 34, line 40 skipping to change at page 35, line 47
2119 Key Words", May 2017, 2119 Key Words", May 2017,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.
[5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 12.2. Informative References
[6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A [6] Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C.
Tschudin, "Information-Centric Networking (ICN): Content-
Centric Networking (CCNx) and Named Data Networking (NDN)
Terminology", RFC 8793, June 2020.
[7] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A
Tool for Measuring and Tracing Content-Centric Networks", Tool for Measuring and Tracing Content-Centric Networks",
IEEE Communications Magazine, Vol.53, No.3, pp.182-188, IEEE Communications Magazine, Vol.53, No.3, pp.182-188,
March 2015. March 2015.
[7] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
D. Oran, "ICN Ping Protocol Specification", draft-irtf- D. Oran, "ICN Ping Protocol Specification", draft-irtf-
icnrg-icnping-03 (work in progress), October 2021. icnrg-icnping-05 (work in progress), April 2022.
[8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and [9] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
D. Oran, "ICN Traceroute Protocol Specification", draft- D. Oran, "ICN Traceroute Protocol Specification", draft-
irtf-icnrg-icntraceroute-03 (work in progress), October irtf-icnrg-icntraceroute-05 (work in progress), April
2021. 2022.
[9] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: [10] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487, October Traceroute Facility for IP Multicast", RFC 8487, October
2018. 2018.
[10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in [11] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in
Content-Centric Networking/Named Data Networking", draft- Content-Centric Networking/Named Data Networking", draft-
li-icnrg-hopauth-02 (work in progress), February 2020. li-icnrg-hopauth-02 (work in progress), February 2020.
[11] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive [12] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive
Caching and Adaptive Retrieval for In-Network Big Data Caching and Adaptive Retrieval for In-Network Big Data
Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018.
[12] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: [13] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore:
Software Platform Enabling Content-Centric Networking and Software Platform Enabling Content-Centric Networking and
Beyond", IEICE Transaction on Communications, Vol.E102-B, Beyond", IEICE Transaction on Communications, Vol.E102-B,
No.9, pp.1792-1803, September 2019. No.9, pp.1792-1803, September 2019.
[13] "Cefore Home Page", <https://cefore.net/>. [14] "Cefore Home Page", <https://cefore.net/>.
Appendix A. ccninfo Command and Options Appendix A. ccninfo Command and Options
CCNinfo is implemented in Cefore [12][13]. The command invoked by CCNinfo is implemented in Cefore [13][14]. The command invoked by
the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo
command sends the Request message and receives the Reply message(s). command sends the Request message and receives the Reply message(s).
There are several options that can be specified with ccninfo, while There are several options that can be specified with ccninfo, while
the content name prefix (e.g., ccnx:/news/today) is the mandatory the content name prefix (e.g., ccnx:/news/today) is the mandatory
parameter. parameter.
The usage of ccninfo command is as follows: The usage of ccninfo command is as follows:
Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v
algo] name_prefix algo] name_prefix
 End of changes. 45 change blocks. 
200 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/