rfc9344.original   rfc9344.txt 
ICN Research Group H. Asaeda Internet Research Task Force (IRTF) H. Asaeda
Internet-Draft A. Ooka Request for Comments: 9344 A. Ooka
Intended status: Experimental NICT Category: Experimental NICT
Expires: 1 July 2023 X. Shao ISSN: 2070-1721 X. Shao
Toyohashi University of Technology Toyohashi University of Technology
28 December 2022 February 2023
CCNinfo: Discovering Content and Network Information in Content-Centric CCNinfo: Discovering Content and Network Information in Content-Centric
Networks Networks
draft-irtf-icnrg-ccninfo-15
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 (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
of in-network cache per name prefix. CCNinfo is useful to understand states of in-network cache per name prefix. CCNinfo is useful to
and debug the behavior of testbed networks and other experimental understand and debug the behavior of testbed networks and other
deployments of CCN systems. experimental deployments of CCN systems.
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 ICNRG and has been reviewed extensively by several members of the of ICNRG and has been reviewed extensively by several members of the
ICN community and the RG. The authors and RG chairs approve of the ICN community and the RG. The authors and RG chairs approve of the
contents. The document is sponsored under the IRTF and is not issued contents. The document is sponsored under the IRTF, is not issued by
by the IETF and is not an IETF standard. This is an experimental the IETF, and is not an IETF standard. This is an experimental
protocol and the specification may change in the future. protocol and the specification may change in the future.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Research Task
time. It is inappropriate to use Internet-Drafts as reference Force (IRTF). The IRTF publishes the results of Internet-related
material or to cite them other than as "work in progress." research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Information-Centric Networking Research Group of the Internet
Research Task Force (IRTF). Documents approved for publication by
the IRSG are not candidates for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on 1 July 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9344.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 5 1.1. CCNinfo as an Experimental Tool
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions
3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9 3. CCNinfo Message Formats
3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10 3.1. Request Message
3.1.1. Request Header Block and Request Block . . . . . . . 12 3.1.1. Request Header Block and Request Block
3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16 3.1.2. Report Block TLV
3.1.3. Content Name Specification . . . . . . . . . . . . . 16 3.1.3. Content Name Specification
3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Reply Message
3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18 3.2.1. Reply Block TLV
3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19 3.2.1.1. Reply Sub-Block TLV
4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22 4. CCNinfo User Behavior
4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22 4.1. Sending CCNinfo Request
4.1.1. Routing Path Information . . . . . . . . . . . . . . 23 4.1.1. Routing Path Information
4.1.2. In-Network Cache Information . . . . . . . . . . . . 23 4.1.2. In-Network Cache Information
4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23 4.2. Receiving CCNinfo Reply
5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 5. Router Behavior
5.1. User and Neighbor Verification . . . . . . . . . . . . . 23 5.1. User and Neighbor Verification
5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 24 5.2. Receiving CCNinfo Request
5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25 5.3. Forwarding CCNinfo Request
5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25 5.3.1. Regular Request
5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 26 5.3.2. Full Discovery Request
5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 27 5.4. Sending CCNinfo Reply
5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27 5.5. Forwarding CCNinfo Reply
5.6. PIT Entry Management for Multipath Support . . . . . . . 28 5.6. PIT Entry Management for Multipath Support
6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 29 6. CCNinfo Termination
6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 29 6.1. Arriving at First-Hop Router
6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 29 6.2. Arriving at Router Having Cache
6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 29 6.3. Arriving at Last Router
6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 30 6.4. Invalid Request
6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 30 6.5. No Route
6.6. No Information . . . . . . . . . . . . . . . . . . . . . 30 6.6. No Information
6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 30 6.7. No Space
6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 30 6.8. Fatal Error
6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 6.9. CCNinfo Reply Timeout
6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 31 6.10. Non-Supported Node
6.11. Administratively Prohibited . . . . . . . . . . . . . . . 31 6.11. Administratively Prohibited
7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 31 7. Configurations
7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 7.1. CCNinfo Reply Timeout
7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 31 7.2. HopLimit in Fixed Header
7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 31 7.3. Access Control
8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 31 8. Diagnosis and Analysis
8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 32 8.1. Number of Hops and RTT
8.2. Caching Router Identification . . . . . . . . . . . . . . 32 8.2. Caching Router Identification
8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 32 8.3. TTL or Hop Limit
8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Time Delay
8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 32 8.5. Path Stretch
8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 32 8.6. Cache Hit Probability
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations
9.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33 9.1. Packet Type Registry
9.2. Top-Level Type Registry . . . . . . . . . . . . . . . . . 33 9.2. Top-Level Type Registry
9.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 33 9.3. Hop-by-Hop Type Registry
9.4. Message Type Registry . . . . . . . . . . . . . . . . . . 33 9.4. Message Type Registry
9.5. Reply Type Registry . . . . . . . . . . . . . . . . . . . 33 9.5. Reply Type Registry
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations
10.1. Policy-Based Information Provisioning for Request . . . 34 10.1. Policy-Based Information Provisioning for Request
10.2. Filtering CCNinfo Users Located in Invalid Networks . . 34 10.2. Filtering CCNinfo Users Located in Invalid Networks
10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 35 10.3. Topology Discovery
10.4. Characteristics of Content . . . . . . . . . . . . . . . 35 10.4. Characteristics of Content
10.5. Computational Attacks . . . . . . . . . . . . . . . . . 35 10.5. Computational Attacks
10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 35 10.6. Longer or Shorter CCNinfo Reply Timeout
10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 36 10.7. Limiting Request Rates
10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 36 10.8. Limiting Reply Rates
10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 36 10.9. Adjacency Verification
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. ccninfo Command and Options
Appendix A. ccninfo Command and Options . . . . . . . . . . . . 38 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses
1. Introduction 1. Introduction
In Content-Centric Networks (CCN), publishers provide the content In Content-Centric Networks (CCNs), 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.
In CCN, while consumers do not generally need to know the content In CCN, while consumers do not generally need to know the content
forwarder that is transmitting the content to them, the operators and forwarder that is transmitting the content to them, the operators and
developers may want to identify the content forwarder and observe the developers may want to identify the content forwarder and observe the
routing path information per name prefix for troubleshooting or routing path information per name prefix for troubleshooting or
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 the destination, and the Round-
Time (RTT) for the path. However, this IP-based network tool cannot Trip Time (RTT) for the path. However, this IP-based network tool
trace the name prefix paths used in CCN. Moreover, such IP-based cannot trace the name prefix paths used in CCN. Moreover, such IP-
network tools do not obtain the states of the in-network cache to be based network tools do not obtain the states of the in-network cache
discovered. to be discovered.
Contrace [7] enables end users (i.e., consumers) to investigate path Contrace [Contrace] enables end users (i.e., consumers) to
and in-network cache conditions in CCN. Contrace is implemented as investigate path and in-network cache conditions in CCN. Contrace is
an external daemon process running over TCP/IP that can interact with implemented as an external daemon process running over TCP/IP that
a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to
caching information on the forwarding daemon. This solution is retrieve the caching information on the forwarding daemon. This
flexible, but it requires defining the common APIs used for global solution is flexible, but it requires defining the common APIs used
deployment in TCP/IP networks. ICN ping [8] and traceroute [9] are for global deployment in TCP/IP networks. ICN (Information-Centric
Networking) ping [ICN-PING] and traceroute [ICN-TRACEROUTE] 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 expose detailed information ICN ping and traceroute, however, do not expose 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 [RFC8609]. The Request-and-Reply message flow,
tree from a consumer toward a publisher, is similar to the behavior walking up the tree from a consumer toward a publisher, is similar to
of the IP multicast traceroute facility [10]. the behavior of the IP multicast traceroute facility [RFC8487].
CCNinfo facilitates the tracing of a routing path and provides: 1) CCNinfo facilitates the tracing of a routing path and provides 1) the
the RTT between the content forwarder (i.e., caching router or first- RTT between the content forwarder (i.e., caching router or first-hop
hop router) and consumer, 2) the states of the in-network cache per router) and consumer, 2) the states of the in-network cache per name
name prefix, and 3) the routing path information per name prefix. 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) metrics for Content Store (CS) in the content forwarder as follows:
size of cached content objects, 2) number of cached content objects, 1) size of cached Content Objects, 2) number of cached Content
3) number of accesses (i.e., received Interests) per content, and 4) Objects, 3) number of accesses (i.e., received Interests) per
elapsed cache time and remaining cache lifetime of content. content, and 4) elapsed cache time and remaining cache lifetime of
content.
CCNinfo supports multipath forwarding. The Request messages can be CCNinfo supports multipath forwarding. The Request messages can be
forwarded to multiple neighbor routers. When the Request messages forwarded to multiple neighbor routers. When the Request messages
are forwarded to multiple routers, the different Reply messages are are forwarded to multiple routers, the different Reply messages are
forwarded from different routers or publishers. forwarded from different routers or publishers.
Furthermore, CCNinfo implements policy-based information provisioning Furthermore, CCNinfo implements policy-based information provisioning
that enables administrators to "hide" secure or private information that enables administrators to "hide" secure or private information
but does not disrupt message forwarding. This policy-based but does not disrupt message forwarding. This policy-based
information provisioning reduces the deployment barrier faced by information provisioning reduces the deployment barrier faced by
skipping to change at page 5, line 44 skipping to change at line 236
CCNinfo is intended as a comprehensive experimental tool for CCNx- CCNinfo is intended as a comprehensive experimental tool for CCNx-
based networks. It provides a wealth of information from forwarders, based networks. It provides a wealth of information from forwarders,
including on-path in-network cache conditions as well as forwarding including on-path in-network cache conditions as well as forwarding
path instrumentation of multiple paths toward content forwarders. As path instrumentation of multiple paths toward content forwarders. As
an experimental capability that exposes detailed information about an experimental capability that exposes detailed information about
the forwarders deployed by a network operator, CCNinfo employs more the forwarders deployed by a network operator, CCNinfo employs more
granular authorization policies than those required of ICN ping or granular authorization policies than those required of ICN ping or
ICN traceroute. ICN traceroute.
CCNinfo uses two message types: Request and Reply. A CCNinfo user, CCNinfo uses two message types: Request and Reply. A CCNinfo user,
e.g., consumer, initiates a CCNinfo Request message when s/he wants e.g., consumer, initiates a CCNinfo Request message when they want to
to obtain routing path and cache information. When an adjacent obtain routing path and cache information. When an adjacent neighbor
neighbor router receives the Request message, it examines its own router receives the Request message, it examines its own cache
cache information. If the router does not cache the specified information. If the router does not cache the specified content, it
content, it inserts its Report block into the hop-by-hop header of inserts its Report block into the hop-by-hop header of the Request
the Request message and forwards the message to its upstream neighbor message and forwards the message to its upstream neighbor router(s)
router(s) decided by its FIB. In Figure 1, CCNinfo user and routers decided by its FIB. In Figure 1, CCNinfo user and routers (Routers
(Router A, B, C) insert their own Report blocks into the Request A, B, C) insert their own Report blocks into the Request message and
message and forward the message toward the content forwarder. 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 message invoked by CCNinfo user and forwarded Figure 1: Request Message Invoked by the CCNinfo User and
by routers. Forwarded by Routers
When the Request message reaches the content forwarder, the content When the Request message reaches the content forwarder, the content
forwarder forms the Reply message; it inserts its own Reply block TLV 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 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 is then forwarded back toward the user in a hop-by-hop manner along
the Pending Interest Table (PIT) entries. In Figure 2, each router the Pending Interest Table (PIT) entries. In Figure 2, each router
(Router C, B, and A) forwards the Reply message along its PIT entry (Routers C, B, and A) forwards the Reply message along its PIT entry,
and finally, the CCNinfo user receives a Reply message from Router C, and finally, the CCNinfo user receives a Reply message from Router C,
which is the first-hop router for the Publisher. Another Reply which is the first-hop router for the publisher. Another Reply
message from the Caching router (i.e., Reply(C)) is discarded at 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 Router B if the other Reply message (i.e., Reply(P)) was already
forwarded by Router B. 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: Reply messages forwarded by routers, and one Reply Figure 2: Reply Messages Forwarded by Routers, and One Reply
message is received by CCNinfo user. Message is Received by the CCNinfo User
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
14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
all capitals, as shown here. 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 [RFC8609]. Although CCNinfo requests flow in the
direction to the data flow, we refer to "upstream" and "downstream" opposite direction to the data flow, we refer to "upstream" and
with respect to data, unless explicitly specified. "downstream" with respect to data, unless explicitly specified.
Scheme name Scheme name:
It indicates a URI and protocol. This document only considers A scheme name indicates a URI and protocol. This document only
"ccnx:/" as the scheme name. considers "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 [RFC8569], is a name that does
uniquely identify a single content object, but rather a namespace not uniquely identify a single Content Object, but rather a
or prefix of an existing content object name. namespace 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 [RFC8569], is one that uniquely
identifies the name of a content object. identifies the name of a Content Object.
Node Node:
A node within a CCN network can fulfill the role of a data A node within a CCN network can fulfill the role of a data
publisher, a data consumer, and/or a forwarder for interest and publisher, a data consumer, and/or a forwarder for Interest and
content object as given in [6]. Content Object, as described in [RFC8793].
Consumer Consumer:
A node that requests content objects by generating and sending out A node that requests Content Objects by generating and sending out
interests. It is a same definition of ICN Consumer as given in Interests. It is the same definition of ICN Consumer, as given in
[6]. [RFC8793].
Publisher Publisher:
A node that creates content objects and makes them available for A node that creates Content Objects and makes them available for
retrieval. It is a same definition of ICN Producer as given in retrieval. It is the same definition of ICN Producer, as given in
[6]. [RFC8793].
Router Router:
A node that implements stateful forwarding in the path between A node that implements stateful forwarding in the path between
consumer and publisher. consumer and publisher.
Caching router Caching router:
A node that temporarily stores and potentially carries interests A node that temporarily stores and potentially carries Interests
or content objects before forwarding it to next node. or Content Objects before forwarding it to the next node.
Content forwarder Content forwarder:
It is either a caching router or a first-hop router that forwards A content forwarder is either a caching router or a first-hop
content objects to consumers. router that forwards Content Objects to consumers.
CCNinfo user CCNinfo user:
A node that initiates the CCNinfo Request, which is consumer or A node that initiates the CCNinfo Request, which is either a
router that invokes the CCNinfo user program with the name prefix consumer or a router that invokes the CCNinfo user program with
of the content. The CCNinfo user program, such as "ccninfo" the name prefix of the content. The CCNinfo user program, such as
command described in Appendix A or other similar commands, "ccninfo" command described in Appendix A or other similar
initiates the Request message to obtain routing path and cache commands, initiates the Request message to obtain routing path and
information. 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 is received.
Upstream router Upstream router:
The router that connects to an Incoming face of a router. The router that connects to an Incoming face of a router.
Downstream router Downstream router:
The router that connects to an Outgoing face of a router. The router that connects to an Outgoing face of a router.
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 Request and Reply messages are encoded in the CCNx TLV format CCNinfo Request and Reply messages are encoded in the CCNx TLV format
([1], Figure 3). The Request message consists of a fixed header, (see [RFC8609] and Figure 3). The Request message consists of a
Request block TLV (Figure 7), and Report block TLV(s) (Figure 12). fixed header, Request block TLV (Figure 5), and Report block TLV(s)
The Reply message consists of a fixed header, Request block TLV, (Figure 7). The Reply message consists of a fixed header, Request
Report block TLV(s), Reply block TLV (Figure 14), and Reply sub-block block TLV, Report block TLV(s), Reply block TLV (Figure 9), and Reply
TLV(s) (Figure 15). sub-block TLV(s) (Figure 10).
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 [RFC8609]
The PacketType values in the fixed header shown in Figure 3 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 (see Table 1). CCNinfo
CCNinfo Request and Reply messages are forwarded in a hop-by-hop Request and Reply messages are forwarded in a hop-by-hop manner.
manner. When the Request message reaches the content forwarder, the When the Request message reaches the content forwarder, the content
content forwarder turns it into a Reply message by changing the Type forwarder turns it into a Reply message by changing the Type field
field value in the fixed header from PT_CCNINFO_REQUEST to value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY
PT_CCNINFO_REPLY and forwards it back toward the node that initiated and forwards it back toward the node that initiated the Request
the Request message. message.
Code Type name +======+=======================+
======== ===================== | Type | Name |
%x00 PT_INTEREST [1] +======+=======================+
%x01 PT_CONTENT [1] | 0x00 | PT_INTEREST [RFC8609] |
%x02 PT_RETURN [1] +------+-----------------------+
%x03 PT_CCNINFO_REQUEST | 0x01 | PT_CONTENT [RFC8609] |
%x04 PT_CCNINFO_REPLY +------+-----------------------+
| 0x02 | PT_RETURN [RFC8609] |
+------+-----------------------+
| 0x03 | PT_CCNINFO_REQUEST |
+------+-----------------------+
| 0x04 | PT_CCNINFO_REPLY |
+------+-----------------------+
Figure 4: Packet Type Namespace Table 1: CCNx Packet Types
Following a fixed header, there can be a sequence of optional hop-by- Following a fixed header, there can be a sequence of optional hop-by-
hop header TLV(s) for a Request message. In the case of a Request hop header TLV(s) for a Request message. In the case of a Request
message, it is followed by a sequence of Report blocks, each from a message, it is followed by a sequence of Report blocks, each from a
router on the path toward the publisher or caching router. 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 (Table 2), 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 +========+================================+
============= ========================= | Type | Name |
%x0000 Reserved [1] +========+================================+
%x0001 T_INTEREST [1] | 0x0000 | Reserved [RFC8609] |
%x0002 T_OBJECT [1] +--------+--------------------------------+
%x0003 T_VALIDATION_ALG [1] | 0x0001 | T_INTEREST [RFC8609] |
%x0004 T_VALIDATION_PAYLOAD [1] +--------+--------------------------------+
%x0005 T_DISCOVERY | 0x0002 | T_OBJECT [RFC8609] |
+--------+--------------------------------+
| 0x0003 | T_VALIDATION_ALG [RFC8609] |
+--------+--------------------------------+
| 0x0004 | T_VALIDATION_PAYLOAD [RFC8609] |
+--------+--------------------------------+
| 0x0005 | T_DISCOVERY |
+--------+--------------------------------+
Figure 5: Top-Level Type Namespace Table 2: CCNx Top-Level Types
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 4. It consists of a
fixed header, Request header block TLV (Figure 7), Report block fixed header, Request header block TLV (Figure 5), Report block
TLV(s) (Figure 12), Name TLV, and Request block TLV. Request header TLV(s) (Figure 7), Name TLV, and Request block TLV. Request header
block TLV and Report block TLV(s) are contained in the hop-by-hop block TLV and Report block TLV(s) are contained in the hop-by-hop
header, as those might change from hop to hop. Request block TLV is header, as those might change from hop to hop. Request block TLV is
encoded in the PacketPayload TLV by content forwarder as the protocol encoded in the PacketPayload TLV by content forwarder as the protocol
message itself. The PacketType value of the Request message is message itself. The PacketType value of the Request message is
PT_CCNINFO_REQUEST (Figure 4). The Type value of the Top-Level type PT_CCNINFO_REQUEST (Table 1). The Type value of the CCNx Top-Level
namespace is T_DISCOVERY (Figure 5). type is T_DISCOVERY (Table 2).
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 36 skipping to change at line 510
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ 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) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 6: Request message consists of a fixed header, Request Figure 4: Request Message
block TLV, Report block TLV(s), and Name TLV
HopLimit: 8 bits HopLimit: 8 bits
HopLimit is a counter that is decremented with each hop whenever a HopLimit is a counter that is decremented with each hop whenever a
Request packet is forwarded. It is specified by the CCNinfo user Request packet is forwarded. It is specified by the CCNinfo user
program. The HopLimit value MUST be decremented by 1 prior to program. The HopLimit value MUST be decremented by 1 prior to
forwarding the Request packet. The packet is discarded if forwarding the Request packet. The packet is discarded if
HopLimit is decremented to zero. HopLimit limits the distance HopLimit is decremented to zero. HopLimit limits the distance
that a Request may travel on the network. Only the specified that a Request may travel on the network. Only the specified
number of hops from the CCNinfo user traces the Request. The last number of hops from the CCNinfo user traces the Request. The last
router stops the trace and sends the Reply message back to the router stops the trace and sends the Reply message back to the
CCNinfo user. CCNinfo user.
ReturnCode: 8 bits ReturnCode: 8 bits
ReturnCode is used for the Reply message. This value is replaced ReturnCode is used for the Reply message. This value is replaced
by the content forwarder when the Request message is returned as by the content forwarder when the Request message is returned as
the Reply message (see Section 3.2). Until then, this field MUST the Reply message (see Section 3.2). Until then, this field MUST
be transmitted as zeros and ignored on receipt. be transmitted as zeros and ignored on receipt.
Value Name Description +=======+=================+================================+
----- --------------- ---------------------------------------------- | Value | Name | Description |
%x00 NO_ERROR No error +=======+=================+================================+
%x01 WRONG_IF CCNinfo Request arrived on an interface | 0x00 | NO_ERROR | No error |
to which this router would not forward for +-------+-----------------+--------------------------------+
the specified name/function toward the | 0x01 | WRONG_IF | CCNinfo Request arrived on an |
publisher. | | | interface to which this router |
%x02 INVALID_REQUEST Invalid CCNinfo Request is received. | | | would not forward for the |
%x03 NO_ROUTE This router has no route for the name prefix | | | specified name and/or function |
and no way to determine a route. | | | toward the publisher. |
%x04 NO_INFO This router has no cache information for the +-------+-----------------+--------------------------------+
specified name prefix. | 0x02 | INVALID_REQUEST | Invalid CCNinfo Request is |
%x05 NO_SPACE There was not enough room to insert another | | | received. |
Report block in the packet. +-------+-----------------+--------------------------------+
%x06 INFO_HIDDEN Information is hidden from this discovery | 0x03 | NO_ROUTE | This router has no route for |
owing to some policy. | | | the name prefix and no way to |
%x0E ADMIN_PROHIB CCNinfo Request is administratively | | | determine a route. |
prohibited. +-------+-----------------+--------------------------------+
%x0F UNKNOWN_REQUEST This router does not support/recognize the | 0x04 | NO_INFO | This router has no cache |
Request message. | | | information for the specified |
%x80 FATAL_ERROR In a fatal error, the router may know the | | | name prefix. |
upstream router but cannot forward the +-------+-----------------+--------------------------------+
message to it. | 0x05 | NO_SPACE | There was not enough room to |
| | | insert another Report block in |
| | | the packet. |
+-------+-----------------+--------------------------------+
| 0x06 | INFO_HIDDEN | Information is hidden from |
| | | this discovery owing to some |
| | | policy. |
+-------+-----------------+--------------------------------+
| 0x0E | ADMIN_PROHIB | CCNinfo Request is |
| | | administratively prohibited. |
+-------+-----------------+--------------------------------+
| 0x0F | UNKNOWN_REQUEST | This router does not support |
| | | or recognize the Request |
| | | message. |
+-------+-----------------+--------------------------------+
| 0x80 | FATAL_ERROR | In a fatal error, the router |
| | | may know the upstream router |
| | | but cannot forward the message |
| | | to it. |
+-------+-----------------+--------------------------------+
Reserved (MBZ): 8 bits Table 3: ReturnCode Used for the Reply Message
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, they MUST insert
her/his Request header block TLV (Figure 7) into the hop-by-hop their Request header block TLV (Figure 5) into the hop-by-hop header
header and Request block TLV (Figure 10) into the message before and Request block TLV (Figure 6) into the message before sending it
sending it through the Incoming face(s). 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|
+---------------+---------------+-------+-------+-------+-+-+-+-+ +---------------+---------------+-------+-------+-------+-+-+-+-+
Figure 7: Request header block TLV (hop-by-hop header)
Code Type name Figure 5: Request Header Block TLV (Hop-by-Hop Header)
============= =========================
%x0000 Reserved [1]
%x0001 T_INTLIFE [1]
%x0002 T_CACHETIME [1]
%x0003 T_MSGHASH [1]
%x0004-%x0007 Reserved [1]
%x0008 T_DISC_REQHDR
%x0009 T_DISC_REPORT
%x0FFE T_PAD [1]
%x0FFF T_ORG [1]
%x1000-%x1FFF Reserved [1]
Figure 8: Hop-by-Hop Type Namespace +===============+=======================+
| Type | Name |
+===============+=======================+
| 0x0000 | Reserved [RFC8609] |
+---------------+-----------------------+
| 0x0001 | T_INTLIFE [RFC8609] |
+---------------+-----------------------+
| 0x0002 | T_CACHETIME [RFC8609] |
+---------------+-----------------------+
| 0x0003 | T_MSGHASH [RFC8609] |
+---------------+-----------------------+
| 0x0004-0x0007 | Reserved [RFC8609] |
+---------------+-----------------------+
| 0x0008 | T_DISC_REQHDR |
+---------------+-----------------------+
| 0x0009 | T_DISC_REPORT |
+---------------+-----------------------+
| 0x0FFE | T_PAD [RFC8609] |
+---------------+-----------------------+
| 0x0FFF | T_ORG [RFC8609] |
+---------------+-----------------------+
| 0x1000-0x1FFF | Reserved [RFC8609] |
+---------------+-----------------------+
Type: 16 bits Table 4: CCNx Hop-by-Hop Types
Format of the Value field. For the type value of the Request Type: 16 bits
Format of the Value field. The type value of the Request header
block TLV MUST be T_DISC_REQHDR. block TLV MUST be T_DISC_REQHDR.
Length: 16 bits Length: 16 bits
Length of Value field in octets. Length of the 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. The number of routers corresponding to the CCNinfo user program. The number of routers corresponding to the
value 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 Table 5, four bits ("C",
"C", "O", "F", and "V" are assigned, and the other 8 bits are "O", "F", and "V") are assigned, and the other 8 bits are reserved
reserved (MBZ) for the future use. Each flag can be mutually (MBZ) for the future use. Each flag can be mutually specified
specified with other flags. These flags are set by the CCNinfo with other flags. These flags are set by the CCNinfo user program
user program when they initiate Requests (see Appendix A), and the when they initiate Requests (see Appendix A), and the routers that
routers that receive the Requests deal with the flags and change receive the Requests deal with the flags and change the behaviors
the behaviors (see Section 5 for details). The Flag values (see Section 5 for details). The Flag values defined in this
defined in this Flags field correspond to the Reply sub-blocks. Flags field correspond to the Reply sub-blocks.
Flag Value Description +======+=======+=====================================+
----- ----- ----------------------------------------------------- | Flag | Value | Description |
C 0 Path discovery (i.e., no cache information retrieved) +======+=======+=====================================+
(default) | C | 0 | Path discovery (i.e., no cache |
C 1 Path and cache information retrieval | | | information retrieved) (default) |
O 0 Request to any content forwarder (default) +------+-------+-------------------------------------+
O 1 Publisher discovery (i.e., only FHR can reply) | C | 1 | Path and cache information |
F 0 Request based on FIB's forwarding strategy (default) | | | retrieval |
F 1 Full discovery request. Request to possible multiple +------+-------+-------------------------------------+
upstream routers specified in FIB simultaneously | O | 0 | Request to any content forwarder |
V 0 No reply validation (default) | | | (default) |
V 1 Reply sender validates Reply message +------+-------+-------------------------------------+
| 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 |
+------+-------+-------------------------------------+
Figure 9: Codes and types specified in Flags field Table 5: 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Type (=T_DISC_REQ) | Length | | Type (=T_DISC_REQ) | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Request Arrival Time | | Request Arrival Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Node Identifier / / Node Identifier /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 10: Request block TLV (packet payload) Figure 6: Request Block TLV (Packet Payload)
Code Type name +===============+==========================+
============== =================== | Type | Name |
%x0000 T_NAME [1] +===============+==========================+
%x0001 T_PAYLOAD [1] | 0x0000 | T_NAME [RFC8609] |
%x0002 T_KEYIDRESTR [1] +---------------+--------------------------+
%x0003 T_OBJHASHRESTR [1] | 0x0001 | T_PAYLOAD [RFC8609] |
%x0005 T_PAYLDTYPE [1] +---------------+--------------------------+
%x0006 T_EXPIRY [1] | 0x0002 | T_KEYIDRESTR [RFC8609] |
%x0007-%x000C Reserved [1] +---------------+--------------------------+
%x000D T_DISC_REQ | 0x0003 | T_OBJHASHRESTR [RFC8609] |
%x000E T_DISC_REPLY +---------------+--------------------------+
%x0FFE T_PAD [1] | 0x0005 | T_PAYLDTYPE [RFC8609] |
%x0FFF T_ORG [1] +---------------+--------------------------+
%x1000-%x1FFF Reserved [1] | 0x0006 | T_EXPIRY [RFC8609] |
+---------------+--------------------------+
| 0x0007-0x000C | Reserved [RFC8609] |
+---------------+--------------------------+
| 0x000D | T_DISC_REQ |
+---------------+--------------------------+
| 0x000E | T_DISC_REPLY |
+---------------+--------------------------+
| 0x0FFE | T_PAD [RFC8609] |
+---------------+--------------------------+
| 0x0FFF | T_ORG [RFC8609] |
+---------------+--------------------------+
| 0x1000-0x1FFF | Reserved [RFC8609] |
+---------------+--------------------------+
Figure 11: CCNx Message Type Namespace Table 6: CCNx Message Types
Type: 16 bits Type: 16 bits
Format of the Value field. For the Request block TLV, the type Format of the Value field. For the Request block TLV, the type
value(s) MUST be T_DISC_REQ (see Figure 11) in the current value(s) MUST be T_DISC_REQ (see Table 6) in the current
specification. specification.
Length: 16 bits Length: 16 bits
Length of Value field in octets. Length of the 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 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.
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 the 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 [11]) or all-zeros if unknown. This based self-certifying name [DCAuth]) or all-zeros if unknown.
document assumes that the Name TLV defined in the CCNx TLV format This document assumes that the Name TLV defined in the CCNx TLV
[1] can be used for this field and the node identifier is format [RFC8609] can be used for this field and the node
specified in it. identifier is 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 7), the
Request Arrival Time and Node Identifier MUST be inserted. Request Arrival Time and Node Identifier values MUST be inserted.
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 /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 12: Report block TLV (hop-by-hop header) Figure 7: Report Block TLV (Hop-by-Hop Header)
Type: 16 bits Type: 16 bits
Format of the Value field. For the Report block TLV, the type Format of the Value field. For the Report block TLV, the type
value(s) MUST be T_DISC_REPORT in the current specification. For value(s) MUST be T_DISC_REPORT in the current specification. For
all the available types for hop-by-hop type namespace, please see all the available types of the CCNx hop-by-hop types, please see
Figure 8. Table 4.
Length: 16 bits Length: 16 bits
Length of Value field in octets. Length of the Value field in octets.
Request Arrival Time: 32 bits Request Arrival Time: 32 bits
Same definition as given in Section 3.1.1. Same definition as given in Section 3.1.1.
Node Identifier: variable length Node Identifier: variable length
Same definition as given in Section 3.1.1. Same definition as given in Section 3.1.1.
3.1.3. Content Name Specification 3.1.3. Content Name Specification
Specifications of the Name TLV (whose type value is T_NAME) and the Specifications of the Name TLV (whose type value is T_NAME) and the
Name Segment TLVs are described in [1], which are followed by Name Segment TLVs are described in [RFC8609], which is followed by
CCNinfo. CCNinfo enables to specification of the content name either CCNinfo. CCNinfo enables the specification of the content name with
with a prefix name without chunk number (such as "ccnx:/news/today") either a prefix name without chunk number (such as "ccnx:/news/
or an exact name (such as "ccnx:/news/today/Chunk=10"). When a today") or an exact name (such as "ccnx:/news/today/Chunk=10"). When
CCNinfo user specifies a prefix name, s/he will obtain the summary a CCNinfo user specifies a prefix name, they will obtain the summary
information of the matched content objects in the content forwarder. information of the matched Content Objects in the content forwarder.
In contrast, when a CCNinfo user specifies an exact name, they will
In contrast, when a CCNinfo user specifies an exact name, s/he will obtain information only about the specified Content Object in the
obtain only about the specified content object in the content content forwarder. A CCNinfo Request message MUST NOT be sent only
forwarder. A CCNinfo Request message MUST NOT be sent only with a with a scheme name, ccnx:/. It will be rejected and discarded by
scheme name, ccnx:/. It will be rejected and discarded by routers. routers.
3.2. Reply Message 3.2. Reply Message
When a content forwarder receives a CCNinfo Request message from an When a content forwarder receives a CCNinfo Request message from an
appropriate adjacent neighbor router, it inserts its own Reply block appropriate adjacent neighbor router, it inserts its own Reply block
TLV and Reply sub-block TLV(s) to the Request message and turns the TLV and Reply sub-block TLV(s) to the Request message and turns the
Request into the Reply by changing the Type field of the fixed header Request into the Reply by changing the Type field of the fixed header
of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY.
The Reply message (see Figure 13) is then forwarded back toward the The Reply message (see Figure 8) is then forwarded back toward the
CCNinfo user in a hop-by-hop manner. CCNinfo user in a hop-by-hop manner.
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 18, line 42 skipping to change at line 875
/ . / / . /
/ . / / . /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ 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) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 13: Reply message consists of a fixed header, Request Figure 8: Reply Message
block TLV, Report block TLV(s), Name TLV, and Reply block/sub-
block TLV(s)
3.2.1. Reply Block TLV 3.2.1. Reply Block TLV
The Reply block TLV is an envelope for the Reply sub-block TLV(s) The Reply block TLV is an envelope for the Reply sub-block TLV(s)
(explained from the next section). (explained in the next section).
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 /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 14: Reply block TLV (packet payload) Figure 9: Reply Block TLV (Packet Payload)
Type: 16 bits Type: 16 bits
Format of the Value field. For the Reply block TLV, the type Format of the Value field. For the Reply block TLV, the type
value MUST be T_DISC_REPLY shown in Figure 11 in the current value MUST be T_DISC_REPLY shown in Table 6 in the current
specification. specification.
Length: 16 bits Length: 16 bits
Length of the Value field in octets. This length is the total Length of the Value field in octets. This length is the total
length of Reply sub-block(s). length of the Reply sub-block(s).
Request Arrival Time: 32 bits Request Arrival Time: 32 bits
Same definition as given in Section 3.1.1. Same definition as given in Section 3.1.1.
Node Identifier: variable length Node Identifier: variable length
Same definition as given in Section 3.1.1. Same definition as given in Section 3.1.1.
3.2.1.1. Reply Sub-Block TLV 3.2.1.1. Reply Sub-Block TLV
The router on the traced path will add one or multiple Reply sub- 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 blocks followed by the Reply block TLV before sending the Reply to
its neighbor router. This section describes the Reply sub-block TLV its neighbor router. This section describes the Reply sub-block TLV
for informing various cache states and conditions as shown in for informing various cache states and conditions as shown in
Figure 15. (Other Reply sub-block TLVs will be discussed in separate Figure 10. (Other Reply sub-block TLVs will be discussed in separate
document(s).) document(s).)
Note that some routers may not be capable of reporting the following Note that some routers may not be capable of reporting the following
values, such as Object Size, Object Count, # Received Interest, First values: Object Size, Object Count, # Received Interest, First Seqnum,
Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime (shown in
shown in Figure 15, or do not report these values due to their Figure 10). Or, some routers do not report these values due to their
policy. In that case, the routers set these fields to a value of all policy. In that case, the routers MUST set these fields to a value
ones (i.e., %xFFFFFFFF). The value of each field will be also all- of all ones (i.e., 0xFFFFFFFF). The value of each field MUST be also
one when the value is equal to or bigger than the maximum size all-one when the value is equal to or bigger than the maximum size
expressed by the 32-bit field. The CCNinfo user program MUST inform expressed by the 32-bit field. The CCNinfo user program MUST inform
that these values are not valid if the fields received are set to the that these values are not valid if the fields received are set to the
value of all ones. value of all ones.
If the cache is refreshed after reboot, the value in each field MUST If the cache is refreshed after reboot, the value in each field MUST
be refreshed (i.e., MUST be set to 0). If the cache remains after be refreshed (i.e., MUST be set to 0). If the cache remains after
reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as
it is). it is).
1 2 3 1 2 3
skipping to change at page 20, line 44 skipping to change at line 962
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Elapsed Cache Time | | Elapsed Cache Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Remain Cache Lifetime | | Remain Cache Lifetime |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name Segment TLVs / / Name Segment TLVs /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 15: Reply sub-block TLV for T_DISC_CONTENT and Figure 10: Reply Sub-Block TLV for T_DISC_CONTENT and
T_DISC_CONTENT_PUBLISHER (packet payload) T_DISC_CONTENT_PUBLISHER (Packet Payload)
Code Type name
============= ===========================
%x0000 T_DISC_CONTENT
%x0001 T_DISC_CONTENT_PUBLISHER
%x0FFF T_ORG
%x1000-%x1FFF Reserved (Experimental Use)
Figure 16: CCNinfo Reply Type Namespace +===============+===============================+
| Type | Name |
+===============+===============================+
| 0x0000 | T_DISC_CONTENT |
+---------------+-------------------------------+
| 0x0001 | T_DISC_CONTENT_PUBLISHER |
+---------------+-------------------------------+
| 0x0FFF | T_ORG |
+---------------+-------------------------------+
| 0x1000-0x1FFF | Reserved for Experimental Use |
+---------------+-------------------------------+
Type: 16 bits Table 7: CCNx Reply Types
Type: 16 bits
Format of the Value field. For the Reply sub-block TLV, the type Format of the Value field. For the Reply sub-block TLV, the type
value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER
defined in the CCNinfo Reply Type Namespace (Figure 16). defined in the CCNx Reply Types (Table 7). T_DISC_CONTENT is
T_DISC_CONTENT is specified when the cache information is replied specified when a content forwarder replies with the cache
from a caching router. T_DISC_CONTENT_PUBLISHER is specified when information. T_DISC_CONTENT_PUBLISHER is specified when a FHR
the content information is replied from a FHR attached to a attached to a publisher replies with the original content
publisher. information.
Length: 16 bits Length: 16 bits
Length of the Value field in octets. Length of the Value field in octets.
Object Size: 32 bits Object Size: 32 bits
The total size (KB) of the unexpired content objects. Values less The total size (KB) of the unexpired Content Objects. Values less
than 1 KB are truncated. Note that the maximum size expressed by than 1 KB are truncated. Note that the maximum size expressed by
the 32-bit field is approximately 4.29 TB. the 32-bit field is approximately 4.29 TB.
Object Count: 32 bits Object Count: 32 bits
The number of the unexpired content objects. Note that the The number of the unexpired Content Objects. Note that the
maximum count expressed by the 32-bit field is approximately 4.29 maximum count expressed by the 32-bit field is approximately 4.29
billion. billion.
# Received Interest: 32 bits # Received Interest: 32 bits
The total number of the received Interest messages to retrieve the The total number of the received Interest messages to retrieve the
cached content objects. cached Content Objects.
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 [12]. as [CONSEC-CACHING].
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.
4. CCNinfo User Behavior 4. CCNinfo User Behavior
4.1. Sending CCNinfo Request 4.1. Sending CCNinfo Request
A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) 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 that initiates a CCNinfo Request message and sends it to the user's
adjacent neighbor router(s) of interest. The user later obtains both adjacent neighbor router(s) of interest. The user later obtains both
the routing path information and in-network cache information in the the routing path information and in-network cache information in the
single Reply. single Reply.
When the CCNinfo user program initiates a Request message, it MUST When the CCNinfo user program initiates a Request message, it MUST
insert the necessary values, i.e., the "Request ID" and the "Node insert the necessary values, i.e., the "Request ID" and the "Node
Identifier", in the Request block. The Request ID MUST be unique for Identifier", in the Request block. The Request ID MUST be unique for
the CCNinfo user until s/he receives the corresponding Reply the CCNinfo user until they receive the corresponding Reply
message(s) or the Request is timed out. message(s) or the Request is timed out.
Owing to some policies, a router may want to validate the CCNinfo Owing to some policies, a router may want to validate the CCNinfo
Requests using the CCNx ValidationPayload TLV (whether it accepts the Requests using the CCNx ValidationPayload TLV (whether it accepts the
Request or not) especially when the router receives the "full Request or not) especially when the router receives the "full
discovery request" (see Section 5.3.2). Accordingly, the CCNinfo discovery request" (see Section 5.3.2). Accordingly, the CCNinfo
user program MAY require validating the Request message and appending user program MAY require validating the Request message and appending
the user's signature into the CCNx ValidationPayload TLV. The router the user's signature into the CCNx ValidationPayload TLV. The router
then forwards the Request message. If the router does not approve then forwards the Request message. If the router does not approve
the Request, it rejects the Request message as described in the Request, it rejects the Request message as described in
Section 6.11. Section 6.11.
After the CCNinfo user program sends the Request message, until the After the CCNinfo user program sends the Request message, until the
Reply is timed out or the expected numbers of Replies or a Reply Reply is timed out or the expected numbers of Replies or a Reply
message with a non-zero ReturnCode in the fixed header is received, message with a non-zero ReturnCode in the fixed header is received,
the CCNinfo user program MUST keep the following information: the CCNinfo user program MUST keep the following information:
HopLimit, specified in the fixed header, Request ID, Flags, Node HopLimit (specified in the fixed header), Request ID and Flags
Identifier, and Request Arrival Time, specified in the Request block. (specified in the Request header block), and Node Identifier and
Request Arrival Time (specified in the Request block).
4.1.1. Routing Path Information 4.1.1. Routing Path Information
A CCNinfo user can send a CCNinfo Request for investigating the A CCNinfo user can send a CCNinfo Request for investigating the
routing path information for the specified named content. Using the routing path information for the specified named content. Using the
Request, a legitimate user can obtain 1) the node identifiers of the Request, a legitimate user can obtain 1) the node identifiers of the
intermediate routers, 2) node identifier of the content forwarder, 3) intermediate routers, 2) the node identifier of the content
number of hops between the content forwarder and consumer, and 4) RTT forwarder, 3) the number of hops between the content forwarder and
between the content forwarder and consumer, per name prefix. This the consumer, and 4) the RTT between the content forwarder and the
CCNinfo Request is terminated when it reaches the content forwarder. consumer, per name prefix. This CCNinfo Request is terminated when
it reaches the content forwarder.
4.1.2. In-Network Cache Information 4.1.2. In-Network Cache Information
A CCNinfo user can send a CCNinfo Request for investigating in- A CCNinfo user can send a CCNinfo Request for investigating in-
network cache information. Using the Request, a legitimate user can network cache information. Using the Request, a legitimate user can
obtain 1) the size of cached content objects, 2) number of cached obtain 1) the size of cached Content Objects, 2) the number of cached
content objects, 3) number of accesses (i.e., received Interests) per Content Objects, 3) the number of accesses (i.e., received Interests)
content, and 4) lifetime and expiration time of the cached content per content, and 4) the lifetime and expiration time of the cached
objects, for Content Store (CS) in the content forwarder, unless the Content Objects, for Content Store (CS) in the content forwarder,
content forwarder is capable of reporting them (see Section 3.2.1.1). unless the content forwarder is capable of reporting them (see
This CCNinfo Request is terminated when it reaches the content Section 3.2.1.1). This CCNinfo Request is terminated when it reaches
forwarder. the content forwarder.
4.2. Receiving CCNinfo Reply 4.2. Receiving CCNinfo Reply
A CCNinfo user program will receive one or multiple CCNinfo Reply A CCNinfo user program will receive one or multiple CCNinfo Reply
messages from the adjacent neighbor router(s). When the program messages from the adjacent neighbor router(s). When the program
receives the Reply, it MUST compare the kept Request ID and Node receives the Reply, it MUST compare the kept Request ID and Node
Identifier to identify the Request and Reply pair. If they do not Identifier values to identify the Request and Reply pair. If they do
match, the Reply message MUST be silently discarded. not match, the Reply message MUST be silently discarded.
If the number of Report blocks in the received Reply is more than the If the number of Report blocks in the received Reply is more than the
initial HopLimit value (which was inserted in the original Request), initial HopLimit value (which was inserted in the original Request),
the Reply MUST be silently ignored. the Reply MUST be silently ignored.
After the CCNinfo user has determined that s/he has traced the whole After the CCNinfo user has determined that they have traced the whole
path or the maximum path that s/he can be expected to, s/he might path or the maximum path that they can be expected to, they might
collect statistics by waiting for a timeout. Useful statistics collect statistics by waiting for a timeout. Useful statistics
provided by CCNinfo are stated in Section 8. provided by CCNinfo are stated in Section 8.
5. Router Behavior 5. Router Behavior
5.1. User and Neighbor Verification 5.1. User and Neighbor Verification
Upon receiving a CCNinfo Request message, a router MAY examine Upon receiving a CCNinfo Request message, a router MAY examine
whether a valid CCNinfo user has sent the message. If the router whether a valid CCNinfo user has sent the message. If the router
recognizes that the Request sender's signature specified in the recognizes that the Request sender's signature specified in the
Request is invalid, it SHOULD terminate the Request, as defined in Request is invalid, it SHOULD terminate the Request, as defined in
Section 6.4. Section 6.4.
Upon receiving a CCNinfo Request/Reply message, a router MAY examine Upon receiving a CCNinfo Request or Reply message, a router MAY
whether the message comes from a valid adjacent neighbor node. If examine whether the message comes from a valid adjacent neighbor
the router recognizes that the Request/Reply sender is invalid, it node. If the router recognizes that the Request or Reply sender is
SHOULD silently ignore the Request/Reply message, as specified in invalid, it SHOULD silently ignore the message, as specified in
Section 10.9. Section 10.9.
5.2. Receiving CCNinfo Request 5.2. Receiving CCNinfo Request
After a router accepts the CCNinfo Request message, it performs the After a router accepts the CCNinfo Request message, it performs the
following steps. following steps.
1. The value of "HopLimit" in the fixed header and that of "SkipHop 1. The value of "HopLimit" in the fixed header and the value of
(Skip Hop Count)" in the Request block are counters that are "SkipHop (Skip Hop Count)" in the Request block are counters that
decremented with each hop. If the HopLimit value is zero, the are decremented with each hop. If the HopLimit value is zero,
router terminates the Request, as defined in Section 6.5. If the the router terminates the Request, as defined in Section 6.5. If
SkipHop value is equal to or more than the HopLimit value, the the SkipHop value is equal to or more than the HopLimit value,
router terminates the Request, as defined in Section 6.4. the router terminates the Request, as defined in Section 6.4;
Otherwise, until the SkipHop value becomes zero, the router otherwise, until the SkipHop value becomes zero, the router
forwards the Request message to the upstream router(s) without forwards the Request message to the upstream router(s) without
adding its own Report block and without replying to the Request. adding its own Report block and without replying to the Request.
If the router does not know the upstream router(s) regarding the If the router does not know the upstream router(s) regarding the
specified name prefix, it terminates the Request, as defined in specified name prefix, it terminates the Request, as defined in
Section 6.5. It should be noted that the Request messages are Section 6.5. It should be noted that the Request messages are
terminated at the FHR; therefore, although the maximum value for terminated at the FHR; therefore, although the maximum value for
the HopLimit is 255 and that for SkipHop is 15, if the Request the HopLimit is 255 and that for SkipHop is 15, if the Request
messages reach the FHR before the HopLimit or SkipHop value messages reach the FHR before the HopLimit or SkipHop value
becomes 0, the FHR silently discards the Request message and the becomes 0, the FHR silently discards the Request message and the
Request is timed out. Request is timed out.
2. The router examines the Flags field (specified in Figure 9) in 2. The router examines the Flags field (specified in Table 5) in the
the Request block of the received CCNinfo Request. If the "C" Request block of the received CCNinfo Request. If the "C" flag
flag is not set, it is categorized as the "routing path is not set, it is categorized as the "routing path information
information discovery". If the "C" flag is set, it is the "cache discovery". If the "C" flag is set, it is the "cache information
information discovery". If the "O" flag is set, it is the discovery". If the "O" flag is set, it is the "publisher
"publisher discovery". 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 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, inserts its own Report block in
block in the hop-by-hop header and forwards the Request to the the hop-by-hop header, and forwards the Request to the upstream
upstream neighbor(s). If the router cannot insert its own Report neighbor(s). If the router cannot insert its own Report block
block because of no space, or if the router does not cache the 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.
4. If the Request is the "publisher discovery", the router examines 4. If the Request is the "publisher discovery", the router examines
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, inserts its own Report block, and forwards the Request
Request to the upstream neighbor(s). If the router cannot insert to the upstream neighbor(s). If the router cannot insert its own
its own Report block in the hop-by-hop header because of no Report block in the hop-by-hop header because of no space, it
space, it terminates the Request, as specified in Section 6.7. terminates the Request, as specified in Section 6.7. If the
If the router is not the FHR and does not know the upstream router is not the FHR and does not know the upstream neighbor
neighbor router(s) for the specified name prefix, it terminates router(s) for the specified name prefix, it terminates the
the Request, as defined in Section 6.5. Note that in Cefore Request, as defined in Section 6.5. Note that in Cefore
[14], there is an API by which a publisher informs the [Cefore-site], 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
Time and Node Identifier in the Report block of the Request message. Time and Node Identifier values in the Report block of the Request
The router then forwards the Request message upstream toward the message. The router then forwards the Request message upstream
publisher or caching router based on the FIB entry like the ordinary toward the publisher or caching router based on the FIB entry like
Interest-Data exchanges in CCN. the ordinary Interest-Data exchanges in CCN.
When the router forwards the Request message, it MUST record the F When the router forwards the Request message, it MUST record the F
flag and Request ID in the Request block of the Request message and flag and Request ID in the Request block of the Request message and
exploiting path labels (specified in Section 1) at the corresponding exploiting path labels (specified in Section 1) at the corresponding
PIT entry. The router can later check the PIT entry to correctly PIT entry. The router can later check the PIT entry to correctly
forward the Reply message(s) back. forward the Reply message(s) back.
CCNinfo supports multipath forwarding. The Request messages can be CCNinfo supports multipath forwarding. The Request messages can be
forwarded to multiple neighbor routers. Some routers may have a forwarded to multiple neighbor routers. Some routers may have a
strategy for multipath forwarding; when a router sends Interest strategy for multipath forwarding; when a router sends Interest
messages to multiple neighbor routers, it may delay or prioritize to messages to multiple neighbor routers, it may delay or prioritize to
send the message to the upstream routers. The CCNinfo Request, as send the message to the upstream routers. The CCNinfo Request, as
the default, complies with such strategies; a CCNinfo user could the default, complies with such strategies; a CCNinfo user could
trace the actual forwarding path based on the forwarding strategy and trace the actual forwarding path based on the forwarding strategy and
will receive a single Reply message such as a content object. will receive a single Reply message such as a Content Object.
5.3.2. Full Discovery Request 5.3.2. Full Discovery Request
There may be a case wherein a CCNinfo user wants to discover all There may be a case wherein a CCNinfo user wants to discover all
possible forwarding paths and content forwarders based on the possible forwarding paths and content forwarders based on the
routers' FIBs. The "full discovery request" enables this routers' FIBs. The "full discovery request" enables this
functionality. If a CCNinfo user sets the F flag in the Request functionality. If a CCNinfo user sets the F flag in the Request
block of the Request message (as seen in Figure 9) to request the block of the Request message (as seen in Table 5) to request the full
full discovery, the upstream routers simultaneously forward the discovery, the upstream routers simultaneously forward the Requests
Requests to all multiple upstream routers based on the FIBs. Then, to all multiple upstream routers based on the FIBs. Then, the
the CCNinfo user can trace all possible forwarding paths. As seen in CCNinfo user can trace all possible forwarding paths. As seen in
Figure 17, each router forwards the Reply message along its PIT entry Figure 11, each router forwards the Reply message along its PIT
and finally, the CCNinfo user receives two Reply messages: one from entry, and finally, the CCNinfo user receives two Reply messages: one
the FHR (Router C) and the other from the Caching router. from the FHR (Router C) and the other from the Caching router.
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 |
+---------+ +---------+
Figure 17: Full discovery request. Reply messages forwarded by Figure 11: Full Discovery Request: Reply Messages Forwarded by
publisher and routers. the Publisher and Routers
To receive different Reply messages forwarded from different routers, To receive different Reply messages forwarded from different routers,
the PIT entries initiated by CCNinfo remain until the configured the PIT entries initiated by CCNinfo remain until the configured
CCNinfo Reply Timeout (Section 7.1) is expired. In other words, CCNinfo Reply Timeout (Section 7.1) is expired. In other words,
unlike the ordinary Interest-Data exchanges in CCN, if routers that unlike the ordinary Interest-Data exchanges in CCN, if routers that
accept the full discovery request receive the full discovery request, accept the full discovery request receive the full discovery request,
the routers SHOULD NOT remove the PIT entry created by the full the routers SHOULD NOT remove the PIT entry created by the full
discovery request until the CCNinfo Reply Timeout value expires. discovery request until the CCNinfo Reply Timeout value expires.
Note that the full discovery request is an OPTIONAL implementation of Note that the full discovery request is an OPTIONAL implementation of
skipping to change at page 27, line 30 skipping to change at line 1273
described in Section 10.8 as well. described in Section 10.8 as well.
5.4. Sending CCNinfo Reply 5.4. Sending CCNinfo Reply
If there is a caching router or FHR for the specified content within If there is a caching router or FHR for the specified content within
the specified hop count along the path, the caching router or FHR the specified hop count along the path, the caching router or FHR
sends back the Reply message toward the CCNinfo user and terminates sends back the Reply message toward the CCNinfo user and terminates
the Request. the Request.
When a router decides to send a Reply message to its downstream When a router decides to send a Reply message to its downstream
neighbor router or the CCNinfo user with NO_ERROR return code, it neighbor router or the CCNinfo user with a NO_ERROR return code, it
inserts a Report block with the Request Arrival Time and Node inserts a Report block with the Request Arrival Time and Node
Identifier to the Request message. Then, the router inserts the Identifier values to the Request message. Then, the router inserts
corresponding Reply sub-block(s) (Figure 15) to the payload. The the corresponding Reply sub-block(s) (Figure 10) to the payload. The
router finally changes the Type field in the fixed header from router finally changes the Type field in the fixed header from
PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back
as the Reply toward the CCNinfo user in a hop-by-hop manner. as the Reply toward the CCNinfo user in a hop-by-hop manner.
If a router cannot continue the Request, the router MUST put an If a router cannot continue the Request, the router MUST put an
appropriate ReturnCode in the Request message, change the Type field appropriate ReturnCode in the Request message, change the Type field
value in the fixed header from PT_CCNINFO_REQUEST to value in the fixed header from PT_CCNINFO_REQUEST to
PT_CCNINFO_REPLY, and forward the Reply message back toward the PT_CCNINFO_REPLY, and forward the Reply message back toward the
CCNinfo user to terminate the Request (see Section 6). CCNinfo user to terminate the Request (see Section 6).
5.5. Forwarding CCNinfo Reply 5.5. Forwarding CCNinfo Reply
When a router receives a CCNinfo Reply whose Request ID and Node When a router receives a CCNinfo Reply whose Request ID and Node
Identifier match those in the PIT entry, sent from a valid adjacent Identifier values match those in the PIT entry, which is sent from a
neighbor router, it forwards the CCNinfo Reply back toward the valid adjacent neighbor router, it forwards the CCNinfo Reply back
CCNinfo user. If the router does not receive the corresponding Reply toward the CCNinfo user. If the router does not receive the
within the [CCNinfo Reply Timeout] period, then it removes the corresponding Reply within the [CCNinfo Reply Timeout] period, then
corresponding PIT entry and terminates the trace. it removes the corresponding PIT entry and terminates the trace.
The Flags field in the Request block TLV is used to indicate whether The Flags field in the Request block TLV is used to indicate whether
the router keeps the PIT entry during the CCNinfo Reply Timeout even the router keeps the PIT entry during the CCNinfo Reply Timeout even
after one or more corresponding Reply messages are forwarded. When after one or more corresponding Reply messages are forwarded. When
the CCNinfo user does not set the F flag (i.e., "0"), the the CCNinfo user does not set the F flag (i.e., "0"), the
intermediate routers immediately remove the PIT entry whenever they intermediate routers immediately remove the PIT entry whenever they
forward the corresponding Reply message. When the CCNinfo user sets forward the corresponding Reply message. When the CCNinfo user sets
the F flag (i.e., "1"), which means the CCNinfo user chooses the the F flag (i.e., "1"), which means the CCNinfo user chooses the
"full discovery request" (see Section 5.3.2), the intermediate "full discovery request" (see Section 5.3.2), the intermediate
routers keep the PIT entry within the [CCNinfo Reply Timeout] period. routers keep the PIT entry within the [CCNinfo Reply Timeout] period.
After this timeout, the PIT entry is removed. After this timeout, the PIT entry is removed.
CCNinfo Replies MUST NOT be cached in routers upon the transmission CCNinfo Replies MUST NOT be cached in routers upon the transmission
of Reply messages. of Reply messages.
5.6. PIT Entry Management for Multipath Support 5.6. PIT Entry Management for Multipath Support
Within a network with multipath condition, there is a case Within a network with a multipath condition, there is a case
(Figure 18) wherein a single CCNinfo Request is split into multiple (Figure 12) wherein a single CCNinfo Request is split into multiple
Requests (e.g., at Router A), which are injected into a single router Requests (e.g., at Router A), which are injected into a single router
(Router D). In this case, multiple Replies with the same Request ID (Router D). In this case, multiple Replies with the same Request ID
and Node Identifier including different Report blocks are received by and Node Identifier values, including different Report blocks, are
the router (Router D). received by the router (Router D).
+--------+ +--------+
| Router | | Router |
| B | | B |
+--------+ +--------+
/ \ / \
/ \ / \
+--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router | | Router | ... |Publisher| | CCNinfo|----| Router | | Router | ... |Publisher|
| user | | A | | D | | | | user | | A | | D | | |
+--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +---------+
\ / \ /
\ / \ /
+--------+ +--------+
| Router | | Router |
| C | | C |
+--------+ +--------+
Figure 18 Figure 12: An Example of Multipath Network Topology
To recognize different CCNinfo Reply messages, the routers MUST To recognize different CCNinfo Reply messages, the routers MUST
distinguish the PIT entries by the Request ID and exploiting path distinguish the PIT entries by the Request ID and exploiting path
labels, which could be a hash value of the concatenation information labels, which could be a hash value of the concatenation information
of the cumulate Node Identifiers in the hop-by-hop header and the of the cumulate node identifiers in the hop-by-hop header and the
specified content name. For example, when Router D in Figure 18 specified content name. For example, when Router D in Figure 12
receives a CCNinfo Request from Router B, its PIT includes the receives a CCNinfo Request from Router B, its PIT includes the
Request ID and value such as H((Router_A|Router_B)|content_name), Request ID and value such as H((Router_A|Router_B)|content_name),
where "H" indicates some hash function and "|" indicates where "H" indicates some hash function and "|" indicates
concatenation. When Router D receives a CCNinfo Request from Router concatenation. When Router D receives a CCNinfo Request from Router
C, its PIT includes the same Request ID and value of C, its PIT includes the same Request ID and value of
H((Router_A|Router_C)|content_name). Two different Replies are later H((Router_A|Router_C)|content_name). Two different Replies are later
received on Router D and each Reply is appropriately forwarded to received on Router D, and each Reply is appropriately forwarded to
Router B and Router C, respectively. Note that two Reply messages 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 coming from Router B and Router C are reached at Router A, but the
CCNinfo user can only receive the first Reply message either from CCNinfo user can only receive the first Reply message either from
Router B or Router C as Router A removes the corresponding PIT entry Router B or Router C as Router A removes the corresponding PIT entry
after it forwards the first Reply. after it forwards the first Reply.
To avoid routing loops, when a router seeks the cumulate Node To avoid routing loops, when a router seeks the cumulate node
Identifiers of the Report blocks in the hop-by-hop header, it MUST identifiers of the Report blocks in the hop-by-hop header, it MUST
examine whether its own Node Identifier is not previously inserted. examine whether its own node identifier is not previously inserted.
If a router detects its own Node Identifier in the hop-by-hop header, If a router detects its own node identifier in the hop-by-hop header,
the router inserts its Report block and terminates the Request as the router inserts its Report block and terminates the Request as
will be described in Section 6.8. will be described in Section 6.8.
6. CCNinfo Termination 6. CCNinfo Termination
When performing a hop-by-hop trace, it is necessary to determine when When performing a hop-by-hop trace, it is necessary to determine when
to stop the trace. There are several cases when an intermediate to stop the trace. There are several cases when an intermediate
router might return a Reply before a Request reaches the caching router might return a Reply before a Request reaches the caching
router or the FHR. router or the FHR.
6.1. Arriving at First-hop Router 6.1. Arriving at First-Hop Router
A CCNinfo Request can be determined to have arrived at the FHR. To A CCNinfo Request can be determined to have arrived at the FHR. To
ensure that a router recognizes that it is the FHR for the specified ensure that a router recognizes that it is the FHR for the specified
content, it needs to have a FIB entry (or attach) to the content, it needs to have a FIB entry (or to attach) to the
corresponding publisher or the content. corresponding publisher or the content.
6.2. Arriving at Router Having Cache 6.2. Arriving at Router Having Cache
A CCNinfo Request can be determined to have arrived at the router A CCNinfo Request can be determined to have arrived at the router
having the specified content cache within the specified HopLimit. having the specified content cache within the specified HopLimit.
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 a NO_INFO return code without appending any Reply
(sub-)block TLVs. block or sub-block TLVs.
6.4. Invalid Request 6.4. Invalid Request
If the router does not validate the Request or the Reply even it is If the router does not validate the Request or the Reply even it is
required, the router MUST note a ReturnCode of INVALID_REQUEST in the required, the router MUST note a ReturnCode of INVALID_REQUEST in the
fixed header of the message, insert its Report block, and forward the fixed header of the message, insert its Report block, and forward the
message as the Reply back to the CCNinfo user. The router MAY, message as the Reply back to the CCNinfo user. The router MAY,
however, randomly ignore the received invalid messages. (See however, randomly ignore the received invalid messages. (See
Section 10.7.) Section 10.7.)
skipping to change at page 30, line 31 skipping to change at line 1416
6.6. No Information 6.6. No Information
If the router does not have any information about the specified name If the router does not have any information about the specified name
prefix within the specified HopLimit, it MUST note a ReturnCode of prefix within the specified HopLimit, it MUST note a ReturnCode of
NO_INFO in the fixed header of the message, insert its Report block, NO_INFO in the fixed header of the message, insert its Report block,
and forward the message as the Reply back to the CCNinfo user. and forward the message as the Reply back to the CCNinfo user.
6.7. No Space 6.7. No Space
If appending the Report block or the Reply (sub-)block would make the If appending the Report block, the Reply block, or Reply sub-block
hop-by-hop header longer than 247 bytes or the Request packet longer would make the hop-by-hop header longer than 247 bytes or the Request
than the MTU of the Incoming face, the router MUST note a ReturnCode packet longer than the MTU of the Incoming face, the router MUST note
of NO_SPACE in the fixed header of the message and forward the a ReturnCode of NO_SPACE in the fixed header of the message and
message as the Reply back to the CCNinfo user. forward the message as the Reply back to the CCNinfo user.
6.8. Fatal Error 6.8. Fatal Error
If a CCNinfo Request has encountered a fatal error, the router MUST If a CCNinfo Request has encountered a fatal error, the router MUST
note a ReturnCode of FATAL_ERROR in the fixed header of the message note a ReturnCode of FATAL_ERROR in the fixed header of the message
and forward the message as the Reply back to the CCNinfo user. This and forward the message as the Reply back to the CCNinfo user. This
may happen, for example, when the router detects some routing loop in may happen, for example, when the router detects some routing loop in
the Request blocks (see Section 1). The fatal error can be encoded the Request blocks (see Section 1). The fatal error can be encoded
with another error: if a router detects routing loop but cannot with another error: if a router detects routing loop but cannot
insert its Report block, it MUST note NO_SPACE and FATAL_ERROR insert its Report block, it MUST note NO_SPACE and FATAL_ERROR
ReturnCodes (i.e., %x85) in the fixed header and forward the message ReturnCodes (i.e., 0x85) in the fixed header and forward the message
back to the CCNinfo user. back to the CCNinfo user.
6.9. CCNinfo Reply Timeout 6.9. CCNinfo Reply Timeout
If a router receives the Request or Reply message that expires its If a router receives the Request or Reply message that expires its
own [CCNinfo Reply Timeout] value (Section 7.1), the router will own [CCNinfo Reply Timeout] value (Section 7.1), the router will
silently discard the Request or Reply message. silently discard the Request or Reply message.
6.10. Non-Supported Node 6.10. Non-Supported Node
skipping to change at page 31, line 30 skipping to change at line 1459
Request message and MUST send the CCNinfo Reply with the ReturnCode Request message and MUST send the CCNinfo Reply with the ReturnCode
of ADMIN_PROHIB. The router MAY, however, randomly ignore the of ADMIN_PROHIB. The router MAY, however, randomly ignore the
Request messages to be rejected (see Section 10.7). Request messages to be rejected (see Section 10.7).
7. Configurations 7. Configurations
7.1. CCNinfo Reply Timeout 7.1. CCNinfo Reply Timeout
The [CCNinfo Reply Timeout] value is used to time out a CCNinfo The [CCNinfo Reply Timeout] value is used to time out a CCNinfo
Reply. The value for a router can be statically configured by the Reply. The value for a router can be statically configured by the
router's administrators/operators. The default value is 3 (seconds). router's administrators and/or operators. The default value is 3
The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 (seconds). The [CCNinfo Reply Timeout] value SHOULD NOT be larger
(seconds) and SHOULD NOT be lower than 2 (seconds). than 4 (seconds) and SHOULD NOT be lower than 2 (seconds).
7.2. HopLimit in Fixed Header 7.2. HopLimit in Fixed Header
If a CCNinfo user does not specify the HopLimit value in the fixed If a CCNinfo user does not specify the HopLimit value in the fixed
header for a Request message as the HopLimit, the HopLimit is set to header for a Request message as the HopLimit, the HopLimit is set to
32. Note that 0 HopLimit is an invalid Request; hence, the router in 32. Note that 0 HopLimit is an invalid Request; hence, the router in
this case follows the way defined in Section 6.4. this case follows the way defined in Section 6.4.
7.3. Access Control 7.3. Access Control
skipping to change at page 32, line 43 skipping to change at line 1517
8.5. Path Stretch 8.5. Path Stretch
By obtaining the path stretch "d / P", where "d" is the hop count of By obtaining the path stretch "d / P", where "d" is the hop count of
the data and "P" is the hop count from the consumer to the publisher, the data and "P" is the hop count from the consumer to the publisher,
we can measure the improvements in path stretch in various cases, we can measure the improvements in path stretch in various cases,
such as in different caching and routing algorithms. We can then such as in different caching and routing algorithms. We can then
facilitate the investigation of the performance of the protocol. facilitate the investigation of the performance of the protocol.
8.6. Cache Hit Probability 8.6. Cache Hit Probability
CCNinfo can show the number of received interests per cache or chunk CCNinfo can show the number of received Interests per cache or chunk
on a router. Accordingly, CCNinfo measures the content popularity on a router. Accordingly, CCNinfo measures the content popularity
(i.e., the number of accesses for each content/cache), thereby (i.e., the number of accesses for each content and/or cache), thereby
enabling the investigation of the routing/caching strategy in enabling the investigation of the routing/caching strategy in
networks. networks.
9. IANA Considerations 9. IANA Considerations
This section details each kind of CCNx protocol value that can be This section details each kind of CCNx protocol value that has been
registered. As per [5], this section makes assignments in four registered. As per [RFC8126], four assignments have been made in
existing registries and creates a new Reply Type registry in the existing registries, and a new Reply Type registry has been created
"Content-Centric Networking (CCNx)" registry group. The registration in the "Content-Centric Networking (CCNx)" registry group.
procedure is "RFC Required", which requires only that this document
be published as an RFC.
9.1. Packet Type Registry 9.1. Packet Type Registry
As shown in Figure 4, CCNinfo defines two packet types, As shown in Table 1, CCNinfo defines two packet types,
PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose suggested values are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose values are 0x03 and
%x03 and %x04, respectively. 0x04, respectively.
9.2. Top-Level Type Registry 9.2. Top-Level Type Registry
As shown in Figure 5, CCNinfo defines one top-level type, As shown in Table 2, CCNinfo defines one top-level type, T_DISCOVERY,
T_DISCOVERY, whose suggested value is %x0005. whose value is 0x0005.
9.3. Hop-by-Hop Type Registry 9.3. Hop-by-Hop Type Registry
As shown in Figure 8, CCNinfo defines two hop-by-hop types, As shown in Table 4, CCNinfo defines two hop-by-hop types,
T_DISC_REQHDR and T_DISC_REPORT, whose suggested values are %x0008 T_DISC_REQHDR and T_DISC_REPORT, whose values are 0x0008 and 0x0009,
and %x0009, respectively. respectively.
9.4. Message Type Registry 9.4. Message Type Registry
As shown in Figure 11, CCNinfo defines two message types, T_DISC_REQ As shown in Table 6, CCNinfo defines two message types, T_DISC_REQ
and T_DISC_REPLY, whose suggested values are %x000D and %x000E, and T_DISC_REPLY, whose values are 0x000D and 0x000E, respectively.
respectively.
9.5. Reply Type Registry 9.5. Reply Type Registry
IANA has created the "CCNx Reply Types" registry and allocated the IANA has created the "CCNx Reply Types" registry and allocated the
reply types. The Type value is 2 octets. The range is reply types. The registration procedure is "RFC Required" [RFC8126].
%x0000-%xFFFF. As shown in Figure 16, CCNinfo defines three reply The Type value is 2 octets. The range is 0x0000-0xFFFF. As shown in
types, T_DISC_CONTENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose Table 7, CCNinfo defines three reply types, T_DISC_CONTENT,
suggested values are %x0000, %x0001, and %x0FFF, respectively. T_DISC_CONTENT_PUBLISHER, and T_ORG, whose values are 0x0000, 0x0001,
and 0x0FFF, respectively.
10. Security Considerations 10. Security Considerations
This section addresses some of the security considerations. This section addresses some of the security considerations.
10.1. Policy-Based Information Provisioning for Request 10.1. Policy-Based Information Provisioning for Request
Although CCNinfo gives excellent troubleshooting cues, some network Although CCNinfo gives excellent troubleshooting cues, some network
administrators or operators may not want to disclose everything about administrators or operators may not want to disclose everything about
their network to the public or may wish to securely transmit private their network to the public or may wish to securely transmit private
skipping to change at page 34, line 21 skipping to change at line 1581
policy-based information provisioning, thereby allowing network policy-based information provisioning, thereby allowing network
administrators to specify their response policy for each router. administrators to specify their response policy for each router.
The access policy regarding "who is allowed to retrieve" and/or "what The access policy regarding "who is allowed to retrieve" and/or "what
kind of cache information" can be defined for each router. For the kind of cache information" can be defined for each router. For the
former type of access policy, routers with the specified content MAY former type of access policy, routers with the specified content MAY
examine the signature enclosed in the Request message and decide examine the signature enclosed in the Request message and decide
whether they should notify the content information in the Reply. If whether they should notify the content information in the Reply. If
the routers decide to not notify the content information, they MUST the routers decide to not notify the content information, they MUST
send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without
appending any Reply (sub-)block TLVs. For the latter type of policy, appending any Reply block or sub-block TLVs. For the latter type of
the permission, whether (1) All (all cache information is disclosed), policy, the permission, whether (1) All (all cache information is
(2) Partial (cache information with a particular name prefix can (or disclosed), (2) Partial (cache information with a particular name
cannot) be disclosed), or (3) Deny (no cache information is prefix can (or cannot) be disclosed), or (3) Deny (no cache
disclosed), is defined at the routers. information is disclosed), is defined at the routers.
In contrast, we entail that each router does not disrupt the In contrast, we entail that each router does not disrupt the
forwarding of CCNinfo Request and Reply messages. When a Request forwarding of CCNinfo Request and Reply messages. When a Request
message is received, the router SHOULD insert the Report block if the message is received, the router SHOULD insert the Report block if the
ReturnCode is NO_ERROR. Here, according to the policy configuration, ReturnCode is NO_ERROR. Here, according to the policy configuration,
the Node Identifier field in the Report block MAY be null (i.e., all- the Node Identifier field in the Report block MAY be null (i.e., all-
zeros), but the Request Arrival Time field SHOULD NOT be null. zeros), but the Request Arrival Time field SHOULD NOT be null.
Finally, the router SHOULD forward the Request message to the Finally, the router SHOULD forward the Request message to the
upstream router toward the content forwarder if the ReturnCode is upstream router toward the content forwarder if the ReturnCode is
kept with NO_ERROR. kept with NO_ERROR.
10.2. Filtering CCNinfo Users Located in Invalid Networks 10.2. Filtering CCNinfo Users Located in Invalid Networks
A router MAY support an access control mechanism to filter out A router MAY support an access control mechanism to filter out
Requests from invalid CCNinfo users. To accomplish this, invalid Requests from invalid CCNinfo users. To accomplish this, invalid
networks (or domains) could, for example, be configured via a list of networks (or domains) could, for example, be configured via a list of
allowed/disallowed networks (as observed in Section 7.3). If a allowed or disallowed networks (as observed in Section 7.3). If a
Request is received from a disallowed network (according to the Node Request is received from a disallowed network (according to the node
Identifier in the Request block), the Request MUST NOT be processed identifier in the Request block), the Request MUST NOT be processed
and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to
note that. The router MAY, however, perform rate limited logging of note that. The router MAY, however, perform rate-limited logging of
such events. such events.
10.3. Topology Discovery 10.3. Topology Discovery
CCNinfo can be used to discover actively used topologies. If a CCNinfo can be used to discover actively used topologies. If a
network topology is not disclosed, CCNinfo Requests SHOULD be network topology is not disclosed, CCNinfo Requests SHOULD be
restricted at the border of the domain using the ADMIN_PROHIB return restricted at the border of the domain using the ADMIN_PROHIB return
code. code.
10.4. Characteristics of Content 10.4. Characteristics of Content
skipping to change at page 35, line 27 skipping to change at line 1631
return code. return code.
10.5. Computational Attacks 10.5. Computational Attacks
CCNinfo may impose heavy tasks at content forwarders because it makes CCNinfo may impose heavy tasks at content forwarders because it makes
content forwarders seek their internal cache states reported in the content forwarders seek their internal cache states reported in the
Reply messages whenever they form the Reply messages. The current Reply messages whenever they form the Reply messages. The current
CCNinfo specification allows to return null values for several CCNinfo specification allows to return null values for several
fields, such as First/Last Seqnum or Elapsed Cache Time fields in the fields, such as First/Last Seqnum or Elapsed Cache Time fields in the
Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY
be null. This means that the content forwarder can not only hide be null. This means that the content forwarder cannot only hide
these values owing to privacy/security policies, but also skip the these values owing to privacy and security policies but also skip the
implementations of the complex functions to report these values. implementations of the complex functions to report these values.
10.6. Longer or Shorter CCNinfo Reply Timeout 10.6. Longer or Shorter CCNinfo Reply Timeout
Routers can configure CCNinfo Reply Timeout (Section 7.1), which is Routers can configure CCNinfo Reply Timeout (Section 7.1), which is
the allowable timeout value to keep the PIT entry. If routers the allowable timeout value to keep the PIT entry. If routers
configure a longer timeout value, there may be an attractive attack configure a longer timeout value, there may be an attractive attack
vector against the PIT memory. Moreover, especially when the full vector against the PIT memory. Moreover, especially when the full
discovery request option (Section 5.3) is specified for the CCNinfo discovery request option (Section 5.3) is specified for the CCNinfo
Request, several Reply messages may be returned and cause a response Request, several Reply messages may be returned and cause a response
storm. (See Section 10.8 for rate-limiting to avoid the storm). To storm. (See Section 10.8 for rate-limiting to avoid the storm). To
avoid DoS attacks, routers MAY configure the timeout value, which is avoid DoS attacks, routers MAY configure the timeout value, which is
shorter than the user-configured CCNinfo timeout value. However, if shorter than the user-configured CCNinfo timeout value. However, if
it is too short, the Request may be timed out and the CCNinfo user it is too short, the Request may be timed out and the CCNinfo user
does not receive all Replies; s/he only retrieves the partial path does not receive all Replies; they only retrieve the partial path
information (i.e., information about a part of the tree). information (i.e., information about a part of the tree).
There may be a way to enable incremental exploration (i.e., to There may be a way to enable incremental exploration (i.e., to
explore the part of the tree that was not explored by the previous explore the part of the tree that was not explored by the previous
operation); however, discussing such mechanisms is out of scope of operation); however, discussing such mechanisms is out of scope of
this document. this document.
10.7. Limiting Request Rates 10.7. Limiting Request Rates
A router MAY rate-limit CCNinfo Requests by ignoring some of the A router MAY rate-limit CCNinfo Requests by ignoring some of the
consecutive messages. The router MAY randomly ignore the received consecutive messages. The router MAY randomly ignore the received
messages to minimize the processing overhead, i.e., to keep fairness messages to minimize the processing overhead, i.e., to keep fairness
in processing requests, or prevent traffic amplification. In such a in processing requests or to prevent traffic amplification. In such
case, no error message is returned. The rate limit function is left a case, no error message is returned. The rate limit function is
to the router's implementation. left to the router's implementation.
10.8. Limiting Reply Rates 10.8. Limiting Reply Rates
CCNinfo supporting multipath forwarding may result in one Request CCNinfo supporting multipath forwarding may result in one Request
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 [11] provides a possible method for and/or router adjacency, while a hop-by-hop authentication such as
an adjacency verification and defines the corresponding message [DCAuth] provides a possible method for an adjacency verification and
format for adjacency verification as well as the router behaviors. defines the corresponding message format for adjacency verification
CCNinfo MAY use a similar method for node adjacency verification. as well as the router behaviors. CCNinfo MAY use a similar method
for node adjacency verification.
11. Acknowledgements
The authors would like to thank Jerome Francois, Erik Kline, Spyridon
Mastorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry
Turletti for their valuable comments and suggestions on this
document.
12. References
12.1. Normative References
[1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 11. References
Format", RFC 8609, July 2019,
<https://www.rfc-editor.org/rfc/rfc8609>.
[2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 11.1. Normative References
RFC 8569, July 2019,
<https://www.rfc-editor.org/rfc/rfc8569>.
[3] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
2119 Key Words", May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
[6] Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Tschudin, "Information-Centric Networking (ICN): Content-
Centric Networking (CCNx) and Named Data Networking (NDN)
Terminology", RFC 8793, June 2020,
<https://www.rfc-editor.org/rfc/rfc8793>.
[7] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Tool for Measuring and Tracing Content-Centric Networks", Networking (CCNx) Semantics", RFC 8569,
IEEE Communications Magazine, Vol.53, No.3, pp.182-188, DOI 10.17487/RFC8569, July 2019,
March 2015. <https://www.rfc-editor.org/info/rfc8569>.
[8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
D. Oran, "ICN Ping Protocol Specification", draft-irtf- Networking (CCNx) Messages in TLV Format", RFC 8609,
icnrg-icnping-06 (work in progress), May 2022. DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[9] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 11.2. Informative References
D. Oran, "ICN Traceroute Protocol Specification", draft-
irtf-icnrg-icntraceroute-06 (work in progress), May 2022.
[10] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: [Cefore] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore:
Traceroute Facility for IP Multicast", RFC 8487, October Software Platform Enabling Content-Centric Networking and
2018, <https://www.rfc-editor.org/rfc/rfc8487>. Beyond", IEICE Transaction on Communications, Volume
E102-B, Issue 9, pp. 1792-1803,
DOI 10.1587/transcom.2018EII0001, September 2019,
<https://doi.org/10.1587/transcom.2018EII0001>.
[11] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in [Cefore-site]
Content-Centric Networking/Named Data Networking", draft- "Cefore", <https://cefore.net/>.
li-icnrg-hopauth-02 (work in progress), February 2020.
[12] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive [CONSEC-CACHING]
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, MO, USA,
DOI 10.1109/ICC.2018.8422233, May 2018,
<https://doi.org/10.1109/ICC.2018.8422233>.
[13] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: [Contrace] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A
Software Platform Enabling Content-Centric Networking and tool for measuring and tracing content-centric networks",
Beyond", IEICE Transaction on Communications, Vol.E102-B, IEEE Communications Magazine, Vol. 53, No. 3, pp. 182-188,
No.9, pp.1792-1803, September 2019. DOI 10.1109/MCOM.2015.7060502, March 2015,
<https://doi.org/10.1109/MCOM.2015.7060502>.
[14] "Cefore Home Page", <https://cefore.net/>. [DCAuth] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
Authentication for Secure In-Network Big-Data Retrieval",
IEEE Transactions on Network Science and Engineering, Vol.
7, No. 1, pp. 15-27, DOI 10.1109/TNSE.2018.2872049,
October 2018, <https://doi.org/10.1109/TNSE.2018.2872049>.
[ICN-PING] Mastorakis, S., Oran, D. R., Gibson, J., Moiseenko, I.,
and R. Droms, "ICN Ping Protocol Specification", Work in
Progress, Internet-Draft, draft-irtf-icnrg-icnping-07, 16
October 2022, <https://datatracker.ietf.org/doc/html/
draft-irtf-icnrg-icnping-07>.
[ICN-TRACEROUTE]
Mastorakis, S., Oran, D. R., Moiseenko, I., Gibson, J.,
and R. Droms, "ICN Traceroute Protocol Specification",
Work in Progress, Internet-Draft, draft-irtf-icnrg-
icntraceroute-07, 16 October 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
icntraceroute-07>.
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487,
DOI 10.17487/RFC8487, October 2018,
<https://www.rfc-editor.org/info/rfc8487>.
[RFC8793] Wissingh, B., 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,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
Appendix A. ccninfo Command and Options Appendix A. ccninfo Command and Options
CCNinfo is implemented in Cefore [13][14]. The command invoked by CCNinfo is implemented in Cefore [Cefore] [Cefore-site]. The command
the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo invoked by the CCNinfo user (e.g., consumer) is named "ccninfo". The
command sends the Request message and receives the Reply message(s). ccninfo command sends the Request message and receives the Reply
There are several options that can be specified with ccninfo, while message(s). There are several options that can be specified with
the content name prefix (e.g., ccnx:/news/today) is the mandatory ccninfo, while the content name prefix (e.g., ccnx:/news/today) is
parameter. the mandatory parameter.
The usage of ccninfo command is as follows: The usage of the ccninfo command is as follows:
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
name_prefix name_prefix:
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
content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants of content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user
to trace. wants to trace.
c option c option:
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.
f option f option:
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.
o option o option:
This option enables to trace the path to the content publisher. This option enables the tracing of the path to the content
Each router along the path to the publisher inserts each Report publisher. Each router along the path to the publisher inserts
block and forwards the Request message. It does not send Reply each Report block and forwards the Request message. It does not
even if it caches the specified content. FHR that attaches the send Reply even if it caches the specified content. FHR that
publisher (who has the complete set of content and is not a attaches the publisher (who has the complete set of content and is
caching router) sends the Reply message. not a caching router) sends the Reply message.
V option V option:
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.
r option r option:
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.
s option s option:
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 user invokes the CCNinfo command with this option, such as CCNinfo user invokes the ccninfo command with this option, such as
"-s 3", three upstream routers along the path only forward the "-s 3", three upstream routers along the path only forward the
Request message but do not append their Report blocks in the hop- Request message but do not append their Report blocks in the hop-
by-hop header and do not send Reply messages despite having the by-hop header and do not send Reply messages despite having the
corresponding cache. corresponding cache.
v option v option:
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.
Acknowledgements
The authors would like to thank Jérôme François, Erik Kline, Spyridon
Mastorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry
Turletti for their valuable comments and suggestions on this
document.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, 4-2-1 Nukui-Kitamachi, Koganei, Tokyo
Tokyo 184-8795 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
Atsushi Ooka Atsushi Ooka
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, 4-2-1 Nukui-Kitamachi, Koganei, Tokyo
Tokyo 184-8795 184-8795
Japan Japan
Email: a-ooka@nict.go.jp Email: a-ooka@nict.go.jp
Xun Shao Xun Shao
Toyohashi University of Technology Toyohashi University of Technology
1-1 Hibarigaoka Tempaku-cho, Toyohashi, 1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi
Aichi 441-8580 441-8580
Japan Japan
Email: shao.xun.ls@tut.jp Email: shao.xun.ls@tut.jp
 End of changes. 207 change blocks. 
634 lines changed or deleted 737 lines changed or added

This html diff was produced by rfcdiff 1.48.