idnits 2.17.00 (12 Aug 2021) /tmp/idnits38203/draft-irtf-icnrg-ccninfo-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 25, 2022) is 19 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '-c' on line 1637 -- Looks like a reference, but probably isn't: '-f' on line 1637 -- Looks like a reference, but probably isn't: '-o' on line 1637 -- Looks like a reference, but probably isn't: '-V' on line 1637 == Outdated reference: A later version (-06) exists of draft-irtf-icnrg-icnping-05 == Outdated reference: A later version (-06) exists of draft-irtf-icnrg-icntraceroute-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group H. Asaeda 3 Internet-Draft A. Ooka 4 Intended status: Experimental NICT 5 Expires: October 27, 2022 X. Shao 6 Kitami Institute of Technology 7 April 25, 2022 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-10 13 Abstract 15 This document describes a mechanism named "CCNinfo" that discovers 16 information about the network topology and in-network cache in 17 Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN 18 routing path information per name prefix, 2) the Round-Trip Time 19 (RTT) between the content forwarder and consumer, and 3) the states 20 of in-network cache per name prefix. CCNinfo is useful to understand 21 and debug the behavior of testbed networks and other experimental 22 deployments of CCN systems. 24 This document is a product of the IRTF Information-Centric Networking 25 Research Group (ICNRG). This document represents the consensus view 26 of ICNRG and has been reviewed extensively by several members of the 27 ICN community and the RG. The authors and RG chairs approve of the 28 contents. The document is sponsored under the IRTF and is not issued 29 by the IETF and is not an IETF standard. This is an experimental 30 protocol and the specification may change in the future. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 27, 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9 71 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10 72 3.1.1. Request Header Block and Request Block . . . . . . . 12 73 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16 74 3.1.3. Content Name Specification . . . . . . . . . . . . . 17 75 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17 76 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18 77 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19 78 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22 79 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22 80 4.1.1. Routing Path Information . . . . . . . . . . . . . . 22 81 4.1.2. In-Network Cache Information . . . . . . . . . . . . 22 82 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23 83 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 84 5.1. User and Neighbor Verification . . . . . . . . . . . . . 23 85 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 23 86 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25 87 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25 88 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 25 89 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 26 90 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27 91 5.6. PIT Entry Management for Multipath Support . . . . . . . 27 92 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 29 93 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 29 94 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 29 95 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 29 96 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 29 97 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 30 99 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 30 100 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 30 101 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30 102 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 30 103 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 30 104 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 31 105 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 106 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 31 107 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 31 108 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 31 109 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 31 110 8.2. Caching Router Identification . . . . . . . . . . . . . . 31 111 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 31 112 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 113 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 32 114 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 32 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 116 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 117 10.1. Policy-Based Information Provisioning for Request . . . 32 118 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 33 119 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33 120 10.4. Characteristics of Content . . . . . . . . . . . . . . . 33 121 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 34 122 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 34 123 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 34 124 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34 125 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 35 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 128 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 129 12.2. Informative References . . . . . . . . . . . . . . . . . 35 130 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 36 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 133 1. Introduction 135 In Content-Centric Networks (CCN), publishers provide the content 136 through the network, and receivers retrieve it by name. In this 137 network architecture, routers forward content requests through their 138 Forwarding Information Bases (FIBs), which are populated by name- 139 based routing protocols. CCN also enables receivers to retrieve 140 content from an in-network cache. 142 In CCN, while consumers do not generally need to know the content 143 forwarder that is transmitting the content to them, the operators and 144 developers may want to identify the content forwarder and observe the 145 routing path information per name prefix for troubleshooting or 146 investigating the network conditions. 148 IP traceroute is a useful tool for discovering the routing conditions 149 in IP networks because it provides intermediate router addresses 150 along the path between the source and destination and the Round-Trip 151 Time (RTT) for the path. However, this IP-based network tool cannot 152 trace the name prefix paths used in CCN. Moreover, such IP-based 153 network tools do not obtain the states of the in-network cache to be 154 discovered. 156 Contrace [7] enables end users (i.e., consumers) to investigate path 157 and in-network cache conditions in CCN. Contrace is implemented as 158 an external daemon process running over TCP/IP that can interact with 159 a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the 160 caching information on the forwarding daemon. This solution is 161 flexible, but it requires TCP/IP networks and defining the common 162 APIs for the global deployment. ICN ping [8] and traceroute [9] are 163 lightweight operational tools that enable a user to explore the 164 path(s) that reach a publisher or a cache storing the named content. 165 ICN ping and traceroute, however, do not exposes detailed information 166 about the forwarders deployed by a network operator. 168 This document describes the specifications of "CCNinfo", an active 169 networking tool for discovering the path and content caching 170 information in CCN. CCNinfo defines the protocol messages to 171 investigate path and in-network cache conditions in CCN. It is 172 embedded in the CCNx forwarding process and can facilitate with non- 173 IP networks as with the basic CCN concept. 175 The two message types, Request and Reply messages, are encoded in the 176 CCNx TLV format [1]. The request-reply message flow, walking up the 177 tree from a consumer toward a publisher, is similar to the behavior 178 of the IP multicast traceroute facility [10]. 180 CCNinfo facilitates the tracing of a routing path and provides: 1) 181 the RTT between the content forwarder (i.e., caching router or first- 182 hop router) and consumer, 2) the states of the in-network cache per 183 name prefix, and 3) the routing path information per name prefix. 185 In addition, CCNinfo identifies the states of the cache, such as the 186 following metrics for Content Store (CS) in the content forwarder: 1) 187 size of cached content objects, 2) number of cached content objects, 188 3) number of accesses (i.e., received Interests) per content, and 4) 189 elapsed cache time and remaining cache lifetime of content. 191 CCNinfo supports multipath forwarding. The Request messages can be 192 forwarded to multiple neighbor routers. When the Request messages 193 are forwarded to multiple routers, the different Reply messages are 194 forwarded from different routers or publishers. 196 Furthermore, CCNinfo implements policy-based information provisioning 197 that enables administrators to "hide" secure or private information 198 but does not disrupt message forwarding. This policy-based 199 information provisioning reduces the deployment barrier faced by 200 operators in installing and running CCNinfo on their routers. 202 1.1. CCNinfo as an Experimental Tool 204 In order to carry out meaningful experimentation with CCNx protocols, 205 comprehensive instrumentation and management information is needed to 206 take measurements and explore both the performance and robustness 207 characteristics of the protocols and of the applications using them. 208 CCNinfo's primary goal is to gather and report this information. As 209 experience is gained with both the CCNx protocols and CCNinfo itself, 210 we can refine the instrumentation capabilities and discover what 211 additional capabilities might be needed in CCNinfo and conversely 212 which features wind up not being of sufficient value to justify the 213 implementation complexity and execution overhead. 215 CCNinfo is intended as a comprehensive experimental tool for CCNx- 216 based networks. It provides a wealth of information from forwarders, 217 including on-path in-network cache conditions as well as forwarding 218 path instrumentation of multiple paths toward content forwarders. As 219 an experimental capability that exposes detailed information about 220 the forwarders deployed by a network operator, CCNinfo employs more 221 granular authorization policies than those required of ICN ping or 222 ICN traceroute. 224 CCNinfo uses two message types: Request and Reply. A CCNinfo user, 225 e.g., consumer, initiates a CCNinfo Request message when s/he wants 226 to obtain routing path and cache information. When an adjacent 227 neighbor router receives the Request message, it examines own cache 228 information. If the router does not cache the specified content, it 229 inserts its Report block into the hop-by-hop header of the Request 230 message and forwards the message to its upstream neighbor router(s) 231 decided by its FIB. In Figure 1, CCNinfo user and routers (Router A, 232 B, C) insert their own Report blocks into the Request message and 233 forward the message toward the content forwarder. 235 1. Request 2. Request 3. Request 236 (U) (U+A) (U+A+B) 237 +----+ +----+ +----+ 238 | | | | | | 239 | v | v | v 240 +--------+ +--------+ +--------+ +--------+ +---------+ 241 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 242 | user | | A | | B | | C | | | 243 +--------+ +--------+ +--------+ +--------+ +---------+ 244 \ 245 \ +-------+ 246 3. Request \ | Cache | 247 (U+A+B) \ +---------+ | 248 v| Caching |----+ 249 | router | 250 +---------+ 252 Figure 1: Request message invoked by CCNinfo user and forwarded by 253 routers. 255 When the Request message reaches the content forwarder, the content 256 forwarder forms the Reply message; it inserts its own Reply block TLV 257 and Reply sub-block TLV(s) to the Request message. The Reply message 258 is then forwarded back toward the user in a hop-by-hop manner along 259 the PIT entries. In Figure 2, each router (Router C, B, and A) 260 forwards the Reply message along its PIT entry and finally, the 261 CCNinfo user receives a Reply message from Router C, which is the 262 first-hop router for the Publisher. Another Reply message from the 263 Caching router (i.e., Reply(C)) is discarded at Router B if the other 264 Reply message (i.e., Reply(P)) was already forwarded by Router B. 266 3. Reply(P) 2. Reply(P) 1. Reply(P) 267 +----+ +----+ +----+ 268 | | | | | | 269 v | v | v | 270 +--------+ +--------+ +--------+ +--------+ +---------+ 271 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 272 | user | | A | | B | | C | | | 273 +--------+ +--------+ +--------+ +--------+ +---------+ 274 ^ 275 \ +-------+ 276 1. Reply(C) \ | Cache | 277 \ +---------+ | 278 \| Caching |----+ 279 | router | 280 +---------+ 282 Figure 2: Reply messages forwarded by routers, and one Reply message 283 is received by CCNinfo user. 285 2. Terminology 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 289 "OPTIONAL" in this document are to be interpreted as described in BCP 290 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in 291 all capitals, as shown here. 293 2.1. Definitions 295 This document follows the basic terminologies and definitions 296 described in [1]. Although CCNinfo requests flow in the opposite 297 direction to the data flow, we refer to "upstream" and "downstream" 298 with respect to data, unless explicitly specified. 300 Scheme name 301 It indicates a URI and protocol. This document only considers 302 "ccnx:/" as the scheme name. 304 Prefix name 305 A prefix name, which is defined in [2], is a name that does not 306 uniquely identify a single content object, but rather a namespace 307 or prefix of an existing content object name. 309 Exact name 310 An exact name, which is defined in [2], is one that uniquely 311 identifies the name of a content object. 313 Node 314 A node within a CCN network can fulfill the role of a data 315 publisher, a data consumer, and/or a forwarder for interest and 316 content object as given in [6]. 318 Consumer 319 A node that requests content objects by generating and sending out 320 interests. It is a same definition of ICN Consumer as given in 321 [6]. 323 Publisher 324 A node that creates content objects and makes them available for 325 retrieval. It is a same definition of ICN Producer as given in 326 [6]. 328 Router 329 A node that implements stateful forwarding in the path between 330 consumer and publisher. 332 Caching router 333 A node that temporarily stores and potentially carries interests 334 or content objects before forwarding it to next node. 336 Content forwarder 337 It is either a caching router or a first-hop router that forwards 338 content objects to consumers. 340 CCNinfo user 341 A node that initiates the CCNinfo Request, which is consumer or 342 router that invokes the CCNinfo user program with the name prefix 343 of the content. The CCNinfo user program, such as "ccninfo" 344 command described in Appendix A or other similar commands, 345 initiates the Request message to obtain routing path and cache 346 information. 348 Incoming face 349 The face on which data are expected to arrive from the specified 350 name prefix. 352 Outgoing face 353 The face to which data from the publisher or router are expected 354 to transmit for the specified name prefix. It is also the face on 355 which the Request messages are received. 357 Upstream router 358 The router that connects to an Incoming face of a router. 360 Downstream router 361 The router that connects to an Outgoing face of a router. 363 First-hop router (FHR) 364 The router that matches a FIB entry with an Outgoing face 365 referring to a local application or a publisher. 367 Last-hop router (LHR) 368 The router that is directly connected to a consumer. 370 3. CCNinfo Message Formats 372 CCNinfo Request and Reply messages are encoded in the CCNx TLV format 373 ([1], Figure 3). The Request message consists of a fixed header, 374 Request block TLV (Figure 7), and Report block TLV(s) (Figure 12). 375 The Reply message consists of a fixed header, Request block TLV, 376 Report block TLV(s), Reply block TLV (Figure 14), and Reply sub-block 377 TLV(s) (Figure 15). 379 1 2 3 380 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 381 +---------------+---------------+---------------+---------------+ 382 | Version | PacketType | PacketLength | 383 +---------------+---------------+---------------+---------------+ 384 | PacketType specific fields | HeaderLength | 385 +---------------+---------------+---------------+---------------+ 386 / Optional Hop-by-hop header TLVs / 387 +---------------+---------------+---------------+---------------+ 388 / PacketPayload TLVs / 389 +---------------+---------------+---------------+---------------+ 390 / Optional CCNx ValidationAlgorithm TLV / 391 +---------------+---------------+---------------+---------------+ 392 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 393 +---------------+---------------+---------------+---------------+ 395 Figure 3: Packet format [1] 397 The PacketType values in the fixed header shown in Figure 3 are 398 PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). 399 CCNinfo Request and Reply messages are forwarded in a hop-by-hop 400 manner. When the Request message reaches the content forwarder, the 401 content forwarder turns it into a Reply message by changing the Type 402 field value in the fixed header from PT_CCNINFO_REQUEST to 403 PT_CCNINFO_REPLY and forwards it back toward the node that initiated 404 the Request message. 406 Code Type name 407 ======== ===================== 408 %x00 PT_INTEREST [1] 409 %x01 PT_CONTENT [1] 410 %x02 PT_RETURN [1] 411 %x03 PT_CCNINFO_REQUEST 412 %x04 PT_CCNINFO_REPLY 414 Figure 4: Packet Type Namespace 416 Following a fixed header, there can be a sequence of optional hop-by- 417 hop header TLV(s) for a Request message. In the case of a Request 418 message, it is followed by a sequence of Report blocks, each from a 419 router on the path toward the publisher or caching router. 421 At the beginning of PacketPayload TLVs, a top-level TLV type, 422 T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx 423 protocol message. This TLV indicates that the Name segment TLV(s) 424 and Reply block TLV(s) would follow in the Request or Reply message. 426 Code Type name 427 ============= ========================= 428 %x0000 Reserved [1] 429 %x0001 T_INTEREST [1] 430 %x0002 T_OBJECT [1] 431 %x0003 T_VALIDATION_ALG [1] 432 %x0004 T_VALIDATION_PAYLOAD [1] 433 %x0005 T_DISCOVERY 435 Figure 5: Top-Level Type Namespace 437 3.1. Request Message 439 When a CCNinfo user initiates a discovery request (e.g., via the 440 ccninfo command described in Appendix A), a CCNinfo Request message 441 is created and forwarded to its upstream router through the Incoming 442 face(s) determined by its FIB. 444 The Request message format is shown in Figure 6. It consists of a 445 fixed header, Request header block TLV (Figure 7), Report block 446 TLV(s) (Figure 12), Name TLV, and Request block TLV. Request header 447 block TLV and Report block TLV(s) are contained in the hop-by-hop 448 header, as those might change from hop to hop. Request block TLV is 449 encoded in the PacketPayload TLV by content forwarder as the protocol 450 message itself. The PacketType value of the Request message is 451 PT_CCNINFO_REQUEST (Figure 4). The Type value of the Top-Level type 452 namespace is T_DISCOVERY (Figure 5). 454 1 2 3 455 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 456 +---------------+---------------+---------------+---------------+ 457 | Version | PacketType | PacketLength | 458 +---------------+---------------+---------------+---------------+ 459 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 460 +===============+===============+===============+===============+ 461 / Request header block TLV / 462 +---------------+---------------+---------------+---------------+ 463 / Report block TLV 1 / 464 +---------------+---------------+---------------+---------------+ 465 / Report block TLV 2 / 466 +---------------+---------------+---------------+---------------+ 467 / . / 468 / . / 469 +---------------+---------------+---------------+---------------+ 470 / Report block TLV n / 471 +===============+===============+===============+===============+ 472 | Type (=T_DISCOVERY) | MessageLength | 473 +---------------+---------------+---------------+---------------+ 474 | T_NAME | Length | 475 +---------------+---------------+---------------+---------------+ 476 / Name segment TLVs (name prefix specified by CCNinfo user) / 477 +---------------+---------------+---------------+---------------+ 478 / Request block TLV / 479 +---------------+---------------+---------------+---------------+ 480 / Optional CCNx ValidationAlgorithm TLV / 481 +---------------+---------------+---------------+---------------+ 482 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 483 +---------------+---------------+---------------+---------------+ 485 Figure 6: Request message consists of a fixed header, Request block 486 TLV, Report block TLV(s), and Name TLV 488 HopLimit: 8 bits 490 HopLimit is a counter that is decremented with each hop whenever a 491 Request packet is forwarded. It is specified by the CCNinfo user 492 program. It limits the distance that a Request may travel on the 493 network. Only the specified number of hops from the CCNinfo user 494 traces the Request. Each router inserts its own Report block and 495 forwards the Request message to the upstream router(s). The last 496 router stops the trace and sends the Reply message back to the 497 CCNinfo user. 499 ReturnCode: 8 bits 500 ReturnCode is used for the Reply message. This value is replaced 501 by the content forwarder when the Request message is returned as 502 the Reply message (see Section 3.2). Until then, this field MUST 503 be transmitted as zeros and ignored on receipt. 505 Value Name Description 506 ----- --------------- ---------------------------------------------- 507 %x00 NO_ERROR No error 508 %x01 WRONG_IF CCNinfo Request arrived on an interface 509 to which this router would not forward for 510 the specified name/function toward the 511 publisher. 512 %x02 INVALID_REQUEST Invalid CCNinfo Request is received. 513 %x03 NO_ROUTE This router has no route for the name prefix 514 and no way to determine a route. 515 %x04 NO_INFO This router has no cache information for the 516 specified name prefix. 517 %x05 NO_SPACE There was not enough room to insert another 518 Report block in the packet. 519 %x06 INFO_HIDDEN Information is hidden from this discovery 520 owing to some policy. 521 %x0E ADMIN_PROHIB CCNinfo Request is administratively 522 prohibited. 523 %x0F UNKNOWN_REQUEST This router does not support/recognize the 524 Request message. 525 %x80 FATAL_ERROR In a fatal error, the router may know the 526 upstream router but cannot forward the 527 message to it. 529 Reserved (MBZ): 8 bits 531 The reserved fields in the Value field MUST be transmitted as 532 zeros and ignored on receipt. 534 3.1.1. Request Header Block and Request Block 536 When a CCNinfo user transmits the Request message, s/he MUST insert 537 her/his Request header block TLV (Figure 7) into the hop-by-hop 538 header and Request block TLV (Figure 10) into the message before 539 sending it through the Incoming face(s). 541 1 2 3 542 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 543 +---------------+---------------+---------------+---------------+ 544 | Type (=T_DISC_REQHDR) | Length | 545 +---------------+---------------+-------+-------+-------+-+-+-+-+ 546 | Request ID |SkipHop| Flags |V|F|O|C| 547 +---------------+---------------+-------+-------+-------+-+-+-+-+ 549 Figure 7: Request header block TLV (hop-by-hop header) 551 Code Type name 552 ============= ========================= 553 %x0000 Reserved [1] 554 %x0001 T_INTLIFE [1] 555 %x0002 T_CACHETIME [1] 556 %x0003 T_MSGHASH [1] 557 %x0004-%x0007 Reserved [1] 558 %x0008 T_DISC_REQHDR 559 %x0009 T_DISC_REPORT 560 %x0FFE T_PAD [1] 561 %x0FFF T_ORG [1] 562 %x1000-%x1FFF Reserved [1] 564 Figure 8: Hop-by-Hop Type Namespace 566 Type: 16 bits 568 Format of the Value field. For the type value of the Request 569 block TLV MUST be T_DISC_REQHDR. 571 Length: 16 bits 573 Length of Value field in octets. 575 Request ID: 16 bits 577 This field is used as a unique identifier for the CCNinfo Request 578 so that the duplicate or delayed Reply messages can be detected. 580 SkipHop (Skip Hop Count): 4 bits 582 Number of skipped routers for a Request. It is specified by the 583 CCNinfo user program. The number of routers corresponding to the 584 value specified in this field are skipped and the CCNinfo Request 585 messages are forwarded to the next router without the addition of 586 Report blocks; the next upstream router then starts the trace. 587 The maximum value of this parameter is 15. This value MUST be 588 lower than that of HopLimit at the fixed header. 590 Flags: 12 bits 592 The Flags field is used to indicate the types of the content or 593 path discoveries. Currently, as shown in Figure 9, four bits, 594 "C", "O", "F", and "V" are assigned, and the other 8 bits are 595 reserved (MBZ) for the future use. Each flag can be mutually 596 specified with other flags. These flags are set by the CCNinfo 597 user program when they initiate Requests (see Appendix A), and the 598 routers that receive the Requests deal with the flags and change 599 the behaviors (see Section 5 for details). The Flag values 600 defined in this Flags field correspond to the Reply sub-blocks. 602 Flag Value Description 603 ----- ----- ----------------------------------------------------- 604 C 0 Path discovery (i.e., no cache information retrieved) 605 (default) 606 C 1 Path and cache information retrieval 607 O 0 Request to any content forwarder (default) 608 O 1 Publisher discovery (i.e., only FHR can reply) 609 F 0 Request based on FIB's forwarding strategy (default) 610 F 1 Full discovery request. Request to possible multiple 611 upstream routers specified in FIB simultaneously 612 V 0 No reply validation (default) 613 V 1 Reply sender validates Reply message 615 Figure 9: Codes and types specified in Flags field 617 1 2 3 618 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 619 +---------------+---------------+---------------+---------------+ 620 | Type (=T_DISC_REQ) | Length | 621 +---------------+---------------+---------------+---------------+ 622 | Request Arrival Time | 623 +---------------+---------------+---------------+---------------+ 624 / Node Identifier / 625 +---------------+---------------+---------------+---------------+ 627 Figure 10: Request block TLV (packet payload) 628 Code Type name 629 ============== =================== 630 %x0000 T_NAME [1] 631 %x0001 T_PAYLOAD [1] 632 %x0002 T_KEYIDRESTR [1] 633 %x0003 T_OBJHASHRESTR [1] 634 %x0005 T_PAYLDTYPE [1] 635 %x0006 T_EXPIRY [1] 636 %x0007 T_DISC_REQ 637 %x0008 T_DISC_REPLY 638 %x0009-%x0012 Reserved [1] 639 %x0FFE T_PAD [1] 640 %x0FFF T_ORG [1] 641 %x1000-%x1FFF Reserved [1] 643 Figure 11: CCNx Message Type Namespace 645 Type: 16 bits 647 Format of the Value field. For the Request block TLV, the type 648 value(s) MUST be T_DISC_REQ (see Figure 11) in the current 649 specification. 651 Length: 16 bits 653 Length of Value field in octets. 655 Request Arrival Time: 32 bits 657 The Request Arrival Time is a 32-bit NTP timestamp specifying the 658 arrival time of the CCNinfo Request message at the router. The 659 32-bit form of an NTP timestamp consists of the middle 32 bits of 660 the full 64-bit form; that is, the low 16 bits of the integer part 661 and the high 16 bits of the fractional part. 663 The following formula converts from a timespec (fractional part in 664 nanoseconds) to a 32-bit NTP timestamp: 666 request_arrival_time 667 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 669 The constant 32384 is the number of seconds from Jan 1, 1900 to 670 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 671 is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" 672 denotes a logical left shift. 674 Note that it is RECOMMENDED for all the routers on the path to 675 have synchronized clocks to measure one-way latency per hop; 676 however, even if they do not have synchronized clocks, CCNinfo 677 measures the RTT between the content forwarder and consumer. 679 Node Identifier: variable length 681 This field specifies the node identifier (e.g., node name or hash- 682 based self-certifying name [11]) or all-zeros if unknown. This 683 document assumes that the Name TLV defined in the CCNx TLV format 684 [1] can be used for this field and the node identifier is 685 specified in it. 687 3.1.2. Report Block TLV 689 A CCNinfo user and each upstream router along the path would insert 690 their own Report block TLV without changing the Type field of the 691 fixed header of the Request message until one of these routers is 692 ready to send a Reply. In the Report block TLV (Figure 12), the 693 Request Arrival Time and Node Identifier MUST be inserted. 695 1 2 3 696 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 697 +---------------+---------------+---------------+---------------+ 698 | Type (=T_DISC_REPORT) | Length | 699 +---------------+---------------+---------------+---------------+ 700 | Request Arrival Time | 701 +---------------+---------------+---------------+---------------+ 702 / Node Identifier / 703 +---------------+---------------+---------------+---------------+ 705 Figure 12: Report block TLV (hop-by-hop header) 707 Type: 16 bits 709 Format of the Value field. For the Report block TLV, the type 710 value(s) MUST be T_DISC_REPORT in the current specification. For 711 all the available types for hop-by-hop type namespace, please see 712 Figure 8. 714 Length: 16 bits 716 Length of Value field in octets. 718 Request Arrival Time: 32 bits 720 Same definition as given in Section 3.1.1. 722 Node Identifier: variable length 723 Same definition as given in Section 3.1.1. 725 3.1.3. Content Name Specification 727 Specifications of the Name TLV (whose type value is T_NAME) and the 728 Name Segment TLVs are described in [1], which are followed by 729 CCNinfo. CCNinfo enables to specification of the content name either 730 with a prefix name without chunk number (such as "ccnx:/news/today") 731 or an exact name (such as "ccnx:/news/today/Chunk=10"). When a 732 CCNinfo user specifies a prefix name, s/he will obtain the summary 733 information of the matched content objects in the content forwarder. 734 In contrast, when a CCNinfo user specifies an exact name, s/he will 735 obtain only about the specified content object in the content 736 forwarder. A CCNinfo Request message MUST NOT be sent only with a 737 scheme name, ccnx:/. It will be rejected and discarded by routers. 739 3.2. Reply Message 741 When a content forwarder receives a CCNinfo Request message from an 742 appropriate adjacent neighbor router, it inserts its own Reply block 743 TLV and Reply sub-block TLV(s) to the Request message and turns the 744 Request into the Reply by changing the Type field of the fixed header 745 of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. 746 The Reply message (see Figure 13) is then forwarded back toward the 747 CCNinfo user in a hop-by-hop manner. 749 1 2 3 750 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 751 +---------------+---------------+---------------+---------------+ 752 | Version | PacketType | PacketLength | 753 +---------------+---------------+-------------+-+---------------+ 754 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 755 +===============+===============+=============+=+===============+ 756 / Request header block TLV / 757 +---------------+---------------+---------------+---------------+ 758 / . / 759 / . / 760 / n Report block TLVs / 761 / . / 762 / . / 763 +===============+===============+===============+===============+ 764 | Type (=T_DISCOVERY) | MessageLength | 765 +---------------+---------------+---------------+---------------+ 766 | T_NAME | Length | 767 +---------------+---------------+---------------+---------------+ 768 / Name segment TLVs (name prefix specified by CCNinfo user) / 769 +---------------+---------------+---------------+---------------+ 770 / Request block TLV / 771 +---------------+---------------+---------------+---------------+ 772 / Reply block TLV / 773 +---------------+---------------+---------------+---------------+ 774 / Reply sub-block TLV 1 / 775 +---------------+---------------+---------------+---------------+ 776 / . / 777 / . / 778 +---------------+---------------+---------------+---------------+ 779 / Reply sub-block TLV k / 780 +---------------+---------------+---------------+---------------+ 781 / Optional CCNx ValidationAlgorithm TLV / 782 +---------------+---------------+---------------+---------------+ 783 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 784 +---------------+---------------+---------------+---------------+ 786 Figure 13: Reply message consists of a fixed header, Request block 787 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 789 3.2.1. Reply Block TLV 791 The Reply block TLV is an envelope for the Reply sub-block TLV(s) 792 (explained from the next section). 794 1 2 3 795 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 796 +---------------+---------------+---------------+---------------+ 797 | Type (=T_DISC_REPLY) | Length | 798 +---------------+---------------+---------------+---------------+ 799 | Request Arrival Time | 800 +---------------+---------------+---------------+---------------+ 801 / Node Identifier / 802 +---------------+---------------+---------------+---------------+ 804 Figure 14: Reply block TLV (packet payload) 806 Type: 16 bits 808 Format of the Value field. For the Reply block TLV, the type 809 value MUST be T_DISC_REPLY shown in Figure 11 in the current 810 specification. 812 Length: 16 bits 814 Length of the Value field in octets. This length is the total 815 length of Reply sub-block(s). 817 Request Arrival Time: 32 bits 819 Same definition as given in Section 3.1.1. 821 Node Identifier: variable length 823 Same definition as given in Section 3.1.1. 825 3.2.1.1. Reply Sub-Block TLV 827 The router on the traced path will add one or multiple Reply sub- 828 blocks followed by the Reply block TLV before sending the Reply to 829 its neighbor router. This section describes the Reply sub-block TLV 830 for informing various cache states and conditions as shown in 831 Figure 15. (Other Reply sub-block TLVs will be discussed in separate 832 document(s).) 834 Note that some routers may not be capable of reporting the following 835 values, such as Object Size, Object Count, # Received Interest, First 836 Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, 837 shown in Figure 15, or do not report these values due to their 838 policy. In that case, the routers set these fields to a value of one 839 (i.e., %xFFFFFFFF). The value of each field will be also all-one 840 when the value is equal to or bigger than the maximum size expressed 841 by the 32-bit field. The CCNinfo user program MUST inform that these 842 values are not valid if the fields received are set to the value of 843 one. 845 If the cache is refreshed after reboot, the value in each field MUST 846 be refreshed (i.e., MUST be set to 0). If the cache remains after 847 reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as 848 it is). 850 1 2 3 851 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 852 +---------------+---------------+---------------+---------------+ 853 | Type | Length | 854 +---------------+---------------+---------------+---------------+ 855 | Object Size | 856 +---------------+---------------+---------------+---------------+ 857 | Object Count | 858 +---------------+---------------+---------------+---------------+ 859 | # Received Interest | 860 +---------------+---------------+---------------+---------------+ 861 | First Seqnum | 862 +---------------+---------------+---------------+---------------+ 863 | Last Seqnum | 864 +---------------+---------------+---------------+---------------+ 865 | Elapsed Cache Time | 866 +---------------+---------------+---------------+---------------+ 867 | Remain Cache Lifetime | 868 +---------------+---------------+---------------+---------------+ 869 | T_NAME | Length | 870 +---------------+---------------+---------------+---------------+ 871 / Name Segment TLVs / 872 +---------------+---------------+---------------+---------------+ 874 Figure 15: Reply sub-block TLV for T_DISC_CONTENT and 875 T_DISC_CONTENT_PUBLISHER (packet payload) 877 Code Type name 878 ============= =========================== 879 %x0000 T_DISC_CONTENT 880 %x0001 T_DISC_CONTENT_PUBLISHER 881 %x0FFF T_ORG 882 %x1000-%x1FFF Reserved (Experimental Use) 884 Figure 16: CCNinfo Reply Type Namespace 886 Type: 16 bits 888 Format of the Value field. For the Reply sub-block TLV, the type 889 value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER 890 defined in the CCNinfo Reply Type Namespace (Figure 16). 891 T_DISC_CONTENT is specified when the cache information is replied 892 from a caching router. T_DISC_CONTENT_PUBLISHER is specified when 893 the content information is replied from a FHR attached to a 894 publisher. 896 Length: 16 bits 898 Length of the Value field in octets. 900 Object Size: 32 bits 902 The total size (KB) of the unexpired content objects. Note that 903 the maximum size expressed by the 32-bit field is approximately 904 4.29 TB. 906 Object Count: 32 bits 908 The number of the unexpired content objects. Note that the 909 maximum count expressed by the 32-bit field is approximately 4.29 910 billion. 912 # Received Interest: 32 bits 914 The total number of the received Interest messages to retrieve the 915 cached content objects. 917 First Seqnum: 32 bits 919 The first sequential number of the unexpired content objects. 921 Last Seqnum: 32 bits 923 The last sequential number of the unexpired content objects. The 924 First Seqnum and Last Seqnum do not guarantee the consecutiveness 925 of the cached content objects; however, knowing these values may 926 help in the analysis of consecutive or discontinuous chunks such 927 as [12]. 929 Elapsed Cache Time: 32 bits 931 The elapsed time (seconds) after the oldest content object of the 932 content is cached. 934 Remain Cache Lifetime: 32 bits 936 The lifetime (seconds) of a content object, which is lastly 937 cached. 939 4. CCNinfo User Behavior 941 4.1. Sending CCNinfo Request 943 A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) 944 that initiates a CCNinfo Request message and sends it to the user's 945 adjacent neighbor router(s) of interest. The user later obtains both 946 the routing path information and in-network cache information in the 947 single Reply. 949 When the CCNinfo user program initiates a Request message, it MUST 950 insert the necessary values, i.e., the "Request ID" and the "Node 951 Identifier", in the Request block. The Request ID MUST be unique for 952 the CCNinfo user until s/he receives the corresponding Reply 953 message(s) or the Request is timed out. 955 Owing to some policies, a router may want to validate the CCNinfo 956 Requests using the CCNx ValidationPayload TLV (whether it accepts the 957 Request or not) especially when the router receives the "full 958 discovery request" (see Section 5.3.2). Accordingly, the CCNinfo 959 user program MAY require validating the Request message and appending 960 the user's signature into the CCNx ValidationPayload TLV. The router 961 then forwards the Request message. If the router does not approve 962 the Request, it rejects the Request message as described in 963 Section 6.11. 965 After the CCNinfo user program sends the Request message, until the 966 Reply is timed out or the expected numbers of Replies or a Reply 967 message with a non-zero ReturnCode in the fixed header is received, 968 the CCNinfo user program MUST keep the following information: 969 HopLimit, specified in the fixed header, Request ID, Flags, Node 970 Identifier, and Request Arrival Time, specified in the Request block. 972 4.1.1. Routing Path Information 974 A CCNinfo user can send a CCNinfo Request for investigating the 975 routing path information for the specified named content. Using the 976 Request, a legitimate user can obtain 1) the node identifiers of the 977 intermediate routers, 2) node identifier of the content forwarder, 3) 978 number of hops between the content forwarder and consumer, and 4) RTT 979 between the content forwarder and consumer, per name prefix. This 980 CCNinfo Request is terminated when it reaches the content forwarder. 982 4.1.2. In-Network Cache Information 984 A CCNinfo user can send a CCNinfo Request for investigating in- 985 network cache information. Using the Request, a legitimate user can 986 obtain 1) the size of cached content objects, 2) number of cached 987 content objects, 3) number of accesses (i.e., received Interests) per 988 content, and 4) lifetime and expiration time of the cached content 989 objects, for Content Store (CS) in the content forwarder, unless the 990 content forwarder is capable of reporting them (see Section 3.2.1.1). 991 This CCNinfo Request is terminated when it reaches the content 992 forwarder. 994 4.2. Receiving CCNinfo Reply 996 A CCNinfo user program will receive one or multiple CCNinfo Reply 997 messages from the adjacent neighbor router(s). When the program 998 receives the Reply, it MUST compare the kept Request ID and Node 999 Identifier to identify the Request and Reply pair. If they do not 1000 match, the Reply message MUST be silently discarded. 1002 If the number of Report blocks in the received Reply is more than the 1003 initial HopLimit value (which was inserted in the original Request), 1004 the Reply MUST be silently ignored. 1006 After the CCNinfo user has determined that s/he has traced the whole 1007 path or the maximum path that s/he can be expected to, s/he might 1008 collect statistics by waiting for a timeout. Useful statistics 1009 provided by CCNinfo are stated in Section 8. 1011 5. Router Behavior 1013 5.1. User and Neighbor Verification 1015 Upon receiving a CCNinfo Request message, a router MAY examine 1016 whether a valid CCNinfo user has sent the message. If the router 1017 recognizes that the Request sender's signature specified in the 1018 Request is invalid, it SHOULD terminate the Request, as defined in 1019 Section 6.4. 1021 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 1022 whether the message comes from a valid adjacent neighbor node. If 1023 the router recognizes that the Request/Reply sender is invalid, it 1024 SHOULD silently ignore the Request/Reply message, as specified in 1025 Section 10.9. 1027 5.2. Receiving CCNinfo Request 1029 After a router accepts the CCNinfo Request message, it performs the 1030 following steps. 1032 1. The value of "HopLimit" in the fixed header and that of "SkipHop 1033 (Skip Hop Count)" in the Request block are counters that are 1034 decremented with each hop. If the HopLimit value is zero, the 1035 router terminates the Request, as defined in Section 6.5. If the 1036 SkipHop value is equal to or more than the HopLimit value, the 1037 router terminates the Request, as defined in Section 6.4. 1038 Otherwise, until the SkipHop value becomes zero, the router 1039 forwards the Request message to the upstream router(s) without 1040 adding its own Report block and without replying to the Request. 1041 If the router does not know the upstream router(s) regarding the 1042 specified name prefix, it terminates the Request, as defined in 1043 Section 6.5. It should be noted that the Request messages are 1044 terminated at the FHR; therefore, although the maximum value for 1045 the HopLimit is 255 and that for SkipHop is 15, if the Request 1046 messages reach the FHR before the HopLimit or SkipHop value 1047 becomes 0, the FHR silently discards the Request message and the 1048 Request is timed out. 1050 2. The router examines the Flags field (specified in Figure 9) in 1051 the Request block of the received CCNinfo Request. If the "C" 1052 flag is not set, it is categorized as the "routing path 1053 information discovery". If the "C" flag is set, it is the "cache 1054 information discovery". If the "O" flag is set, it is the 1055 "publisher discovery". 1057 3. If the Request is either "cache information discovery" or 1058 "routing path information discovery", the router examines its FIB 1059 and CS. If the router caches the specified content, it sends the 1060 Reply message with its own Reply block and sub-block(s). If the 1061 router cannot insert its own Reply block or sub-block(s) because 1062 of no space, it terminates the Request, as specified in 1063 Section 6.7. If the router does not cache the specified content 1064 but knows the upstream neighbor router(s) for the specified name 1065 prefix, it creates the PIT entry, and inserts its own Report 1066 block in the hop-by-hop header and forwards the Request to the 1067 upstream neighbor(s). If the router cannot insert its own Report 1068 block because of no space, or if the router does not cache the 1069 specified content and does not know the upstream neighbor 1070 router(s) for the specified name prefix, it terminates the 1071 Request, as defined in Section 6.5. 1073 4. If the Request is the "publisher discovery", the router examines 1074 whether it is the FHR for the requested content. If the router 1075 is the FHR, it sends the Reply message with its own Report block 1076 and sub-blocks (in the case of cache information discovery) or 1077 the Reply message with its own Report block without adding any 1078 Reply sub-blocks (in the case of routing path information 1079 discovery). If the router is not the FHR but knows the upstream 1080 neighbor router(s) for the specified name prefix, it creates the 1081 PIT entry, and inserts its own Report block and forwards the 1082 Request to the upstream neighbor(s). If the router cannot insert 1083 its own Report block in the hop-by-hop header because of no 1084 space, it terminates the Request, as specified in Section 6.7. 1085 If the router is not the FHR and does not know the upstream 1086 neighbor router(s) for the specified name prefix, it terminates 1087 the Request, as defined in Section 6.5. Note that in Cefore 1088 [14], there is an API by which a publisher informs the 1089 application prefix to the FHR and the FHR registers it into the 1090 FIB. The prefix entry then can be statically configured on other 1091 routers or announced by a routing protocol. 1093 5.3. Forwarding CCNinfo Request 1095 5.3.1. Regular Request 1097 When a router decides to forward a Request message with its Report 1098 block to its upstream router(s), it specifies the Request Arrival 1099 Time and Node Identifier in the Report block of the Request message. 1100 The router then forwards the Request message upstream toward the 1101 publisher or caching router based on the FIB entry like the ordinary 1102 Interest-Data exchanges in CCN. 1104 When the router forwards the Request message, it MUST record the F 1105 flag and Request ID in the Request block of the Request message and 1106 exploiting path labels (specified in Section 1) at the corresponding 1107 PIT entry. The router can later check the PIT entry to correctly 1108 forward the Reply message(s) back. 1110 CCNinfo supports multipath forwarding. The Request messages can be 1111 forwarded to multiple neighbor routers. Some routers may have a 1112 strategy for multipath forwarding; when a router sends Interest 1113 messages to multiple neighbor routers, it may delay or prioritize to 1114 send the message to the upstream routers. The CCNinfo Request, as 1115 the default, complies with such strategies; a CCNinfo user could 1116 trace the actual forwarding path based on the forwarding strategy and 1117 will receive a single Reply message such as a content object. 1119 5.3.2. Full Discovery Request 1121 There may be a case wherein a CCNinfo user wants to discover all 1122 possible forwarding paths and content forwarders based on the 1123 routers' FIBs. The "full discovery request" enables this 1124 functionality. If a CCNinfo user sets the F flag in the Request 1125 block of the Request message (as seen in Figure 9) to request the 1126 full discovery, the upstream routers simultaneously forward the 1127 Requests to all multiple upstream routers based on the FIBs. Then, 1128 the CCNinfo user can trace all possible forwarding paths. 1130 3. Reply(C) 2. Reply(C) 1131 3. Reply(P) 2. Reply(P) 1. Reply(P) 1132 +----+ +----+ +----+ 1133 | | | | | | 1134 v | v | v | 1135 +--------+ +--------+ +--------+ +--------+ +---------+ 1136 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 1137 | user | | A | | B | | C | | | 1138 +--------+ +--------+ +--------+ +--------+ +---------+ 1139 ^ 1140 \ +-------+ 1141 1. Reply(C) \ | Cache | 1142 \ +---------+ | 1143 \| Caching |----+ 1144 | router | 1145 +---------+ 1147 Figure 17: Full discovery request. Reply messages forwarded by 1148 publisher and routers. Each router forwards the Reply message along 1149 its PIT entry and finally, the CCNinfo user receives two Reply 1150 messages: one from the FHR (Router C) and the other from the Caching 1151 router. 1153 To receive different Reply messages forwarded from different routers, 1154 the PIT entries initiated by CCNinfo remain until the configured 1155 CCNinfo Reply Timeout (Section 7.1) is expired. In other words, 1156 unlike the ordinary Interest-Data exchanges in CCN, if routers that 1157 accept the full discovery request receive the full discovery request, 1158 the routers SHOULD NOT remove the PIT entry created by the full 1159 discovery request until the CCNinfo Reply Timeout value expires. 1161 Note that the full discovery request is an OPTIONAL implementation of 1162 CCNinfo; it may not be implemented on routers. Even if it is 1163 implemented on a router, it may not accept the full discovery request 1164 from non-validated CCNinfo users or routers or because of its policy. 1165 If a router does not accept the full discovery request, it rejects 1166 the full discovery request as described in Section 6.11. Routers 1167 that enable the full discovery request MAY rate-limit Replies, as 1168 described in Section 10.8 as well. 1170 5.4. Sending CCNinfo Reply 1172 If there is a caching router or FHR for the specified content within 1173 the specified hop count along the path, the caching router or FHR 1174 sends back the Reply message toward the CCNinfo user and terminates 1175 the Request. 1177 When a router decides to send a Reply message to its downstream 1178 neighbor router or the CCNinfo user with NO_ERROR return code, it 1179 inserts a Report block with the Request Arrival Time and Node 1180 Identifier to the Request message. Then, the router inserts the 1181 corresponding Reply sub-block(s) (Figure 15) to the payload. The 1182 router finally changes the Type field in the fixed header from 1183 PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back 1184 as the Reply toward the CCNinfo user in a hop-by-hop manner. 1186 If a router cannot continue the Request, the router MUST put an 1187 appropriate ReturnCode in the Request message, change the Type field 1188 value in the fixed header from PT_CCNINFO_REQUEST to 1189 PT_CCNINFO_REPLY, and forward the Reply message back toward the 1190 CCNinfo user to terminate the Request (see Section 6). 1192 5.5. Forwarding CCNinfo Reply 1194 When a router receives a CCNinfo Reply whose Request ID and Node 1195 Identifier match those in the PIT entry, sent from a valid adjacent 1196 neighbor router, it forwards the CCNinfo Reply back toward the 1197 CCNinfo user. If the router does not receive the corresponding Reply 1198 within the [CCNinfo Reply Timeout] period, then it removes the 1199 corresponding PIT entry and terminates the trace. 1201 The Flags field in the Request block TLV is used to indicate whether 1202 the router keeps the PIT entry during the CCNinfo Reply Timeout even 1203 after one or more corresponding Reply messages are forwarded. When 1204 the CCNinfo user does not set the F flag (i.e., "0"), the 1205 intermediate routers immediately remove the PIT entry whenever they 1206 forward the corresponding Reply message. When the CCNinfo user sets 1207 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1208 "full discovery request" (see Section 5.3.2), the intermediate 1209 routers keep the PIT entry within the [CCNinfo Reply Timeout] period. 1210 After this timeout, the PIT entry is removed. 1212 CCNinfo Replies MUST NOT be cached in routers upon the transmission 1213 of Reply messages. 1215 5.6. PIT Entry Management for Multipath Support 1217 Within a network with multipath condition, there is a case 1218 (Figure 18) wherein a single CCNinfo Request is split into multiple 1219 Requests (e.g., at Router A), which are injected into a single router 1220 (Router D). In this case, multiple Replies with the same Request ID 1221 and Node Identifier including different Report blocks are received by 1222 the router (Router D). 1224 +--------+ 1225 | Router | 1226 | B | 1227 +--------+ 1228 / \ 1229 / \ 1230 +--------+ +--------+ +--------+ +---------+ 1231 | CCNinfo|----| Router | | Router | ... |Publisher| 1232 | user | | A | | D | | | 1233 +--------+ +--------+ +--------+ +---------+ 1234 \ / 1235 \ / 1236 +--------+ 1237 | Router | 1238 | C | 1239 +--------+ 1241 Figure 18 1243 To recognize different CCNinfo Reply messages, the routers MUST 1244 distinguish the PIT entries by the Request ID and exploiting path 1245 labels, which could be a hash value of the concatenation information 1246 of the cumulate Node Identifiers in the hop-by-hop header and the 1247 specified content name. For example, when Router D in Figure 18 1248 receives a CCNinfo Request from Router B, its PIT includes the 1249 Request ID and value such as H((Router_A|Router_B)|content_name), 1250 where "H" indicates some hash function and "|" indicates 1251 concatenation. When Router D receives a CCNinfo Request from Router 1252 C, its PIT includes the same Request ID and value of 1253 H((Router_A|Router_C)|content_name). Two different Replies are later 1254 received on Router D and each Reply is appropriately forwarded to 1255 Router B and Router C, respectively. Note that two Reply messages 1256 coming from Router B and Router C are reached at Router A, but the 1257 CCNinfo user can only receive the first Reply message either from 1258 Router B or Router C as Router A removes the corresponding PIT entry 1259 after it forwards the first Reply. 1261 To avoid routing loop, when a router seeks the cumulate Node 1262 Identifiers of the Report blocks in the hop-by-hop header, it MUST 1263 examine whether its own Node Identifier is not previously inserted. 1264 If a router detects its own Node Identifier in the hop-by-hop header, 1265 the router inserts its Report block and terminates the Request as 1266 will be described in Section 6.8. 1268 6. CCNinfo Termination 1270 When performing a hop-by-hop trace, it is necessary to determine when 1271 to stop the trace. There are several cases when an intermediate 1272 router might return a Reply before a Request reaches the caching 1273 router or the FHR. 1275 6.1. Arriving at First-hop Router 1277 A CCNinfo Request can be determined to have arrived at the FHR. To 1278 ensure that a router recognizes that it is the FHR for the specified 1279 content, it needs to have a FIB entry (or attach) to the 1280 corresponding publisher or the content. 1282 6.2. Arriving at Router Having Cache 1284 A CCNinfo Request can be determined to have arrived at the router 1285 having the specified content cache within the specified HopLimit. 1287 6.3. Arriving at Last Router 1289 A CCNinfo Request can be determined to have arrived at the last 1290 router of the specified HopLimit. If the last router does not have 1291 the corresponding cache, it MUST insert its Report block and send the 1292 Reply message with NO_INFO return code without appending any Reply 1293 (sub-)block TLVs. 1295 6.4. Invalid Request 1297 If the router does not validate the Request or the Reply even it is 1298 required, the router MUST note a ReturnCode of INVALID_REQUEST in the 1299 fixed header of the message, insert its Report block, and forward the 1300 message as the Reply back to the CCNinfo user. The router MAY, 1301 however, randomly ignore the received invalid messages. (See 1302 Section 10.7.) 1304 6.5. No Route 1306 If the router cannot determine the routing paths or neighbor routers 1307 for the specified name prefix within the specified HopLimit, it MUST 1308 note a ReturnCode of NO_ROUTE in the fixed header of the message, 1309 insert its Report block, and forward the message as the Reply back to 1310 the CCNinfo user. 1312 6.6. No Information 1314 If the router does not have any information about the specified name 1315 prefix within the specified HopLimit, it MUST note a ReturnCode of 1316 NO_INFO in the fixed header of the message, insert its Report block, 1317 and forward the message as the Reply back to the CCNinfo user. 1319 6.7. No Space 1321 If appending the Report block or the Reply (sub-)block would make the 1322 hop-by-hop header longer than 247 bytes or the Request packet longer 1323 than the MTU of the Incoming face, the router MUST note a ReturnCode 1324 of NO_SPACE in the fixed header of the message and forward the 1325 message as the Reply back to the CCNinfo user. 1327 6.8. Fatal Error 1329 If a CCNinfo Request has encountered a fatal error, the router MUST 1330 note a ReturnCode of FATAL_ERROR in the fixed header of the message 1331 and forward the message as the Reply back to the CCNinfo user. This 1332 may happen, for example, when the router detects some routing loop in 1333 the Request blocks (see Section 1). The fatal error can be encoded 1334 with another error: if a router detects routing loop but cannot 1335 insert its Report block, it MUST note NO_SPACE and FATAL_ERROR 1336 ReturnCodes (i.e., %x85) in the fixed header and forward the message 1337 back to the CCNinfo user. 1339 6.9. CCNinfo Reply Timeout 1341 If a router receives the Request or Reply message that expires its 1342 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1343 silently discard the Request or Reply message. 1345 6.10. Non-Supported Node 1347 Cases will arise in which a router or a FHR along the path does not 1348 support CCNinfo. In such cases, a CCNinfo user and routers that 1349 forward the CCNinfo Request will time out the CCNinfo request. 1351 6.11. Administratively Prohibited 1353 If CCNinfo is administratively prohibited, the router rejects the 1354 Request message and MUST send the CCNinfo Reply with the ReturnCode 1355 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1356 Request messages to be rejected (see Section 10.7). 1358 7. Configurations 1360 7.1. CCNinfo Reply Timeout 1362 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1363 Reply. The value for a router can be statically configured by the 1364 router's administrators/operators. The default value is 3 (seconds). 1365 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 1366 (seconds) and SHOULD NOT be lower than 2 (seconds). 1368 7.2. HopLimit in Fixed Header 1370 If a CCNinfo user does not specify the HopLimit value in the fixed 1371 header for a Request message as the HopLimit, the HopLimit is set to 1372 32. Note that 0 HopLimit is an invalid Request; hence, the router in 1373 this case follows the way defined in Section 6.4. 1375 7.3. Access Control 1377 A router MAY configure the valid or invalid networks to enable an 1378 access control. The access control MAY be defined per name prefix, 1379 such as "who can retrieve which name prefix" (see Section 10.2). 1381 8. Diagnosis and Analysis 1383 8.1. Number of Hops and RTT 1385 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1386 each forwarding router appends its own Report block. We can then 1387 verify the number of hops to reach the content forwarder or publisher 1388 and the RTT between the content forwarder or publisher. 1390 8.2. Caching Router Identification 1392 While some routers may hide their node identifiers with all-zeros in 1393 the Report blocks (as seen in Section 10.1), the routers in the path 1394 from the CCNinfo user to the content forwarder can be identified. 1396 8.3. TTL or Hop Limit 1398 By taking the HopLimit from the content forwarder and forwarding the 1399 TTL threshold over all hops, it is possible to discover the TTL or 1400 hop limit required for the content forwarder to reach the CCNinfo 1401 user. 1403 8.4. Time Delay 1405 If the routers have synchronized clocks, it is possible to estimate 1406 the propagation and queuing delays from the differences between the 1407 timestamps at the successive hops. However, this delay includes the 1408 control processing overhead; therefore, it is not necessarily 1409 indicative of the delay that would be experienced by the data 1410 traffic. 1412 8.5. Path Stretch 1414 By obtaining the path stretch "d / P", where "d" is the hop count of 1415 the data and "P" is the hop count from the consumer to the publisher, 1416 we can measure the improvements in path stretch in various cases, 1417 such as in different caching and routing algorithms. We can then 1418 facilitate the investigation of the performance of the protocol. 1420 8.6. Cache Hit Probability 1422 CCNinfo can show the number of received interests per cache or chunk 1423 on a router. Accordingly, CCNinfo measures the content popularity 1424 (i.e., the number of accesses for each content/cache), thereby 1425 enabling the investigation of the routing/caching strategy in 1426 networks. 1428 9. IANA Considerations 1430 New assignments can only be made via a Standards Action as specified 1431 in [5]. This document does not intend to be the standard document. 1432 However, the new assignments such as the ReturnCode and various type 1433 values will be considered when this specification becomes the RFC. 1435 10. Security Considerations 1437 This section addresses some of the security considerations. 1439 10.1. Policy-Based Information Provisioning for Request 1441 Although CCNinfo gives excellent troubleshooting cues, some network 1442 administrators or operators may not want to disclose everything about 1443 their network to the public or may wish to securely transmit private 1444 information to specific members of their networks. CCNinfo provides 1445 policy-based information provisioning, thereby allowing network 1446 administrators to specify their response policy for each router. 1448 The access policy regarding "who is allowed to retrieve" and/or "what 1449 kind of cache information" can be defined for each router. For the 1450 former type of access policy, routers with the specified content MAY 1451 examine the signature enclosed in the Request message and decide 1452 whether they should notify the content information in the Reply. If 1453 the routers decide to not notify the content information, they MUST 1454 send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1455 appending any Reply (sub-)block TLVs. For the latter type of policy, 1456 the permission, whether (1) All (all cache information is disclosed), 1457 (2) Partial (cache information with a particular name prefix can (or 1458 cannot) be disclosed), or (3) Deny (no cache information is 1459 disclosed), is defined at the routers. 1461 In contrast, we entail that each router does not disrupt the 1462 forwarding of CCNinfo Request and Reply messages. When a Request 1463 message is received, the router SHOULD insert the Report block if the 1464 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1465 the Node Identifier field in the Report block MAY be null (i.e., all- 1466 zeros), but the Request Arrival Time field SHOULD NOT be null. 1467 Finally, the router SHOULD forward the Request message to the 1468 upstream router toward the content forwarder if the ReturnCode is 1469 kept with NO_ERROR. 1471 10.2. Filtering CCNinfo Users Located in Invalid Networks 1473 A router MAY support an access control mechanism to filter out 1474 Requests from invalid CCNinfo users. To accomplish this, invalid 1475 networks (or domains) could, for example, be configured via a list of 1476 allowed/disallowed networks (as observed in Section 7.3). If a 1477 Request is received from a disallowed network (according to the Node 1478 Identifier in the Request block), the Request MUST NOT be processed 1479 and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to 1480 note that. The router MAY, however, perform rate limited logging of 1481 such events. 1483 10.3. Topology Discovery 1485 CCNinfo can be used to discover actively used topologies. If a 1486 network topology is not disclosed, CCNinfo Requests SHOULD be 1487 restricted at the border of the domain using the ADMIN_PROHIB return 1488 code. 1490 10.4. Characteristics of Content 1492 CCNinfo can be used to discover the type of content being sent by 1493 publishers. If this information is a secret, CCNinfo Requests SHOULD 1494 be restricted at the border of the domain, using the ADMIN_PROHIB 1495 return code. 1497 10.5. Computational Attacks 1499 CCNinfo may impose heavy tasks at content forwarders because it makes 1500 content forwarders seek their internal cache states reported in the 1501 Reply messages whenever they form the Reply messages. The current 1502 CCNinfo specification allows to return null values for several 1503 fields, such as First/Last Seqnum or Elapsed Cache Time fields in the 1504 Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY 1505 be null. This means that the content forwarder can not only hide 1506 these values owing to privacy/security policies, but also skip the 1507 implementations of the complex functions to report these values. 1509 10.6. Longer or Shorter CCNinfo Reply Timeout 1511 Routers can configure CCNinfo Reply Timeout (Section 7.1), which is 1512 the allowable timeout value to keep the PIT entry. If routers 1513 configure a longer timeout value, there may be an attractive attack 1514 vector against the PIT memory. Moreover, especially when the full 1515 discovery request option (Section 5.3) is specified for the CCNinfo 1516 Request, several Reply messages may be returned and cause a response 1517 storm. (See Section 10.8 for rate-limiting to avoid the storm). To 1518 avoid DoS attacks, routers MAY configure the timeout value, which is 1519 shorter than the user-configured CCNinfo timeout value. However, if 1520 it is too short, the Request may be timed out and the CCNinfo user 1521 does not receive all Replies; s/he only retrieves the partial path 1522 information (i.e., information about a part of the tree). 1524 There may be a way to enable incremental exploration (i.e., to 1525 explore the part of the tree that was not explored by the previous 1526 operation); however, discussing such mechanisms is out of scope of 1527 this document. 1529 10.7. Limiting Request Rates 1531 A router MAY rate-limit CCNinfo Requests by ignoring some of the 1532 consecutive messages. The router MAY randomly ignore the received 1533 messages to minimize the processing overhead, i.e., to keep fairness 1534 in processing requests, or prevent traffic amplification. In such a 1535 case, no error message is returned. The rate limit function is left 1536 to the router's implementation. 1538 10.8. Limiting Reply Rates 1540 CCNinfo supporting multipath forwarding may result in one Request 1541 returning multiple Reply messages. To prevent abuse, the routers in 1542 the traced path MAY need to rate-limit the Replies. In such a case, 1543 no error message is returned. The rate limit function is left to the 1544 router's implementation. 1546 10.9. Adjacency Verification 1548 It is assumed that the CCNinfo Request and Reply messages are 1549 forwarded by adjacent neighbor nodes or routers. The CCNx message 1550 format or semantics do not define a secure way to verify the node/ 1551 router adjacency, while HopAuth [11] provides a possible method for 1552 an adjacency verification and defines the corresponding message 1553 format for adjacency verification as well as the router behaviors. 1554 CCNinfo MAY use a similar method for node adjacency verification. 1556 11. Acknowledgements 1558 The authors would like to thank Spyridon Mastorakis, Paulo Mendes, 1559 Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable 1560 comments and suggestions on this document. 1562 12. References 1564 12.1. Normative References 1566 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1567 Format", RFC 8609, July 2019. 1569 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1570 RFC 8569, July 2019. 1572 [3] Bradner, S., "Key words for use in RFCs to Indicate 1573 Requirement Levels", BCP 14, RFC 2119, 1574 DOI 10.17487/RFC2119, March 1997, 1575 . 1577 [4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1578 2119 Key Words", May 2017, 1579 . 1581 [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1582 Writing an IANA Considerations Section in RFCs", BCP 26, 1583 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1584 . 1586 12.2. Informative References 1588 [6] Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. 1589 Tschudin, "Information-Centric Networking (ICN): Content- 1590 Centric Networking (CCNx) and Named Data Networking (NDN) 1591 Terminology", RFC 8793, June 2020. 1593 [7] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1594 Tool for Measuring and Tracing Content-Centric Networks", 1595 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1596 March 2015. 1598 [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1599 D. Oran, "ICN Ping Protocol Specification", draft-irtf- 1600 icnrg-icnping-05 (work in progress), April 2022. 1602 [9] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1603 D. Oran, "ICN Traceroute Protocol Specification", draft- 1604 irtf-icnrg-icntraceroute-05 (work in progress), April 1605 2022. 1607 [10] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1608 Traceroute Facility for IP Multicast", RFC 8487, October 1609 2018. 1611 [11] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in 1612 Content-Centric Networking/Named Data Networking", draft- 1613 li-icnrg-hopauth-02 (work in progress), February 2020. 1615 [12] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive 1616 Caching and Adaptive Retrieval for In-Network Big Data 1617 Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. 1619 [13] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: 1620 Software Platform Enabling Content-Centric Networking and 1621 Beyond", IEICE Transaction on Communications, Vol.E102-B, 1622 No.9, pp.1792-1803, September 2019. 1624 [14] "Cefore Home Page", . 1626 Appendix A. ccninfo Command and Options 1628 CCNinfo is implemented in Cefore [13][14]. The command invoked by 1629 the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo 1630 command sends the Request message and receives the Reply message(s). 1631 There are several options that can be specified with ccninfo, while 1632 the content name prefix (e.g., ccnx:/news/today) is the mandatory 1633 parameter. 1635 The usage of ccninfo command is as follows: 1637 Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v 1638 algo] name_prefix 1640 name_prefix 1641 Prefix name of content (e.g., ccnx:/news/today) or exact name of 1642 content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants 1643 to trace. 1645 c option 1646 This option can be specified if a CCNinfo user needs the cache 1647 information as well as the routing path information for the 1648 specified content/cache and RTT between the CCNinfo user and 1649 content forwarder. 1651 f option 1652 This option enables the "full discovery request"; routers send 1653 CCNinfo Requests to multiple upstream faces based on their FIBs 1654 simultaneously. The CCNinfo user can then trace all possible 1655 forwarding paths. 1657 o option 1658 This option enables to trace the path to the content publisher. 1659 Each router along the path to the publisher inserts each Report 1660 block and forwards the Request message. It does not send Reply 1661 even if it caches the specified content. FHR that attaches the 1662 publisher (who has the complete set of content and is not a 1663 caching router) sends the Reply message. 1665 V option 1666 This option requests the Reply sender to validate the Reply 1667 message with the Reply sender's signature. The Reply message will 1668 then include the CCNx ValidationPayload TLV. The validation 1669 algorithm is selected by the Reply sender. 1671 r option 1672 Number of traced routers. This value is set in the "HopLimit" 1673 field located in the fixed header of the Request. For example, 1674 when the CCNinfo user invokes the CCNinfo command with this 1675 option, such as "-r 3", only three routers along the path examine 1676 their path and cache information. 1678 s option 1679 Number of skipped routers. This value is set in the "SkipHop" 1680 field located in the Request block TLV. For example, when the 1681 CCNinfo user invokes the CCNinfo command with this option, such as 1682 "-s 3", three upstream routers along the path only forward the 1683 Request message but do not append their Report blocks in the hop- 1684 by-hop header and do not send Reply messages despite having the 1685 corresponding cache. 1687 v option 1688 This option enables the CCNinfo user to validate the Request 1689 message with his/her signature. The Request message will include 1690 the CCNx ValidationPayload TLV. The validation algorithm is 1691 specified by the CCNinfo user. 1693 Authors' Addresses 1695 Hitoshi Asaeda 1696 National Institute of Information and Communications Technology 1697 4-2-1 Nukui-Kitamachi 1698 Koganei, Tokyo 184-8795 1699 Japan 1701 Email: asaeda@nict.go.jp 1703 Atsushi Ooka 1704 National Institute of Information and Communications Technology 1705 4-2-1 Nukui-Kitamachi 1706 Koganei, Tokyo 184-8795 1707 Japan 1709 Email: a-ooka@nict.go.jp 1711 Xun Shao 1712 Kitami Institute of Technology 1713 165 Koen-cho 1714 Kitami, Hokkaido 090-8507 1715 Japan 1717 Email: x-shao@mail.kitami-it.ac.jp