idnits 2.17.1 draft-irtf-icnrg-ccninfo-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 document date (March 11, 2019) is 1873 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: '-f' on line 1346 -- Looks like a reference, but probably isn't: '-n' on line 1346 -- Looks like a reference, but probably isn't: '-o' on line 1346 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '6') (Obsoleted by RFC 6814) Summary: 1 error (**), 0 flaws (~~), 2 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 12, 2019 X. Shao 6 Kitami Institute of Technology 7 March 11, 2019 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-01 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 content forwarder and consumer, and 3) the states of 20 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 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 8 60 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 9 61 3.1.1. Request Block . . . . . . . . . . . . . . . . . . . . 11 62 3.1.2. Report Block . . . . . . . . . . . . . . . . . . . . 13 63 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 14 64 3.2.1. Reply Block . . . . . . . . . . . . . . . . . . . . . 16 65 3.2.1.1. Reply Sub-Block . . . . . . . . . . . . . . . . . 16 66 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 19 67 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 19 68 4.1.1. Routing Path Information . . . . . . . . . . . . . . 20 69 4.1.2. In-Network Cache Information . . . . . . . . . . . . 20 70 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 20 71 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 72 5.1. User and Neighbor Verification . . . . . . . . . . . . . 20 73 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 21 74 5.2.1. Normal Processing . . . . . . . . . . . . . . . . . . 21 75 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 22 76 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 23 77 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 23 78 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 24 79 6.1. Arriving at First-hop router . . . . . . . . . . . . . . 24 80 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 24 81 6.3. Invalid Request . . . . . . . . . . . . . . . . . . . . . 24 82 6.4. No Route . . . . . . . . . . . . . . . . . . . . . . . . 24 83 6.5. No Information . . . . . . . . . . . . . . . . . . . . . 24 84 6.6. No Space . . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.7. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 25 86 6.8. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25 87 6.9. Non-Supported Node . . . . . . . . . . . . . . . . . . . 25 88 6.10. Administratively Prohibited . . . . . . . . . . . . . . . 25 89 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 25 90 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25 91 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 25 92 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 25 93 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 26 94 8.1. Number of Hops . . . . . . . . . . . . . . . . . . . . . 26 95 8.2. Caching Router Identification . . . . . . . . . . . . . . 26 96 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 26 97 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 26 98 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 26 99 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 26 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 9.1. Policy-Based Information Provisioning for Request . . . . 27 102 9.2. Filtering of CCNinfo Users Located in Invalid Networks . 27 103 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28 104 9.4. Characteristics of Content . . . . . . . . . . . . . . . 28 105 9.5. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . . 28 106 9.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 28 107 9.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 28 108 9.8. Adjacency Verification . . . . . . . . . . . . . . . . . 29 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 112 11.2. Informative References . . . . . . . . . . . . . . . . . 29 113 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 30 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 116 1. Introduction 118 In Content-Centric Networks (CCN), publishers provide content through 119 the network, and receivers retrieve content by name. In this network 120 architecture, routers forward content requests by means of their 121 Forwarding Information Bases (FIBs), which are populated by name- 122 based routing protocols. CCN also enables receivers to retrieve 123 content from an in-network cache. 125 In CCN, while consumers do not generally need to know which content 126 forwarder is transmitting the content to them, operators and 127 developers may want to identify the content forwarder and observe the 128 routing path information per name prefix for troubleshooting or 129 investigating the network conditions. 131 Traceroute [6] is a useful tool for discovering the routing 132 conditions in IP networks as it provides intermediate router 133 addresses along the path between source and destination and the 134 Round-Trip Time (RTT) for the path. However, this IP-based network 135 tool cannot trace the name prefix paths used in CCN. Moreover, such 136 IP-based network tool does not obtain the states of the in-network 137 cache to be discovered. 139 This document describes the specification of "CCNinfo", an active 140 networking tool for discovering the path and content caching 141 information in CCN. CCNinfo is designed based on the work previously 142 published in [5]. 144 CCNinfo can be implemented with the ccninfo user command and the 145 forwarding function implementation on a content forwarder (e.g., 146 router). The CCNinfo user (e.g., consumer) invokes the ccninfo 147 command (described in Appendix A) with the name prefix of the 148 content. The ccninfo command initiates the "Request" message 149 (described in Section 3.1). The Request message, for example, 150 obtains routing path and cache information. When an appropriate 151 adjacent neighbor router receives the Request message, it retrieves 152 cache information. If the router is not the content forwarder for 153 the request, it inserts its "Report" block (described in 154 Section 3.1.2) into the Request message and forwards the Request 155 message to its upstream neighbor router(s) decided by its FIB. These 156 two message types, Request and Reply messages, are encoded in the 157 CCNx TLV format [1]. 159 In this way, the Request message is forwarded by routers toward the 160 content publisher, and the Report record is inserted by each 161 intermediate router. When the Request message reaches the content 162 forwarder (i.e., a router who can forward the specified cache or 163 content), the content forwarder forms the "Reply" message (described 164 in Section 3.2) and sends it to the downstream neighbor router. The 165 Reply message is forwarded back toward the user in a hop-by-hop 166 manner. This request-reply message flow, walking up the tree from a 167 consumer toward a publisher, is similar to the behavior of the IP 168 multicast traceroute facility [7]. 170 CCNinfo supports multipath forwarding. The Request messages can be 171 forwarded to multiple neighbor routers. When the Request messages 172 forwarded to multiple routers, the different Reply messages will be 173 forwarded from different routers or publisher. 175 1. Request 2. Request 3. Request 176 (+U) (U+A) (U+A+B) 177 +----+ +----+ +----+ 178 | | | | | | 179 | v | v | v 180 +--------+ +--------+ +--------+ +--------+ +---------+ 181 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 182 | user | | A | | B | | C | | | 183 +--------+ +--------+ +--------+ +--------+ +---------+ 184 \ 185 \ +-------+ 186 3. Request \ | Cache | 187 (U+A+B) \ +---------+ | 188 v| Caching |----+ 189 | router | 190 +---------+ 192 Figure 1: Request messages forwarded by consumer and routers. 193 CCNinfo user and routers (i.e., Router A,B,C) insert their own Report 194 blocks into the Request message and forward the message toward the 195 content forwarder (i.e., caching router and publisher) 197 3. Reply(P) 2. Reply(P) 1. Reply(P) 198 +----+ +----+ +----+ 199 | | | | | | 200 v | v | v | 201 +--------+ +--------+ +--------+ +--------+ +---------+ 202 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 203 | user | | A | | B | | C | | | 204 +--------+ +--------+ +--------+ +--------+ +---------+ 205 ^ 206 \ +-------+ 207 1. Reply(C) \ | Cache | 208 \ +---------+ | 209 \| Caching |----+ 210 | router | 211 +---------+ 213 Figure 2: Default behavior. Reply messages forwarded by routers. 214 Each router forwards the Reply message along its PIT entry, and 215 finally the CCNinfo user receives a Reply message from Router C, 216 which is the first-hop router for Publisher. Another Reply message 217 from Caching router is discarded at Router B as the corresponding 218 Reply message was already forwarded. 220 3. Reply(C) 2. Reply(C) 221 3. Reply(P) 2. Reply(P) 1. Reply(P) 222 +----+ +----+ +----+ 223 | | | | | | 224 v | v | v | 225 +--------+ +--------+ +--------+ +--------+ +---------+ 226 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 227 | user | | A | | B | | C | | | 228 +--------+ +--------+ +--------+ +--------+ +---------+ 229 ^ 230 \ +-------+ 231 1. Reply(C) \ | Cache | 232 \ +---------+ | 233 \| Caching |----+ 234 | router | 235 +---------+ 237 Figure 3: Full discovery request. Reply messages forwarded by 238 publisher and routers. Each router forwards the Reply message along 239 its PIT entry, and finally the CCNinfo user receives two Reply 240 messages: one from the first-hop router and the other from the 241 caching router. 243 CCNinfo facilitates the tracing of a routing path and provides: 1) 244 the RTT between content forwarder (i.e., caching router or first-hop 245 router) and consumer, 2) the states of in-network cache per name 246 prefix, and 3) the routing path information per name prefix. 248 In addition, CCNinfo identifies the states of the cache, such as the 249 following metrics for Content Store (CS) in the content forwarder: 1) 250 size of the cached content objects, 2) number of the cached content 251 objects, 3) number of the accesses (i.e., received Interests) per 252 content, and 4) elapsed cache time and remain cache lifetime of 253 content. 255 Furthermore, CCNinfo implements policy-based information provisioning 256 that enables administrators to "hide" secure or private information, 257 but does not disrupt the forwarding of messages. This policy-based 258 information provisioning reduces the deployment barrier faced by 259 operators in installing and running CCNinfo on their routers. 261 2. Terminology 263 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 264 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 265 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3], 266 and indicate requirement levels for compliant CCNinfo 267 implementations. 269 2.1. Definitions 271 Since CCNinfo requests flow in the opposite direction to the data 272 flow, we refer to "upstream" and "downstream" with respect to data, 273 unless explicitly specified. 275 Router 276 It is a router facilitating CCN-based content retrieval in the 277 path between consumer and publisher. 279 Scheme name 280 It indicates a URI and protocol. This document only considers 281 "ccn:/" as the scheme name. 283 Prefix name 284 A prefix name, which is defined in [2], is a name that does not 285 uniquely identify a single content object, but rather a namespace 286 or prefix of an existing content object name. 288 Exact name 289 An exact name, which is defined in [2], is one which uniquely 290 identifies the name of a content object. 292 Node 293 It is a router, publisher, or consumer. 295 Content forwarder 296 It is either a caching router or a first-hop router that forwards 297 content objects to consumers. 299 CCNinfo user 300 It is a node that invokes the ccninfo command and initiates the 301 CCNinfo Request. 303 Incoming face 304 The face on which data is expected to arrive from the specified 305 name prefix. 307 Outgoing face 308 The face to which data from the publisher or router is expected to 309 transmit for the specified name prefix. It is also the face on 310 which the Request messages are received. 312 Upstream router 313 The router, connecting to the Incoming face of a router, which is 314 responsible for forwarding data for the specified name prefix to 315 the router. 317 First-hop router (FHR) 318 The router that is directly connected to the publisher. 320 Last-hop router (LHR) 321 The router that is directly connected to the consumers. 323 3. CCNinfo Message Formats 325 CCNinfo uses two message types: Request and Reply. Both messages are 326 encoded in the CCNx TLV format ([1], Figure 4). The Request message 327 consists of a fixed header, Request block TLV Figure 8, and Report 328 block TLV(s) Figure 11. The Reply message consists of a fixed 329 header, Request block TLV, Report block TLV(s), and Reply block/sub- 330 block TLV(s) Figure 14. 332 1 2 3 333 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 334 +---------------+---------------+---------------+---------------+ 335 | Version | PacketType | PacketLength | 336 +---------------+---------------+---------------+---------------+ 337 | PacketType specific fields | HeaderLength | 338 +---------------+---------------+---------------+---------------+ 339 / Optional Hop-by-hop header TLVs / 340 +---------------+---------------+---------------+---------------+ 341 / PacketPayload TLVs / 342 +---------------+---------------+---------------+---------------+ 343 / Optional CCNx ValidationAlgorithm TLV / 344 +---------------+---------------+---------------+---------------+ 345 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 346 +---------------+---------------+---------------+---------------+ 348 Figure 4: Packet format [1] 350 The Request and Reply Type values in the fixed header are PT_REQUEST 351 and PT_REPLY, respectively (Figure 5). These messages are forwarded 352 in a hop-by-hop manner. When the Request message reaches the content 353 forwarder, the content forwarder turns the Request message into a 354 Reply message by changing the Type field value in the fixed header 355 from PT_REQUEST to PT_REPLY and forwards back to the node that has 356 initiated the Request message. 358 Code Type name 359 ======== ===================== 360 %x00 PT_INTEREST [1] 361 %x01 PT_CONTENT [1] 362 %x02 PT_RETURN [1] 363 %x03 PT_REQUEST 364 %x04 PT_REPLY 366 Figure 5: Packet Type Namespace 368 The CCNinfo Request and Reply messages MUST begin with a fixed header 369 with either a Request or Reply type value to specify whether it is a 370 Request message or Reply message. Following a fixed header, there 371 can be a sequence of optional hop-by-hop header TLV(s) for a Request 372 message. In the case of a Request message, it is followed by a 373 sequence of Report blocks, each from a router on the path toward the 374 publisher or caching router. 376 At the beginning of PacketPayload TLVs, one top-level TLV type, 377 T_DISCOVERY (Figure 6), exists at the outermost level of a CCNx 378 protocol message. This TLV indicates that the Name segment TLV(s) 379 and Reply block TLV(s) would follow in the Request or Reply message. 381 Code Type name 382 ============= ========================= 383 %x0000 Reserved [1] 384 %x0001 T_INTEREST [1] 385 %x0002 T_OBJECT [1] 386 %x0003 T_VALIDATION_ALG [1] 387 %x0004 T_VALIDATION_PAYLOAD [1] 388 %x0005 T_DISCOVERY 390 Figure 6: Top-Level Type Namespace 392 3.1. Request Message 394 When a CCNinfo user initiates a discovery request (e.g., by ccninfo 395 command described in Appendix A), a CCNinfo Request message is 396 created and forwarded to its upstream router through the Incoming 397 face(s) determined by its FIB. 399 The Request message format is as shown in Figure 7. It consists of a 400 fixed header, Request block TLV (Figure 8), Report block TLV(s) 401 (Figure 11), and Name TLV. The Type value of Top-Level type 402 namespace is T_DISCOVERY (Figure 6). The Type value for the Report 403 message is PT_REQUEST. 405 1 2 3 406 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 407 +---------------+---------------+---------------+---------------+ 408 | Version | PacketType | PacketLength | 409 +---------------+---------------+---------------+---------------+ 410 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 411 +===============+===============+===============+===============+ 412 | | 413 + Request block TLV + 414 | | 415 +---------------+---------------+---------------+---------------+ 416 / Report block TLV 1 / 417 +---------------+---------------+---------------+---------------+ 418 / Report block TLV 2 / 419 +---------------+---------------+---------------+---------------+ 420 / . / 421 / . / 422 +---------------+---------------+---------------+---------------+ 423 / Report block TLV n / 424 +===============+===============+===============+===============+ 425 | T_DISCOVERY | MessageLength | 426 +---------------+---------------+---------------+---------------+ 427 | T_NAME | Length | 428 +---------------+---------------+---------------+---------------+ 429 / Name segment TLVs (name prefix specified by ccninfo command) / 430 +---------------+---------------+---------------+---------------+ 432 Figure 7: Request message consists of a fixed header, Request block 433 TLV, Report block TLV(s), and Name TLV 435 HopLimit: 8 bits 437 HopLimit is a counter that is decremented with each hop whenever a 438 Request packet is forwarded. It limits the distance a Request may 439 travel on the network. 441 ReturnCode: 8 bits 443 ReturnCode is used for the Reply message. This value is replaced 444 by the content forwarder when the Request message is returned as 445 the Reply message (see Section 3.2). Until then, this field MUST 446 be transmitted as zeros and ignored on receipt. 448 Value Name Description 449 ----- --------------- ---------------------------------------------- 450 %x00 NO_ERROR No error 451 %x01 WRONG_IF CCNinfo Request arrived on an interface 452 to which this router would not forward for 453 the specified name/function toward the 454 publisher. 455 %x02 INVALID_REQUEST Invalid CCNinfo Request is received. 456 %x03 NO_ROUTE This router has no route for the name prefix 457 and no way to determine a potential route. 458 %x04 NO_INFO This router has no cache information for the 459 specified name prefix. 460 %x05 NO_SPACE There was not enough room to insert another 461 Report block in the packet. 462 %x06 INFO_HIDDEN Information is hidden from this discovery 463 because of some policy. 464 %x0E ADMIN_PROHIB CCNinfo Request is administratively 465 prohibited. 466 %x0F UNKNOWN_REQUEST This router does not support/recognize the 467 Request message. 468 %x80 FATAL_ERROR A fatal error is one where the router may 469 know the upstream router but cannot forward 470 the message to it. 472 Reserved (MBZ): 8 bits 474 The reserved fields in the Value field MUST be transmitted as 475 zeros and ignored on receipt. 477 3.1.1. Request Block 479 When a CCNinfo user transmits the Request message, it MUST insert the 480 Request block TLV (Figure 8) and the Report block TLV (Figure 11) of 481 its own to the Request message before sending it through the Incoming 482 face(s). 484 1 2 3 485 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 486 +---------------+---------------+---------------+---------------+ 487 | T_DISC_REQ | Length | 488 +---------------+---------------+---------------+---------+-+-+-+ 489 | Request ID | SkipHopCount | Flags |F|O|C| 490 +---------------+---------------+---------------+---------+-+-+-+ 491 | Request Arrival Time | 492 +---------------+---------------+---------------+---------------+ 493 / Node Identifier / 494 +---------------+---------------+---------------+---------------+ 496 Figure 8: Request block TLV (hop-by-hop header) 498 Code Type name 499 ============= ========================= 500 %x0000 Reserved [1] 501 %x0001 T_INTLIFE [1] 502 %x0002 T_CACHETIME [1] 503 %x0003 T_MSGHASH [1] 504 %x0004-%x0007 Reserved [1] 505 %x0008 T_DISC_REQ 506 %x0009 T_DISC_REPORT 507 %x0FFE T_PAD [1] 508 %x0FFF T_ORG [1] 509 %x1000-%x1FFF Reserved [1] 511 Figure 9: Hop-by-Hop Type Namespace 513 Type: 16 bits 515 Format of the Value field. For the single Request block TLV, the 516 type value MUST be T_DISC_REQ. For all the available types for 517 hop-by-hop type namespace, please see Figure 9. 519 Length: 16 bits 521 Length of Value field in octets. 523 Request ID: 16 bits 525 This field is used as a unique identifier for this CCNinfo Request 526 so that duplicate or delayed Reply messages can be detected. 528 SkipHopCount: 8 bits 529 Number of skipped routers for a Request. This value MUST be lower 530 than the value of HopLimit at the fixed header. 532 Flags: 16 bits 534 Flags field is used to indicate the types of the content or path 535 discoveries. Currently, as shown in Figure 10, three bits, "C", 536 "O", and "F", are assigned, and the other 5 bits are reserved 537 (MBZ) for the future use. These flags are set by CCNinfo users 538 when they initiate Requests (see Appendix A), and routers that 539 receive the Requests deal with the flags and change the behaviors 540 (see Section 5 for details). 542 Flag Value Description 543 ----- ----- ---------------------------------------------------- 544 C 0 Path discovery (i.e., no cache information retried) 545 C 1 Cache information retrieval (default) 546 O 0 Request to any content forwarder (default) 547 O 1 Publisher reachability (i.e., only FHR can reply) 548 F 0 Request based on FIB's strategy (default) 549 F 1 Full discovery request. Request to multiple upstream 550 routers simultaneously 552 Figure 10: Codes and types specified in Flags field 554 3.1.2. Report Block 556 A CCNinfo user and each upstream router along the path would insert 557 its own Report block TLV without changing the Type field of the fixed 558 header of the Request message until one of these routers is ready to 559 send a Reply. In the Report block TLV (Figure 11), the Request 560 Arrival Time and the Node Identifier MUST be inserted. 562 1 2 3 563 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 564 +---------------+---------------+---------------+---------------+ 565 | T_DISC_REPORT | Length | 566 +---------------+---------------+---------------+---------------+ 567 | Request Arrival Time | 568 +---------------+---------------+---------------+---------------+ 569 / Node Identifier / 570 +---------------+---------------+---------------+---------------+ 572 Figure 11: Report block TLV (hop-by-hop header) 574 Type: 16 bits 575 Format of the Value field. For the Report block TLV, the type 576 value(s) MUST be T_DISC_REPORT in the current specification. 578 Length: 16 bits 580 Length of Value field in octets. 582 Request Arrival Time: 32 bits 584 The Request Arrival Time is a 32-bit NTP timestamp specifying the 585 arrival time of the CCNinfo Request packet at this router. The 586 32-bit form of an NTP timestamp consists of the middle 32 bits of 587 the full 64-bit form; that is, the low 16 bits of the integer part 588 and the high 16 bits of the fractional part. 590 The following formula converts from a UNIX timeval to a 32-bit NTP 591 timestamp: 593 request_arrival_time 594 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 596 The constant 32384 is the number of seconds from Jan 1, 1900 to 597 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 598 is a reduction of ((tv.tv_nsec / 1000000000) << 16). 600 Note that it is RECOMMENDED that all the routers on the path to 601 have synchronized clocks; however, if they do not have 602 synchronized clocks, CCNinfo measures one-way latency. 604 Node Identifier: variable length 606 This field specifies the CCNinfo user or the router identifier 607 (e.g., IPv4 address) of the Incoming face on which packets from 608 the publisher are expected to arrive, or all-zeros if unknown or 609 unnumbered. Since we may not always rely on the IP addressing 610 architecture, it would be necessary to define the identifier 611 uniqueness (e.g., by specifying the protocol family) for this 612 field. However, defining such uniqueness is out of scope of this 613 document. Potentially, this field may be defined as a new TLV 614 based on the CCNx TLV format [1]. 616 3.2. Reply Message 618 When a content forwarder receives a CCNinfo Request message from the 619 appropriate adjacent neighbor router, it would insert a Reply block 620 TLV and Reply sub-block TLV(s) of its own to the Request message and 621 turn the Request into the Reply by changing the Type field of the 622 fixed header of the Request message from PT_REQUEST to PT_REPLY. The 623 Reply message (see Figure 12) would then be forwarded back toward the 624 CCNinfo user in a hop-by-hop manner. 626 1 2 3 627 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 628 +---------------+---------------+---------------+---------------+ 629 | Version | PacketType | PacketLength | 630 +---------------+---------------+-------------+-+---------------+ 631 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 632 +===============+===============+=============+=+===============+ 633 | | 634 + Request block TLV + 635 | | 636 +---------------+---------------+---------------+---------------+ 637 / . / 638 / . / 639 / n Report block TLVs / 640 / . / 641 / . / 642 +===============+===============+===============+===============+ 643 | T_DISCOVERY | MessageLength | 644 +---------------+---------------+---------------+---------------+ 645 | T_NAME | Length | 646 +---------------+---------------+---------------+---------------+ 647 / Name segment TLVs (name prefix specified by ccninfo command) / 648 +---------------+---------------+---------------+---------------+ 649 / Reply block TLV / 650 +---------------+---------------+---------------+---------------+ 651 / Reply sub-block TLV 1 / 652 +---------------+---------------+---------------+---------------+ 653 / Reply sub-block TLV 2 / 654 +---------------+---------------+---------------+---------------+ 655 / . / 656 / . / 657 +---------------+---------------+---------------+---------------+ 658 / Reply sub-block TLV k / 659 +---------------+---------------+---------------+---------------+ 661 Figure 12: Reply message consists of a fixed header, Request block 662 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 663 Code Type name 664 ============== =================== 665 %x0000 T_NAME [1] 666 %x0001 T_PAYLOAD [1] 667 %x0002 T_KEYIDRESTR [1] 668 %x0003 T_OBJHASHRESTR [1] 669 %x0005 T_PAYLDTYPE [1] 670 %x0006 T_EXPIRY [1] 671 %x0007 T_DISC_REPLY 672 %x0008-%x0012 Reserved [1] 673 %x0FFE T_PAD [1] 674 %x0FFF T_ORG [1] 675 %x1000-%x1FFF Reserved [1] 677 Figure 13: CCNx Message Type Namespace 679 3.2.1. Reply Block 681 The Reply block TLV is an envelope for Reply sub-block TLV(s) 682 (explained in Section 3.2.1.1). 684 1 2 3 685 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 686 +---------------+---------------+---------------+---------------+ 687 | T_DISC_REPLY | Length | 688 +---------------+---------------+---------------+---------------+ 690 Figure 14: Reply block TLV (packet payload) 692 Type: 16 bits 694 Format of the Value field. For the Reply block TLV, the type 695 value MUST be T_DISC_REPLY in the current specification. 697 Length: 16 bits 699 Length of Value field in octets. This length is a total length of 700 Reply sub-block(s). 702 3.2.1.1. Reply Sub-Block 704 In addition to the Reply block, a router on the traced path will add 705 one or multiple Reply sub-blocks followed by the Reply block before 706 sending the Reply to its neighbor router. 708 The Reply sub-block is flexible for various purposes. For instance, 709 operators and developers may want to obtain various characteristics 710 of content such as content's ownership and copyright, or other cache 711 states and conditions. In this document, Reply sub-block TLVs for 712 T_DISC_CONTENT and T_DISC_CONTENT_OWNER (Figure 15) are defined; 713 other Reply sub-block TLVs will be defined in separate document(s). 715 1 2 3 716 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 717 +---------------+---------------+---------------+---------------+ 718 | Type | Length | 719 +---------------+---------------+---------------+---------------+ 720 | Object Size | 721 +---------------+---------------+---------------+---------------+ 722 | Object Count | 723 +---------------+---------------+---------------+---------------+ 724 | # Received Interest | 725 +---------------+---------------+---------------+---------------+ 726 | First Seqnum | 727 +---------------+---------------+---------------+---------------+ 728 | Last Seqnum | 729 +---------------+---------------+---------------+---------------+ 730 | Elapsed Cache Time | 731 +---------------+---------------+---------------+---------------+ 732 | Remain Cache Lifetime | 733 +---------------+---------------+---------------+---------------+ 734 | T_NAME | Length | 735 +---------------+---------------+---------------+---------------+ 736 / Name Segment TLVs / 737 +---------------+---------------+---------------+---------------+ 739 Figure 15: Reply sub-block TLV for T_DISC_CONTENT and 740 T_DISC_CONTENT_OWNER (packet payload) 742 Code Type name 743 ============= =========================== 744 %x0000 T_DISC_CONTENT 745 %x0001 T_DISC_CONTENT_OWNER 746 %x0FFF T_ORG 747 %x1000-%x1FFF Reserved (Experimental Use) 749 Figure 16: CCNinfo Reply Type Namespace 751 Type: 16 bits 753 Format of the Value field. For the Reply sub-block TLV, the type 754 value MUST be one of the type value defined in the CCNinfo Reply 755 Type Namespace (Figure 16). T_DISC_CONTENT is specified when the 756 cache information is replied from a caching router. 757 T_DISC_CONTENT_OWNER is specified when the content information is 758 replied from a FHR attached to a publisher. 760 Length: 16 bits 762 Length of Value field in octets. 764 Object Size: 32 bits 766 The total size (byte) of the (cached) content objects. Note that 767 the maximum size expressed by 32 bit field is about 4.29 GB. This 768 value MAY be null when FHR sends the Reply message. 770 Object Count: 32 bits 772 The number of the (cached) content objects. Note that the maximum 773 count expressed by 32 bit field is about 4.29 billion. This value 774 MAY be null when FHR sends the Reply message. 776 # Received Interest: 32 bits 778 The total number of the received Interest messages to retrieve the 779 cached content objects. 781 First Seqnum: 32 bits 783 The first sequential number of the (cached) content objects. This 784 value MAY be null if the router does not know or cannot report. 786 Last Seqnum: 32 bits 788 The last sequential number of the (cached) content objects. Above 789 First Seqnum and this Last Seqnum do not guarantee the 790 consecutiveness of the cached content objects. This value MAY be 791 null if the router does not know or cannot report. 793 Elapsed Cache Time: 32 bits 795 The elapsed time (seconds) after the oldest content object of the 796 content is cached. This value MAY be null if the router does not 797 know or cannot report. 799 Remain Cache Lifetime: 32 bits 801 The lifetime (seconds) of a content object, which is removed first 802 among the cached content objects. This value MAY be null if the 803 router does not know or cannot report. 805 Specification of the Name TLV (whose type value is T_NAME) and the 806 Name Segment TLVs are described in [1], and CCNinfo follows that 807 specification. CCNinfo also allows to specify the content name 808 either with a prefix name (such as "ccn:/news/today") or an exact 809 name (such as "ccn:/news/today/Chunk=10"). When a CCNinfo user 810 specifies a prefix name, s/he will obtain the information of the 811 matched content objects in the content forwarder. On the other hand, 812 when a CCNinfo user specifies an exact name, s/he will obtain only 813 about the specified content object in the content forwarder. 815 4. CCNinfo User Behavior 817 4.1. Sending CCNinfo Request 819 The CCNinfo user's program (e.g., ccninfo command) enables user to 820 obtain both the routing path information and in-network cache 821 information in a same time. 823 A CCNinfo user initiates a CCNinfo Request by sending the Request 824 message to the adjacent neighbor router(s) of interest. As a typical 825 example, a CCNinfo user invokes the ccninfo command (detailed in 826 Appendix A) that forms a Request message and sends it to the user's 827 adjacent neighbor router(s). 829 When the CCNinfo user's program initiates a Request message, it MUST 830 insert the necessary values, the "Request ID" (in the Request block) 831 and the "Node Identifier" (in the Report block), in the Request and 832 Report blocks. The Request ID MUST be unique for the CCNinfo user 833 until s/he receives the corresponding Reply message(s) or times out 834 the Request. 836 Because of some policy, a router needs to validate CCNinfo Requests 837 (whether it accepts the Request or not) especially when the router 838 receives the "full discovery request" (see Section 5.3). To support 839 this requirement, the CCNinfo user's program MAY require appending 840 the user's signature into the CCNx ValidationPayload TLV. The router 841 then forwards the Request message or reply the Reply message whenever 842 it approves the Request. 844 After the CCNinfo user's program sends the Request message, until the 845 Reply times out or the expected numbers of Replies or a Reply message 846 having a non-zero ReturnCode in the fixed header is received, the 847 CCNinfo user's program MUST keep the following information; Request 848 ID and Flags specified in the Request block, Node Identifier and 849 Request Arrival Time specified in the Report block, and HopLimit 850 specified in the fixed header. 852 4.1.1. Routing Path Information 854 A CCNinfo user can send a CCNinfo Request for investigating routing 855 path information for the specified named content. By the Request, 856 the legitimate user can obtain; 1) identifiers (e.g., IP addresses) 857 of intermediate routers, 2) identifier of content forwarder, 3) 858 number of hops between content forwarder and consumer, and 4) RTT 859 between content forwarder and consumer, per name prefix. This 860 CCNinfo Request is terminated when it reaches the content forwarder. 862 4.1.2. In-Network Cache Information 864 A CCNinfo user can send a CCNinfo Request for investigating in- 865 network cache information. By the Request, the legitimate user can 866 obtain; 1) size of the cached content objects, 2) number of the 867 cached content objects, 3) number of the accesses (i.e., received 868 Interests) per content, and 4) lifetime and expiration time of the 869 cached content object, for Content Store (CS) in the content 870 forwarder. This CCNinfo Request is terminated when it reaches the 871 content forwarder. 873 4.2. Receiving CCNinfo Reply 875 A CCNinfo user's program will receive one or multiple CCNinfo Reply 876 messages from the adjacent neighbor router that has previously 877 received and forwarded the Request message(s). When the program 878 receives the Reply, it MUST compare the kept Request ID and Node 879 Identifier and the ones noted in the Request block TLV in the Reply. 880 If they do not match, the Reply message MUST be silently discarded. 882 If the number of the Report blocks in the received Reply is more than 883 the initial HopLimit value (which was inserted in the original 884 Request), the Reply MUST be silently ignored. 886 After the CCNinfo user has determined that s/he has traced the whole 887 path or as much as s/he can expect to, s/he might collect statistics 888 by waiting a timeout. Useful statistics provided by CCNinfo can be 889 seen in Section 8. 891 5. Router Behavior 893 5.1. User and Neighbor Verification 895 Upon receiving a CCNinfo Request message, a router MAY examine 896 whether the message comes from a valid CCNinfo user. If the router 897 recognizes that the Request sender's signature specified in the 898 Request is invalid, it terminates the Request as defined in 899 Section 6.3. 901 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 902 whether the message comes from a valid adjacent neighbor node. If 903 the router recognizes that the Request/Reply sender is invalid, the 904 Request/Reply message MUST be silently ignored. See Section 9.8. 906 5.2. Receiving CCNinfo Request 908 5.2.1. Normal Processing 910 After the CCNinfo Request message verification, the router performs 911 the following steps. 913 1. The value of the "HopLimit" in the fixed header and the value of 914 the "SkipHopCount" in the Request block are counters that are 915 decremented with each hop. If the HopLimit value is zero, the 916 router terminates the Request as defined in Section 6.4. If the 917 SkipHopCount value is equal or more than the HopLimit value, the 918 router terminates the Request as defined in Section 6.3. 919 Otherwise, until the SkipHopCount value becomes zero, the router 920 forwards the Request message to the upstream router(s) without 921 adding its own Report block and without replying the Request. If 922 the router does not know the upstream router(s) for the specified 923 name prefix, it terminates the Request as defined in Section 6.4. 925 2. The router examines the Flags field (specified in Figure 10) in 926 the Request block of received CCNinfo Request. If the "C" flag 927 is set but the "O" flag is not set, that is categorized as the 928 "cache information discovery". If both the "C" and "O" flags are 929 not set, that is categorized as the "routing path information 930 discovery". If "O" flag is set, that is categorized as the 931 "publisher discovery". 933 3. If the Request is either the "cache information discovery" or the 934 "routing path information discovery", the router examines its FIB 935 and CS. If the router caches the specified content, it inserts 936 own Report block in the hop-by-hop header, and sends the Reply 937 message with own Reply block and sub-block(s) (in case of cache 938 information discovery) or sends the Reply message with own Reply 939 block without adding any Reply sub-block (in case of routing path 940 information discovery). If the router does not cache the 941 specified content but knows the upstream neighbor router(s) for 942 the specified name prefix, it inserts own Report block and 943 forwards the Request to the upstream neighbor(s). If the router 944 does not cache the specified content and does not know the 945 upstream neighbor router(s) for the specified name prefix, it 946 terminates the Request as defined in Section 6.4. 948 4. If the Request is the "publisher discovery", the router examines 949 whether it is the FHR for the requested content. If it is the 950 FHR, it sends the Reply message with own Report block and sub- 951 block. If the router is not the FHR but knows the upstream 952 neighbor router(s) for the specified name prefix, it adds the own 953 Report block and forwards the Request to the neighbor(s). If the 954 node is not the FHR and does not know the upstream neighbor 955 router(s) for the specified name prefix, it terminates the 956 Request as defined in Section 6.4. 958 5.3. Forwarding CCNinfo Request 960 When a router decides to forward a Request message with its Report 961 block to its upstream router(s), it specifies the Request Arrival 962 Time and Node Identifier in the Report block of the Request message. 963 The router then forwards the Request message upstream toward the 964 publisher or caching router based on the FIB entry. 966 When the router forwards the Request message, it MUST record the 967 Request ID, the F flag, and the Node Identifier specified in the 968 Request block at the corresponding PIT entry. The router can later 969 check the PIT entry to correctly forward back the Reply message(s). 970 (See below.) 972 CCNinfo supports multipath forwarding. The Request messages can be 973 forwarded to multiple neighbor routers. Some router may have 974 strategy for multipath forwarding; when it sends Interest messages to 975 multiple neighbor routers, it may delay or prioritize to send the 976 message to the upstream routers. The CCNinfo Request, as the 977 default, complies with such strategy; a CCNinfo user could trace the 978 actual forwarding path based on the forwarding strategy. 980 On the other hand, there may be the case that a CCNinfo user wants to 981 discover all potential forwarding paths based on routers' FIBs. The 982 "full discovery request" enables this function. If a CCNinfo user 983 sets the F flag in the Request block of the Request message (as seen 984 in Figure 10) to request the full discovery, the upstream routers 985 forward the Requests to the all multiple upstream routers based on 986 the FIBs simultaneously. Then the CCNinfo user could trace the all 987 potential forwarding paths. Note that some routers MAY ignore the 988 full discovery request according to their policy. In that case, the 989 router terminates the Request as defined in Section 6.10. 991 When the Request messages forwarded to multiple routers, the 992 different Reply messages will be forwarded from different routers or 993 publisher. To support this case, PIT entries initiated by CCNinfo 994 remain until the configured CCNinfo Reply Timeout (Section 7.1) 995 passes. In other words, unlike the ordinary Interest-Data 996 communications in CCN, the router SHOULD NOT remove the PIT entry 997 created by the CCNinfo Request until the timeout value expires. 999 CCNinfo Requests SHOULD NOT result in PIT aggregation in routers 1000 during the Request message transmission. 1002 5.4. Sending CCNinfo Reply 1004 When a router decides to send a Reply message to its downstream 1005 neighbor router or the CCNinfo user with NO_ERROR return code, it 1006 inserts a Report block having the Request Arrival Time and Node 1007 Identifier to the hop-by-hop TLV header of the Request message. And 1008 then the router inserts the corresponding Reply block with an 1009 appropriate type value (Figure 15) and Reply sub-block(s) to the 1010 payload. The router does not insert any Reply block/sub-block if 1011 there is an error. The router finally changes the Type field in the 1012 fixed header from PT_REQUEST to PT_REPLY and forwards the message 1013 back as the Reply toward the CCNinfo user in a hop-by-hop manner. 1015 If a router cannot continue the Request, it MUST put an appropriate 1016 ReturnCode in the Request message, change the Type field value in the 1017 fixed header from PT_REQUEST to PT_REPLY, and forward the Reply 1018 message back toward the CCNinfo user, to terminate the request. See 1019 Section 6. 1021 5.5. Forwarding CCNinfo Reply 1023 When a router receives a CCNinfo Reply whose Request ID and Node 1024 Identifier match the ones in the PIT entry and sent from a valid 1025 adjacent neighbor router, it forwards the CCNinfo Reply back toward 1026 the CCNinfo user. If the router does not receive the corresponding 1027 Reply within the [CCNinfo Reply Timeout] period, then it removes the 1028 corresponding PIT entry and terminates the trace. 1030 Flags field in the Request block TLV is used to indicate whether the 1031 router keeps the PIT entry during the CCNinfo Reply Timeout even 1032 after one or more corresponding Reply messages are forwarded. When 1033 the CCNinfo user does not set the F flag (i.e., "0"), the 1034 intermediate routers immediately remove the PIT entry whenever they 1035 forward the corresponding Reply message. When the CCNinfo user sets 1036 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1037 "full discovery request", the intermediate routers keep the PIT entry 1038 within the [CCNinfo Reply Timeout] period. After this timeout, the 1039 PIT entry is removed. 1041 CCNinfo Replies MUST NOT be cached in routers upon the Reply message 1042 transmission. 1044 6. CCNinfo Termination 1046 When performing an expanding hop-by-hop trace, it is necessary to 1047 determine when to stop expanding. There are several cases an 1048 intermediate router might return a Reply before a Request reaches the 1049 caching router or the publisher. 1051 6.1. Arriving at First-hop router 1053 A CCNinfo Request can be determined to have arrived at the first-hop 1054 router. 1056 6.2. Arriving at Router Having Cache 1058 A CCNinfo Request can be determined to have arrived at the router 1059 having the specified content cache within the specified HopLimit. 1061 6.3. Invalid Request 1063 If the router does not accept the Request, the router MUST note a 1064 ReturnCode of INVALID_REQUEST in the fixed header of the message and 1065 forward the message without appending any Reply (sub-)block TLV as 1066 the Reply back to the CCNinfo user. The router MAY, however, 1067 randomly ignore the received invalid messages. (See Section 9.6.) 1069 6.4. No Route 1071 If the router cannot determine the routing paths or neighbor routers 1072 for the specified name prefix within the specified HopLimit, the 1073 router MUST note a ReturnCode of NO_ROUTE in the fixed header of the 1074 message and forward the message as the Reply back to the CCNinfo 1075 user. 1077 6.5. No Information 1079 If the router does not have any information about the specified name 1080 prefix within the specified HopLimit, the router MUST note a 1081 ReturnCode of NO_INFO in the fixed header of the message and forward 1082 the message as the Reply back to the CCNinfo user. 1084 6.6. No Space 1086 If appending the Report block would exceed the maximum (i.e., 255 1087 byte) header length or make the CCNinfo Request message longer than 1088 the MTU of the Incoming face or longer than 1280 bytes (especially in 1089 the situation supporting IPv6 as the payload [4]), the router MUST 1090 note a ReturnCode of NO_SPACE in the fixed header of the message and 1091 forward the message as the Reply back to the CCNinfo user. 1093 6.7. Fatal Error 1095 A CCNinfo Request has encountered a fatal error if the last 1096 ReturnCode in the trace has the 0x80 bit set (see Section 3.1). 1098 6.8. CCNinfo Reply Timeout 1100 If a router receives the Request or Reply message that expires its 1101 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1102 silently discard the Request or Reply message. 1104 6.9. Non-Supported Node 1106 Cases will arise in which a router or a publisher along the path does 1107 not support CCNinfo. In such cases, a CCNinfo user and routers that 1108 forward the CCNinfo Request will time out the CCNinfo request. 1110 6.10. Administratively Prohibited 1112 If CCNinfo is administratively prohibited, the router rejects the 1113 Request message and MUST reply the CCNinfo Reply with the ReturnCode 1114 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1115 rejected messages. (See Section 9.6.) 1117 7. Configurations 1119 7.1. CCNinfo Reply Timeout 1121 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1122 Reply. The value for a router can be statically configured by the 1123 router's administrators/operators. The default value is 4 (seconds). 1124 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 5 1125 (seconds) and SHOULD NOT be lower than 2 (seconds). 1127 7.2. HopLimit in Fixed Header 1129 If a CCNinfo user does not specify the HopLimit value in a fixed 1130 header for a Request message as the HopLimit, the HopLimit is set to 1131 32. Note that 0 HopLimit is an invalid Request; hence the router in 1132 this case follows the way defined in Section 6.3. 1134 7.3. Access Control 1136 A router MAY configure the valid or invalid networks to enable an 1137 access control. The access control can be defined per name prefix, 1138 such as "who can retrieve which name prefix". See Section 9.2. 1140 8. Diagnosis and Analysis 1142 8.1. Number of Hops 1144 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1145 each forwarding router appended its own Report block. We can then 1146 verify the number of hops to reach the content forwarder or the 1147 publisher. 1149 8.2. Caching Router Identification 1151 It is possible to identify the routers in the path from the CCNinfo 1152 user to the content forwarder, while some routers may hide their 1153 identifier (e.g., IP address) with all-zeros in the Report blocks 1154 (Section 9.1). 1156 8.3. TTL or Hop Limit 1158 By taking the HopLimit from the content forwarder and forwarding TTL 1159 threshold over all hops, it is possible to discover the TTL or hop 1160 limit required for the content forwarder to reach the CCNinfo user. 1162 8.4. Time Delay 1164 If the routers have synchronized clocks, it is possible to estimate 1165 propagation and queuing delay from the differences between the 1166 timestamps at successive hops. However, this delay includes control 1167 processing overhead, so is not necessarily indicative of the delay 1168 that data traffic would experience. 1170 8.5. Path Stretch 1172 By getting the path stretch "d / P", where "d" is the hop count of 1173 the data and "P" is the hop count from the consumer to the publisher, 1174 we can measure the improvement in path stretch in various cases, such 1175 as different caching and routing algorithms. We can then facilitate 1176 investigation of the performance of the protocol. 1178 8.6. Cache Hit Probability 1180 CCNinfo can show the number of received interests per cache or chunk 1181 on a router. By this, CCNinfo measures the content popularity (i.e., 1182 the number of accesses for each content/cache), and you can 1183 investigate the routing/caching strategy in networks. 1185 9. Security Considerations 1187 This section addresses some of the security considerations. 1189 9.1. Policy-Based Information Provisioning for Request 1191 Although CCNinfo gives excellent troubleshooting cues, some network 1192 administrators or operators may not want to disclose everything about 1193 their network to the public, or may wish to securely transmit private 1194 information to specific members of their networks. CCNinfo provides 1195 policy-based information provisioning allowing network administrators 1196 to specify their response policy for each router. 1198 The access policy regarding "who is allowed to retrieve" and/or "what 1199 kind of information" can be defined for each router. For the former 1200 access policy, routers having the specified content MAY examine the 1201 signature enclosed in the Request message and decide whether they 1202 should notify the content information in the Reply or not. If the 1203 routers decide to not notify the content information, they MUST reply 1204 the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1205 appending any Reply (sub-)block TLV. For the latter policy, the 1206 permission, whether (1) All (all cache information is disclosed), (2) 1207 Partial (cache information with the particular name prefix can (or 1208 cannot) be disclosed), or (3) Deny (no cache information is 1209 disclosed), is defined at routers. 1211 On the other hand, we entail that each router does not disrupt 1212 forwarding CCNinfo Request and Reply messages. When a Request 1213 message is received, the router SHOULD insert Report block if the 1214 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1215 the Node Identifier field in the Report block MAY be null (i.e., all- 1216 zeros), but the Request Arrival Time field SHOULD NOT be null. At 1217 last, the router SHOULD forward the Request message to the upstream 1218 router toward the content forwarder if the ReturnCode is kept with 1219 NO_ERROR. 1221 9.2. Filtering of CCNinfo Users Located in Invalid Networks 1223 A router MAY support an access control mechanism to filter out 1224 Requests from invalid CCNinfo users. For it, invalid networks (or 1225 domains) could, for example, be configured via a list of allowed/ 1226 disallowed networks (as seen in Section 7.3). If a Request is 1227 received from the disallowed network (according to the Node 1228 Identifier in the Request block), the Request MUST NOT be processed 1229 and the Reply with the ReturnCode of INFO_HIDDEN may be used to note 1230 that. The router MAY, however, perform rate-limited logging of such 1231 events. 1233 9.3. Topology Discovery 1235 CCNinfo can be used to discover actively-used topologies. If a 1236 network topology is a secret, CCNinfo Requests SHOULD be restricted 1237 at the border of the domain, using the ADMIN_PROHIB return code. 1239 9.4. Characteristics of Content 1241 CCNinfo can be used to discover what publishers are sending to what 1242 kinds of contents. If this information is a secret, CCNinfo Requests 1243 SHOULD be restricted at the border of the domain, using the 1244 ADMIN_PROHIB return code. 1246 9.5. Longer or Shorter CCNinfo Reply Timeout 1248 Routers can configure the CCNinfo Reply Timeout (Section 7.1), which 1249 is the allowable timeout value to keep the PIT entry. If routers 1250 configure the longer timeout value, there may be an attractive attack 1251 vector against PIT memory. Moreover, especially when the full 1252 discovery request option (Section 5.3) is specified for the CCNinfo 1253 Request, a number of Reply messages may come back and cause a 1254 response storm. (See Section 9.7 for rate limiting to avoid the 1255 storm). In order to avoid DoS attacks, routers may configure the 1256 timeout value, which is shorter than the user-configured CCNinfo 1257 timeout value. However, if it is too short, the Request may be timed 1258 out and the CCNinfo user does not receive the all Replies and only 1259 retrieves the partial path information (i.e., information about part 1260 of the tree). 1262 There may be the way to allow for incremental exploration (i.e., to 1263 explore the part of the tree the previous operation did not explore), 1264 whereas discussing such mechanism is out of scope of this document. 1266 9.6. Limiting Request Rates 1268 A router may limit CCNinfo Requests by ignoring some of the 1269 consecutive messages. The router MAY randomly ignore the received 1270 messages to minimize the processing overhead, i.e., to keep fairness 1271 in processing requests, or prevent traffic amplification. No error 1272 is returned. The rate limit is left to the router's implementation. 1274 9.7. Limiting Reply Rates 1276 CCNinfo supporting multipath forwarding may result in one Request 1277 returning multiple Reply messages. In order to prevent abuse, the 1278 routers in the traced path MAY need to rate-limit the Replies. No 1279 error is returned. The rate limit function is left to the router's 1280 implementation. 1282 9.8. Adjacency Verification 1284 It is assumed that CCNinfo Request and Reply messages are forwarded 1285 by adjacent neighbor nodes or routers. Defining the secure way to 1286 verify the adjacency cannot rely on the way specified in CCNx message 1287 format or semantics, yet specifying the mechanism to validate 1288 adjacent neighbor routers is out of scope of this document. An 1289 adjacency verification mechanism and the corresponding TLV for 1290 adjacency verification using hop-by-hop TLV header such as [8] is the 1291 potential way and will be defined in a separate document. 1293 10. Acknowledgements 1295 The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko, 1296 David Oran, and Thierry Turletti for their valuable comments and 1297 suggestions on this document. 1299 11. References 1301 11.1. Normative References 1303 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1304 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 1305 progress), January 2019. 1307 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1308 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 1309 January 2019. 1311 [3] Bradner, S., "Key words for use in RFCs to indicate 1312 requirement levels", RFC 2119, March 1997. 1314 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1315 (IPv6) Specification", RFC 8200, July 2017. 1317 11.2. Informative References 1319 [5] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1320 Tool for Measuring and Tracing Content-Centric Networks", 1321 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1322 March 2015. 1324 [6] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1325 January 1993. 1327 [7] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1328 Traceroute Facility for IP Multicast", RFC 8487, October 1329 2018. 1331 [8] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 1332 Authentication for Secure In-Network Big-Data Retrieval", 1333 IEEE Transactions on Network Science and Engineering 1334 (TNSE) , October 2018. 1336 Appendix A. ccninfo Command and Options 1338 The ccninfo command enables the CCNinfo user to investigate the 1339 routing path based on the name prefix of the content (e.g., 1340 ccn:/news/today). The name prefix is mandatory but exclusive 1341 options; that is, only one of them should be used with the ccninfo 1342 command at once. 1344 The usage of ccninfo command is as follows: 1346 Usage: ccninfo [-f] [-n] [-o] [-r hop_count] [-s hop_count] 1347 name_prefix 1349 name_prefix 1350 Prefix name of content (e.g., ccn:/news/today) or exact name of 1351 content (e.g., ccn:/news/today/Chunk=10) the CCNinfo user wants to 1352 trace. 1354 f option 1355 This option enables "full discovery request"; routers ignore the 1356 forwarding strategy and send CCNinfo Requests to multiple upstream 1357 routers simultaneously. The CCNinfo user could then trace the all 1358 potential forwarding paths. 1360 n option 1361 This option can be specified if a CCNinfo user only needs the 1362 routing path information to the specified content/cache and RTT 1363 between CCNinfo user and content forwarder; therefore, cache 1364 information is not given. 1366 o option 1367 This option enables to trace the path to the content publisher. 1368 Each router along the path to the publisher inserts each Report 1369 block and forwards the Request message. It does not send Reply 1370 even if it caches the specified content. FHR that attaches the 1371 publisher (who has the complete set of content and is not a 1372 caching router) replies the Reply message. 1374 r option 1375 Number of traced routers. If the CCNinfo user specifies this 1376 option, only the specified number of hops from the CCNinfo user 1377 trace the Request; each router inserts its own Report block and 1378 forwards the Request message to the upstream router(s), and the 1379 last router stops the trace and sends the Reply message back to 1380 the CCNinfo user. This value is set in the "HopLimit" field 1381 located in the fixed header of the Request. For example, when the 1382 CCNinfo user invokes the CCNinfo command with this option such as 1383 "-r 3", only three routers along the path examine their path and 1384 cache information. If there is a caching router or FHR within the 1385 hop count along the path, the caching router or FHR sends back the 1386 Reply message and terminates the trace request. If the last 1387 router does not have the corresponding cache, it replies the Reply 1388 message with NO_INFO return code (described in Section 3.1) with 1389 no Reply block TLV inserted. The Request messages are terminated 1390 at FHR; therefore, although the maximum value for this option a 1391 CCNinfo user can specify is 255, the Request messages should be in 1392 general reached at FHR within significantly lower than 255 hops. 1394 s option 1395 Number of skipped routers. If the CCNinfo user specifies this 1396 option, the number of hops from the CCNinfo user simply forward 1397 the CCNinfo Request messages without adding its own Report block 1398 and without replying the Request, and the next upstream router 1399 starts the trace. This value is set in the "SkipHopCount" field 1400 located in the Request block TLV. For example, when the CCNinfo 1401 user invokes the CCNinfo command with this option such as "-s 3", 1402 the three upstream routers along the path only forwards the 1403 Request message, but does not append their Report blocks in the 1404 hop-by-hop headers and does not send the Reply messages even 1405 though they have the corresponding cache. The Request messages 1406 are terminated at FHR; therefore, although the maximum value for 1407 this option a CCNinfo user can specify is 255, if the Request 1408 messages reaches FHR, the FHR silently discards the Request 1409 message and the request will be timed out. 1411 Authors' Addresses 1413 Hitoshi Asaeda 1414 National Institute of Information and Communications Technology 1415 4-2-1 Nukui-Kitamachi 1416 Koganei, Tokyo 184-8795 1417 Japan 1419 Email: asaeda@nict.go.jp 1420 Atsushi Ooka 1421 National Institute of Information and Communications Technology 1422 4-2-1 Nukui-Kitamachi 1423 Koganei, Tokyo 184-8795 1424 Japan 1426 Email: a-ooka@nict.go.jp 1428 Xun Shao 1429 Kitami Institute of Technology 1430 165 Koen-cho 1431 Kitami, Hokkaido 090-8507 1432 Japan 1434 Email: x-shao@mail.kitami-it.ac.jp