idnits 2.17.1 draft-irtf-icnrg-ccninfo-05.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that the full discovery request is an OPTIONAL implementation of CCNinfo; it MAY NOT be implemented on routers. Even if it is implemented on a router, it MAY NOT accept the full discovery request from non-validated CCNinfo users or routers or because of its policy. If a router does not accept the full discovery request, it rejects the full discovery request as described in Section 6.11. Routers that enable the full discovery request MAY rate-limit Replies, as described in Section 10.8 as well. -- The document date (September 21, 2020) is 1313 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 1578 -- Looks like a reference, but probably isn't: '-f' on line 1578 -- Looks like a reference, but probably isn't: '-o' on line 1578 -- Looks like a reference, but probably isn't: '-V' on line 1578 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '5') (Obsoleted by RFC 6814) == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icnping-00 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icntraceroute-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: March 25, 2021 X. Shao 6 Kitami Institute of Technology 7 September 21, 2020 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-05 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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 25, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 59 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9 60 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10 61 3.1.1. Request Header Block and Request Block . . . . . . . 12 62 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16 63 3.1.3. Content Name Specification . . . . . . . . . . . . . 17 64 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17 65 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18 66 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19 67 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22 68 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22 69 4.1.1. Routing Path Information . . . . . . . . . . . . . . 22 70 4.1.2. In-Network Cache Information . . . . . . . . . . . . 22 71 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23 72 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 73 5.1. User and Neighbor Verification . . . . . . . . . . . . . 23 74 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 23 75 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25 76 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25 77 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 25 78 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 26 79 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27 80 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 27 81 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 28 82 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 28 83 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 28 84 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 28 85 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 28 86 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 28 87 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 28 88 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 29 89 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 29 90 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 29 91 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 29 92 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 29 93 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 29 94 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 30 95 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 30 96 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 30 97 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 30 98 8.2. Caching Router Identification . . . . . . . . . . . . . . 30 99 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 30 100 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 101 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 31 102 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 31 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 105 10.1. Policy-Based Information Provisioning for Request . . . 31 106 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 32 107 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 108 10.4. Characteristics of Content . . . . . . . . . . . . . . . 32 109 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 32 110 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 33 111 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 33 112 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 33 113 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 33 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 117 12.2. Informative References . . . . . . . . . . . . . . . . . 34 118 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 35 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 121 1. Introduction 123 In Content-Centric Networks (CCN), publishers provide the content 124 through the network, and receivers retrieve it by name. In this 125 network architecture, routers forward content requests through their 126 Forwarding Information Bases (FIBs), which are populated by name- 127 based routing protocols. CCN also enables receivers to retrieve 128 content from an in-network cache. 130 In CCN, while consumers do not generally need to know the content 131 forwarder that is transmitting the content to them, the operators and 132 developers may want to identify the content forwarder and observe the 133 routing path information per name prefix for troubleshooting or 134 investigating the network conditions. 136 Traceroute [5] is a useful tool for discovering the routing 137 conditions in IP networks because it provides intermediate router 138 addresses along the path between the source and destination and the 139 Round-Trip Time (RTT) for the path. However, this IP-based network 140 tool cannot trace the name prefix paths used in CCN. Moreover, such 141 IP-based network tools do not obtain the states of the in-network 142 cache to be discovered. 144 Contrace [6] enables end users (i.e., consumers) to investigate path 145 and in-network cache conditions in CCN. Contrace is implemented as 146 an external daemon process running over TCP/IP that can interact with 147 a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the 148 caching information on the forwarding daemon. This solution is 149 flexible, but it requires TCP/IP networks and defining the common 150 APIs for the global deployment. 152 This document describes the specifications of "CCNinfo", an active 153 networking tool for discovering the path and content caching 154 information in CCN. CCNinfo defines the protocol messages to 155 investigate path and in-network cache conditions in CCN. It is 156 embedded in the CCNx forwarding process and facilitates with non-IP 157 networks as with the basic CCN concept. 159 CCNinfo is intended as a comprehensive network management tool for 160 CCN networks. It provides a wealth of information from CCN 161 forwarders, including on-path in-network cache conditions as well as 162 forwarding path instrumentation of multiple paths toward content 163 forwarders. ICN ping [7] and traceroute [8], in contrast, are 164 lightweight operational tools that enable a user to explore the 165 path(s) that reach a publisher or a cache storing the named content. 166 As a management capability that exposes detailed information about 167 the forwarders deployed by a network operator, CCNinfo employs more 168 granular authorization policies than those required of ICN ping or 169 ICN traceroute. 171 Usually, the CCNinfo user (e.g., consumer) invokes the CCNinfo user 172 program (such as "ccninfo" command described in Appendix A) with the 173 name prefix of the content. The user program initiates the "Request" 174 message (described in Section 3.1) to obtain routing path and cache 175 information. When an appropriate adjacent neighbor router receives 176 the Request message, it retrieves own cache information. If the 177 router is not the content forwarder for the specified name prefix, it 178 inserts its "Report" block (described in Section 3.1.2) into the 179 Request message and forwards it to its upstream neighbor router(s) 180 decided by its FIB. 182 The Request message is forwarded by routers toward the content 183 publisher and the Report record is inserted by each intermediate 184 router. When the Request message reaches the content forwarder 185 (i.e., a router that can forward the specified content), the content 186 forwarder forms the "Reply" message (described in Section 3.2) and 187 sends it to the downstream neighbor router. The Reply message is 188 forwarded back toward the user in a hop-by-hop manner (along the PIT 189 entries). 191 These two message types, Request and Reply messages, are encoded in 192 the CCNx TLV format [1]. The request-reply message flow, walking up 193 the tree from a consumer toward a publisher, is similar to the 194 behavior of the IP multicast traceroute facility [9]. 196 CCNinfo facilitates the tracing of a routing path and provides: 1) 197 the RTT between the content forwarder (i.e., the caching or first-hop 198 router) and consumer, 2) the states of the in-network cache per name 199 prefix, and 3) the routing path information per name prefix. 201 In addition, CCNinfo identifies the states of the cache, such as the 202 following metrics for Content Store (CS) in the content forwarder: 1) 203 size of cached content objects, 2) number of cached content objects, 204 3) number of accesses (i.e., received Interests) per content, and 4) 205 elapsed cache time and remaining cache lifetime of content. 207 1. Request 2. Request 3. Request 208 (+U) (U+A) (U+A+B) 209 +----+ +----+ +----+ 210 | | | | | | 211 | v | v | v 212 +--------+ +--------+ +--------+ +--------+ +---------+ 213 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 214 | user | | A | | B | | C | | | 215 +--------+ +--------+ +--------+ +--------+ +---------+ 216 \ 217 \ +-------+ 218 3. Request \ | Cache | 219 (U+A+B) \ +---------+ | 220 v| Caching |----+ 221 | router | 222 +---------+ 224 Figure 1: Request messages forwarded by consumer and routers. 225 CCNinfo user and routers (i.e., Router A, B, C) insert their own 226 Report blocks into the Request message and forward the message toward 227 the content forwarder (i.e., caching router and publisher). 229 3. Reply(P) 2. Reply(P) 1. Reply(P) 230 +----+ +----+ +----+ 231 | | | | | | 232 v | v | v | 233 +--------+ +--------+ +--------+ +--------+ +---------+ 234 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 235 | user | | A | | B | | C | | | 236 +--------+ +--------+ +--------+ +--------+ +---------+ 237 ^ 238 \ +-------+ 239 1. Reply(C) \ | Cache | 240 \ +---------+ | 241 \| Caching |----+ 242 | router | 243 +---------+ 245 Figure 2: Default behavior. Reply messages forwarded by routers. 246 Each router forwards the Reply message along its PIT entry and 247 finally, the CCNinfo user receives a Reply message from Router C, 248 which is the first-hop router for the Publisher. Another Reply 249 message from the Caching router (i.e., Reply(C)) is discarded at 250 Router B when the other Reply message (i.e., Reply(P)) was already 251 forwarded by Router B. 253 CCNinfo supports multipath forwarding. The Request messages can be 254 forwarded to multiple neighbor routers. When the Request messages 255 are forwarded to multiple routers, the different Reply messages are 256 forwarded from different routers or publishers. 258 Within a network with multipath condition, there is a case (Figure 3) 259 wherein a single CCNinfo Request is split into multiple Requests 260 (e.g., at Router A), which are injected into a single router (Router 261 D). In this case, multiple Replies with the same Request ID and Node 262 Identifier including different Report blocks are received by the 263 router (Router D). To recognize different CCNinfo Reply messages, 264 the routers MUST distinguish the PIT entries by the Request ID and 265 exploiting path labels, which could be a hash value of the 266 concatenation information of the cumulate Node Identifiers in the 267 hop-by-hop header and the specified content name. For example, when 268 Router D in Figure 3 receives a CCNinfo Request from Router B, its 269 PIT includes the Request ID and value such as 270 H((Router_A|Router_B)|content_name), where "H" indicates some hash 271 function and "|" indicates concatenation. When Router D receives a 272 CCNinfo Request from Router C, its PIT includes the same Request ID 273 and value of H((Router_A|Router_C)|content_name). Two different 274 Replies are later received on Router D and each Reply is 275 appropriately forwarded to Router B and Router C, respectively. Note 276 that two Reply messages coming from Router B and Router C are reached 277 at Router A, but the CCNinfo user can only receive the first Reply 278 message either from Router B or Router C as Router A removes the 279 corresponding PIT entry after it forwards the first Reply. 281 +--------+ 282 | Router | 283 | B | 284 +--------+ 285 / \ 286 / \ 287 +--------+ +--------+ +--------+ +---------+ 288 | CCNinfo|----| Router | | Router | ... |Publisher| 289 | user | | A | | D | | | 290 +--------+ +--------+ +--------+ +---------+ 291 \ / 292 \ / 293 +--------+ 294 | Router | 295 | C | 296 +--------+ 298 Figure 3 300 To avoid routing loop, when a router seeks the cumulate Node 301 Identifiers of the Report blocks in the hop-by-hop header, it MUST 302 examine whether its own Node Identifier is not previously inserted. 303 If a router detects its own Node Identifier in the hop-by-hop header, 304 the router inserts its Report block and terminates the Request as 305 will be described in Section 6.8. 307 Furthermore, CCNinfo implements policy-based information provisioning 308 that enables administrators to "hide" secure or private information 309 but does not disrupt message forwarding. This policy-based 310 information provisioning reduces the deployment barrier faced by 311 operators in installing and running CCNinfo on their routers. 313 2. Terminology 315 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 316 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 317 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]; 318 they indicate the requirement levels for the compliant CCNinfo 319 implementations. 321 2.1. Definitions 323 This document follows the basic terminologies and definitions 324 described in [1]. Although CCNinfo requests flow in the opposite 325 direction to the data flow, we refer to "upstream" and "downstream" 326 with respect to data, unless explicitly specified. 328 Router 329 It is a router that facilitates CCN-based content retrieval in the 330 path between the consumer and publisher. 332 Scheme name 333 It indicates a URI and protocol. This document only considers 334 "ccnx:/" as the scheme name. 336 Prefix name 337 A prefix name, which is defined in [2], is a name that does not 338 uniquely identify a single content object, but rather a namespace 339 or prefix of an existing content object name. 341 Exact name 342 An exact name, which is defined in [2], is one that uniquely 343 identifies the name of a content object. 345 Node 346 It is a router, publisher, or consumer. 348 Content forwarder 349 It is either a caching router or a first-hop router that forwards 350 content objects to consumers. 352 CCNinfo user 353 It is a node that initiates the CCNinfo Request, which is usually 354 invoked by the user program (described in Appendix A) or other 355 similar commands. 357 Incoming face 358 The face on which data are expected to arrive from the specified 359 name prefix. 361 Outgoing face 362 The face to which data from the publisher or router are expected 363 to transmit for the specified name prefix. It is also the face on 364 which the Request messages are received. 366 Upstream router 367 The router that connects to an Incoming face of a router. 369 Downstream router 370 The router that connects to an Outgoing face of a router. 372 First-hop router (FHR) 373 The router that matches a FIB entry with an Outgoing face 374 referring to a local application or a publisher. 376 Last-hop router (LHR) 377 The router that is directly connected to a consumer. 379 3. CCNinfo Message Formats 381 CCNinfo uses two message types: Request and Reply. Both messages are 382 encoded in the CCNx TLV format ([1], Figure 4). The Request message 383 consists of a fixed header, Request block TLV (Figure 8), and Report 384 block TLV(s) (Figure 13). The Reply message consists of a fixed 385 header, Request block TLV, Report block TLV(s), and Reply block/sub- 386 block TLV(s) (Figure 15). 388 1 2 3 389 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 390 +---------------+---------------+---------------+---------------+ 391 | Version | PacketType | PacketLength | 392 +---------------+---------------+---------------+---------------+ 393 | PacketType specific fields | HeaderLength | 394 +---------------+---------------+---------------+---------------+ 395 / Optional Hop-by-hop header TLVs / 396 +---------------+---------------+---------------+---------------+ 397 / PacketPayload TLVs / 398 +---------------+---------------+---------------+---------------+ 399 / Optional CCNx ValidationAlgorithm TLV / 400 +---------------+---------------+---------------+---------------+ 401 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 402 +---------------+---------------+---------------+---------------+ 404 Figure 4: Packet format [1] 406 The Request and Reply Type values in the fixed header are 407 PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 5). 408 These messages are forwarded in a hop-by-hop manner. When the 409 Request message reaches the content forwarder, the content forwarder 410 turns it into a Reply message by changing the Type field value in the 411 fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards 412 it back toward the node that initiated the Request message. 414 Code Type name 415 ======== ===================== 416 %x00 PT_INTEREST [1] 417 %x01 PT_CONTENT [1] 418 %x02 PT_RETURN [1] 419 %x03 PT_CCNINFO_REQUEST 420 %x04 PT_CCNINFO_REPLY 422 Figure 5: Packet Type Namespace 424 The CCNinfo Request and Reply messages MUST begin with a fixed header 425 with either a Request or Reply type value to specify whether it is a 426 Request message or Reply message. Following a fixed header, there 427 can be a sequence of optional hop-by-hop header TLV(s) for a Request 428 message. In the case of a Request message, it is followed by a 429 sequence of Report blocks, each from a router on the path toward the 430 publisher or caching router. 432 At the beginning of PacketPayload TLVs, a top-level TLV type, 433 T_DISCOVERY (Figure 6), exists at the outermost level of a CCNx 434 protocol message. This TLV indicates that the Name segment TLV(s) 435 and Reply block TLV(s) would follow in the Request or Reply message. 437 Code Type name 438 ============= ========================= 439 %x0000 Reserved [1] 440 %x0001 T_INTEREST [1] 441 %x0002 T_OBJECT [1] 442 %x0003 T_VALIDATION_ALG [1] 443 %x0004 T_VALIDATION_PAYLOAD [1] 444 %x0005 T_DISCOVERY 446 Figure 6: Top-Level Type Namespace 448 3.1. Request Message 450 When a CCNinfo user initiates a discovery request (e.g., via the 451 ccninfo command described in Appendix A), a CCNinfo Request message 452 is created and forwarded to its upstream router through the Incoming 453 face(s) determined by its FIB. 455 The Request message format is shown in Figure 7. It consists of a 456 fixed header, Request header block TLV (Figure 8), Report block 457 TLV(s) (Figure 13), Name TLV, and Request block TLV. The Type value 458 of the Top-Level type namespace is T_DISCOVERY (Figure 6). The Type 459 value for the Report message is PT_CCNINFO_REQUEST. 461 1 2 3 462 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 463 +---------------+---------------+---------------+---------------+ 464 | Version | PacketType | PacketLength | 465 +---------------+---------------+---------------+---------------+ 466 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 467 +===============+===============+===============+===============+ 468 / Request header block TLV / 469 +---------------+---------------+---------------+---------------+ 470 / Report block TLV 1 / 471 +---------------+---------------+---------------+---------------+ 472 / Report block TLV 2 / 473 +---------------+---------------+---------------+---------------+ 474 / . / 475 / . / 476 +---------------+---------------+---------------+---------------+ 477 / Report block TLV n / 478 +===============+===============+===============+===============+ 479 | Type (=T_DISCOVERY) | MessageLength | 480 +---------------+---------------+---------------+---------------+ 481 | T_NAME | Length | 482 +---------------+---------------+---------------+---------------+ 483 / Name segment TLVs (name prefix specified by CCNinfo user) / 484 +---------------+---------------+---------------+---------------+ 485 / Request block TLV / 486 +---------------+---------------+---------------+---------------+ 487 / Optional CCNx ValidationAlgorithm TLV / 488 +---------------+---------------+---------------+---------------+ 489 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 490 +---------------+---------------+---------------+---------------+ 492 Figure 7: Request message consists of a fixed header, Request block 493 TLV, Report block TLV(s), and Name TLV 495 HopLimit: 8 bits 497 HopLimit is a counter that is decremented with each hop whenever a 498 Request packet is forwarded. It is specified by the CCNinfo user 499 program. It limits the distance that a Request may travel on the 500 network. Only the specified number of hops from the CCNinfo user 501 traces the Request. Each router inserts its own Report block and 502 forwards the Request message to the upstream router(s). The last 503 router stops the trace and sends the Reply message back to the 504 CCNinfo user. 506 ReturnCode: 8 bits 507 ReturnCode is used for the Reply message. This value is replaced 508 by the content forwarder when the Request message is returned as 509 the Reply message (see Section 3.2). Until then, this field MUST 510 be transmitted as zeros and ignored on receipt. 512 Value Name Description 513 ----- --------------- ---------------------------------------------- 514 %x00 NO_ERROR No error 515 %x01 WRONG_IF CCNinfo Request arrived on an interface 516 to which this router would not forward for 517 the specified name/function toward the 518 publisher. 519 %x02 INVALID_REQUEST Invalid CCNinfo Request is received. 520 %x03 NO_ROUTE This router has no route for the name prefix 521 and no way to determine a route. 522 %x04 NO_INFO This router has no cache information for the 523 specified name prefix. 524 %x05 NO_SPACE There was not enough room to insert another 525 Report block in the packet. 526 %x06 INFO_HIDDEN Information is hidden from this discovery 527 owing to some policy. 528 %x0E ADMIN_PROHIB CCNinfo Request is administratively 529 prohibited. 530 %x0F UNKNOWN_REQUEST This router does not support/recognize the 531 Request message. 532 %x80 FATAL_ERROR In a fatal error, the router may know the 533 upstream router but cannot forward the 534 message to it. 536 Reserved (MBZ): 8 bits 538 The reserved fields in the Value field MUST be transmitted as 539 zeros and ignored on receipt. 541 3.1.1. Request Header Block and Request Block 543 When a CCNinfo user transmits the Request message, s/he MUST insert 544 her/his Request header block TLV (Figure 8) into the hop-by-hop 545 header and Request block TLV (Figure 8) into the message before 546 sending it through the Incoming face(s). 548 1 2 3 549 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 550 +---------------+---------------+---------------+---------------+ 551 | Type (=T_DISC_REQHDR) | Length | 552 +---------------+---------------+-------+-------+-------+-+-+-+-+ 553 | Request ID |SkipHop| Flags |V|F|O|C| 554 +---------------+---------------+-------+-------+-------+-+-+-+-+ 556 Figure 8: Request header block TLV (hop-by-hop header) 558 Code Type name 559 ============= ========================= 560 %x0000 Reserved [1] 561 %x0001 T_INTLIFE [1] 562 %x0002 T_CACHETIME [1] 563 %x0003 T_MSGHASH [1] 564 %x0004-%x0007 Reserved [1] 565 %x0008 T_DISC_REQHDR 566 %x0009 T_DISC_REPORT 567 %x0FFE T_PAD [1] 568 %x0FFF T_ORG [1] 569 %x1000-%x1FFF Reserved [1] 571 Figure 9: Hop-by-Hop Type Namespace 573 Type: 16 bits 575 Format of the Value field. For the type value of the Request 576 block TLV MUST be T_DISC_REQHDR. 578 Length: 16 bits 580 Length of Value field in octets. 582 Request ID: 16 bits 584 This field is used as a unique identifier for the CCNinfo Request 585 so that the duplicate or delayed Reply messages can be detected. 587 SkipHop (Skip Hop Count): 4 bits 589 Number of skipped routers for a Request. It is specified by the 590 CCNinfo user program. Routers corresponding to the value 591 specified in this field are skipped and the CCNinfo Request 592 messages are forwarded to the next router without the addition of 593 Report blocks; the next upstream router then starts the trace. 594 The maximum value of this parameter is 15. This value MUST be 595 lower than that of HopLimit at the fixed header. 597 Flags: 12 bits 599 The Flags field is used to indicate the types of the content or 600 path discoveries. Currently, as shown in Figure 10, four bits, 601 "C", "O", "F", and "V" are assigned, and the other 8 bits are 602 reserved (MBZ) for the future use. Each flag can be mutually 603 specified with other flags. These flags are set by the CCNinfo 604 user program when they initiate Requests (see Appendix A), and the 605 routers that receive the Requests deal with the flags and change 606 the behaviors (see Section 5 for details). The Flag values 607 defined in this Flags field correspond to the Reply sub-blocks. 609 Flag Value Description 610 ----- ----- ----------------------------------------------------- 611 C 0 Path discovery (i.e., no cache information retrieved) 612 (default) 613 C 1 Cache information retrieval 614 O 0 Request to any content forwarder (default) 615 O 1 Publisher discovery (i.e., only FHR can reply) 616 F 0 Request based on FIB's strategy (default) 617 F 1 Full discovery request. Request to possible multiple 618 upstream routers specified in FIB simultaneously 619 V 0 No reply validation (default) 620 V 1 Reply sender validates Reply message 622 Figure 10: Codes and types specified in Flags field 624 1 2 3 625 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 626 +---------------+---------------+---------------+---------------+ 627 | Type (=T_DISC_REQ) | Length | 628 +---------------+---------------+---------------+---------------+ 629 | Request Arrival Time | 630 +---------------+---------------+---------------+---------------+ 631 / Node Identifier / 632 +---------------+---------------+---------------+---------------+ 634 Figure 11: Request block TLV (packet payload) 635 Code Type name 636 ============== =================== 637 %x0000 T_NAME [1] 638 %x0001 T_PAYLOAD [1] 639 %x0002 T_KEYIDRESTR [1] 640 %x0003 T_OBJHASHRESTR [1] 641 %x0005 T_PAYLDTYPE [1] 642 %x0006 T_EXPIRY [1] 643 %x0007 T_DISC_REQ 644 %x0008 T_DISC_REPLY 645 %x0009-%x0012 Reserved [1] 646 %x0FFE T_PAD [1] 647 %x0FFF T_ORG [1] 648 %x1000-%x1FFF Reserved [1] 650 Figure 12: CCNx Message Type Namespace 652 Type: 16 bits 654 Format of the Value field. For the Request block TLV, the type 655 value(s) MUST be T_DISC_REQ (see Figure 12) in the current 656 specification. 658 Length: 16 bits 660 Length of Value field in octets. 662 Request Arrival Time: 32 bits 664 The Request Arrival Time is a 32-bit NTP timestamp specifying the 665 arrival time of the CCNinfo Request packet at a specific router. 666 The 32-bit form of an NTP timestamp consists of the middle 32 bits 667 of the full 64-bit form; that is, the low 16 bits of the integer 668 part and the high 16 bits of the fractional part. 670 The following formula converts from a UNIX timeval to a 32-bit NTP 671 timestamp: 673 request_arrival_time 674 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 676 The constant 32384 is the number of seconds from Jan 1, 1900 to 677 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 678 is a reduction of ((tv.tv_nsec / 1000000000) << 16). 680 Note that it is RECOMMENDED for all the routers on the path to 681 have synchronized clocks to measure one-way latency per hop; 682 however, even if they do not have synchronized clocks, CCNinfo 683 measures the RTT between the content forwarder and consumer. 685 Node Identifier: variable length 687 This field specifies the node identifier (e.g., node name or hash- 688 based self-certifying name [10]) or all-zeros if unknown. This 689 document assumes that the Name TLV defined in the CCNx TLV format 690 [1] can be used for this field and the node identifier is 691 specified in it. 693 3.1.2. Report Block TLV 695 A CCNinfo user and each upstream router along the path would insert 696 their own Report block TLV without changing the Type field of the 697 fixed header of the Request message until one of these routers is 698 ready to send a Reply. In the Report block TLV (Figure 13), the 699 Request Arrival Time and Node Identifier MUST be inserted. 701 1 2 3 702 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 703 +---------------+---------------+---------------+---------------+ 704 | Type (=T_DISC_REPORT) | Length | 705 +---------------+---------------+---------------+---------------+ 706 | Request Arrival Time | 707 +---------------+---------------+---------------+---------------+ 708 / Node Identifier / 709 +---------------+---------------+---------------+---------------+ 711 Figure 13: Report block TLV (hop-by-hop header) 713 Type: 16 bits 715 Format of the Value field. For the Report block TLV, the type 716 value(s) MUST be T_DISC_REPORT in the current specification. For 717 all the available types for hop-by-hop type namespace, please see 718 Figure 9. 720 Length: 16 bits 722 Length of Value field in octets. 724 Request Arrival Time: 32 bits 726 Same definition as given in Section 3.1.1. 728 Node Identifier: variable length 729 Same definition as given in Section 3.1.1. 731 3.1.3. Content Name Specification 733 Specifications of the Name TLV (whose type value is T_NAME) and the 734 Name Segment TLVs are described in [1], which are followed by 735 CCNinfo. CCNinfo enables to specification of the content name either 736 with a prefix name without chunk number (such as "ccnx:/news/today") 737 or an exact name (such as "ccnx:/news/today/Chunk=10"). When a 738 CCNinfo user specifies a prefix name, s/he will obtain the summary 739 information of the matched content objects in the content forwarder. 740 In contrast, when a CCNinfo user specifies an exact name, s/he will 741 obtain only about the specified content object in the content 742 forwarder. A CCNinfo Request message MUST NOT be sent only with a 743 scheme name, ccnx:/. It will be rejected and discarded by routers. 745 3.2. Reply Message 747 When a content forwarder receives a CCNinfo Request message from an 748 appropriate adjacent neighbor router, it inserts its own Reply block 749 TLV and Reply sub-block TLV(s) to the Request message and turns the 750 Request into the Reply by changing the Type field of the fixed header 751 of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. 752 The Reply message (see Figure 14) is then forwarded back toward the 753 CCNinfo user in a hop-by-hop manner. 755 1 2 3 756 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 757 +---------------+---------------+---------------+---------------+ 758 | Version | PacketType | PacketLength | 759 +---------------+---------------+-------------+-+---------------+ 760 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 761 +===============+===============+=============+=+===============+ 762 / Request header block TLV / 763 +---------------+---------------+---------------+---------------+ 764 / . / 765 / . / 766 / n Report block TLVs / 767 / . / 768 / . / 769 +===============+===============+===============+===============+ 770 | Type (=T_DISCOVERY) | MessageLength | 771 +---------------+---------------+---------------+---------------+ 772 | T_NAME | Length | 773 +---------------+---------------+---------------+---------------+ 774 / Name segment TLVs (name prefix specified by CCNinfo user) / 775 +---------------+---------------+---------------+---------------+ 776 / Request block TLV / 777 +---------------+---------------+---------------+---------------+ 778 / Reply block TLV / 779 +---------------+---------------+---------------+---------------+ 780 / Reply sub-block TLV 1 / 781 +---------------+---------------+---------------+---------------+ 782 / . / 783 / . / 784 +---------------+---------------+---------------+---------------+ 785 / Reply sub-block TLV k / 786 +---------------+---------------+---------------+---------------+ 787 / Optional CCNx ValidationAlgorithm TLV / 788 +---------------+---------------+---------------+---------------+ 789 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 790 +---------------+---------------+---------------+---------------+ 792 Figure 14: Reply message consists of a fixed header, Request block 793 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 795 3.2.1. Reply Block TLV 797 The Reply block TLV is an envelope for the Reply sub-block TLV(s) 798 (explained from the next section). 800 1 2 3 801 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 802 +---------------+---------------+---------------+---------------+ 803 | Type (=T_DISC_REPLY) | Length | 804 +---------------+---------------+---------------+---------------+ 805 | Request Arrival Time | 806 +---------------+---------------+---------------+---------------+ 807 / Node Identifier / 808 +---------------+---------------+---------------+---------------+ 810 Figure 15: Reply block TLV (packet payload) 812 Type: 16 bits 814 Format of the Value field. For the Reply block TLV, the type 815 value MUST be T_DISC_REPLY shown in Figure 12 in the current 816 specification. 818 Length: 16 bits 820 Length of the Value field in octets. This length is the total 821 length of Reply sub-block(s). 823 Request Arrival Time: 32 bits 825 Same definition as given in Section 3.1.1. 827 Node Identifier: variable length 829 Same definition as given in Section 3.1.1. 831 3.2.1.1. Reply Sub-Block TLV 833 The router on the traced path will add one or multiple Reply sub- 834 blocks followed by the Reply block TLV before sending the Reply to 835 its neighbor router. This section describes the Reply sub-block TLV 836 for informing various cache states and conditions as shown in 837 Figure 16. (Other Reply sub-block TLVs will be discussed in separate 838 document(s).) 840 Note that some routers may not be capable of reporting the following 841 values, such as Object Size, Object Count, # Received Interest, First 842 Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, 843 shown in Figure 16, or do not report these values due to their 844 policy. These values therefore MAY be returned with null. Also, the 845 value of each field will be all-one when the value is equal to or 846 bigger than the maximum size expressed by the 32-bit field. 848 If the cache is refreshed after reboot, the value in each field MUST 849 be refreshed (i.e., MUST be set to 0). If the cache remains after 850 reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as 851 it is). 853 1 2 3 854 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 855 +---------------+---------------+---------------+---------------+ 856 | Type | Length | 857 +---------------+---------------+---------------+---------------+ 858 | Object Size | 859 +---------------+---------------+---------------+---------------+ 860 | Object Count | 861 +---------------+---------------+---------------+---------------+ 862 | # Received Interest | 863 +---------------+---------------+---------------+---------------+ 864 | First Seqnum | 865 +---------------+---------------+---------------+---------------+ 866 | Last Seqnum | 867 +---------------+---------------+---------------+---------------+ 868 | Elapsed Cache Time | 869 +---------------+---------------+---------------+---------------+ 870 | Remain Cache Lifetime | 871 +---------------+---------------+---------------+---------------+ 872 | T_NAME | Length | 873 +---------------+---------------+---------------+---------------+ 874 / Name Segment TLVs / 875 +---------------+---------------+---------------+---------------+ 877 Figure 16: Reply sub-block TLV for T_DISC_CONTENT and 878 T_DISC_CONTENT_PUBLISHER (packet payload) 880 Code Type name 881 ============= =========================== 882 %x0000 T_DISC_CONTENT 883 %x0001 T_DISC_CONTENT_PUBLISHER 884 %x0FFF T_ORG 885 %x1000-%x1FFF Reserved (Experimental Use) 887 Figure 17: CCNinfo Reply Type Namespace 889 Type: 16 bits 891 Format of the Value field. For the Reply sub-block TLV, the type 892 value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER 893 defined in the CCNinfo Reply Type Namespace (Figure 17). 894 T_DISC_CONTENT is specified when the cache information is replied 895 from a caching router. T_DISC_CONTENT_PUBLISHER is specified when 896 the content information is replied from a FHR attached to a 897 publisher. 899 Length: 16 bits 901 Length of the Value field in octets. 903 Object Size: 32 bits 905 The total size (KB) of the unexpired content objects. Note that 906 the maximum size expressed by the 32-bit field is approximately 907 4.29 TB. 909 Object Count: 32 bits 911 The number of the unexpired content objects. Note that the 912 maximum count expressed by the 32-bit field is approximately 4.29 913 billion. 915 # Received Interest: 32 bits 917 The total number of the received Interest messages to retrieve the 918 cached content objects. 920 First Seqnum: 32 bits 922 The first sequential number of the unexpired content objects. 924 Last Seqnum: 32 bits 926 The last sequential number of the unexpired content objects. The 927 First Seqnum and Last Seqnum do not guarantee the consecutiveness 928 of the cached content objects; however, knowing these values may 929 help in the analysis of consecutive or discontinuous chunks such 930 as [11]. 932 Elapsed Cache Time: 32 bits 934 The elapsed time (seconds) after the oldest content object of the 935 content is cached. 937 Remain Cache Lifetime: 32 bits 939 The lifetime (seconds) of a content object, which is lastly 940 cached. 942 4. CCNinfo User Behavior 944 4.1. Sending CCNinfo Request 946 A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) 947 that initiates a CCNinfo Request message and sends it to the user's 948 adjacent neighbor router(s) of interest. The user later obtains both 949 the routing path information and in-network cache information in the 950 single Reply. 952 When the CCNinfo user program initiates a Request message, it MUST 953 insert the necessary values, i.e., the "Request ID" and the "Node 954 Identifier", in the Request block. The Request ID MUST be unique for 955 the CCNinfo user until s/he receives the corresponding Reply 956 message(s) or the Request is timed out. 958 Owing to some policies, a router may want to validate the CCNinfo 959 Requests using the CCNx ValidationPayload TLV (whether it accepts the 960 Request or not) especially when the router receives the "full 961 discovery request" (see Section 5.3.2). Accordingly, the CCNinfo 962 user program MAY require validating the Request message and appending 963 the user's signature into the CCNx ValidationPayload TLV. The router 964 then forwards the Request message. If the router does not approve 965 the Request, it rejects the Request message as described in 966 Section 6.11. 968 After the CCNinfo user program sends the Request message, until the 969 Reply is timed out or the expected numbers of Replies or a Reply 970 message with a non-zero ReturnCode in the fixed header is received, 971 the CCNinfo user program MUST keep the following information: 972 HopLimit, specified in the fixed header, Request ID, Flags, Node 973 Identifier, and Request Arrival Time, specified in the Request block. 975 4.1.1. Routing Path Information 977 A CCNinfo user can send a CCNinfo Request for investigating the 978 routing path information for the specified named content. Using the 979 Request, a legitimate user can obtain 1) the node identifiers of the 980 intermediate routers, 2) node identifier of the content forwarder, 3) 981 number of hops between the content forwarder and consumer, and 4) RTT 982 between the content forwarder and consumer, per name prefix. This 983 CCNinfo Request is terminated when it reaches the content forwarder. 985 4.1.2. In-Network Cache Information 987 A CCNinfo user can send a CCNinfo Request for investigating in- 988 network cache information. Using the Request, a legitimate user can 989 obtain 1) the size of cached content objects, 2) number of cached 990 content objects, 3) number of accesses (i.e., received Interests) per 991 content, and 4) lifetime and expiration time of the cached content 992 objects, for Content Store (CS) in the content forwarder, unless the 993 content forwarder is capable of reporting them (see Section 3.2.1.1). 994 This CCNinfo Request is terminated when it reaches the content 995 forwarder. 997 4.2. Receiving CCNinfo Reply 999 A CCNinfo user program will receive one or multiple CCNinfo Reply 1000 messages from the adjacent neighbor router(s). When the program 1001 receives the Reply, it MUST compare the kept Request ID and Node 1002 Identifier to identify the Request and Reply pair. If they do not 1003 match, the Reply message MUST be silently discarded. 1005 If the number of Report blocks in the received Reply is more than the 1006 initial HopLimit value (which was inserted in the original Request), 1007 the Reply MUST be silently ignored. 1009 After the CCNinfo user has determined that s/he has traced the whole 1010 path or the maximum path that s/he can be expected to, s/he might 1011 collect statistics by waiting for a timeout. Useful statistics 1012 provided by CCNinfo are stated in Section 8. 1014 5. Router Behavior 1016 5.1. User and Neighbor Verification 1018 Upon receiving a CCNinfo Request message, a router MAY examine 1019 whether a valid CCNinfo user has sent the message. If the router 1020 recognizes that the Request sender's signature specified in the 1021 Request is invalid, it SHOULD terminate the Request, as defined in 1022 Section 6.4. 1024 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 1025 whether the message comes from a valid adjacent neighbor node. If 1026 the router recognizes that the Request/Reply sender is invalid, it 1027 SHOULD silently ignore the Request/Reply message, as specified in 1028 Section 10.9. 1030 5.2. Receiving CCNinfo Request 1032 After a router accepts the CCNinfo Request message, it performs the 1033 following steps. 1035 1. The value of "HopLimit" in the fixed header and that of "SkipHop 1036 (Skip Hop Count)" in the Request block are counters that are 1037 decremented with each hop. If the HopLimit value is zero, the 1038 router terminates the Request, as defined in Section 6.5. If the 1039 SkipHop value is equal to or more than the HopLimit value, the 1040 router terminates the Request, as defined in Section 6.4. 1041 Otherwise, until the SkipHop value becomes zero, the router 1042 forwards the Request message to the upstream router(s) without 1043 adding its own Report block and without replying to the Request. 1044 If the router does not know the upstream router(s) regarding the 1045 specified name prefix, it terminates the Request, as defined in 1046 Section 6.5. It should be noted that the Request messages are 1047 terminated at the FHR; therefore, although the maximum value for 1048 the HopLimit is 255 and that for SkipHop is 15, if the Request 1049 messages reach the FHR before the HopLimit or SkipHop value 1050 becomes 0, the FHR silently discards the Request message and the 1051 Request is timed out. 1053 2. The router examines the Flags field (specified in Figure 10) in 1054 the Request block of the received CCNinfo Request. If the "C" 1055 flag is not set, it is categorized as the "routing path 1056 information discovery". If the "C" flag is set, it is the "cache 1057 information discovery". If the "O" flag is set, it is the 1058 "publisher discovery". 1060 3. If the Request is either "cache information discovery" or 1061 "routing path information discovery", the router examines its FIB 1062 and CS. If the router caches the specified content, it sends the 1063 Reply message with its own Reply block and sub-block(s). If the 1064 router cannot insert its own Reply block or sub-block(s) because 1065 of no space, it it terminates the Request, as specified in 1066 Section 6.7. If the router does not cache the specified content 1067 but knows the upstream neighbor router(s) for the specified name 1068 prefix, it creates the PIT entry, and inserts its own Report 1069 block in the hop-by-hop header and forwards the Request to the 1070 upstream neighbor(s). If the router cannot insert its own Report 1071 block because of no space, or if the router does not cache the 1072 specified content and does not know the upstream neighbor 1073 router(s) for the specified name prefix, it terminates the 1074 Request, as defined in Section 6.5. 1076 4. If the Request is the "publisher discovery", the router examines 1077 whether it is the FHR for the requested content. If the router 1078 is the FHR, it sends the Reply message with its own Report block 1079 and sub-blocks (in the case of cache information discovery) or 1080 the Reply message with its own Report block without adding any 1081 Reply sub-blocks (in the case of routing path information 1082 discovery). If the router is not the FHR but knows the upstream 1083 neighbor router(s) for the specified name prefix, it creates the 1084 PIT entry, and inserts its own Report block and forwards the 1085 Request to the upstream neighbor(s). If the router cannot insert 1086 its own Report block in the hop-by-hop header because of no 1087 space, it it terminates the Request, as specified in Section 6.7. 1088 If the router is not the FHR and does not know the upstream 1089 neighbor router(s) for the specified name prefix, it terminates 1090 the Request, as defined in Section 6.5. Note that in Cefore 1091 [13], there is an API by which a publisher informs the 1092 application prefix to the FHR and the FHR registers it into the 1093 FIB. The prefix entry then can be statically configured on other 1094 routers or announced by a routing protocol. 1096 5.3. Forwarding CCNinfo Request 1098 5.3.1. Regular Request 1100 When a router decides to forward a Request message with its Report 1101 block to its upstream router(s), it specifies the Request Arrival 1102 Time and Node Identifier in the Report block of the Request message. 1103 The router then forwards the Request message upstream toward the 1104 publisher or caching router based on the FIB entry like the ordinary 1105 Interest-Data exchanges in CCN. 1107 When the router forwards the Request message, it MUST record the F 1108 flag and Request ID in the Request block of the Request message and 1109 exploiting path labels (specified in Section 1) at the corresponding 1110 PIT entry. The router can later check the PIT entry to correctly 1111 forward the Reply message(s) back. 1113 CCNinfo supports multipath forwarding. The Request messages can be 1114 forwarded to multiple neighbor routers. Some routers may have a 1115 strategy for multipath forwarding; when a router sends Interest 1116 messages to multiple neighbor routers, it may delay or prioritize to 1117 send the message to the upstream routers. The CCNinfo Request, as 1118 the default, complies with such strategies; a CCNinfo user could 1119 trace the actual forwarding path based on the forwarding strategy and 1120 will receive a single Reply message such as a content object. 1122 5.3.2. Full Discovery Request 1124 There may be a case wherein a CCNinfo user wants to discover all 1125 possible forwarding paths and content forwarders based on the 1126 routers' FIBs. The "full discovery request" enables this 1127 functionality. If a CCNinfo user sets the F flag in the Request 1128 block of the Request message (as seen in Figure 10) to request the 1129 full discovery, the upstream routers simultaneously forward the 1130 Requests to all multiple upstream routers based on the FIBs. Then, 1131 the CCNinfo user can trace all possible forwarding paths. 1133 3. Reply(C) 2. Reply(C) 1134 3. Reply(P) 2. Reply(P) 1. Reply(P) 1135 +----+ +----+ +----+ 1136 | | | | | | 1137 v | v | v | 1138 +--------+ +--------+ +--------+ +--------+ +---------+ 1139 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 1140 | user | | A | | B | | C | | | 1141 +--------+ +--------+ +--------+ +--------+ +---------+ 1142 ^ 1143 \ +-------+ 1144 1. Reply(C) \ | Cache | 1145 \ +---------+ | 1146 \| Caching |----+ 1147 | router | 1148 +---------+ 1150 Figure 18: Full discovery request. Reply messages forwarded by 1151 publisher and routers. Each router forwards the Reply message along 1152 its PIT entry and finally, the CCNinfo user receives two Reply 1153 messages: one from the FHR (Router C) and the other from the Caching 1154 router. 1156 To receive different Reply messages forwarded from different routers, 1157 the PIT entries initiated by CCNinfo remain until the configured 1158 CCNinfo Reply Timeout (Section 7.1) is expired. In other words, 1159 unlike the ordinary Interest-Data exchanges in CCN, if routers that 1160 accept the full discovery request receive the full discovery request, 1161 the routers SHOULD NOT remove the PIT entry created by the full 1162 discovery request until the CCNinfo Reply Timeout value expires. 1164 Note that the full discovery request is an OPTIONAL implementation of 1165 CCNinfo; it MAY NOT be implemented on routers. Even if it is 1166 implemented on a router, it MAY NOT accept the full discovery request 1167 from non-validated CCNinfo users or routers or because of its policy. 1168 If a router does not accept the full discovery request, it rejects 1169 the full discovery request as described in Section 6.11. Routers 1170 that enable the full discovery request MAY rate-limit Replies, as 1171 described in Section 10.8 as well. 1173 5.4. Sending CCNinfo Reply 1175 If there is a caching router or FHR for the specified content within 1176 the specified hop count along the path, the caching router or FHR 1177 sends back the Reply message toward the CCNinfo user and terminates 1178 the Request. 1180 When a router decides to send a Reply message to its downstream 1181 neighbor router or the CCNinfo user with NO_ERROR return code, it 1182 inserts a Report block with the Request Arrival Time and Node 1183 Identifier to the Request message. Then, the router inserts the 1184 corresponding Reply sub-block(s) (Figure 16) to the payload. The 1185 router finally changes the Type field in the fixed header from 1186 PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back 1187 as the Reply toward the CCNinfo user in a hop-by-hop manner. 1189 If a router cannot continue the Request, the router MUST put an 1190 appropriate ReturnCode in the Request message, change the Type field 1191 value in the fixed header from PT_CCNINFO_REQUEST to 1192 PT_CCNINFO_REPLY, and forward the Reply message back toward the 1193 CCNinfo user to terminate the Request (see Section 6). 1195 5.5. Forwarding CCNinfo Reply 1197 When a router receives a CCNinfo Reply whose Request ID and Node 1198 Identifier match those in the PIT entry, sent from a valid adjacent 1199 neighbor router, it forwards the CCNinfo Reply back toward the 1200 CCNinfo user. If the router does not receive the corresponding Reply 1201 within the [CCNinfo Reply Timeout] period, then it removes the 1202 corresponding PIT entry and terminates the trace. 1204 The Flags field in the Request block TLV is used to indicate whether 1205 the router keeps the PIT entry during the CCNinfo Reply Timeout even 1206 after one or more corresponding Reply messages are forwarded. When 1207 the CCNinfo user does not set the F flag (i.e., "0"), the 1208 intermediate routers immediately remove the PIT entry whenever they 1209 forward the corresponding Reply message. When the CCNinfo user sets 1210 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1211 "full discovery request" (see Section 5.3.2), the intermediate 1212 routers keep the PIT entry within the [CCNinfo Reply Timeout] period. 1213 After this timeout, the PIT entry is removed. 1215 CCNinfo Replies MUST NOT be cached in routers upon the transmission 1216 of Reply messages. 1218 6. CCNinfo Termination 1220 When performing a hop-by-hop trace, it is necessary to determine when 1221 to stop the trace. There are several cases when an intermediate 1222 router might return a Reply before a Request reaches the caching 1223 router or the FHR. 1225 6.1. Arriving at First-hop Router 1227 A CCNinfo Request can be determined to have arrived at the FHR. To 1228 ensure that a router recognizes that it is the FHR for the specified 1229 content, it needs to have a FIB entry (or attach) to the 1230 corresponding publisher or the content. 1232 6.2. Arriving at Router Having Cache 1234 A CCNinfo Request can be determined to have arrived at the router 1235 having the specified content cache within the specified HopLimit. 1237 6.3. Arriving at Last Router 1239 A CCNinfo Request can be determined to have arrived at the last 1240 router of the specified HopLimit. If the last router does not have 1241 the corresponding cache, it MUST insert its Report block and send the 1242 Reply message with NO_INFO return code without appending any Reply 1243 (sub-)block TLVs. 1245 6.4. Invalid Request 1247 If the router does not validate the Request or the Reply, the router 1248 MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the 1249 message, insert its Report block, and forward the message as the 1250 Reply back to the CCNinfo user. The router MAY, however, randomly 1251 ignore the received invalid messages. (See Section 10.7.) 1253 6.5. No Route 1255 If the router cannot determine the routing paths or neighbor routers 1256 for the specified name prefix within the specified HopLimit, it MUST 1257 note a ReturnCode of NO_ROUTE in the fixed header of the message, 1258 insert its Report block, and forward the message as the Reply back to 1259 the CCNinfo user. 1261 6.6. No Information 1263 If the router does not have any information about the specified name 1264 prefix within the specified HopLimit, it MUST note a ReturnCode of 1265 NO_INFO in the fixed header of the message, insert its Report block, 1266 and forward the message as the Reply back to the CCNinfo user. 1268 6.7. No Space 1270 If appending the Report block or the Reply (sub-)block would make the 1271 hop-by-hop header longer than 247 bytes or the Request packet longer 1272 than the MTU of the Incoming face, the router MUST note a ReturnCode 1273 of NO_SPACE in the fixed header of the message and forward the 1274 message as the Reply back to the CCNinfo user. 1276 6.8. Fatal Error 1278 If a CCNinfo Request has encountered a fatal error, the router MUST 1279 note a ReturnCode of FATAL_ERROR in the fixed header of the message 1280 and forward the message as the Reply back to the CCNinfo user. This 1281 may happen, for example, when the router detects some routing loop in 1282 the Request blocks (see Section 1). The fatal error can be encoded 1283 with another error: if a router detects routing loop but cannot 1284 insert its Report block, it MUST note NO_SPACE and FATAL_ERROR 1285 ReturnCodes (i.e., %x85) in the fixed header and forward the message 1286 back to the CCNinfo user. 1288 6.9. CCNinfo Reply Timeout 1290 If a router receives the Request or Reply message that expires its 1291 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1292 silently discard the Request or Reply message. 1294 6.10. Non-Supported Node 1296 Cases will arise in which a router or a FHR along the path does not 1297 support CCNinfo. In such cases, a CCNinfo user and routers that 1298 forward the CCNinfo Request will time out the CCNinfo request. 1300 6.11. Administratively Prohibited 1302 If CCNinfo is administratively prohibited, the router rejects the 1303 Request message and MUST send the CCNinfo Reply with the ReturnCode 1304 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1305 Request messages to be rejected (see Section 10.7). 1307 7. Configurations 1309 7.1. CCNinfo Reply Timeout 1311 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1312 Reply. The value for a router can be statically configured by the 1313 router's administrators/operators. The default value is 3 (seconds). 1314 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 1315 (seconds) and SHOULD NOT be lower than 2 (seconds). 1317 7.2. HopLimit in Fixed Header 1319 If a CCNinfo user does not specify the HopLimit value in the fixed 1320 header for a Request message as the HopLimit, the HopLimit is set to 1321 32. Note that 0 HopLimit is an invalid Request; hence, the router in 1322 this case follows the way defined in Section 6.4. 1324 7.3. Access Control 1326 A router MAY configure the valid or invalid networks to enable an 1327 access control. The access control MAY be defined per name prefix, 1328 such as "who can retrieve which name prefix" (see Section 10.2). 1330 8. Diagnosis and Analysis 1332 8.1. Number of Hops and RTT 1334 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1335 each forwarding router appends its own Report block. We can then 1336 verify the number of hops to reach the content forwarder or publisher 1337 and the RTT between the content forwarder or publisher. 1339 8.2. Caching Router Identification 1341 While some routers may hide their node identifiers with all-zeros in 1342 the Report blocks (as seen in Section 10.1), the routers in the path 1343 from the CCNinfo user to the content forwarder can be identified. 1345 8.3. TTL or Hop Limit 1347 By taking the HopLimit from the content forwarder and forwarding the 1348 TTL threshold over all hops, it is possible to discover the TTL or 1349 hop limit required for the content forwarder to reach the CCNinfo 1350 user. 1352 8.4. Time Delay 1354 If the routers have synchronized clocks, it is possible to estimate 1355 the propagation and queuing delays from the differences between the 1356 timestamps at the successive hops. However, this delay includes the 1357 control processing overhead; therefore, it is not necessarily 1358 indicative of the delay that would be experienced by the data 1359 traffic. 1361 8.5. Path Stretch 1363 By obtaining the path stretch "d / P", where "d" is the hop count of 1364 the data and "P" is the hop count from the consumer to the publisher, 1365 we can measure the improvements in path stretch in various cases, 1366 such as in different caching and routing algorithms. We can then 1367 facilitate the investigation of the performance of the protocol. 1369 8.6. Cache Hit Probability 1371 CCNinfo can show the number of received interests per cache or chunk 1372 on a router. Accordingly, CCNinfo measures the content popularity 1373 (i.e., the number of accesses for each content/cache), thereby 1374 enabling the investigation of the routing/caching strategy in 1375 networks. 1377 9. IANA Considerations 1379 New assignments can only be made via a Standards Action as specified 1380 in [4]. This document does not intend to be the standard document. 1381 However, the new assignments such as the ReturnCode and various type 1382 values will be considered when this specification becomes the RFC. 1384 10. Security Considerations 1386 This section addresses some of the security considerations. 1388 10.1. Policy-Based Information Provisioning for Request 1390 Although CCNinfo gives excellent troubleshooting cues, some network 1391 administrators or operators may not want to disclose everything about 1392 their network to the public or may wish to securely transmit private 1393 information to specific members of their networks. CCNinfo provides 1394 policy-based information provisioning, thereby allowing network 1395 administrators to specify their response policy for each router. 1397 The access policy regarding "who is allowed to retrieve" and/or "what 1398 kind of cache information" can be defined for each router. For the 1399 former type of access policy, routers with the specified content MAY 1400 examine the signature enclosed in the Request message and decide 1401 whether they should notify the content information in the Reply. If 1402 the routers decide to not notify the content information, they MUST 1403 send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1404 appending any Reply (sub-)block TLVs. For the latter type of policy, 1405 the permission, whether (1) All (all cache information is disclosed), 1406 (2) Partial (cache information with a particular name prefix can (or 1407 cannot) be disclosed), or (3) Deny (no cache information is 1408 disclosed), is defined at the routers. 1410 In contrast, we entail that each router does not disrupt the 1411 forwarding of CCNinfo Request and Reply messages. When a Request 1412 message is received, the router SHOULD insert the Report block if the 1413 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1414 the Node Identifier field in the Report block MAY be null (i.e., all- 1415 zeros), but the Request Arrival Time field SHOULD NOT be null. 1416 Finally, the router SHOULD forward the Request message to the 1417 upstream router toward the content forwarder if the ReturnCode is 1418 kept with NO_ERROR. 1420 10.2. Filtering CCNinfo Users Located in Invalid Networks 1422 A router MAY support an access control mechanism to filter out 1423 Requests from invalid CCNinfo users. To accomplish this, invalid 1424 networks (or domains) could, for example, be configured via a list of 1425 allowed/disallowed networks (as observed in Section 7.3). If a 1426 Request is received from a disallowed network (according to the Node 1427 Identifier in the Request block), the Request MUST NOT be processed 1428 and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to 1429 note that. The router MAY, however, perform rate-limited logging of 1430 such events. 1432 10.3. Topology Discovery 1434 CCNinfo can be used to discover actively used topologies. If a 1435 network topology is not disclosed, CCNinfo Requests SHOULD be 1436 restricted at the border of the domain using the ADMIN_PROHIB return 1437 code. 1439 10.4. Characteristics of Content 1441 CCNinfo can be used to discover the type of content being sent by 1442 publishers. If this information is a secret, CCNinfo Requests SHOULD 1443 be restricted at the border of the domain, using the ADMIN_PROHIB 1444 return code. 1446 10.5. Computational Attacks 1448 CCNinfo may impose heavy tasks at content forwarders. The current 1449 CCNinfo specification allows to return null values for several 1450 fields, such as First/Last Seqnum or Elapsed Cache Time fields in the 1451 Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY 1452 be null. This means that the content forwarder can not only hide 1453 these values owing to privacy/security policies, but also skip the 1454 implementations of the complex functions to report these values. 1456 10.6. Longer or Shorter CCNinfo Reply Timeout 1458 Routers can configure CCNinfo Reply Timeout (Section 7.1), which is 1459 the allowable timeout value to keep the PIT entry. If routers 1460 configure a longer timeout value, there may be an attractive attack 1461 vector against the PIT memory. Moreover, especially when the full 1462 discovery request option (Section 5.3) is specified for the CCNinfo 1463 Request, several Reply messages may be returned and cause a response 1464 storm. (See Section 10.8 for rate limiting to avoid the storm). To 1465 avoid DoS attacks, routers MAY configure the timeout value, which is 1466 shorter than the user-configured CCNinfo timeout value. However, if 1467 it is too short, the Request may be timed out and the CCNinfo user 1468 does not receive all Replies; s/he only retrieves the partial path 1469 information (i.e., information about a part of the tree). 1471 There may be a way to enable incremental exploration (i.e., to 1472 explore the part of the tree that was not explored by the previous 1473 operation); however, discussing such mechanisms is out of scope of 1474 this document. 1476 10.7. Limiting Request Rates 1478 A router may rate-limit CCNinfo Requests by ignoring some of the 1479 consecutive messages. The router MAY randomly ignore the received 1480 messages to minimize the processing overhead, i.e., to keep fairness 1481 in processing requests, or prevent traffic amplification. In such a 1482 case, no error message is returned. The rate limit function is left 1483 to the router's implementation. 1485 10.8. Limiting Reply Rates 1487 CCNinfo supporting multipath forwarding may result in one Request 1488 returning multiple Reply messages. To prevent abuse, the routers in 1489 the traced path MAY need to rate-limit the Replies. In such a case, 1490 no error message is returned. The rate limit function is left to the 1491 router's implementation. 1493 10.9. Adjacency Verification 1495 It is assumed that the CCNinfo Request and Reply messages are 1496 forwarded by adjacent neighbor nodes or routers. The CCNx message 1497 format or semantics do not define a secure way to verify the node/ 1498 router adjacency, while HopAuth [10] provides a possible method for 1499 an adjacency verification and defines the corresponding message 1500 format for adjacency verification as well as the router behaviors. 1501 CCNinfo MAY use a similar method for node adjacency verification. 1503 11. Acknowledgements 1505 The authors would like to thank Spyridon Mastorakis, Paulo Mendes, 1506 Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable 1507 comments and suggestions on this document. 1509 12. References 1511 12.1. Normative References 1513 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1514 Format", RFC 8609, July 2019. 1516 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1517 RFC 8569, July 2019. 1519 [3] Bradner, S., "Key words for use in RFCs to Indicate 1520 Requirement Levels", BCP 14, RFC 2119, 1521 DOI 10.17487/RFC2119, March 1997, 1522 . 1524 [4] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1525 Writing an IANA Considerations Section in RFCs", BCP 26, 1526 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1527 . 1529 12.2. Informative References 1531 [5] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1532 January 1993. 1534 [6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1535 Tool for Measuring and Tracing Content-Centric Networks", 1536 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1537 March 2015. 1539 [7] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1540 D. Oran, "ICN Ping Protocol Specification", draft-irtf- 1541 icnrg-icnping-00 (work in progress), March 2020. 1543 [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1544 D. Oran, "ICN Traceroute Protocol Specification", draft- 1545 irtf-icnrg-icntraceroute-00 (work in progress), March 1546 2020. 1548 [9] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1549 Traceroute Facility for IP Multicast", RFC 8487, October 1550 2018. 1552 [10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in 1553 Content-Centric Networking/Named Data Networking", draft- 1554 li-icnrg-hopauth-02 (work in progress), February 2020. 1556 [11] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive 1557 Caching and Adaptive Retrieval for In-Network Big Data 1558 Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. 1560 [12] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: 1561 Software Platform Enabling Content-Centric Networking and 1562 Beyond", IEICE Transaction on Communications, Vol.E102-B, 1563 No.9, pp.1792-1803, September 2019. 1565 [13] "Cefore Home Page", . 1567 Appendix A. ccninfo Command and Options 1569 CCNinfo is implemented in Cefore [12][13]. "ccninfo" is the command 1570 invoked by the CCNinfo user (e.g., consumer). The ccninfo command 1571 sends the Request message and receives the Reply message(s). There 1572 are several options that can be specified with ccninfo, while the 1573 content name prefix (e.g., ccnx:/news/today) is the mandatory 1574 parameter. 1576 The usage of ccninfo command is as follows: 1578 Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v 1579 algo] name_prefix 1581 name_prefix 1582 Prefix name of content (e.g., ccnx:/news/today) or exact name of 1583 content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants 1584 to trace. 1586 c option 1587 This option can be specified if a CCNinfo user needs the cache 1588 information as well as the routing path information for the 1589 specified content/cache and RTT between the CCNinfo user and 1590 content forwarder. 1592 f option 1593 This option enables the "full discovery request"; routers send 1594 CCNinfo Requests to multiple upstream faces based on their FIBs 1595 simultaneously. The CCNinfo user can then trace all possible 1596 forwarding paths. 1598 o option 1599 This option enables to trace the path to the content publisher. 1600 Each router along the path to the publisher inserts each Report 1601 block and forwards the Request message. It does not send Reply 1602 even if it caches the specified content. FHR that attaches the 1603 publisher (who has the complete set of content and is not a 1604 caching router) sends the Reply message. 1606 V option 1607 This option requests the Reply sender to validate the Reply 1608 message with the Reply sender's signature. The Reply message will 1609 then include the CCNx ValidationPayload TLV. The validation 1610 algorithm is selected by the Reply sender. 1612 r option 1613 Number of traced routers. This value is set in the "HopLimit" 1614 field located in the fixed header of the Request. For example, 1615 when the CCNinfo user invokes the CCNinfo command with this 1616 option, such as "-r 3", only three routers along the path examine 1617 their path and cache information. 1619 s option 1620 Number of skipped routers. This value is set in the "SkipHop" 1621 field located in the Request block TLV. For example, when the 1622 CCNinfo user invokes the CCNinfo command with this option, such as 1623 "-s 3", three upstream routers along the path only forward the 1624 Request message but do not append their Report blocks in the hop- 1625 by-hop header and do not send Reply messages despite having the 1626 corresponding cache. 1628 v option 1629 This option enables the CCNinfo user to validate the Request 1630 message with his/her signature. The Request message will include 1631 the CCNx ValidationPayload TLV. The validation algorithm is 1632 specified by the CCNinfo user. 1634 Authors' Addresses 1636 Hitoshi Asaeda 1637 National Institute of Information and Communications Technology 1638 4-2-1 Nukui-Kitamachi 1639 Koganei, Tokyo 184-8795 1640 Japan 1642 Email: asaeda@nict.go.jp 1643 Atsushi Ooka 1644 National Institute of Information and Communications Technology 1645 4-2-1 Nukui-Kitamachi 1646 Koganei, Tokyo 184-8795 1647 Japan 1649 Email: a-ooka@nict.go.jp 1651 Xun Shao 1652 Kitami Institute of Technology 1653 165 Koen-cho 1654 Kitami, Hokkaido 090-8507 1655 Japan 1657 Email: x-shao@mail.kitami-it.ac.jp