idnits 2.17.1 draft-irtf-icnrg-ccninfo-06.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 -- 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 (March 9, 2021) is 1143 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 1585 -- Looks like a reference, but probably isn't: '-f' on line 1585 -- Looks like a reference, but probably isn't: '-o' on line 1585 -- Looks like a reference, but probably isn't: '-V' on line 1585 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icnping-01 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icntraceroute-01 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 10, 2021 X. Shao 6 Kitami Institute of Technology 7 March 9, 2021 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-06 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 September 10, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 IP traceroute is a useful tool for discovering the routing conditions 137 in IP networks because it provides intermediate router addresses 138 along the path between the source and destination and the Round-Trip 139 Time (RTT) for the path. However, this IP-based network tool cannot 140 trace the name prefix paths used in CCN. Moreover, such IP-based 141 network tools do not obtain the states of the in-network cache to be 142 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 317 "OPTIONAL" in this document are to be interpreted as described in BCP 318 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in 319 all capitals, as shown here. 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 timespec (fractional part in 671 nanoseconds) to a 32-bit NTP 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), where "<<" 679 denotes a logical left shift. 681 Note that it is RECOMMENDED for all the routers on the path to 682 have synchronized clocks to measure one-way latency per hop; 683 however, even if they do not have synchronized clocks, CCNinfo 684 measures the RTT between the content forwarder and consumer. 686 Node Identifier: variable length 688 This field specifies the node identifier (e.g., node name or hash- 689 based self-certifying name [10]) or all-zeros if unknown. This 690 document assumes that the Name TLV defined in the CCNx TLV format 691 [1] can be used for this field and the node identifier is 692 specified in it. 694 3.1.2. Report Block TLV 696 A CCNinfo user and each upstream router along the path would insert 697 their own Report block TLV without changing the Type field of the 698 fixed header of the Request message until one of these routers is 699 ready to send a Reply. In the Report block TLV (Figure 13), the 700 Request Arrival Time and Node Identifier MUST be inserted. 702 1 2 3 703 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 704 +---------------+---------------+---------------+---------------+ 705 | Type (=T_DISC_REPORT) | Length | 706 +---------------+---------------+---------------+---------------+ 707 | Request Arrival Time | 708 +---------------+---------------+---------------+---------------+ 709 / Node Identifier / 710 +---------------+---------------+---------------+---------------+ 712 Figure 13: Report block TLV (hop-by-hop header) 714 Type: 16 bits 716 Format of the Value field. For the Report block TLV, the type 717 value(s) MUST be T_DISC_REPORT in the current specification. For 718 all the available types for hop-by-hop type namespace, please see 719 Figure 9. 721 Length: 16 bits 723 Length of Value field in octets. 725 Request Arrival Time: 32 bits 727 Same definition as given in Section 3.1.1. 729 Node Identifier: variable length 730 Same definition as given in Section 3.1.1. 732 3.1.3. Content Name Specification 734 Specifications of the Name TLV (whose type value is T_NAME) and the 735 Name Segment TLVs are described in [1], which are followed by 736 CCNinfo. CCNinfo enables to specification of the content name either 737 with a prefix name without chunk number (such as "ccnx:/news/today") 738 or an exact name (such as "ccnx:/news/today/Chunk=10"). When a 739 CCNinfo user specifies a prefix name, s/he will obtain the summary 740 information of the matched content objects in the content forwarder. 741 In contrast, when a CCNinfo user specifies an exact name, s/he will 742 obtain only about the specified content object in the content 743 forwarder. A CCNinfo Request message MUST NOT be sent only with a 744 scheme name, ccnx:/. It will be rejected and discarded by routers. 746 3.2. Reply Message 748 When a content forwarder receives a CCNinfo Request message from an 749 appropriate adjacent neighbor router, it inserts its own Reply block 750 TLV and Reply sub-block TLV(s) to the Request message and turns the 751 Request into the Reply by changing the Type field of the fixed header 752 of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. 753 The Reply message (see Figure 14) is then forwarded back toward the 754 CCNinfo user in a hop-by-hop manner. 756 1 2 3 757 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 758 +---------------+---------------+---------------+---------------+ 759 | Version | PacketType | PacketLength | 760 +---------------+---------------+-------------+-+---------------+ 761 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 762 +===============+===============+=============+=+===============+ 763 / Request header block TLV / 764 +---------------+---------------+---------------+---------------+ 765 / . / 766 / . / 767 / n Report block TLVs / 768 / . / 769 / . / 770 +===============+===============+===============+===============+ 771 | Type (=T_DISCOVERY) | MessageLength | 772 +---------------+---------------+---------------+---------------+ 773 | T_NAME | Length | 774 +---------------+---------------+---------------+---------------+ 775 / Name segment TLVs (name prefix specified by CCNinfo user) / 776 +---------------+---------------+---------------+---------------+ 777 / Request block TLV / 778 +---------------+---------------+---------------+---------------+ 779 / Reply block TLV / 780 +---------------+---------------+---------------+---------------+ 781 / Reply sub-block TLV 1 / 782 +---------------+---------------+---------------+---------------+ 783 / . / 784 / . / 785 +---------------+---------------+---------------+---------------+ 786 / Reply sub-block TLV k / 787 +---------------+---------------+---------------+---------------+ 788 / Optional CCNx ValidationAlgorithm TLV / 789 +---------------+---------------+---------------+---------------+ 790 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 791 +---------------+---------------+---------------+---------------+ 793 Figure 14: Reply message consists of a fixed header, Request block 794 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 796 3.2.1. Reply Block TLV 798 The Reply block TLV is an envelope for the Reply sub-block TLV(s) 799 (explained from the next section). 801 1 2 3 802 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 803 +---------------+---------------+---------------+---------------+ 804 | Type (=T_DISC_REPLY) | Length | 805 +---------------+---------------+---------------+---------------+ 806 | Request Arrival Time | 807 +---------------+---------------+---------------+---------------+ 808 / Node Identifier / 809 +---------------+---------------+---------------+---------------+ 811 Figure 15: Reply block TLV (packet payload) 813 Type: 16 bits 815 Format of the Value field. For the Reply block TLV, the type 816 value MUST be T_DISC_REPLY shown in Figure 12 in the current 817 specification. 819 Length: 16 bits 821 Length of the Value field in octets. This length is the total 822 length of Reply sub-block(s). 824 Request Arrival Time: 32 bits 826 Same definition as given in Section 3.1.1. 828 Node Identifier: variable length 830 Same definition as given in Section 3.1.1. 832 3.2.1.1. Reply Sub-Block TLV 834 The router on the traced path will add one or multiple Reply sub- 835 blocks followed by the Reply block TLV before sending the Reply to 836 its neighbor router. This section describes the Reply sub-block TLV 837 for informing various cache states and conditions as shown in 838 Figure 16. (Other Reply sub-block TLVs will be discussed in separate 839 document(s).) 841 Note that some routers may not be capable of reporting the following 842 values, such as Object Size, Object Count, # Received Interest, First 843 Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, 844 shown in Figure 16, or do not report these values due to their 845 policy. In that case, the routers set these fields to a value of one 846 (i.e., %xFFFFFFFF). The value of each field will be also all-one 847 when the value is equal to or bigger than the maximum size expressed 848 by the 32-bit field. The CCNinfo user program MUST inform that these 849 values are invalid if the fields received are set to the value of 850 one. 852 If the cache is refreshed after reboot, the value in each field MUST 853 be refreshed (i.e., MUST be set to 0). If the cache remains after 854 reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as 855 it is). 857 1 2 3 858 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 859 +---------------+---------------+---------------+---------------+ 860 | Type | Length | 861 +---------------+---------------+---------------+---------------+ 862 | Object Size | 863 +---------------+---------------+---------------+---------------+ 864 | Object Count | 865 +---------------+---------------+---------------+---------------+ 866 | # Received Interest | 867 +---------------+---------------+---------------+---------------+ 868 | First Seqnum | 869 +---------------+---------------+---------------+---------------+ 870 | Last Seqnum | 871 +---------------+---------------+---------------+---------------+ 872 | Elapsed Cache Time | 873 +---------------+---------------+---------------+---------------+ 874 | Remain Cache Lifetime | 875 +---------------+---------------+---------------+---------------+ 876 | T_NAME | Length | 877 +---------------+---------------+---------------+---------------+ 878 / Name Segment TLVs / 879 +---------------+---------------+---------------+---------------+ 881 Figure 16: Reply sub-block TLV for T_DISC_CONTENT and 882 T_DISC_CONTENT_PUBLISHER (packet payload) 884 Code Type name 885 ============= =========================== 886 %x0000 T_DISC_CONTENT 887 %x0001 T_DISC_CONTENT_PUBLISHER 888 %x0FFF T_ORG 889 %x1000-%x1FFF Reserved (Experimental Use) 891 Figure 17: CCNinfo Reply Type Namespace 893 Type: 16 bits 895 Format of the Value field. For the Reply sub-block TLV, the type 896 value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER 897 defined in the CCNinfo Reply Type Namespace (Figure 17). 898 T_DISC_CONTENT is specified when the cache information is replied 899 from a caching router. T_DISC_CONTENT_PUBLISHER is specified when 900 the content information is replied from a FHR attached to a 901 publisher. 903 Length: 16 bits 905 Length of the Value field in octets. 907 Object Size: 32 bits 909 The total size (KB) of the unexpired content objects. Note that 910 the maximum size expressed by the 32-bit field is approximately 911 4.29 TB. 913 Object Count: 32 bits 915 The number of the unexpired content objects. Note that the 916 maximum count expressed by the 32-bit field is approximately 4.29 917 billion. 919 # Received Interest: 32 bits 921 The total number of the received Interest messages to retrieve the 922 cached content objects. 924 First Seqnum: 32 bits 926 The first sequential number of the unexpired content objects. 928 Last Seqnum: 32 bits 930 The last sequential number of the unexpired content objects. The 931 First Seqnum and Last Seqnum do not guarantee the consecutiveness 932 of the cached content objects; however, knowing these values may 933 help in the analysis of consecutive or discontinuous chunks such 934 as [11]. 936 Elapsed Cache Time: 32 bits 938 The elapsed time (seconds) after the oldest content object of the 939 content is cached. 941 Remain Cache Lifetime: 32 bits 943 The lifetime (seconds) of a content object, which is lastly 944 cached. 946 4. CCNinfo User Behavior 948 4.1. Sending CCNinfo Request 950 A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) 951 that initiates a CCNinfo Request message and sends it to the user's 952 adjacent neighbor router(s) of interest. The user later obtains both 953 the routing path information and in-network cache information in the 954 single Reply. 956 When the CCNinfo user program initiates a Request message, it MUST 957 insert the necessary values, i.e., the "Request ID" and the "Node 958 Identifier", in the Request block. The Request ID MUST be unique for 959 the CCNinfo user until s/he receives the corresponding Reply 960 message(s) or the Request is timed out. 962 Owing to some policies, a router may want to validate the CCNinfo 963 Requests using the CCNx ValidationPayload TLV (whether it accepts the 964 Request or not) especially when the router receives the "full 965 discovery request" (see Section 5.3.2). Accordingly, the CCNinfo 966 user program MAY require validating the Request message and appending 967 the user's signature into the CCNx ValidationPayload TLV. The router 968 then forwards the Request message. If the router does not approve 969 the Request, it rejects the Request message as described in 970 Section 6.11. 972 After the CCNinfo user program sends the Request message, until the 973 Reply is timed out or the expected numbers of Replies or a Reply 974 message with a non-zero ReturnCode in the fixed header is received, 975 the CCNinfo user program MUST keep the following information: 976 HopLimit, specified in the fixed header, Request ID, Flags, Node 977 Identifier, and Request Arrival Time, specified in the Request block. 979 4.1.1. Routing Path Information 981 A CCNinfo user can send a CCNinfo Request for investigating the 982 routing path information for the specified named content. Using the 983 Request, a legitimate user can obtain 1) the node identifiers of the 984 intermediate routers, 2) node identifier of the content forwarder, 3) 985 number of hops between the content forwarder and consumer, and 4) RTT 986 between the content forwarder and consumer, per name prefix. This 987 CCNinfo Request is terminated when it reaches the content forwarder. 989 4.1.2. In-Network Cache Information 991 A CCNinfo user can send a CCNinfo Request for investigating in- 992 network cache information. Using the Request, a legitimate user can 993 obtain 1) the size of cached content objects, 2) number of cached 994 content objects, 3) number of accesses (i.e., received Interests) per 995 content, and 4) lifetime and expiration time of the cached content 996 objects, for Content Store (CS) in the content forwarder, unless the 997 content forwarder is capable of reporting them (see Section 3.2.1.1). 998 This CCNinfo Request is terminated when it reaches the content 999 forwarder. 1001 4.2. Receiving CCNinfo Reply 1003 A CCNinfo user program will receive one or multiple CCNinfo Reply 1004 messages from the adjacent neighbor router(s). When the program 1005 receives the Reply, it MUST compare the kept Request ID and Node 1006 Identifier to identify the Request and Reply pair. If they do not 1007 match, the Reply message MUST be silently discarded. 1009 If the number of Report blocks in the received Reply is more than the 1010 initial HopLimit value (which was inserted in the original Request), 1011 the Reply MUST be silently ignored. 1013 After the CCNinfo user has determined that s/he has traced the whole 1014 path or the maximum path that s/he can be expected to, s/he might 1015 collect statistics by waiting for a timeout. Useful statistics 1016 provided by CCNinfo are stated in Section 8. 1018 5. Router Behavior 1020 5.1. User and Neighbor Verification 1022 Upon receiving a CCNinfo Request message, a router MAY examine 1023 whether a valid CCNinfo user has sent the message. If the router 1024 recognizes that the Request sender's signature specified in the 1025 Request is invalid, it SHOULD terminate the Request, as defined in 1026 Section 6.4. 1028 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 1029 whether the message comes from a valid adjacent neighbor node. If 1030 the router recognizes that the Request/Reply sender is invalid, it 1031 SHOULD silently ignore the Request/Reply message, as specified in 1032 Section 10.9. 1034 5.2. Receiving CCNinfo Request 1036 After a router accepts the CCNinfo Request message, it performs the 1037 following steps. 1039 1. The value of "HopLimit" in the fixed header and that of "SkipHop 1040 (Skip Hop Count)" in the Request block are counters that are 1041 decremented with each hop. If the HopLimit value is zero, the 1042 router terminates the Request, as defined in Section 6.5. If the 1043 SkipHop value is equal to or more than the HopLimit value, the 1044 router terminates the Request, as defined in Section 6.4. 1045 Otherwise, until the SkipHop value becomes zero, the router 1046 forwards the Request message to the upstream router(s) without 1047 adding its own Report block and without replying to the Request. 1048 If the router does not know the upstream router(s) regarding the 1049 specified name prefix, it terminates the Request, as defined in 1050 Section 6.5. It should be noted that the Request messages are 1051 terminated at the FHR; therefore, although the maximum value for 1052 the HopLimit is 255 and that for SkipHop is 15, if the Request 1053 messages reach the FHR before the HopLimit or SkipHop value 1054 becomes 0, the FHR silently discards the Request message and the 1055 Request is timed out. 1057 2. The router examines the Flags field (specified in Figure 10) in 1058 the Request block of the received CCNinfo Request. If the "C" 1059 flag is not set, it is categorized as the "routing path 1060 information discovery". If the "C" flag is set, it is the "cache 1061 information discovery". If the "O" flag is set, it is the 1062 "publisher discovery". 1064 3. If the Request is either "cache information discovery" or 1065 "routing path information discovery", the router examines its FIB 1066 and CS. If the router caches the specified content, it sends the 1067 Reply message with its own Reply block and sub-block(s). If the 1068 router cannot insert its own Reply block or sub-block(s) because 1069 of no space, it it terminates the Request, as specified in 1070 Section 6.7. If the router does not cache the specified content 1071 but knows the upstream neighbor router(s) for the specified name 1072 prefix, it creates the PIT entry, and inserts its own Report 1073 block in the hop-by-hop header and forwards the Request to the 1074 upstream neighbor(s). If the router cannot insert its own Report 1075 block because of no space, or if the router does not cache the 1076 specified content and does not know the upstream neighbor 1077 router(s) for the specified name prefix, it terminates the 1078 Request, as defined in Section 6.5. 1080 4. If the Request is the "publisher discovery", the router examines 1081 whether it is the FHR for the requested content. If the router 1082 is the FHR, it sends the Reply message with its own Report block 1083 and sub-blocks (in the case of cache information discovery) or 1084 the Reply message with its own Report block without adding any 1085 Reply sub-blocks (in the case of routing path information 1086 discovery). If the router is not the FHR but knows the upstream 1087 neighbor router(s) for the specified name prefix, it creates the 1088 PIT entry, and inserts its own Report block and forwards the 1089 Request to the upstream neighbor(s). If the router cannot insert 1090 its own Report block in the hop-by-hop header because of no 1091 space, it it terminates the Request, as specified in Section 6.7. 1092 If the router is not the FHR and does not know the upstream 1093 neighbor router(s) for the specified name prefix, it terminates 1094 the Request, as defined in Section 6.5. Note that in Cefore 1095 [13], there is an API by which a publisher informs the 1096 application prefix to the FHR and the FHR registers it into the 1097 FIB. The prefix entry then can be statically configured on other 1098 routers or announced by a routing protocol. 1100 5.3. Forwarding CCNinfo Request 1102 5.3.1. Regular Request 1104 When a router decides to forward a Request message with its Report 1105 block to its upstream router(s), it specifies the Request Arrival 1106 Time and Node Identifier in the Report block of the Request message. 1107 The router then forwards the Request message upstream toward the 1108 publisher or caching router based on the FIB entry like the ordinary 1109 Interest-Data exchanges in CCN. 1111 When the router forwards the Request message, it MUST record the F 1112 flag and Request ID in the Request block of the Request message and 1113 exploiting path labels (specified in Section 1) at the corresponding 1114 PIT entry. The router can later check the PIT entry to correctly 1115 forward the Reply message(s) back. 1117 CCNinfo supports multipath forwarding. The Request messages can be 1118 forwarded to multiple neighbor routers. Some routers may have a 1119 strategy for multipath forwarding; when a router sends Interest 1120 messages to multiple neighbor routers, it may delay or prioritize to 1121 send the message to the upstream routers. The CCNinfo Request, as 1122 the default, complies with such strategies; a CCNinfo user could 1123 trace the actual forwarding path based on the forwarding strategy and 1124 will receive a single Reply message such as a content object. 1126 5.3.2. Full Discovery Request 1128 There may be a case wherein a CCNinfo user wants to discover all 1129 possible forwarding paths and content forwarders based on the 1130 routers' FIBs. The "full discovery request" enables this 1131 functionality. If a CCNinfo user sets the F flag in the Request 1132 block of the Request message (as seen in Figure 10) to request the 1133 full discovery, the upstream routers simultaneously forward the 1134 Requests to all multiple upstream routers based on the FIBs. Then, 1135 the CCNinfo user can trace all possible forwarding paths. 1137 3. Reply(C) 2. Reply(C) 1138 3. Reply(P) 2. Reply(P) 1. Reply(P) 1139 +----+ +----+ +----+ 1140 | | | | | | 1141 v | v | v | 1142 +--------+ +--------+ +--------+ +--------+ +---------+ 1143 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 1144 | user | | A | | B | | C | | | 1145 +--------+ +--------+ +--------+ +--------+ +---------+ 1146 ^ 1147 \ +-------+ 1148 1. Reply(C) \ | Cache | 1149 \ +---------+ | 1150 \| Caching |----+ 1151 | router | 1152 +---------+ 1154 Figure 18: Full discovery request. Reply messages forwarded by 1155 publisher and routers. Each router forwards the Reply message along 1156 its PIT entry and finally, the CCNinfo user receives two Reply 1157 messages: one from the FHR (Router C) and the other from the Caching 1158 router. 1160 To receive different Reply messages forwarded from different routers, 1161 the PIT entries initiated by CCNinfo remain until the configured 1162 CCNinfo Reply Timeout (Section 7.1) is expired. In other words, 1163 unlike the ordinary Interest-Data exchanges in CCN, if routers that 1164 accept the full discovery request receive the full discovery request, 1165 the routers SHOULD NOT remove the PIT entry created by the full 1166 discovery request until the CCNinfo Reply Timeout value expires. 1168 Note that the full discovery request is an OPTIONAL implementation of 1169 CCNinfo; it may not be implemented on routers. Even if it is 1170 implemented on a router, it may not accept the full discovery request 1171 from non-validated CCNinfo users or routers or because of its policy. 1172 If a router does not accept the full discovery request, it rejects 1173 the full discovery request as described in Section 6.11. Routers 1174 that enable the full discovery request MAY rate-limit Replies, as 1175 described in Section 10.8 as well. 1177 5.4. Sending CCNinfo Reply 1179 If there is a caching router or FHR for the specified content within 1180 the specified hop count along the path, the caching router or FHR 1181 sends back the Reply message toward the CCNinfo user and terminates 1182 the Request. 1184 When a router decides to send a Reply message to its downstream 1185 neighbor router or the CCNinfo user with NO_ERROR return code, it 1186 inserts a Report block with the Request Arrival Time and Node 1187 Identifier to the Request message. Then, the router inserts the 1188 corresponding Reply sub-block(s) (Figure 16) to the payload. The 1189 router finally changes the Type field in the fixed header from 1190 PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back 1191 as the Reply toward the CCNinfo user in a hop-by-hop manner. 1193 If a router cannot continue the Request, the router MUST put an 1194 appropriate ReturnCode in the Request message, change the Type field 1195 value in the fixed header from PT_CCNINFO_REQUEST to 1196 PT_CCNINFO_REPLY, and forward the Reply message back toward the 1197 CCNinfo user to terminate the Request (see Section 6). 1199 5.5. Forwarding CCNinfo Reply 1201 When a router receives a CCNinfo Reply whose Request ID and Node 1202 Identifier match those in the PIT entry, sent from a valid adjacent 1203 neighbor router, it forwards the CCNinfo Reply back toward the 1204 CCNinfo user. If the router does not receive the corresponding Reply 1205 within the [CCNinfo Reply Timeout] period, then it removes the 1206 corresponding PIT entry and terminates the trace. 1208 The Flags field in the Request block TLV is used to indicate whether 1209 the router keeps the PIT entry during the CCNinfo Reply Timeout even 1210 after one or more corresponding Reply messages are forwarded. When 1211 the CCNinfo user does not set the F flag (i.e., "0"), the 1212 intermediate routers immediately remove the PIT entry whenever they 1213 forward the corresponding Reply message. When the CCNinfo user sets 1214 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1215 "full discovery request" (see Section 5.3.2), the intermediate 1216 routers keep the PIT entry within the [CCNinfo Reply Timeout] period. 1217 After this timeout, the PIT entry is removed. 1219 CCNinfo Replies MUST NOT be cached in routers upon the transmission 1220 of Reply messages. 1222 6. CCNinfo Termination 1224 When performing a hop-by-hop trace, it is necessary to determine when 1225 to stop the trace. There are several cases when an intermediate 1226 router might return a Reply before a Request reaches the caching 1227 router or the FHR. 1229 6.1. Arriving at First-hop Router 1231 A CCNinfo Request can be determined to have arrived at the FHR. To 1232 ensure that a router recognizes that it is the FHR for the specified 1233 content, it needs to have a FIB entry (or attach) to the 1234 corresponding publisher or the content. 1236 6.2. Arriving at Router Having Cache 1238 A CCNinfo Request can be determined to have arrived at the router 1239 having the specified content cache within the specified HopLimit. 1241 6.3. Arriving at Last Router 1243 A CCNinfo Request can be determined to have arrived at the last 1244 router of the specified HopLimit. If the last router does not have 1245 the corresponding cache, it MUST insert its Report block and send the 1246 Reply message with NO_INFO return code without appending any Reply 1247 (sub-)block TLVs. 1249 6.4. Invalid Request 1251 If the router does not validate the Request or the Reply, the router 1252 MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the 1253 message, insert its Report block, and forward the message as the 1254 Reply back to the CCNinfo user. The router MAY, however, randomly 1255 ignore the received invalid messages. (See Section 10.7.) 1257 6.5. No Route 1259 If the router cannot determine the routing paths or neighbor routers 1260 for the specified name prefix within the specified HopLimit, it MUST 1261 note a ReturnCode of NO_ROUTE in the fixed header of the message, 1262 insert its Report block, and forward the message as the Reply back to 1263 the CCNinfo user. 1265 6.6. No Information 1267 If the router does not have any information about the specified name 1268 prefix within the specified HopLimit, it MUST note a ReturnCode of 1269 NO_INFO in the fixed header of the message, insert its Report block, 1270 and forward the message as the Reply back to the CCNinfo user. 1272 6.7. No Space 1274 If appending the Report block or the Reply (sub-)block would make the 1275 hop-by-hop header longer than 247 bytes or the Request packet longer 1276 than the MTU of the Incoming face, the router MUST note a ReturnCode 1277 of NO_SPACE in the fixed header of the message and forward the 1278 message as the Reply back to the CCNinfo user. 1280 6.8. Fatal Error 1282 If a CCNinfo Request has encountered a fatal error, the router MUST 1283 note a ReturnCode of FATAL_ERROR in the fixed header of the message 1284 and forward the message as the Reply back to the CCNinfo user. This 1285 may happen, for example, when the router detects some routing loop in 1286 the Request blocks (see Section 1). The fatal error can be encoded 1287 with another error: if a router detects routing loop but cannot 1288 insert its Report block, it MUST note NO_SPACE and FATAL_ERROR 1289 ReturnCodes (i.e., %x85) in the fixed header and forward the message 1290 back to the CCNinfo user. 1292 6.9. CCNinfo Reply Timeout 1294 If a router receives the Request or Reply message that expires its 1295 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1296 silently discard the Request or Reply message. 1298 6.10. Non-Supported Node 1300 Cases will arise in which a router or a FHR along the path does not 1301 support CCNinfo. In such cases, a CCNinfo user and routers that 1302 forward the CCNinfo Request will time out the CCNinfo request. 1304 6.11. Administratively Prohibited 1306 If CCNinfo is administratively prohibited, the router rejects the 1307 Request message and MUST send the CCNinfo Reply with the ReturnCode 1308 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1309 Request messages to be rejected (see Section 10.7). 1311 7. Configurations 1313 7.1. CCNinfo Reply Timeout 1315 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1316 Reply. The value for a router can be statically configured by the 1317 router's administrators/operators. The default value is 3 (seconds). 1318 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 1319 (seconds) and SHOULD NOT be lower than 2 (seconds). 1321 7.2. HopLimit in Fixed Header 1323 If a CCNinfo user does not specify the HopLimit value in the fixed 1324 header for a Request message as the HopLimit, the HopLimit is set to 1325 32. Note that 0 HopLimit is an invalid Request; hence, the router in 1326 this case follows the way defined in Section 6.4. 1328 7.3. Access Control 1330 A router MAY configure the valid or invalid networks to enable an 1331 access control. The access control MAY be defined per name prefix, 1332 such as "who can retrieve which name prefix" (see Section 10.2). 1334 8. Diagnosis and Analysis 1336 8.1. Number of Hops and RTT 1338 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1339 each forwarding router appends its own Report block. We can then 1340 verify the number of hops to reach the content forwarder or publisher 1341 and the RTT between the content forwarder or publisher. 1343 8.2. Caching Router Identification 1345 While some routers may hide their node identifiers with all-zeros in 1346 the Report blocks (as seen in Section 10.1), the routers in the path 1347 from the CCNinfo user to the content forwarder can be identified. 1349 8.3. TTL or Hop Limit 1351 By taking the HopLimit from the content forwarder and forwarding the 1352 TTL threshold over all hops, it is possible to discover the TTL or 1353 hop limit required for the content forwarder to reach the CCNinfo 1354 user. 1356 8.4. Time Delay 1358 If the routers have synchronized clocks, it is possible to estimate 1359 the propagation and queuing delays from the differences between the 1360 timestamps at the successive hops. However, this delay includes the 1361 control processing overhead; therefore, it is not necessarily 1362 indicative of the delay that would be experienced by the data 1363 traffic. 1365 8.5. Path Stretch 1367 By obtaining the path stretch "d / P", where "d" is the hop count of 1368 the data and "P" is the hop count from the consumer to the publisher, 1369 we can measure the improvements in path stretch in various cases, 1370 such as in different caching and routing algorithms. We can then 1371 facilitate the investigation of the performance of the protocol. 1373 8.6. Cache Hit Probability 1375 CCNinfo can show the number of received interests per cache or chunk 1376 on a router. Accordingly, CCNinfo measures the content popularity 1377 (i.e., the number of accesses for each content/cache), thereby 1378 enabling the investigation of the routing/caching strategy in 1379 networks. 1381 9. IANA Considerations 1383 New assignments can only be made via a Standards Action as specified 1384 in [5]. This document does not intend to be the standard document. 1385 However, the new assignments such as the ReturnCode and various type 1386 values will be considered when this specification becomes the RFC. 1388 10. Security Considerations 1390 This section addresses some of the security considerations. 1392 10.1. Policy-Based Information Provisioning for Request 1394 Although CCNinfo gives excellent troubleshooting cues, some network 1395 administrators or operators may not want to disclose everything about 1396 their network to the public or may wish to securely transmit private 1397 information to specific members of their networks. CCNinfo provides 1398 policy-based information provisioning, thereby allowing network 1399 administrators to specify their response policy for each router. 1401 The access policy regarding "who is allowed to retrieve" and/or "what 1402 kind of cache information" can be defined for each router. For the 1403 former type of access policy, routers with the specified content MAY 1404 examine the signature enclosed in the Request message and decide 1405 whether they should notify the content information in the Reply. If 1406 the routers decide to not notify the content information, they MUST 1407 send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1408 appending any Reply (sub-)block TLVs. For the latter type of policy, 1409 the permission, whether (1) All (all cache information is disclosed), 1410 (2) Partial (cache information with a particular name prefix can (or 1411 cannot) be disclosed), or (3) Deny (no cache information is 1412 disclosed), is defined at the routers. 1414 In contrast, we entail that each router does not disrupt the 1415 forwarding of CCNinfo Request and Reply messages. When a Request 1416 message is received, the router SHOULD insert the Report block if the 1417 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1418 the Node Identifier field in the Report block MAY be null (i.e., all- 1419 zeros), but the Request Arrival Time field SHOULD NOT be null. 1420 Finally, the router SHOULD forward the Request message to the 1421 upstream router toward the content forwarder if the ReturnCode is 1422 kept with NO_ERROR. 1424 10.2. Filtering CCNinfo Users Located in Invalid Networks 1426 A router MAY support an access control mechanism to filter out 1427 Requests from invalid CCNinfo users. To accomplish this, invalid 1428 networks (or domains) could, for example, be configured via a list of 1429 allowed/disallowed networks (as observed in Section 7.3). If a 1430 Request is received from a disallowed network (according to the Node 1431 Identifier in the Request block), the Request MUST NOT be processed 1432 and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to 1433 note that. The router MAY, however, perform rate limited logging of 1434 such events. 1436 10.3. Topology Discovery 1438 CCNinfo can be used to discover actively used topologies. If a 1439 network topology is not disclosed, CCNinfo Requests SHOULD be 1440 restricted at the border of the domain using the ADMIN_PROHIB return 1441 code. 1443 10.4. Characteristics of Content 1445 CCNinfo can be used to discover the type of content being sent by 1446 publishers. If this information is a secret, CCNinfo Requests SHOULD 1447 be restricted at the border of the domain, using the ADMIN_PROHIB 1448 return code. 1450 10.5. Computational Attacks 1452 CCNinfo may impose heavy tasks at content forwarders because it makes 1453 content forwarders seek their internal cache states reported in the 1454 Reply messages whenever they form the Reply messages. The current 1455 CCNinfo specification allows to return null values for several 1456 fields, such as First/Last Seqnum or Elapsed Cache Time fields in the 1457 Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY 1458 be null. This means that the content forwarder can not only hide 1459 these values owing to privacy/security policies, but also skip the 1460 implementations of the complex functions to report these values. 1462 10.6. Longer or Shorter CCNinfo Reply Timeout 1464 Routers can configure CCNinfo Reply Timeout (Section 7.1), which is 1465 the allowable timeout value to keep the PIT entry. If routers 1466 configure a longer timeout value, there may be an attractive attack 1467 vector against the PIT memory. Moreover, especially when the full 1468 discovery request option (Section 5.3) is specified for the CCNinfo 1469 Request, several Reply messages may be returned and cause a response 1470 storm. (See Section 10.8 for rate-limiting to avoid the storm). To 1471 avoid DoS attacks, routers MAY configure the timeout value, which is 1472 shorter than the user-configured CCNinfo timeout value. However, if 1473 it is too short, the Request may be timed out and the CCNinfo user 1474 does not receive all Replies; s/he only retrieves the partial path 1475 information (i.e., information about a part of the tree). 1477 There may be a way to enable incremental exploration (i.e., to 1478 explore the part of the tree that was not explored by the previous 1479 operation); however, discussing such mechanisms is out of scope of 1480 this document. 1482 10.7. Limiting Request Rates 1484 A router MAY rate-limit CCNinfo Requests by ignoring some of the 1485 consecutive messages. The router MAY randomly ignore the received 1486 messages to minimize the processing overhead, i.e., to keep fairness 1487 in processing requests, or prevent traffic amplification. In such a 1488 case, no error message is returned. The rate limit function is left 1489 to the router's implementation. 1491 10.8. Limiting Reply Rates 1493 CCNinfo supporting multipath forwarding may result in one Request 1494 returning multiple Reply messages. To prevent abuse, the routers in 1495 the traced path MAY need to rate-limit the Replies. In such a case, 1496 no error message is returned. The rate limit function is left to the 1497 router's implementation. 1499 10.9. Adjacency Verification 1501 It is assumed that the CCNinfo Request and Reply messages are 1502 forwarded by adjacent neighbor nodes or routers. The CCNx message 1503 format or semantics do not define a secure way to verify the node/ 1504 router adjacency, while HopAuth [10] provides a possible method for 1505 an adjacency verification and defines the corresponding message 1506 format for adjacency verification as well as the router behaviors. 1507 CCNinfo MAY use a similar method for node adjacency verification. 1509 11. Acknowledgements 1511 The authors would like to thank Spyridon Mastorakis, Paulo Mendes, 1512 Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable 1513 comments and suggestions on this document. 1515 12. References 1517 12.1. Normative References 1519 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1520 Format", RFC 8609, July 2019. 1522 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1523 RFC 8569, July 2019. 1525 [3] Bradner, S., "Key words for use in RFCs to Indicate 1526 Requirement Levels", BCP 14, RFC 2119, 1527 DOI 10.17487/RFC2119, March 1997, 1528 . 1530 [4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1531 2119 Key Words", May 2017, 1532 . 1534 [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1535 Writing an IANA Considerations Section in RFCs", BCP 26, 1536 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1537 . 1539 12.2. Informative References 1541 [6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1542 Tool for Measuring and Tracing Content-Centric Networks", 1543 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1544 March 2015. 1546 [7] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1547 D. Oran, "ICN Ping Protocol Specification", draft-irtf- 1548 icnrg-icnping-01 (work in progress), October 2020. 1550 [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1551 D. Oran, "ICN Traceroute Protocol Specification", draft- 1552 irtf-icnrg-icntraceroute-01 (work in progress), October 1553 2020. 1555 [9] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1556 Traceroute Facility for IP Multicast", RFC 8487, October 1557 2018. 1559 [10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in 1560 Content-Centric Networking/Named Data Networking", draft- 1561 li-icnrg-hopauth-02 (work in progress), February 2020. 1563 [11] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive 1564 Caching and Adaptive Retrieval for In-Network Big Data 1565 Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. 1567 [12] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: 1568 Software Platform Enabling Content-Centric Networking and 1569 Beyond", IEICE Transaction on Communications, Vol.E102-B, 1570 No.9, pp.1792-1803, September 2019. 1572 [13] "Cefore Home Page", . 1574 Appendix A. ccninfo Command and Options 1576 CCNinfo is implemented in Cefore [12][13]. "ccninfo" is the command 1577 invoked by the CCNinfo user (e.g., consumer). The ccninfo command 1578 sends the Request message and receives the Reply message(s). There 1579 are several options that can be specified with ccninfo, while the 1580 content name prefix (e.g., ccnx:/news/today) is the mandatory 1581 parameter. 1583 The usage of ccninfo command is as follows: 1585 Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v 1586 algo] name_prefix 1588 name_prefix 1589 Prefix name of content (e.g., ccnx:/news/today) or exact name of 1590 content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants 1591 to trace. 1593 c option 1594 This option can be specified if a CCNinfo user needs the cache 1595 information as well as the routing path information for the 1596 specified content/cache and RTT between the CCNinfo user and 1597 content forwarder. 1599 f option 1600 This option enables the "full discovery request"; routers send 1601 CCNinfo Requests to multiple upstream faces based on their FIBs 1602 simultaneously. The CCNinfo user can then trace all possible 1603 forwarding paths. 1605 o option 1606 This option enables to trace the path to the content publisher. 1607 Each router along the path to the publisher inserts each Report 1608 block and forwards the Request message. It does not send Reply 1609 even if it caches the specified content. FHR that attaches the 1610 publisher (who has the complete set of content and is not a 1611 caching router) sends the Reply message. 1613 V option 1614 This option requests the Reply sender to validate the Reply 1615 message with the Reply sender's signature. The Reply message will 1616 then include the CCNx ValidationPayload TLV. The validation 1617 algorithm is selected by the Reply sender. 1619 r option 1620 Number of traced routers. This value is set in the "HopLimit" 1621 field located in the fixed header of the Request. For example, 1622 when the CCNinfo user invokes the CCNinfo command with this 1623 option, such as "-r 3", only three routers along the path examine 1624 their path and cache information. 1626 s option 1627 Number of skipped routers. This value is set in the "SkipHop" 1628 field located in the Request block TLV. For example, when the 1629 CCNinfo user invokes the CCNinfo command with this option, such as 1630 "-s 3", three upstream routers along the path only forward the 1631 Request message but do not append their Report blocks in the hop- 1632 by-hop header and do not send Reply messages despite having the 1633 corresponding cache. 1635 v option 1636 This option enables the CCNinfo user to validate the Request 1637 message with his/her signature. The Request message will include 1638 the CCNx ValidationPayload TLV. The validation algorithm is 1639 specified by the CCNinfo user. 1641 Authors' Addresses 1643 Hitoshi Asaeda 1644 National Institute of Information and Communications Technology 1645 4-2-1 Nukui-Kitamachi 1646 Koganei, Tokyo 184-8795 1647 Japan 1649 Email: asaeda@nict.go.jp 1650 Atsushi Ooka 1651 National Institute of Information and Communications Technology 1652 4-2-1 Nukui-Kitamachi 1653 Koganei, Tokyo 184-8795 1654 Japan 1656 Email: a-ooka@nict.go.jp 1658 Xun Shao 1659 Kitami Institute of Technology 1660 165 Koen-cho 1661 Kitami, Hokkaido 090-8507 1662 Japan 1664 Email: x-shao@mail.kitami-it.ac.jp